引越し業者と契約するとき、「何時までに届ける」「壊れたら弁償する」という約束を書面で交わします。ITサービスの品質について、この約束書にあたるのが SLA（サービスレベル合意）です。クラウドサービスや外部APIを事業の基盤に使うなら、その契約にどんな SLA が付いているかで、どこまで頼ってよいかが判断できます。
SLA で約束されることが多いのは、次のような項目です。
- 月間や年間で、サービスが正常に動いている割合（稼働率）
- リクエストに対して、どれだけ速く返事をするか（応答時間）
- 問い合わせから最初の返答までの目標時間
- 障害が起きたとき、何分以内に知らせるか
たとえば「月間稼働率99.9%を保証し、下回った場合は利用料の一部を返還する」という形で、品質の水準と、守れなかったときの扱いがセットで書かれています。
契約する前に読むところ
このクラウド、SLAで稼働率99.9%を保証してるって。止まっても補償があるなら安心だな。
補償って、実際いくら戻ってくるんでしょう？
数字そのものより、数字の周りに書かれた条件のほうが大事なことがよくあります。
- 対象の期間。「月間」なのか「年間」なのかで、同じ99.9%でも許される停止の長さが変わる
- 測り方と対象外。どの機能を測るのか、計画メンテナンスは含まれるのか
- 補償の条件、上限額、申請方法。SLA を下回っても自動では補償されず、利用者からの申請が必要なことが多い
- 補償の中身が、自社の損失と釣り合っているか
特に4つ目は見落とされがちです。補償の多くは利用料の一部返還で、サービスが止まったことで自社が失う売上や信用までは埋まりません。99.9%の保証でも年に8時間以上の停止が許される水準であることを踏まえ、自社がどれだけの停止に耐えられるかと照らし合わせます。事業への影響が大きいシステムほど、「SLA があるかどうか」ではなく「中身が十分か」で採用を判断してください。
SLA と SLO
SLA は利用者に対する約束です。これに対して SLO（Service Level Objective）は、サービスを提供する側が内部で目指す品質の目標値で、社内の設計目標として使われることが多い言葉です。約束（SLA）を守るために、それより厳しめの目標（SLO）を置いて運用する、という関係になっています。
自社サービスの品質を顧客に示す立場になったときも、この2つを分けて考えると、約束できる範囲と目指す範囲を整理しやすくなります。止まりにくさをどう作るかは可用性で扱っています。