エラーバジェット — 障害を許容する予算の概念と計算

前回、SLO を 100% ではない値に決めました。その瞬間、面白いものが生まれます。目標が 99.9% なら 0.1% 分は失敗してもいいという意味で、この「失敗してもいい取り分」に名前を付けたのがエラーバジェット(エラー予算)です。予算という名前は比喩ではなく、運用の仕方そのものです。残高があり、消費され、底をつけば支出が統制されます。

予算の大きさ — 計算は引き算と掛け算だけ #

エラーバジェット = 1 − SLO です。これを測定区間に掛けると、手に取れる大きさになります。

二つの換算を両方作っておくのが実用的です。時間の換算は「今回の 37 分の障害で今月の予算の 86% を使った」のようにインシデントの重さを即座に語ってくれ、リクエスト数の換算は完全停止ではない部分障害(エラー率 5% が 2 時間)を計算できるようにしてくれます。部分障害の消費量は「エラー率 × 継続時間」なので、5% のエラー率 2 時間は、100% 停止 6 分と同じ支出です。

予算が変えるもの ① — 対立がルールになります #

エラーバジェットの最初の使い道は、第 1 回で予告したもの、開発速度と安定性の対立を会議ではなくルールに変えることです。

• 予算が残っていればデプロイし、実験し、リスクを取ります。信頼性が目標を上回っているという意味なので、余った信頼性は速度に替えて使うのが合理的です。
• 予算が尽きたら、事前に合意したポリシーが発動します。典型的には機能デプロイの凍結(ホットフィックス・信頼性の改善のみ許可)、信頼性の作業の優先度の格上げです。

肝心なのは、ポリシーを予算が残っているうちに事前合意しておくことです。尽きた後に「凍結か否か」を議論すれば、結局は力関係の問題に戻ります。文書に固定されたポリシーがあれば、凍結は誰かの判断ではなく残高照会の結果になります。そしてこのルールは開発チームを罰する装置ではありません。予算が潤沢なときは「もっと大胆にデプロイしていい」という許可を与える、双方向の装置として運用してはじめて制度が生きます。

予算が変えるもの ② — アラートが消費速度ベースになります #

伝統的なアラートはしきい値です(「エラー率 1% 超過で呼び出し」)。この方式には二つの外し方があります。短いスパイクで人を起こし(予算で見ればごく小さな支出です)、しきい値のすぐ下でじわじわ続くエラーの垂れ流しは見逃します。

エラーバジェットはこれをバーンレート(burn rate、消費速度)のアラートに変えます。バーンレート 1 は「この速度なら区間の終了と同時に予算がちょうど 0」という速度です。バーンレート 14.4 は 30 日の予算を 2 日で燃やす速度です。実務の標準は二段階です。

• 速い消費(例: 1 時間の窓でバーンレート 14 以上) — 即座に呼び出します。いま大きく漏れています。
• 遅い消費(例: 6 時間の窓でバーンレート 3 以上) — チケット・業務時間の対応です。このままだと予算が数日で干上がります。

この構造の長所は、アラートの意味が自明になることです。「エラー率 1%」は深刻かどうか解釈が要りますが、「この速度なら 2 日後に予算枯渇」はそれ自体が判断です。

運用で直面する現実の問題 #

• 依存が燃やす予算 — クラウドや外部 API の障害も、自分たちの SLI には自分たちの失敗として計上されます。原則的には正しい扱いです。ユーザーは原因を区別しないからです。依存の障害が予算を繰り返し燃やすなら、それは「うちのせいではない」ではなく、リトライ・フォールバック・マルチリージョンのような防御が必要だという信号として読みます。
• 計画メンテナンス(点検の窓) — ユーザーに影響のある計画作業も予算から使います。予算が潤沢なときにメンテナンスを配置する、という形で、メンテナンスの日程の決定にも同じ残高を使います。
• 区間の方式 — カレンダー基準の 30 日(毎月リセット)は理解しやすく、ローリング 30 日は月初のリセット直後に予算が急に潤沢になる歪みがありません。始まりはカレンダー基準が楽で、成熟したらローリングへ移るチームが多いのです。
• 使わなすぎるのも信号です — 予算が毎月大半残るなら、目標が実際の能力より緩いという意味で、その分デプロイを保守的にしている可能性があります。予算は使うためにあるのです。

始め方 — 小さく、一つのサービスから #

導入の手順は、SLO さえあればシンプルです。コアサービス一つの SLO から予算を換算してダッシュボードに残高とバーンレートを載せ、二段階のバーンレートアラートを設定し、枯渇時のポリシー 1 ページを関係チームと合意します。最初の月の目標はルールの完璧さではなく「残高を見る習慣」です。インシデントが予算の言葉で振り返られ始めたら(次回扱います)、制度が根づいたということです。

まとめ #

• エラーバジェット = 1 − SLO。時間とリクエスト数の両方に換算しておけば、インシデントの重さと部分障害の支出を即座に語れます。
• 予算が残っていれば速度に使い、尽きたら事前合意のポリシー(デプロイ凍結、信頼性優先)が発動します。ポリシーは必ず枯渇の前に合意します。
• アラートはしきい値ではなくバーンレートで設定します。速い消費は呼び出し、遅い消費はチケットという二段階が標準です。
• 依存の障害も予算から使います。繰り返されるなら免責の事由ではなく、防御の設計が必要だという信号です。
• 毎月余る予算は目標が緩いという信号です。予算は使うためにあります。

次回は予算を実際に燃やす瞬間の話、インシデントハンドリングです。