エラーバジェット

概要

エラーバジェット（エラー予算）は、SLO が許容する失敗の「残量」です。SLO が「30日間でリクエストの99.9%が成功する」なら、裏返せば「0.1%までは失敗してよい」ことになります。この0.1% — 停止時間に換算すれば30日で約43分 — が、そのチームに与えられたエラーバジェットです。障害やエラーが起きるたびに予算が消費され、残量がゼロに近づけば慎重に、余裕があれば大胆に動く。信頼性を「守るべき聖域」ではなく「使ってよい予算」として扱い直す発想です。

この道具の真価は、リリースの可否という組織的な対立を数値で裁けることにあります。予算が残っているうちは新機能のリリースも実験も自由に行い、予算を使い切ったらリリースを凍結して信頼性の改善に専念する — 誰かの声の大きさではなく、ユーザー影響の実測値が意思決定を下す仕組みです。

なぜ生まれたか

エラーバジェット以前、開発チームと運用チームは構造的に対立していました。開発の評価は「どれだけ速く機能を出したか」、運用の評価は「どれだけ障害を起こさなかったか」。障害の最大の原因は変更なので、運用は変更を拒みたくなり、開発は運用を「進歩を止める門番」と見なす。この綱引きは、どちらが正しいかを判定する客観的な基準がない限り、政治力の勝負になってしまいます。

Google の SRE が持ち込んだ解決は、「SLO を満たしている限り、残りの信頼性は使ってよい資源である」という再定義でした。100%の信頼性を目指さないと決めた瞬間、100%と SLO の間には「意図的に許容された失敗の余地」が生まれます。これを予算として明示すれば、「リリースしてよいか」という水掛け論は「予算は残っているか」という測定可能な問いに変わります。開発と運用が同じ数字を見て同じルールに従う — エラーバジェットは技術指標であると同時に、組織の合意形成の道具として生まれたのです。

詳細

予算の計算と消費

エラーバジェットの計算は単純です。SLO が99.9%なら予算は0.1%。30日間に100万リクエストを処理するサービスなら、1,000リクエストの失敗までが予算内です。時間ベースの SLO なら、30日 × 0.1% ＝ 約43分の停止時間が予算になります。予算は障害だけでなく、デプロイ直後の一時的なエラー増加、依存サービスの不調、ネットワークの揺らぎなど、SLI を悪化させるすべての事象で消費されます。「大障害ゼロでも小さなエラーの積み重ねで予算が尽きる」ことがある点が、障害件数の管理との違いです。

残量で行動を切り替える

エラーバジェットの運用は、残量に応じた行動の切り替えとしてあらかじめ合意しておきます。

予算が潤沢なうちは、CI/CD パイプラインからの頻繁なリリース、カナリアリリースによる段階的な展開、フィーチャーフラグでの実験を積極的に回します。エラーバジェットはカオスエンジニアリングのような「意図的に障害を起こす訓練」の原資にもなります。予算が残っているからこそ、本番でリスクを取る活動が正当化できるのです。

予算を使い切ったら、合意したポリシーに従ってリリースを凍結し、チームの力を信頼性の改善 — 障害の再発防止、ポストモーテムで挙がった改善項目の消化、テストや自動化の強化 — に振り向けます。予算が回復すれば通常運転に戻ります。重要なのは、この切り替えが罰ではなくルールであることです。事前に経営層まで含めて合意されたポリシーだからこそ、凍結の場面で「今回だけは例外に」という政治を排除できます。

バーンレート — 消費の速さで警報を鳴らす

予算の絶対量だけでなく、消費の速さ（バーンレート）を監視するのが実践上の要点です。バーンレート1倍は「ちょうど期間満了で予算を使い切るペース」を意味し、たとえば14.4倍なら1時間で月間予算の2%が溶けていく緊急事態です。モニタリングで SLI を集計し、「速いバーンレートを短い窓で、遅いバーンレートを長い窓で」検知する多段のアラートを組むと、瞬間的なスパイクによる誤報を抑えつつ、じわじわ進行する劣化も捉えられます。閾値ベースの単純な警報に比べ、「このままだと SLO を割る」という未来予測に基づいて鳴る点が本質的な改善です。

落とし穴 — 数字が形骸化するとき

エラーバジェットが機能しなくなる典型例は3つあります。第一に、土台の SLO がユーザー体験と乖離している場合。予算の消費が実害と連動しなければ、凍結にも続行にも説得力がありません。第二に、凍結ポリシーが実際には発動されない場合。「予算は尽きたが今期の目玉機能だから出す」を一度許すと、以後この仕組みは誰にも信用されなくなります。第三に、予算を「使い切らないこと」自体を目標にしてしまう場合です。予算が毎期ほぼ満額残るなら、それは慎重さの証ではなく、リリース速度や実験に投資し損ねているシグナル — SLO が緩すぎるか、チームが必要以上にリスクを避けている — と読むべきです。エラーバジェットは節約するものではなく、信頼性と開発速度のトレードオフを最適な位置で運転するためのハンドルなのです。