フレームワーク活用ガイドひとことで言うと#
SLO（サービスレベル目標）から逆算した「許容できる障害の量」がエラーバジェット。バジェットが残っていれば積極的にリリースし、枯渇したらリリースを止めて信頼性改善に集中する。スピードと信頼性のトレードオフを定量的に管理する仕組み。
押さえておきたい用語#
- Error Budget（エラーバジェット）
- SLOの目標値から算出される許容可能な障害量のこと。例えばSLO 99.9%なら、月間で0.1%分の障害が「予算」になる。
- SLO（Service Level Objective）
- サービスの信頼性について内部で設定する目標値を指す。SLAとは異なり顧客への契約ではなく、チームの運用目標。
- SLI（Service Level Indicator）
- SLOの達成度を測る具体的な指標。レイテンシ、エラー率、可用性などが使われる。
- Burn Rate（バーンレート）
- エラーバジェットの消費速度である。急速に消費されているならアラートを出す。
- Error Budget Policy
- エラーバジェットが枯渇した/しそうなときにどのようなアクションを取るかを事前に定めたルール。
エラーバジェットの全体像#
こんな悩みに効く#
- 「もっと速くリリースしたい」vs「安定性を優先したい」の議論が終わらない
- 障害対応が場当たり的で、信頼性改善の優先順位が付けられない
- SLOを設定したが運用に落とし込めていない
基本の使い方#
SLO 99.9%の場合、月間のエラーバジェットは0.1%。30日間で約43分のダウンタイムが「予算」になる。
| SLO | 月間エラーバジェット |
|---|---|
| 99% | 約7.2時間 |
| 99.9% | 約43分 |
| 99.95% | 約22分 |
| 99.99% | 約4.3分 |
具体例#
BtoB SaaS。プロダクトチームは「週2回リリースしたい」、SREチームは「月1回で十分」と主張し、毎月の計画会議が紛糾していた。
エラーバジェットを導入し、データ駆動で判断する仕組みに。
| 月 | エラーバジェット残量 | 判断 | リリース回数 |
|---|---|---|---|
| 1月 | 78% | リリースOK | 週2回（8回） |
| 2月 | 42% | 注意。大規模変更は延期 | 週1回（4回） |
| 3月 | 12% | リリース凍結。信頼性改善 | 0回 |
| 4月 | 85% | リリース再開 | 週2回（8回） |
チーム間の対立が「バジェットが残っているかどうか」という客観的な基準に置き換わり、計画会議の所要時間が 2時間 → 30分 に短縮された。
月間1,000万ユーザーの動画配信サービス。SLO 99.95%（月間約22分のダウンタイム許容）を設定。
Burn Rate Based Alertingを導入。
- 1時間で月間バジェットの5%以上消費 → P1アラート（即対応）
- 6時間で月間バジェットの10%以上消費 → P2アラート（1時間以内対応）
- 3日で月間バジェットの50%以上消費 → P3アラート（翌営業日対応）
従来の「エラー率が1%を超えたらアラート」に比べて、誤アラートが 80%減少 し、本当に対応が必要な障害だけを検知できるようになった。
大規模ECプラットフォーム。年末セール期間にトラフィックが通常の10倍になり、毎年エラーバジェットを使い切っていた。
月別のバジェット配分を事前に計画する運用を導入。
- 10月: バジェットを温存（リリース最小限、信頼性テスト強化）
- 11-12月（セール期間）: バジェット消費を想定内に管理
- 1月: バジェットリセット、通常運用に復帰
セール期間前に信頼性改善に投資する正当な根拠ができ、PMも納得してリリース計画を調整。セール期間中のダウンタイムは前年比 60%減少 した。
やりがちな失敗パターン#
- SLOを高く設定しすぎる — 99.99%のSLOは月4.3分しか許容されず、ほぼ毎月バジェットが枯渇する。最初は99.9%から始めて実績を見て調整する
- エラーバジェットポリシーを事前に合意しない — バジェットが枯渇してから「どうする？」と議論すると感情的になる。平時にポリシーを決めておく
- 開発チームだけで運用する — PMやビジネスサイドもポリシーに合意しないと、「バジェットが枯渇してもリリースしたい」という圧力に負ける
- バジェットが余っても何もしない — バジェットに余裕があるときは実験的なデプロイやカオスエンジニアリングに使う。余らせるのはバジェットの無駄遣い
まとめ#
エラーバジェットはSLOから逆算した 「許容障害量」 を予算として管理し、リリース速度と信頼性のトレードオフを定量的に判断する仕組み。バジェットが残っていればスピード優先、枯渇したら信頼性優先というシンプルなルールで、チーム間の感情的な対立をデータ駆動の意思決定に置き換える。ポリシーの事前合意とバーンレートの監視が運用のポイントになる。