エラーバジェット

エラーバジェットとは

エラーバジェット (Error Budget) は、SLO (Service Level Objective) で許容される障害の量を予算として管理し、信頼性と開発速度のバランスを取る仕組みである。Google の SRE の実践から広まった考え方で、書籍『Site Reliability Engineering』の第 3 章「Embracing Risk」で定式化されている。

計算方法

可用性の SLO を決めると、その裏返しとして許容される障害の量が自動的に決まる。

SLO: 99.9% の可用性
エラーバジェット = 100% - 99.9% = 0.1%

月間 (30日) のエラーバジェット:
  30日 × 24時間 × 60分 × 0.1% = 43.2 分

→ 月に 43 分までのダウンタイムが許容される

原典のエラーバジェットは停止時間ではなく、四半期あたりのクエリ成功率で定義されている。リクエスト単位の SLO を採る場合、予算は「分」ではなく「失敗を許されるリクエスト数」になる。時間換算はあくまで可用性 SLO の場合の目安である。

SLO とエラーバジェットの関係

30 日を 43200 分として換算すると、9 が 1 つ増えるたびに許容できる停止時間が 1 桁近く縮む。

SLO	エラーバジェット (月間)
99%	7.2 時間
99.9%	43 分
99.95%	22 分
99.99%	4.3 分

エラーバジェットの使い方

残量が意思決定の分岐点になる。障害が起きてから開発と運用が交渉するのではなく、どちらに倒すかを先に決めておくための道具である。

エラーバジェットが残っている:
  → 新機能のリリースを積極的に進める
  → リスクのある変更も許容
  → 実験的なデプロイを実施

エラーバジェットを消費した:
  → 新機能のリリースを凍結
  → 信頼性改善に注力
  → 自動テスト、モニタリングの強化

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

残量ごとの対応をあらかじめ文書化したものをエラーバジェットポリシーと呼ぶ。閾値の刻み方に標準はなく、下表は書き方の一例である。

バジェット残量	アクション
> 50%	通常の開発速度
25〜50%	リスクの高い変更を控える
< 25%	信頼性改善を優先
0%	機能リリースを凍結

エラーバジェットのメリット

「リリースすべきか」を数値で客観的に判断でき、開発チームと運用チームの対立を共通の指標で解消する。99.999% の可用性が本当に必要かを問い直すことで過剰な信頼性投資を防止し、バジェットに余裕がある間は積極的にリスクテイクできる。

100% の可用性を目指さない理由

• エラーバジェットが 0 → 一切の変更ができない
• ユーザーの体験は ISP、デバイス、ネットワークにも依存する。SRE 本は ISP 側の背景エラー率を 0.01% 〜 1% と実測している
• 99.99% と 99.999% の差はユーザーにはほぼ分からない
• コストが指数関数的に増加する

エラーバジェットを扱う関連書籍も多い。