エラーバジェット
定義
エラーバジェット = 1 - SLO
例:SLOが99.9%(月間)であれば、エラーバジェットは0.1%。30日 × 24時間 × 60分 × 0.1% ≈ 43.2分が許容できる停止時間。
この「バジェット」をどのように使うかは開発チームが決める。新機能リリース、インフラ変更、実験はすべてバジェットを消費する。
なぜ重要か
信頼性と開発速度のトレードオフを明示的かつ客観的に管理できる:
- バジェット残あり → 積極的なリリース・実験が合理的
- バジェット枯渇 → 信頼性改善を最優先にする(新機能リリース凍結)
この判断を「感情」ではなく「数値」でできる点が最大の価値。SREと開発が対立するのではなく、同じバジェットを共有するパートナーになれる。
適用場面
- リリース判断の議論で「今リリースしても大丈夫か」が主観になっているとき
- SREが「もっと慎重にすべき」と言い、開発が「速く出したい」と言っているとき
- インシデントの頻度を定量化したいとき
エラーバジェットポリシー
あらかじめ「バジェットがXX%消費されたら何をするか」を合意しておく:
| 消費状況 | アクション |
|---|---|
| 0〜50% | 通常どおり開発・リリース |
| 50〜75% | リリースの影響分析を強化 |
| 75〜100% | リリース凍結、信頼性改善にスプリントを割く |
| 100%超 | SLAへの影響を検討 |
関連概念
- SLO / SLI / SLA — エラーバジェットの源泉
- バーンレート — エラーバジェットの消費速度
- 多ウィンドウ多バーンレートアラート — バジェット消費の早期検知
出典
Google SRE Workbook(Betsy Beyer他)第2章「Implementing SLOs」