用語の整理
まずはごっちゃになるSLI, SLO, SLAの整理から。
ちなみにSLは全部Service Level。
SLI
SLIはService Level Indicatorの略。Indicator: 指標
サービス品質をどうやって定量的に測るのかを決める。
SLIとして用いられる代表的なものは ↓
- 可用性（Availability）
- 遅延（Latency）
- エラー率（Error Rate）
- スループット（Throughput）
- フレッシュネス（データの鮮度）
SLO
SLOはService Level Objectiveの略。Objective: 目標
「このサービス品質は維持したい」という基準値を決める。
例:
- 95% のリクエストが 300ms 未満で応答
- 30日間で可用性 99.9% を維持
SLA
SLAはService Level Agreementの略。Agreement: 契約
「このサービス品質を守ります」という正式な契約内容を決める。
違反すると返金やペナルティが発生。
そのためSLAをSLOより厳しくするのは絶対NG。
SLOの設計原則
原則1: ユーザー満足度を基準にする
Google SRE本ではこう書かれています：
“SLOs should be based on user happiness, not engineer ambition.”
（SLOはエンジニアの理想ではなく、ユーザーが幸せでいられる範囲で設定すべき）
基本的には「ユーザーが満足しているなら現状値より少し緩めに設定」が定番のパターン。
原則2: 現状の性能より“少し余裕”のある値にする
SLOは実測値そのものではなく“目標”。
例えば現状が「90% 160ms, 95% 300ms」で、それに顧客が満足しているなら、SLOは「95% ≤ 350ms」のようにする（厳しくしすぎても緩すぎてもダメ）。
原則3: SLO を厳しくし過ぎない
SLOが厳しいと常にSLO違反になってしまい、精神的に苦しい運用になる。
後述するエラーバジェットが枯渇し、リリースが凍結されたり改善活動が止まったりする。
エラーバジェット（Error Budget）
SLOを超えて許容できる「失敗の量」
例: SLO：99.9% Availability
この場合、月間 0.1% = 約 43分 まで障害が許容される。
これがエラーバジェット。
たとえば新機能をリリースしたい時、エラーバジェットが残っていればOKだが、障害が続きエラーバジェットを消費しきっていたら、リリース凍結して信頼性の改善に集中するなど。