Help us understand the problem. What is going on with this article?

[Doc] Service Level Agreement の書き方(+Operation Level Agreement,Underpinning Contract)

サービスの開発が終わり、さて運用フェイズとなったとき必要となるのが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を念頭に要件定義書に落とし込みしましょう。

参考:要件定義書テンプレート

syantien
トランスコスモス技術研究所にて様々な開発案件を進めています。最近はKotlin頑張ってます。開発メンバー絶賛採用中。このどれかのキーワードでビビっと来た人は面談にお越しください。「ASP.NET C#」, 「Kotlin」,「Swift」,「Angular」,「QA」,「UXデザイナー」,「データサイエンティスト」,「海外開発案件挑戦してみたい」,「Shopify」。
http://syantien.hatenablog.com/
trnd
ソフトウェア・ウェブサービス開発時に読み返せる記事をまとめています。
https://t-rnd.com
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした