LESSON 30分

ストーリー

田
田中VPoE
SLOの階層設計ができた。次はSLOを「生きた仕組み」にするための核心 — エラーバジェットポリシーだ
あなた
エラーバジェット自体は知っています。SLOの余白部分ですよね。SLO 99.9%なら0.1%がエラーバジェット
あ
田
田中VPoE
計算はそうだ。だが重要なのは「エラーバジェットが減ったとき何が起きるか」を組織として明文化することだ。これがないとSLOは単なる飾りになる。エラーバジェットポリシーは「開発速度と信頼性のバランス」を自動的に調整するメカニズムなんだ
あなた
バジェットが減ったらデプロイを止める、みたいな話ですか？
あ
田
田中VPoE
それは一つの手段だ。ポリシーはもっと包括的だ。バジェット消費率に応じた段階的なアクション、意思決定プロセス、エスカレーションルール — これらを事前に合意して文書化する。障害が起きてから「どうしよう」と議論するのではなく、事前にルールを決めておくんだ

エラーバジェットの基本

エラーバジェットの計算

概念計算式例（SLO 99.9%、30日間）
エラーバジェット率100% - SLO0.1%
エラーバジェット（時間）30日 × 24時間 × エラーバジェット率43.2分
エラーバジェット（リクエスト）月間総リクエスト × エラーバジェット率5億 × 0.1% = 50万リクエスト

エラーバジェットの消費パターン

エラーバジェット消費の典型パターン:

パターン1: 大規模障害型
  ████████████████████░░░░░░░░░░  1回の障害で大量消費
  → 30分の全面障害で月間バジェットの70%を消費

パターン2: 慢性的劣化型
  ██░██░██░██░██░██░██░██░██░██░  少量ずつ継続的に消費
  → エラーレート0.005%の常時発生で月末にバジェット枯渇

パターン3: デプロイ起因型
  ░░░░░████░░░░░░████░░░░░░████░  デプロイ直後に消費
  → 各デプロイで5-10分のエラー増加

パターン4: 健全型
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ほぼ消費なし
  → バジェット余剰は「リスクのある改善に投資できる余裕」

エラーバジェットポリシーの設計

ポリシーの構成要素

要素説明例
バジェット閾値アクションを起動するバジェット残量の境界線残量50%、25%、0%
トリガーアクション各閾値で実行するアクション機能フリーズ、ポストモーテム必須化
意思決定者アクションの実行を判断する責任者サービスオーナー、SREリード、VPoE
解除条件アクションを解除する条件バジェット回復、改善策の実施完了
例外プロセスポリシーの例外を認めるプロセスVPoE承認によるデプロイ許可

4段階のエラーバジェットポリシー

ステージバジェット残量状態アクション
Green75-100%健全通常運用。新機能開発・実験的デプロイ可
Yellow50-75%注意バジェット消費原因の調査。リスクの高いデプロイに追加レビュー
Orange25-50%警告機能開発の一部凍結。信頼性改善タスクの優先度引き上げ
Red0-25%危険機能フリーズ。全リソースを信頼性回復に投入

ステージ別の詳細アクション

Green（75-100%）

カテゴリアクション
開発通常のスプリント計画。新機能開発可
デプロイ通常のデプロイプロセス
実験カナリアデプロイ、フィーチャーフラグによる実験可
改善技術的負債の返済をスプリントの20%で実施

Yellow（50-75%）

カテゴリアクション
調査バジェット消費の主因を特定し、チーム内で共有
開発新機能開発は継続するが、リスク評価を強化
デプロイ大規模変更にはSREレビューを追加
改善信頼性改善タスクをスプリントの30%に引き上げ

Orange（25-50%）

カテゴリアクション
エスカレーションSREリードとサービスオーナーが対策会議を実施
開発新機能の一部を凍結。クリティカルな機能のみ開発継続
デプロイ全デプロイにSRE承認が必要。カナリアデプロイ必須
改善信頼性改善タスクをスプリントの50%に引き上げ

Red（0-25%）

