LESSON 30分

ストーリー

田
田中VPoE
SLI/SLOの基礎を理解した。ここからSREの最も革新的な概念に入る。エラーバジェットだ
あなた
SLOの余白分、ということですよね？99.9%のSLOなら0.1%が使える
あ
田
田中VPoE
数字としてはその通りだ。だが、エラーバジェットの本質は「数字」ではなく「意思決定の仕組み」だ。開発チームと運用チームの永遠の対立を、データで解決する革命的なアイデアだ
あなた
「早く出したい」vs「安定を守りたい」の対立ですね
あ
田
田中VPoE
そうだ。エラーバジェットがあれば「今月はバジェットに余裕がある。新機能をどんどん出そう」「バジェットが残り少ない。リリースを控えて信頼性改善に集中しよう」と、感情ではなくデータで判断できる

エラーバジェットとは

基本概念

エラーバジェット = 100% - SLO

例: SLO 99.9% の場合
  エラーバジェット = 100% - 99.9% = 0.1%

30日間に換算:
  0.1% × 30日 × 24時間 × 60分 = 43.2分

→ 月間43.2分までのダウンタイムは「許容範囲内」

エラーバジェットの消費

消費要因説明例
計画的ダウンタイムメンテナンスウィンドウDB移行で15分停止
インシデント障害によるサービス停止デプロイ失敗で30分停止
パフォーマンス劣化SLO未達のリクエストレイテンシSLO超過
依存サービスの障害外部サービスの問題CDN障害で10分間影響

エラーバジェットに基づく意思決定

判断フレームワーク

バジェット残量状態アクション
75%以上安全圏積極的にリリース、新機能開発を加速
50-75%注意圏通常ペースでリリース、リスクの高い変更は慎重に
25-50%警戒圏リリース頻度を下げる、信頼性改善タスクを優先
25%以下危険圏新機能リリースを一時停止、信頼性回復に集中
0%（枯渇）凍結機能リリース凍結、ポストモーテムと改善のみ

具体的なシナリオ

--- シナリオ: SLO 99.9%（月間43.2分のバジェット）---

月初: バジェット 43.2分（100%）

Day 5: デプロイ失敗で12分のダウンタイム
  → 残り 31.2分（72%）→ 注意圏
  → アクション: デプロイパイプラインの改善タスクを追加

Day 12: 新機能リリース、問題なし
  → 残り 31.2分（72%）→ 注意圏
  → アクション: 通常ペース継続

Day 18: DB接続プール枯渇で20分のダウンタイム
  → 残り 11.2分（26%）→ 警戒圏
  → アクション: 残りの月は信頼性改善に集中

Day 25: 大型リリースの要請
  → バジェット不足、リリースを来月に延期
  → 開発チーム: 「エラーバジェットが理由なら納得できる」

エラーバジェットの組織的効果

対立の解消

従来の議論エラーバジェットがある議論
「もっと慎重にテストしろ」「バジェット残量は十分。リリースしよう」
「早くリリースしたい」「バジェットが少ない。今月は信頼性改善を優先」
「障害が多すぎる」（主観）「バジェット消費率が計画の2倍」（客観）
「安定性が最優先だ」「バジェットに余裕がある。イノベーションに使おう」

インセンティブの整合

ステークホルダーエラーバジェットによるインセンティブ
開発チームバジェット残量が多い = リリース頻度を上げられる → 信頼性改善に協力するインセンティブ
SREチームバジェット枯渇 = リリース凍結権を持つ → 具体的な改善提案をするインセンティブ
プロダクトマネージャーバジェット管理 = 機能リリース計画の精度向上 → バランスの取れた計画のインセンティブ
経営層バジェット = リスクの可視化 → 投資判断のインセンティブ

エラーバジェットの計算と可視化

計算式

可用性エラーバジェット:
  月間バジェット = (1 - SLO) × 30日 × 24時間 × 60分

  例: SLO 99.9%
  = (1 - 0.999) × 30 × 24 × 60
  = 0.001 × 43,200
  = 43.2分

レイテンシエラーバジェット:
  月間バジェット = (1 - SLO割合) × 月間総リクエスト数

  例: P99 ≤ 500ms のSLO 99.5%、月間1,000万リクエスト
  = (1 - 0.995) × 10,000,000
  = 50,000リクエストまでSLO超過可能

ダッシュボードの設計

表示項目説明
バジェット残量（%）当月のエラーバジェット消費率
バーンレートバジェットの消費速度（1.0 = 計画通り）
予測枯渇日現在のバーンレートでバジェットが枯渇する予測日
SLI推移グラフ直近30日のSLI値の推移
インシデント影響各インシデントのバジェット消費量

バーンレート

バーンレート = 実際のエラー率 / 許容エラー率

例: SLO 99.9%（許容エラー率 0.1%）で実際のエラー率が0.2%の場合
  バーンレート = 0.2% / 0.1% = 2.0

バーンレートの解釈:
  1.0 = 計画通りのペース（月末にちょうど枯渇）
  2.0 = 2倍の速さで消費（月の半分で枯渇）
  0.5 = 半分の速さ（余裕あり）

まとめ

ポイント内容
エラーバジェットの本質数字ではなく意思決定の仕組み
組織的効果開発と運用の対立をデータで解消する
バーンレートバジェット消費速度の指標。1.0が基準

チェックリスト

  • エラーバジェットの計算方法を理解した
  • バジェット残量に基づく意思決定フレームワークを理解した
  • バーンレートの概念と解釈を理解した

次のステップへ

次は「SLO設計の実践」です。実際のサービスに対してSLI/SLOを設計する実践的な手法を学びましょう。

推定読了時間: 30分