# SLAとは

サービスの提供者と利用者の間で、稼働率や復旧時間などの水準を数値で取り決める文書です。数字そのものより、算定方法と除外条件と補償の範囲が実質を左右します。

## SLAとは

SLA（Service Level Agreement）は、サービスの提供者と利用者の間で、稼働率、障害時の復旧時間、応答時間などの水準をあらかじめ数値で規定する[書面による合意](https://www.soumu.go.jp/main_content/000843318.pdf)です。


合意の対象は遵守する水準、その測り方、遵守できなかったときの扱いの3つです。


稼働率や応答時間の測定値をSLI（Service Level Indicator、指標）、その測定値に対する目標値をSLO（Service Level Objective、目標）と呼びます。
SLAはSLOを充足できなかったときの補償や体制の約束まで含んだ合意です。
SLOとSLAはSLOを充足できなかったときに何が発生するかで[区別します](https://sre.google/sre-book/service-level-objectives/)。
明示的な結果が定められていなければ、それは概ねSLOです。


![SLIの測定値に対してSLOの目標値を定め、SLAがSLOを満たせなかったときの補償まで含む関係を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-sla-657d9bb5724318e8164402cb0e01a4c1bce7dd15d8e2d394a75032787aa1fab4.png)

社内の情報システム部門と事業部門の間で、同じ形式の合意を締結する例もあります。
補償がない場合は実質的に目標の共有になり、部門間の優先順位を決定する材料になります。


## 停止したときの扱いを先に決める

システムの調達では機能と金額は比較の対象になりますが、停止したときの扱いは比較されにくいです。
提供者と利用者の双方が停止しないことを前提に検討を開始し、障害の発生後に復旧の要求水準や補償の有無を協議することになります。
この状態では、利用者は復旧の約束を受け取れず、提供者も見積もりの前提を定められません。


SLAはこの部分を契約の条項にします。
稼働率と復旧時間の目標、測定の方法、遵守できなかったときの補償が文書に記載されていれば、障害のたびに交渉する必要はありません。


調達の比較にも利用できます。
クラウドサービスのサービス品質の[開示項目](https://www.soumu.go.jp/main_content/000477838.pdf)には、稼働率の目標値と実績値、SLAを契約書に添付するかどうかが含まれます。


![調達の比較で機能と金額は並べて比べられるのに対し、停止したときの復旧と補償は決まっておらず障害の発生後に協議になることを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-sla-14c9957232a57d1652d739a5c380b56f24ec479527f1d56a74ab38b3a9864193.png)

## 障害時の手順と比較の基準が決まる

- 停止したときの連絡、復旧、補償の手順が契約で確定し、障害のたびの交渉が不要になる
- 複数社の提案を同じ項目と同じ数値で比較できる
- 提供者側の見積もりの前提が確定し、水準の異なる提案が混在しにくくなる
- 稼働率の実績が定期的に報告され、水準の妥当性を再検討できる
- 復旧時間の目標を定めると監視の範囲と当番体制を設計できる

## 水準を高めるほど費用と体制の負担が拡大する

- 稼働率を99%から99.9%へと9を1桁増やすごとに費用は前の段より増加し、利用者にとっての価値の増分は[小さくなる](https://sre.google/workbook/implementing-slos/)
- 高い水準は機器を二重に保有する構成を前提とし、設備と設計の費用が先に必要になる
- AWS（Amazon Web Services）の[Amazon EC2のSLA](https://aws.amazon.com/compute/sla/)は、単一のインスタンスに99.5%、稼働中の全インスタンスを同一リージョン内の2つ以上の可用性ゾーンに分散させた構成に99.99%の水準を定めている
- 夜間と休日の待機、監視、復旧の訓練に人件費が毎月かかる
- 実績の測定と報告、除外事由の記録、補償の請求に事務の工数がかかる
- 補償は利用料の減額が中心で、停止による損害は対象外になる
- 水準を高く設定しすぎると、提供者が遵守できない項目が増え、数字だけの契約になる
- 除外条件が広範だと契約に記載された数字と実際の可用性が一致しなくなる

![稼働率を一段引き上げるごとに、必要になる設備と体制が増え、費用が前の段より大きく増える関係を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-sla-6e671aacb0c67979ad9c140ea3dda3ff81da8110ace52bd378704287ce46c19f.png)

## 稼働率はどこまで求めるか

決済、受注、給与のように停止の影響が重大な業務は99.9%前後と復旧時間の目標、社内の文書共有やチャットは99.5%前後と翌営業日までの復旧を目安にします。
稼働率99.99%以上はシステム全体をその水準で維持する費用と体制を用意できる場合に限ります。


### 水準の設定

1か月を30日として計算すると、99.9%は月約43分、99.95%は約22分、99.5%は約3.6時間、99%は約7.2時間の停止に相当します。
99.9%から99.99%へと9が1つ増えるごとに、許容される停止時間は10分の1に短縮されます。


![稼働率99%から99.95%までの水準ごとに、1か月に許される停止時間が7.2時間から22分へ短くなる対応を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-sla-fca4dfe0f470e18ae1940e32a22f17dfa3f2be6f5ed03fdced9d92f4b590fd78.png)

水準は平均ではなく、停止が業務に影響する時間帯から設定します。
給与、会計、受注は月末と月初に処理が集中します。
[通常業務時間帯に99.95%、その他の時間帯に99.5%](https://www.soumu.go.jp/main_content/000703895.pdf)のように、時間帯を分けて目標を設定します。
提供時間を24時間とするか業務時間に限るかでも、同じ数値の意味は異なります。


月次の締めや締め日前後の処理がある業務は、99.95%を目安にします。
稼働率の提示がない製品は基幹業務の候補から除外します。
実績の報告がない製品も同じ扱いにします。
自社で構築する場合は外部のサービスと自社のアプリケーションのうち低いほうの水準が全体の上限になります。
試作や検証の段階、個人情報を含まない社内ツールでは、稼働率と復旧時間の目標だけを確認すれば十分です。


### 条項の読み方

![稼働率の数字だけを見ず、算定方法、除外条件、測定の主体をセットで読むことを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-sla-092ed1d92b0cf82eade471c1bc71ee71d9dd94489f23b3c49529e42beb860e84.png)

| 項目 | 確認すること |
|---|---|
| 算定方法 | 時間単位とリクエスト単位のどちらか、分母に何を含めるか |
| 復旧時間 | 起算点が検知、連絡、一次応答のどれか、完了条件が業務再開と全機能復旧のどちらか |
| 除外条件 | 計画停止、外部のサービス、利用者側の機器、災害 |
| 数値の性格 | 達成の保証か、商業的に合理的な努力か |
| 補償 | 減額の率、請求の期限と手続き、損害の扱い |
| 測定 | 実績を提供者、利用者、第三者の誰が測定するか |
| 報告 | 実績の報告頻度と形式、窓口の対応時間 |

算定方法は時間単位かリクエスト単位かによって結果は異なります。
算定は、[サービス提供時間から除外事由を除いた停止時間を減算した値をサービス提供時間で割る](https://www.soumu.go.jp/main_content/000703895.pdf)形が例にあります。
稼働率は、[正常なリクエストの割合として測定する](https://sre.google/sre-book/service-level-objectives/)形もあります。
どちらを採用するかで、短時間の全面停止と長時間の一部機能停止の評価は逆転する場合があります。


数値が保証か目標かも確認します。
水準の達成には[商業的に合理的な努力](https://aws.amazon.com/compute/sla/)をする義務があり、達成できなかった場合は補償が適用される構成です。
数値は達成を約束するものではなく、充足できなかったときの補償の条件という位置づけになります。


除外条件の範囲は実質の稼働率を左右します。
除外する事由は、[事前に合意した停止、制御できない事由、利用者側の責任、その他](https://www.soumu.go.jp/main_content/000703895.pdf)の4つに分類できます。
計画停止の事前通知の期限は[開示項目](https://www.soumu.go.jp/main_content/000477838.pdf)にも列挙されており、外部のサービスの障害がどこまで除外されるかと同時に確認します。


### 補償の範囲

クラウドサービスでは、補償は利用料の減額が中心です。
AWSは、障害の影響を受けたリージョンのAmazon EC2の月額請求額に対して[10%、30%、100%の3段階の減額](https://aws.amazon.com/compute/sla/)を定め、将来の支払いに充当します。
返金ではありません。
委託開発や自社の設備で稼働するシステムでは、補償を定めないか、損害賠償の上限とする契約もあります。


請求の手続きが必要な場合があります。
AWSは[障害の発生した請求サイクルの2回後の請求サイクルが終わるまで](https://aws.amazon.com/compute/sla/)に、対象の日時、リソース、障害を示すログを添えて申請することを求めています。
申請がない場合や情報が足りない場合は対象外になります。
期限は約2か月後を目安に、担当と手順を契約時に定めます。


補償は停止による損失を対象にしません。
この補償は、利用不能に対する[唯一の救済](https://aws.amazon.com/compute/sla/)とされています。
売上の損失や業務の遅れは対象外です。
日本の契約で同種の免責がどこまで有効かは、故意と重過失の扱いを含めて法務の確認が必要です。
損失が重大な業務は補償ではなく、復旧時間の目標、連絡体制、代替の手順で備えます。


## よくある誤解

### SLAを結べば停止しなくなる

SLAは停止したときの扱いを定める合意で、停止を防止する仕組みではありません。
稼働率を維持するのは設計と運用です。


### 稼働率の数字が高い製品ほど安全

数字は算定方法と除外条件で異なります。
計画停止を除外していれば、実質の稼働率は低下します。
比較するときは算定方法を統一します。


### SLOとSLAは同じもの

SLOは目標で、SLAは遵守できなかったときの結果を含む合意です。
社内の目標をSLAと呼んでいる場合でも、補償や体制の約束がなければSLOです。