SLOについて理解し、SLOの運用を始めることができるようになるためのガイドとなるような内容をまとめる。
組織やチームにSLOの導入を行い、運用を開始していくためには幾つかの段階を踏む必要がある。
SLOを組織に初めて導入するには当たっては、まずはSLOについての知識を共有し、導入目的や運用方針について合意を取ることが重要である。筆者の経験に基づく所感であるが、SLOの運用の難しさはSLOの知識や目的に由来する部分もあると感じており、導入までのプロセスを丁寧に進めることが重要であると考えている。SLOは文化といえるような雰囲気を作り上げていかないとサービスやひいては組織の改善につながるような運用プロセスを達成することは難しいと感じている。
SLOを考える上で前提となるユーザーとサービスについての定義を明記する。
ユーザーとは、サービスを利用する人間だけでなく、サービスを利用するシステムやロボットなどあらゆるサービスの利用者を指す。
一方で、「サービスとは、ユーザーが存在する何らかのシステム」のことである。Webサービス、API、バッチジョブ、データベース、ネットワーク、デバイスなどが挙げられる。
SLOを運用する上で心に留めておきたいマインドセットについて整理する。
SLOは何かを強いるような要求ではなく、気付きを与えるデータであり、指針である。
SLOを運用することでどのように振る舞うかは自ら考える必要がある。
SLOは一度達成したら終わりではなく、継続的に運用されるものである。
運用の中で更新をしたり、不要になれば廃止をしたりすることが求められ、完了条件のあるようなタスクではない。
サービスの変化に応じてSLOも変化することが求められる。
また、導入にしてもすぐに運用のメリットが得られるわけではなく、時間をかけてプロセスを継続・改善していく根気強さが必要である。
SLOは最終的に人の行動に影響を与えるものである。
サービスが対象とするユーザーだけでなく、エンジニアやビジネスサイドのメンバーなどサービスに関わるステークホルダーに良い影響をもたらすためのである。
信頼性とは「ユーザーが求めている動作をシステムが実行していること」である。
100%の信頼性を提供することは不可能であり、ユーザーが求める動作を提供するためのコストを考慮して信頼性を提供する必要がある。
どの程度の信頼性が必要かはサービスによって異なる。SLOによって定量化し、適切な信頼性を提供することが求められる。
サービスレベルとは、「サービスが提供する品質や性能を示すもの」であり、サービスが提供する信頼性の水準を示す。
サービスレベルはSLOやSLIの概念を内包した概念という位置づけである。
ex. ユーザーのログイン処理が一定時間内に完了すること
SLIとは、「一定期間におけるサービスの特性を示す指標」である。サービスレベルを測定するためのデータを提供する。
可用性やレイテンシ、レスポンスタイム、スループット、エラーレートなどが指標として挙げられる。
SLIは、良いイベント（good events）を有効な総イベント（valid events）で割ったものに100を掛けた割合で表される。
SLIはユーザーの観点からサービスがどのように機能しているかを示す指標となる。効果的なSLIはユーザー・エンジニア・ビジネスにとって良い影響を及ぼす。ユーザーの体験を向上し、エンジニアには問題の特定や改善の方向性を示し、ビジネスにはサービスの信頼性を示すことができる。そのようなSLIは、サービスが何を提供するかという視点ではなく、ユーザーが何を必要としているかという視点から発見される。
SLOとは、「一定期間におけるサービスレベルの目標値」である。SLOはSLIに対する目標値を示す。
SLOを上回っていればユーザーはサービスに満足し、SLOを下回っていればユーザーは不満を持つと考えられる。
SLOは合意ではなく、努力目標であり、変更が許容される。
SLOの目的は、サービスの信頼性を定量化するためのデータを集めることである。SLOが運用されることで、信頼性の改善点の発見や信頼性という観点からの開発や運用の改善が行われる。
SLOの目標値は100%未満の割合で設定される（時には時間で設定しても良い）。100%の信頼性というのは現実的に不可能であるため、信頼性のコストを考慮して検討する必要がある。
| 稼働率 | 年間停止時間 | 月間停止時間 |
|---|---|---|
| 99.0% | 87.6時間 | 7.6時間 |
| 99.5% | 43.8時間 | 3.65時間 |
| 99.9% | 8.76時間 | 43.8分 |
| 99.95% | 4.38時間 | 21.9分 |
| 99.99% | 52.56秒 | 4.38分 |
| 99.999% | 5.256秒 | 26.28秒 |
| 99.9999% | 31.536秒 | 2.628秒 |
99.9%までは手動による信頼性の回復が可能であるが、それ以降は自動化を前提としてないと達成が難しいような目標値となる。
エラーバジェットとは「一定期間におけるサービスの信頼性損失の許容を示す指標」である。エラーバジェットはSLOを達成するための余裕であり、ユーザーが不満を持つまでの累積可能なエラーの量を示す。
エラーバジェットは、100% - SLO の値で計算される。
エラーバジェットは、信頼性と機能追加のどちらを優先すべきかの判断材料となる。エラーバジェットの状態による対応は強制されるものではなく、あくまで意思決定のためのデータとなる。
エラーバジェットの計測には時間枠の設定が必要となる。時間枠はイベントベースと時間ベースの2つがある。イベントベースは回数を計測することで、時間枠でのエラー回数（1週間で残り500回）を観測することができる。時間ベースは時間を計測することで、時間枠でのエラー時間（ex. 1週間で後10分）を観測することができる。
効果的なエラーバジェットの運用にはエラーバジェットポリシーを作成すると良い。
消費ポリシーや超過ポリシーでは、「したほうが良い（推奨）」「すべきである（勧告）」「する必要がある（強制）」など行動基準の温度感を示すことと良い。
SLOはビジネス・開発・運用のそれぞれの視点においてSLOを基準とした意思決定を行う手段を提供する。
ビジネスの視点では、信頼性に投資するか？機能追加に投資するか？といった意思決定を行うための指標となる。
開発の視点では、機能追加と信頼性の改善のバランスを取るための指標となる。
運用の視点では、信頼性の改善点を発見し、信頼性を向上させるための方向性を示したり、適切な信頼性を模索するための指標となる。
SLOを運用すると、例えば次のような良い変化が期待できるかもしれない。
SLOの設計は次のようなステップで行うことができる。
ユーザージャーニーとは、ユーザーがサービスを利用する際の流れを示すものである。
ユーザージャーニーを定義することで、サービスが提供する機能やユーザーが求める動作を明確にすることができる。
ex. ユーザーが商品を購入する際のユーザージャーニー : 商品をカートに入れる -> 住所を入力する -> お支払い方法を選択する -> 購入する
ユーザージャーニーに関わるアーキテクチャを定義することで、サービスが提供する機能やユーザーが求める動作を実現するためのシステム構成を明確にすることができる。システム間の依存関係やデータの流れを理解し、SLIの候補となるメトリクスの選定に役立つ。
ex. ユーザーが商品を購入する際のアーキテクチャ : Webサーバー -> データベース -> 支払いサービス -> メッセージキュー -> 通知サービス
ユーザージャーニーとアーキテクチャの定義を元に、SLIを定義する。
ex. ユーザーが商品を購入する際の SLI : 商品をカートに入れるリクエストのレスポンスタイム、住所を入力するリクエストの成功率、お支払い方法を選択するリクエストの成功率、購入するリクエストの成功率
SLIの定義を元に、SLOを定義する。
ex. ユーザーが商品を購入する際の SLO : 商品をカートに入れるリクエストのレスポンスタイムが 100ms 以下であること、住所を入力するリクエストの成功率が 99.9% 以上であること、お支払い方法を選択するリクエストの成功率が 99.9% 以上であること、購入するリクエストの成功率が 99.9% 以上であること
SLOは継続的なプロセスを通じて改善されるものであるため、最初から完璧なものを目指す必要はなく、小さいスコープから始めていくことが取り組み始めるための一歩となる。
設定されたSLOは監視を行い、定期的に分析をし、継続的に運用を行う。
SLOの達成状況を定期的に確認し、問題がある場合は該当するSLIを元に調査を行い、影響を与えた要因について分析する。
エラーバジェットの運用ポリシーに基づき、SLOの達成状況に対する対応を検討する。
SLOの目標値やSLIの調整、SLOの新規追加や削除なども継続的な運用の中で行う。サービスを取り巻く環境の変化により、以前定義したSLOやSLIが適切でなくなることもある。
SLOの運用によって得られるデータ及び生じる議論は、サービスの信頼性向上につながる資産であるため、情報を適切に保存・共有する。