カテゴリアクション
エスカレーションVPoEに報告。経営層への状況説明を準備
開発全機能フリーズ。信頼性改善のみ実施
デプロイ信頼性改善のデプロイのみ許可。SREリード承認必須
ポストモーテムバジェット枯渇の全原因について公式ポストモーテム実施
改善全スプリントを信頼性改善に充当

エラーバジェットのバーンレート

バーンレートとは

概念説明
定義エラーバジェットが消費される速度
計算式実際のエラーレート / 許容エラーレート
バーンレート1.0ちょうど月末にバジェットが0%になる速度
バーンレート2.0月の半分でバジェットが枯渇する速度

バーンレートに基づくアラート設計

バーンレート意味アラート対応
< 1.0バジェット消費は計画内なし通常運用
1.0 - 3.0やや速いペースで消費中低（Slack通知）原因調査を開始
3.0 - 10.0数日でバジェット枯渇中（PagerDuty Low）即座に調査、対策検討
> 10.0数時間でバジェット枯渇高（PagerDuty High）即座に対応、必要ならロールバック

マルチウィンドウバーンレートアラート

推奨アラート設定:

ページアラート（即時対応）:
  条件: 1時間バーンレート > 14.4 AND 5分バーンレート > 14.4
  意味: この速度が続くと2時間でバジェット2%を消費
  アクション: オンコール即時対応

チケットアラート（計画対応）:
  条件: 6時間バーンレート > 6 AND 30分バーンレート > 6
  意味: この速度が続くと5日でバジェット100%を消費
  アクション: 翌営業日までに調査

報告アラート（情報共有）:
  条件: 3日バーンレート > 1
  意味: 月末までにバジェットが枯渇する可能性
  アクション: 週次SLOレビューで議題化

エラーバジェットポリシーの組織展開

展開の4ステップ

ステップアクション期間成果物
1. ドラフト作成SREチームがポリシー草案を作成2週間ポリシードラフト
2. ステークホルダー合意各チームリード、PdM、VPoEとの合意形成2週間合意済みポリシー
3. パイロット運用Tier 1サービスで試行運用1ヶ月運用レポート
4. 全社展開フィードバックを反映して全サービスに展開2ヶ月組織標準ポリシー

ステークホルダー別の説明ポイント

ステークホルダー主な関心事説明のポイント
開発チーム「機能フリーズは困る」バジェットが健全なら自由に開発できる。フリーズは信頼性を守るための安全装置
PdM「リリーススケジュールへの影響」SLOを適切に設定すればバジェット枯渇は稀。年1-2回程度
経営層「ビジネスへの影響」SLA違反（ペナルティ）を未然に防ぐ仕組み。信頼性への先行投資
SRE「運用負荷の変化」アラート基準が明確化。ポリシーに基づく判断で属人化を排除

例外プロセス

条件承認者例
Red状態での緊急デプロイVPoE + SREリードセキュリティパッチの即時適用
大規模リリースでのバジェット超過見込みPdM + SREリード年に1度のメジャーバージョンアップ
外部要因によるバジェット消費SREリードクラウドプロバイダの障害による影響

「エラーバジェットポリシーの真の価値は”議論を不要にすること”だ。障害が起きたとき、デプロイの可否を毎回議論するのではなく、ポリシーに従って自動的に判断される。これが組織のスケーラビリティだ」 — 田中VPoE

まとめ

ポイント内容
エラーバジェットSLOの余白。開発速度と信頼性のバランスを定量的に管理する仕組み
4段階ポリシーGreen/Yellow/Orange/Redで段階的にアクションをエスカレーション
バーンレートバジェット消費速度に基づくアラート設計で早期検知を実現
組織展開ステークホルダー合意とパイロット運用で段階的に展開

チェックリスト

  • エラーバジェットの計算方法と消費パターンを理解した
  • 4段階のポリシー設計（Green/Yellow/Orange/Red）を理解した
  • バーンレートに基づくアラート設計を理解した
  • 組織への展開ステップとステークホルダー対応を理解した

次のステップへ

次は「SLOレビュープロセス」を学びます。設定したSLOとエラーバジェットポリシーを継続的に運用し、改善していくためのレビュープロセスを設計しましょう。

推定読了時間: 30分