エラーバジェットの運用

ストーリー

「SLO が 99.9% だとすると、0.1% は『失敗しても良い』 ことになる。この 0.1% がエラーバジェットだ」

松本先輩がダッシュボードのグラフを指した。

「エラーバジェットは、信頼性とイノベーションの バランスを取るための仕組みだ。 予算が残っていれば積極的にリリースできるし、 使い切りそうならリリースを止めて改善に集中する。 これがSREの真骨頂だ」

エラーバジェットとは

エラーバジェットとは、SLO で許容される「失敗の量」のことです。

計算方法

エラーバジェット = 1 - SLO目標値

例: SLO が 99.9% の場合
  エラーバジェット = 1 - 0.999 = 0.001 = 0.1%

30日間のエラーバジェット:
  全リクエスト数（推定）: 1,000,000 件/月
  許容エラー数: 1,000,000 × 0.001 = 1,000 件

  時間換算:
  30日 × 24時間 × 60分 = 43,200 分
  許容ダウンタイム: 43,200 × 0.001 = 43.2 分/月

エラーバジェットの消費例

月初:  エラーバジェット 100% 残り

Week 1: 新機能リリース → レイテンシ上昇で 15% 消費
         残り: 85%

Week 2: DB移行 → 一時的な障害で 25% 消費
         残り: 60%

Week 3: 通常運用 → 軽微なエラーで 5% 消費
         残り: 55%

Week 4: 大型リリース予定
         → 55% 残っているのでリリース可能

エラーバジェットポリシー

エラーバジェットの残量に応じてチームの行動を変えるルールです。

┌──────────────────────────────────────────┐
│       エラーバジェットポリシー           │
├──────────────────────────────────────────┤
│                                          │
│  残量 75-100%: 通常運用                 │
│  ├── 新機能のリリースを積極的に行う     │
│  ├── 実験的な変更も許可               │
│  └── 通常のリリースサイクルで運用       │
│                                          │
│  残量 50-75%: 注意                      │
│  ├── リリース前のテストを強化           │
│  ├── カナリアリリースの範囲を縮小       │
│  └── 大規模な変更は慎重に判断           │
│                                          │
│  残量 25-50%: 警戒                      │
│  ├── 必要最小限のリリースのみ           │
│  ├── 信頼性改善タスクを優先             │
│  └── 変更のロールバック基準を厳格化     │
│                                          │
│  残量 0-25%: 凍結                       │
│  ├── 機能リリースを凍結                 │
│  ├── 全リソースを信頼性改善に投入       │
│  ├── ポストモーテムの実施               │
│  └── SLO達成まで凍結を継続             │
│                                          │
└──────────────────────────────────────────┘

エラーバジェットの活用

1. リリース判断の基準

リリース判断フロー:

新機能をリリースしたい
     │
     ▼
エラーバジェットの残量は？
├── 50%以上 → リリースOK（通常手順）
├── 25-50% → リリースOK（カナリアリリース必須）
└── 25%未満 → リリースNG（信頼性改善を優先）

2. 開発チームとSREの共通言語

従来の議論:
  開発: 「早くリリースしたい」
  運用: 「安定性が心配だからリリースしたくない」
  → 感覚的な議論で平行線

エラーバジェットでの議論:
  開発: 「エラーバジェットが70%残っているので、
         この機能をリリースしたい」
  SRE: 「リリースのリスクを考慮しても50%は残る見込み。
         問題ないのでリリースしましょう」
  → データに基づいた建設的な議論

3. インシデント後の対応

インシデント発生
     │
     ▼
エラーバジェット消費量を計算
     │
     ├── 消費量 < 10% → 通常対応、ポストモーテム実施
     │
     ├── 消費量 10-30% → 緊急ポストモーテム
     │                    再発防止策を次スプリントに組み込み
     │
     └── 消費量 > 30% → 機能リリース凍結
                          全チームで信頼性改善に注力

エラーバジェットダッシュボード

──────────────────────────────────────────
  注文API - エラーバジェット状況
──────────────────────────────────────────

SLO: 99.9% (30日ローリングウィンドウ)

  消費済み ████████░░░░░░░░░░░░  38%
  残り     ░░░░░░░░████████████  62%

  許容ダウンタイム: 43.2分
  消費済み:        16.4分
  残り:            26.8分

  バーンレート: 1.27x (やや高め)
  バジェット枯渇予測: 残り19日

  ステータス: ⚠️ 注意
──────────────────────────────────────────

バーンレート

エラーバジェットの消費速度を示す指標です。

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

バーンレート 1.0 → ちょうどペース通り（30日で使い切る）
バーンレート 0.5 → 余裕あり（60日分の余裕）
バーンレート 2.0 → 倍速で消費中（15日で使い切る）
バーンレート 10.0 → 危険（3日で使い切る）

アラート閾値:
├── バーンレート > 2.0 → 警告アラート
├── バーンレート > 5.0 → 緊急アラート
└── バーンレート > 10.0 → ページング（即座に対応）

まとめ

チェックリスト

• エラーバジェットの計算方法を説明できる
• エラーバジェットポリシーを設計できる
• エラーバジェットを使ったリリース判断ができる
• バーンレートの概念を理解した
• エラーバジェットが開発とSREの共通言語になることを理解した

次のステップへ

エラーバジェットを学んだら、次はトイル削減の実践を学びます。手動で繰り返す運用作業を自動化で排除する方法を見ていきましょう。

推定読了時間: 30分