サービスの開発が終わり、さて運用フェイズとなったとき必要となるのがSLA（実際には開発する前からSLAを提示してクライアントに承諾をもらう必要があります）。
#SLA/OLA/UCとは
「SLA（Service Level Agreement）」とは、サービスの利用者と提供者の間で合意され、サービスの品質や内容を記載したものになります。SLAをベースにサービス提供者は運用もしくはサービスそのものを構築する必要があります。サービス提供者目線で見ると、利用者側から定義された以上のモノを求められないという防御線になるメリットの一方、（当たり前ですが）順守する義務が発生します。
要件定義書と同じく関係者において品質や内容が不明確なためトラブルになることもあり、事前に品質のサービスレベルが定量的に明確されている必要があります。
SLAの他に「OLA（Operational Level Agreement）」は、SLAを守るためのオペレーションレベルの合意書も必要となります。そこには、各サービスの担当者、責任者、役割、連絡網、組織構成などが記載されます。
さらに「UC（Underpinning Contract：請負契約）」は、SLAを順守するためにサービス提供者と本サービスが利用する社外のサプライヤとの間で取り決めた合意文書も必要となります。例えばAzure上に構築されたサービスは、AzureのSLA以上のものは提供できないのでAzureのSLAを添付する必要があります。
SLAのKPI
SLAを順守する義務がある中で、本当にSLAが順守されているかKPIを設定する必要があります。守れなかったらどうするといことは、努力目標型SLAなのか目標保障型SLAなのかによって意味合いがことなりますが、どちらにしてもKPIを定期的に計測する必要があります。
- SLAの合意目標を達成しなかった割合
- OLA、UCがSLAの合意目標にそぐわなかった件数
- スケジュール通りにSLAがレビューされた割合
- SLAの変更を必要とした件数
- SLAによってカバーされていないITサービスが発生した件数
- 顧客満足度、ユーザ満足度
上記のように運用したことないサービスに対して目標保障型SLAを立てるのことは困難です。まずは努力目標SLAを構築し、実現するためのコストなどを計算し、そのコストをサービス料金の中に含めても運用していける事を確認することをお勧めします。SLAを改定し、サービス料金の見直しするなどの手法も必要かもしれません。
では、実際にSLAのテンプレートなる項目を下記に記載します。
契約におけるSLAの範囲
ここで、提供しているサービスの名前・機能・範囲、提供している事業主などを明記し、このSLAが適用される範囲をできるだけ詳しく具体的に表記します。
サービス提供時間帯
上記で明記したサービスの提供時間を記載します。ここではシステム稼働時間に連動するサービスと、監視・問い合わせなどといった運用サービスの時間を記載します。
計画停止
サービスの向上もしくは改修にはどうしてもサービスを停止しないといけない場合があります。そのようなときは計画的にサービスを停止することがあります。その計画の定義をここに明記します。どれぐらい前にどのような理由であれば計画停止と呼び事ができて、その計画停止はどれぐらいの頻度で発生させることが可能なのか明記します。
SLA の設定
SLAが達成されなかったときにどうなるのか、どのようにSLAが達成されていないと申請できるのかを明記します。返金される金額、その金額の上限値など、目標が達成されなかったときのペナルティーに関しては明記するだけでなく利用者に理解と承諾を得る必要があります。
サービスごとの基準値
サービスごとに基準値を設定します
- 提供時間帯
- 障害対応時間帯
- 障害復旧までの時間
- 障害通知までの時間と手法
- 計画停止の通知
などの基準値を明記してください。
障害の定義
障害という言葉が独り歩きしてしまうので・・ ここで障害とは何か定義します。
SLA の適用外
天災であったり、契約先のベンダーの不具合であったり、責任とれないもの＝SLA適用外をここに明記します。
SLA の変更
SLAの変更フローをここに記載します。
備考
努力目標型SLAと目標保障型SLA？
いきなり目標保障することは難しいので、努力目標SLAで運用する期間を設定し、そのあと目標保障SLAに移管することをお勧めします。 これを飲んでくれないお客様にはちゃんと運用するのに十分な予算をいただき、仕事を引き受けることをお勧めします。
SLAを書くのは法務？サービス？
準拠するのはサービス運用者なので、サービス運用者が内容を決めて、法務にレビューしてもらうのがいいと思います。
SLAはいつから書き始める？
開発前にSLAをある程度明記することも必要です。見積りを作る際にも必要となる情報であり、求められるSLAを達成するためのシステム構成などもあるので、開発着手前そしてできるだけ早く書き始めましょう。要件定義書にも項目として含まれているのでSLAを念頭に要件定義書に落とし込みしましょう。
参考：要件定義書テンプレート