良いSLAを結ぶには？事例を交えて考えてみよう！
はじめに
本記事では、SLAについて解説をするのと、実際のプロジェクトで結んで良いSLAと悪いSLAについて事例を共有します。若手、ITSM向けに解説したものを目指します。筆者が受注者側の立場にいることが多かったため、受注者側に立つような文章が多く目立つと思われますが、発注者側の方にも役立つ内容を提供できればと思います。
SLAとは
SLA（Service Level Agreement：サービスレベル合意）は、提供するITサービスの品質を客観的な基準値として定め、契約者間で合意する取り決めです。SLAは事業者が一定の基準を守ってサービスを提供することを保証する契約であり、サービス導入後の品質を具体的に把握・管理するために用いられるとされています。SLAには、委託業務の範囲、役割分担、サービスレベル、結果への対応、運営ルール等を定めることが一般的であり、契約書の付属資料として作成されます。特に運用保守工程では、障害対応や運用品質を数値的に測定・評価し、継続的に品質を維持・向上させるための仕組みとして位置づけられています。SLAは調達段階から提示することが望ましいとされています。
SLAで考慮しなければならないこと
SLAはKPIと異なり、お客様との契約事項です。SLAが未達であった場合は、契約に基づいて損害賠償を支払う必要などが出てきます。では、ゆるゆるのSLAを結ぼうとした場合、提供するシステムの価値を100%届けることができません。ですので、価値を最大限に届けるための最低ラインを設定しつつ、運用保守を開始してから実はあのSLAはかなり無理のあるものだったこと悔やむことのないようにする必要があります。
次の章では、いくつかSLAで締結されそうな文言を用意しています。実際にお客様からSLAを提示されたと仮定して、飲んでいいものなのか測っていただければと思います。
事例を交えて解説
それでは、事例を交えて解説していきましょう！
例１：月の可用性を99.0%とする。
この場合の月間のサービス停止許容時間は、7.2時間です。
短いように見えるでしょうか？長いように見えるでしょうか？
まずは、担当のシステム特性を把握する必要があります。
仮に、24/365で稼働する停止した場合の社会的に影響の大きいミッションクリティカルなシステムであれば、このSLAはかなり緩い部類になります。
逆に、平日9時~18時のみしか動作させず、祝日・土休日は全く使用しないシステムであれば、メンテナンスの時間はたっぷりありますので、あくまでもシステムが安定運用している際は問題ないです。
加えて、あなたの担当システムの体制についても考慮する必要があります。
知識経験のある運用・保守人材を無尽蔵に投入できるリソースがある場合、障害を迅速に解決できる可能性があります。ただし、現実には制約が多くあります。平日9~18時のみ動作するシステムでも、仮にシステムITSMが2人しかおらず、スキルが均一でない場合、このSLA達成は難しくなる場合があります。例えば、システム更改作業を夜間に終え日中に動作開始をし、しばらくした後に、障害が発生したとします。日勤対応のITSMのスキルが低い場合、障害対処速度が遅くなります。スキルのあるすでに退勤すみのITSMも応援に駆けつけるとしますが、最悪なことに障害解決まで時間がかかったとします。人間、寝ずに作業をし続けることはできませんので、最悪の場合、2人とも共倒れになってしまう可能性があります。
トラブル発生時の、対応体制、スキルマップの用意、迅速に復旧できるための障害シナリオの準備、コンチプランの用意などを加味して、現実的に対応可能なのかを見分ける必要があります。
例２：トラブルの障害報告の時間はトラブル発生から20分以内とする。
こちらの事例はいかがでしょうか？
現実のSLAでは、さらに詳細が記載されていると期待していますが、上記のSLAは非常に曖昧でかつ、達成が難しいように見えます。その理由を紹介します。
まず、トラブル障害報告を受ける側の体制と方法についての記載がありません。
日勤帯でお客様が出勤している際は、報告することができますが、仮に深夜の時間帯で発生した障害報告を受けるお客様体制を確認する必要があります。
トラブル発生についての基準も不明確です。トラブル発生した時間をトラブル発生時間とするのか、それともトラブル検知時間を基準とするのかで報告時間のリードタイムが変化します。
20分以内という時間も考慮する必要があります。
トラブル報告を実施する際に、どの粒度の報告をお客様にしなければならないのか合意する必要があります。エラーメッセージと障害発生時間を報告すればいいのであれば、20分以内に報告は完了します。ただし、一次原因や根本原因など調査をする必要がある体裁のものを報告するのであれば、とても20分以内で完了することはできないでしょう。原因が正しいのか、有識者・上長レビューが必要になるためです。
また、トラブルの報告の方法についてですが、電話・メール・FAXなど様式はありますがこちらも決定していた方がベターです。
電話ならすぐ済みますが、相手方が打ち合わせで離席をしていた場合、障害の報告の用意はできていたけれど、報告ができなかった事例も考えられます。
メールは確実かもしれませんが、宛先・雛形を決定していなければ、1日100件以上たまるメールボックスの中に埋もれしまう可能性があります。
FAXについても、FAXの使用方法を相手方が知らない場合もあります。
例１でも類似の内容を述べましたが、障害報告をする体制と実施できるかの体力、対応時間、報告方法を考慮する必要があります。実際に障害が発生した時にあなたはどう動くのか？これを考慮しながらSLAの実現不可避具合を考えるのは良いかもしれません。
例3：ベンダからパッチ情報が出された時に、72時間に適用有無の報告を行い、パッチ情報が出されたから1週間以内にシステムに適用すること。
こちらはいかがでしょうか？
筆者の感覚としてこちらはできなくはないという感覚です。
ただし、システムの特性や体制の強さにもよると考えています。
まず、パッチ情報ですが、セキュリティパッチと可用性に関するパッチに分類します。セキュリティパッチは脆弱性対応に関連するところで、このセキュリティパッチを適用しないと、システム上にセキュリティホールが存在することがなり、サービスの提供が困難になります。こちらはどのシステムも早急に対応する必要があります。一方で、可用性パッチは異なる場合があります。2023年４月にANAの旅客基幹システムにおいて、航空券が発券できない障害が発生しました。この障害が発生した理由は、端的に言えばバグパッチの未適用が原因でした。ここでは、詳しい障害の原因は語りませんが、バグパッチが未適用の状態が続いたことによって、バグを引いてしまったことになります。
つまり、システムにおいて、安定稼働をしているのだからわざわざパッチを適用する必要がない考えがあります。パッチを適用するにもまずはデバッグ環境で試験をして、問題ないことを確認してから本番環境に適用します。あなたが担当しているシステムの特性にもよりますが、可用性パッチを確認して、机上やデバッグ環境で問題ないことを確認する必要があります。可用性パッチはいつ発表されるかも不明ですので、他のシステム担当がデバッグ環境を別試験で使用していたら、社内調整が困難を極めます。また、1週間以内に適用とありますが、本番環境を日中に停止してパッチを適用するにも、お客様調整が必要ですし、仮に24365で稼働しているシステムであったら、そのタイミングはかなり限られてしまします。
また、可用性パッチを見つけることも、労力や資金がかかります。ベンダとの契約で、可用性パッチが発生した際に、報告をしてくれてかつ、システムの構成情報を把握した上で、適用に問題がないかを判断してくれる場合があります。ただし、これにはベンダとの上位契約を結ぶ必要があり、多くの資金を必要とするでしょう。また、OSSを使用している場合は、自力で探す必要もあります。これらの情報を適切に管理するために、SBOMの整理であったり、運用するためのルールが必要です。ですので、この章の冒頭で申し上げたように、この例のSLAを達成することは不可能ではないです。ただし、達成するための体制・投入できる資金・パッチ適用に関するお客様の考え方やシステム特性を踏まえる必要があります。
例4：サービスデスクで問い合わせを受けた際、回答完了は1日以内に設定する。
最後の例です、こちらはいかがでしょうか？？
例１、例２でもダメだしをし続けたので、なんとなく想像はつくと思いますが、こちらも曖昧な点があります。
まずは、問い合わせを受ける様式について決定した方がベターです。
続いて、回答の定義についても決める必要があります。問い合わせ事項を解決する回答が出されたのが回答完了するのか、それとも問い合わせを受け付けた旨を知らせるチケット発行を回答とするのかによって達成難易度は異なります。お客様から、システムにログインができない旨の問い合わせを受けた際に、ログインできない事象をサポート窓口からITSM側にエスカレーションし解決するまで1日以内です。システム内部で完結できる場合は良いですが、外部のクラウドサービスを使用していて、世界的なクラウドサービスの障害によって解決できない場合も考えられます。*この場合は、クラウド障害の取り決めが別のSLAとして決められる場合があります。
また、回答期間にも曖昧な点があります。1日以内と記載がありますが、これは回答受領から２４時間以内のことを指すのか、１営業日以内（*問い合わせを受けた日を1日とする。）を指すのか不明です。就業終了時刻が18:00の場合、問い合わせが17:55に来たとします。
その場合、24時間以内の解決なら現実味がありますが、後者の場合その日中の対応を超勤対応をしない限り難しいです。
最後に
SLAとは、ITサービスの品質を数値などの客観的基準で定め、顧客と合意する重要な契約です。本記事では、運用保守・ITSMの現場で実際に起こり得る可用性、障害報告時間、パッチ適用、問い合わせ対応といった具体例を通じて、現実的に達成可能なSLAを設計する重要性を解説しました。SLAは厳しすぎても緩すぎても適切な価値提供につながりません。システム特性、運用体制、対応可能なリソースを踏まえ、実務に即したサービスレベルを設定することが、安定運用と顧客満足度向上の鍵となります。適切なSLAの締結が、発注側と受注側にとって持続可能なITサービスマネジメントになります。
参考文献
大阪市情報システム調達における SLA ガイドライン ～情報システム調達の適正化に向けて～
https://www.city.osaka.lg.jp/ictsenryakushitsu/cmsfiles/contents/0000671/671504/SLA_Guideline.pdf