🎯
SLO / SLI / SLA
サービスの信頼性目標を数値化し、開発速度と信頼性のトレードオフを明示的に管理するフレームワーク
定義
| 用語 | 意味 | 例 |
|---|---|---|
| SLI (Service Level Indicator) | 測定可能なサービス品質の指標 | 成功リクエスト率、P99レイテンシ |
| SLO (Service Level Objective) | SLIに対する内部目標値 | 「99.9%のリクエストを300ms以内に返す」 |
| SLA (Service Level Agreement) | 顧客との契約上の合意。違反時にペナルティが発生する | 「月間99.5%の可用性を保証する」 |
SLOはSLAより厳しく設定するのが原則。SLAを下回る前にチームが行動できる余裕を持たせる。
なぜ重要か
「信頼性が十分か否か」を主観的に議論するのではなく、数値で合意することで:
- 開発速度と信頼性のトレードオフをエラーバジェットとして可視化できる
- 「これ以上信頼性を上げる必要はない」という判断が合理的に行える
- PM・開発・SREの3者が同じ基準で議論できる
100%の可用性は目標として設定してはならない。それは開発を完全に止めることを意味するからだ。
適用場面
- 新規サービスのローンチ前に、最初のSLOをドラフトするとき
- インフラ障害後に「なぜ検知できなかったか」を振り返るとき
- 開発速度が遅いという主張と信頼性要求が衝突しているとき(エラーバジェットで仲裁)
SLO設定のプロセス
- ユーザーの幸福度を起点に考える(レイテンシ?エラー率?スループット?)
- 測定可能なSLIを選ぶ(「体感的に速い」はSLIにならない)
- 過去データから現実的なSLO値を決める
- PM・開発・SRE の3者で合意する
- 定期的(四半期)に見直す
出典
Google SRE Workbook(Betsy Beyer他)第2章「Implementing SLOs」
- 1. 🔌メタデータ中心ロギング(Metadata-Centric Logging)
- 2. 📐ログにはメタデータを記録し、コンテンツを含めない
- 3. 🔭オブザーバビリティ(Observability)
- 4. 🎯SLO / SLI / SLA
- 5. ⚖️エラーバジェットで優先度を決める
- 6. 📟オンコール設計
- 7. 💰エラーバジェット
- 8. ⏱️オンコール当番中も戦略的作業時間を確保する