フレームワーク活用ガイドひとことで言うと#
SLI（計測指標）→SLO（目標値）→SLA（契約）の3段階でサービス品質を定義し、エラーバジェットの考え方で信頼性と開発速度のバランスを取るフレームワーク。
押さえておきたい用語#
- SLI（Service Level Indicator）
- サービス品質を数値化する具体的な計測指標のこと。可用性、レイテンシ、エラー率などが代表的。
- SLO（Service Level Objective）
- SLIに対して設定する内部的な品質目標を指す。「可用性99.9%」「p99レイテンシ200ms以下」など。
- SLA（Service Level Agreement）
- 顧客との間で交わす品質保証の契約。SLOより緩く設定し、違反時にはペナルティが発生する。
- Error Budget（エラーバジェット）
- SLO目標から逆算した許容される障害の総量。100% - SLO = エラーバジェットで計算する。
- Burn Rate（バーンレート）
- エラーバジェットが消費される速度。急速に消費されている場合はアラートを発報する指標である。
SLOの全体像#
こんな悩みに効く#
- 「可用性100%を目指す」方針のせいでリリースが遅くなっている
- 信頼性エンジニアリングに投資すべきタイミングがわからない
- SLAを設定しているがSLOとの関係が整理されていない
基本の使い方#
具体例#
エンジニア80名のBtoB SaaS。「障害をゼロにする」方針で、リリース前のテスト期間が 2週間 に設定されていた。結果、リリース頻度は月1回に低下。
SLO 99.9%（月間43分のエラーバジェット）を設定。バジェット残量でリリース判断を行うルールに変更。
| 状態 | 行動 |
|---|---|
| バジェット残り > 70% | 積極的にリリース |
| バジェット残り 30-70% | 通常リリース |
| バジェット残り < 30% | リリース凍結、信頼性改善に集中 |
リリース頻度が 月1回 → 週2回 に改善。エラーバジェットの枯渇は四半期で 1回 のみで、その際は信頼性改善にリソースを集中投下し、次の四半期はバジェットに余裕を持てた。
月間売上30億円のEC。顧客向けSLAで「可用性99.99%」を約束していたが、実態のSLOも同じ99.99%に設定していたためバッファがなく、SLA違反が年 3回 発生。違反ペナルティの支払い総額は年間 1,200万円。
SLO 99.95%（SLAより厳しい）に再設定し、SLA 99.9%（SLOより緩い）にバッファを設けた。
| 指標 | 旧 | 新 |
|---|---|---|
| SLO | 99.99% | 99.95% |
| SLA | 99.99% | 99.9% |
| バッファ | 0% | 0.05% |
SLOを現実的な値にしたことで、SLO違反時にSLA違反前に対策を打てるようになった。SLA違反は年 3回 → 0回 に。ペナルティ支払いもゼロに。
月間500万ユーザーの動画配信サービス。「再生開始まで3秒以内」をユーザーが期待しているが、計測していなかったため実態が不明だった。
レイテンシSLIとして「再生開始時間のp95」を定義し、SLO 3秒以下を設定。計測を開始すると、p95が 4.8秒 でSLO未達が判明。
CDN配置の最適化とプリフェッチの導入で、3ヶ月後にp95が 4.8秒 → 2.3秒 に改善。SLO達成率は 72% → 97% に向上し、ユーザーの「バッファリングが長い」というNPS低評価コメントが 60%減 になった。
やりがちな失敗パターン#
- SLOを100%に設定する — 100%は数学的にゼロダウンタイムを意味し、コストが無限に。ビジネス要件に見合った目標を設定する
- SLAとSLOを同じ値にする — バッファがないとSLO違反=即SLA違反になる。SLOをSLAより厳しく設定してバッファを確保する
- 内部メトリクスをSLIにする — CPU使用率80%でもユーザーに影響がなければ問題ない。SLIはユーザー体験に直結する指標を選ぶ
- SLOを一度決めて見直さない — ユーザーの期待値は変化する。四半期ごとにSLO達成率をレビューし、必要に応じて調整する
まとめ#
SLOはSLI（計測指標）→SLO（目標値）→SLA（契約）の3段階でサービス品質を定義し、エラーバジェットで信頼性と開発速度のバランスを取るフレームワーク。100%を目指すのではなく、ユーザーの期待に見合った適切な目標を設定する。エラーバジェットの残量に応じてリリース判断を行い、四半期ごとにSLO達成率をレビューして目標を調整するサイクルが運用の鍵になる。