エラーバジェットの数理とバーンレート

エラーバジェットを「量」として定義する

SRE と SLO の枠組みでは、エラーバジェットを エラーバジェット = 100% − SLO と説明します。原理レベルでは、これを イベント数の絶対量 に落とすと計算が明確になります。SLO が「直近30日のリクエスト成功率 99.9%」で、その期間の総リクエストが N なら、

許容エラー率 (1 − SLO) = 0.001
バジェット（許容失敗数） = (1 − SLO) × N = 0.001 × N

N が 30日で 1億リクエストなら、バジェットは 10万リクエスト。これが「期間内に失敗してよい総数」です。重要なのは、バジェットを 時間（分）ではなくイベント比 で考えること。トラフィックが昼夜で10倍変動するサービスでは「43分ぶん」という時間換算は誤差が大きく、比率ベースのほうが正確に消費を追えます。

バーンレート：残量ではなく「消費の速さ」

残バジェットだけを見ると、「残り5%」になってから慌てることになります。SRE の鍵は バーンレート（burn rate）、つまり予算を 何倍の速さで消費しているか です。

バーンレート = 実測エラー率 ÷ 許容エラー率 (1 − SLO)

許容エラー率が 0.001 のとき、ある時間窓で実測エラー率が 0.01 なら、バーンレートは 0.01 ÷ 0.001 = 10。これは「通常の10倍の速さで予算を燃やしている」状態です。

バーンレートが意味を持つのは、期間全体を均す基準速度 が 1 だからです。30日のバジェットをちょうど30日で使い切るペースがバーンレート 1。そこから、ある一定のバーンレートが続いた場合に 何時間で全予算を使い切るか が逆算できます。

枯渇までの時間 = SLO期間 ÷ バーンレート
（例：30日 ÷ バーンレート14.4 ≒ 2.08日 ≒ 約50時間）

逆に「特定時間で予算の何割を消費するか」も出せます。これがしきい値設計の中核です。

ある窓で消費する予算割合 = バーンレート × (窓の長さ ÷ SLO期間)
（例：バーンレート14.4 × (1時間 ÷ 720時間) = 0.02 = 予算の2%）

なぜマルチウィンドウ・マルチバーンレートなのか

単一しきい値のアラートには、避けられないトレードオフがあります。

Google の SRE Workbook が推奨するのは、1つのアラート条件に長短2つの窓を AND で結ぶ 方式です。長い窓（例：1時間）で「予算を有意に消費した」ことを確認しつつ、短い窓（例：5分）で「今もまだ燃えている」ことを確認します。短窓の役割は、障害がすでに収束したのに長窓の慣性で鳴り続ける状態（リセットの遅れ）を防ぐことです。

速いバーン（重大）:
  alert if  burn_rate(1h)  > 14.4  AND  burn_rate(5m)  > 14.4
  → 1時間で予算2%消費ペース。即ページング。

遅いバーン（緩慢）:
  alert if  burn_rate(6h)  > 6     AND  burn_rate(30m) > 6
  → 6時間で予算5%消費ペース。チケット／日中対応。

短窓は経験則として 長窓の1/12 にとると、長窓が満杯になる前に短窓が反応・解除できてバランスが良いとされます。複数のバーンレート段（14.4 / 6 / 1 など）を並べる マルチバーンレート にすると、「急性の大障害は即ページ、慢性の微小劣化はチケット」と重大度を分離できます。

検知時間と誤警報の力学

マルチウィンドウ方式の性能は、2つの指標で評価します。検知時間（time to detect） と 検知後の鳴り続け時間（reset time） です。一定のバーンレート r で障害が始まったとき、長窓 w でしきい値 r_th を超えるまでの理論上の検知時間は次のように近似できます。

検知時間 ≒ w × (r_th ÷ r)
（r が r_th と同じなら窓1つぶん、r が大きいほど早く超える）

つまり実害が大きい（r が大きい）ほど速く鳴り、軽微なほどゆっくり鳴る——重大度と緊急度が自動で連動します。これは「CPUが高い」式の固定しきい値アラートにはない性質で、SLO を脅かす速度そのもの を発報基準にしているからこそ得られます。アラートが何を観測すべきかは オブザーバビリティ の設計とも一体です。

リリース速度との力学：予算をリスク原資に使う

バーンレートはアラートだけでなく、リリース速度の制御ループ にもなります。残バジェットが潤沢なら、それは「取ってよいリスクの在庫」です。フィーチャーフラグ でのロールアウト比率を上げ、デプロイ戦略 のカナリア露出を拡大できます。逆に直近のバーンレートが高止まりしていれば、自動でロールアウトを絞る／凍結する、という ポリシー・アズ・コード が組めます。

この力学が、開発の「速く出したい」と運用の「壊したくない」を 同一の数字 で調停します。予算が余っているのに過度に慎重なのは、SRE 的には「遅すぎる」状態です。一方で枯渇後も出し続ければ、ポストモーテム で繰り返し同じ根本原因に行き着くことになります。バーンレートは、その判断を感情ではなく速度の数値に置き換える装置です。

まとめ

• エラーバジェットは (1 − SLO) × 総イベント数。時間換算より イベント比 が正確。
• バーンレート = 実測エラー率 ÷ 許容エラー率。1 が期間消費の基準速度で、速さの倍率 を見る。
• しきい値は バーンレート = 目標消費割合 ÷ (窓 ÷ SLO期間) で逆算。マジックナンバーではない。
• マルチウィンドウ（長窓 AND 短窓）で誤検知と鳴り続けを抑え、マルチバーンレートで重大度を分離する。
• 残量とバーンレートを合わせて読み、リリース速度を自動制御する——それがエラーバジェットの本質的な使い道。