SLO / SLI / SLA
エラーバジェットの考え方を学び、信頼性目標の設計を実践する
よくあるシナリオ:「どこまで頑張ればいいの?」問題
SaaSクライアントで開発チームと運用チームが対立。開発側は「なぜいつもリリースを止めるのか」、運用側は「なぜいつも急リリースして障害を起こすのか」と平行線。根本原因は「いつ・どこまで安定していればOKか」の合意がないこと。
- 「信頼性が高い」の定義が人によって違う
- リリースのたびに開発vs運用の対立が起きる
- 障害報告が「先月2回ありました」で終わる
- 際限ないオンコールでエンジニアが疲弊
SLI → SLO → SLA の関係
SLI / SLO / SLA の関係
実際に計測する指標
─────────────
総リクエスト数
チームが設定する目標
顧客との契約・約束
核心概念を押さえる
実際に計測するサービスの指標。ユーザーが直接体験できるもの(可用性・レイテンシ・エラー率)を選ぶ。
例:成功リクエスト数 ÷ 全リクエスト数 = 99.87%
チームが内部で設定する信頼性目標。100%を設定してはいけない——失敗の余地(エラーバジェット)がゼロになる。
例:月次可用性 99.9% 目標 = 月43.2分のダウンタイムまで許容
顧客との法的な契約値。SLOより低く設定し、SLO違反時に社内で検知・対処できるバッファを持つ。
例:SLO 99.9% に対しSLA 99.5% を顧客に約束 → バッファ0.4%
SLOから逆算した「許容できる失敗の量」。これが残っている間は積極的にリリースし、枯渇したら安定化を優先。
例:SLO 99.9% → 月43.2分がバジェット。今月20分消費→残り23.2分
エラーバジェットの消費速度。バーンレート14倍=1時間でバジェット枯渇。これで緊急対応の判断基準を持てる。
例:バーンレート10x → このペースが続くと10倍速でバジェットが尽きる
バジェット残量に応じてリリース可否を決めるルール。開発と運用が客観的な数値で合意できる仕組み。
例:バジェット50%以上→自由にリリース。10%未満→新機能凍結、信頼性改善を優先
エラーバジェットの考え方
→ 信頼性改善に全力を注ぐ
AI で SRE の仕事はどう変わるか
- SLO値を経験則で設定(根拠があいまい)
- エラーバジェット計算をスプレッドシートで手動
- SLA違反リスクを定性的に評価
- 四半期ごとの手動レポート作成
- 過去トラフィックデータからSLO推奨値を自動算出(Nobl9 AI)
- バーンレートを予測し「このままだと〇時間後に枯渇」と警告(Datadog SLO Analytics)
- SLA違反リスクをリアルタイムスコアリング(Google Cloud Error Budget)
- 月次信頼性レポートを自動生成(PagerDuty Analytics)
- ビジネス優先度に基づくSLO目標の最終決定
- ステークホルダーとのSLA交渉・合意形成
- エラーバジェットポリシーの組織設計
- AI推奨SLOの妥当性レビュー
主なツール:Nobl9、Datadog SLO Analytics、Google Cloud SLO API、Chronosphere、Grafana SLO
この先の見通し:AIが自動的にSLOの最適値を学習・提案し、エラーバジェット枯渇をリアルタイム予測する時代へ。2027年には「SLO設定はAIが初期提案、人間が承認」という形式が標準化する見込み。SREの役割はSLO設計の哲学者・調整役にシフト。
導入による効果の目安(業界の一般的な傾向)
- SLA違反削減
- -40%
- 契約違反のリスク低減
- 開発vs運用の摩擦
- -60%
- 客観的指標による合意形成
- リリース頻度向上
- +30%
- バジェット余裕時の積極展開
- 優先度判断
- 明確化
- 数値ベースの意思決定