SRE 実践 #2 エラーバジェット運用 — ポリシー文書とバーンレート

エラーバジェットの概念と計算で、バジェットとは何でどう計算するかを扱いました。今回はそのバジェットを組織の意思決定ツールとして機能させる方法です。バジェットはダッシュボードに表示しておく数字ではなく、「この数字がこうなったら、我々はこうする」という事前合意とセットになって初めて力を持ちます。

エラーバジェットポリシー — 障害の前に合意する文書 #

エラーバジェットポリシー(error budget policy)は、バジェットの状態に応じた行動をあらかじめ決めておく文書です。核心はタイミングです。バジェットが残っているとき、利害が絡んでいない状態で合意します。 バジェットが尽きたあとに「それで、デプロイを止めるのか」を議論すれば、その議論は常に力の強い側が勝ちます。

ポリシー文書の骨格は段階別の行動表です。たとえばこうです。

数字と行動は組織ごとに決めればよいのです。重要なのは 3 つです。

1. 行動が具体的であること。「注意する」はポリシーではありません。「緊急修正と信頼性改善以外のデプロイを停止する」がポリシーです。
2. 経営層の署名が必要です。 フィーチャーフリーズはプロダクト組織のロードマップを止める決定です。エンジニアリング内部の文書では実行されず、プロダクト責任者と経営層が事前に署名して初めて、実際の場面で守られます。
3. 例外の手続きも文書に入れます。「凍結中でもデプロイが必要なら誰が承認するのか」を決めておけば、例外がポリシーを崩す代わりに、ポリシーの中で処理されます。

バーンレート — バジェットが減る速度 #

バジェットの残量だけを見る運用には穴があります。残量 80% という数字は、「この 3 週間が平穏だった」と「さっき始まった障害が毎時 10% ずつ燃やしている最中」を区別できません。だから速度を見ます。

バーンレート(burn rate)はバジェットを消費する速度の倍率です。 基準は 1 倍 = ウィンドウの終わりにバジェットがちょうど 0 になる速度です。

• SLO 99.9%、ウィンドウ 28 日なら、許容エラー率は 0.1% です。
• 実際のエラー率が 0.1% ならバーンレート 1 倍。28 日後にバジェットがちょうど尽きます。
• エラー率 1% ならバーンレート 10 倍。バジェットは 2.8 日で底をつきます。
• エラー率 0.05% なら 0.5 倍。バジェットの半分だけ使ってウィンドウが終わります。

計算は単純です。バーンレート = 実際のエラー率 / (1 - SLO)。この数字ひとつで、「この問題は夜中に人を起こしてでも対処すべきか」を判断できるようになります。

速い消費と遅い消費は別の問題です #

バーンレートの観点では、バジェットを脅かす状況は 2 種類あり、対応も異なります。

• 速い消費(fast burn): デプロイ事故やインフラ障害のように、短時間でバジェットを大きく燃やすケースです。数時間以内に人が介入すべきなので、即時呼び出し(ページ) の対象です。
• 遅い消費(slow burn): エラー率が SLO の少し上を数日にわたって漂うケースです。今夜起こす話ではありませんが、放置するとウィンドウ後半でバジェットが尽きます。業務時間に処理するチケットの対象です。

この区別をアラートシステムにそのまま写したのがマルチウィンドウのバーンレートアラートで、次回(アラート設計)の中心テーマです。ここでは原則だけ覚えれば十分です。同じ「バジェットの脅威」でも、速度によってページとチケットに振り分けて対応します。

リリース判断にバジェットをつなぐ #

ポリシーとバーンレートがそろえば、バジェットをデプロイパイプラインの入力として使えます。

• デプロイゲート: バジェット残量がしきい値を下回ったら、パイプラインが非緊急のデプロイを自動的に保留します。人がポリシーを覚えている必要がなくなります。
• 段階的デリバリーとの組み合わせ: カナリア段階でバーンレートが跳ねたら自動ロールバックします。バジェットを「このデプロイは安全か」の判定基準として使うわけです。
• リスク予算の配分: 大規模マイグレーションのようなリスクの高い作業には「バジェットの 20% まで使ってよい」と事前に配分しておけば、危険な作業を漫然と先送りする代わりに、計画的に実行できます。

ここがエラーバジェットの本当の価値です。バジェットは開発速度と信頼性の争いをなくすツールです。 バジェットが残っていれば速くリリースする権利があり、尽きたら速度を落とす義務があります。どちらの側も、感情ではなく数字で正当化されます。

よくある失敗パターン #

• ポリシーなきバジェット: ダッシュボードにバジェットはあるのに、枯渇しても何も起きないケースです。2 回も繰り返せば、誰もバジェットを見なくなります。
• 形骸化したフリーズ: フィーチャーフリーズを宣言したのに「これは重要だから」という例外が続くケースです。例外の承認手続きをポリシーに入れ、例外の回数そのものを記録すべきです。
• SLO が間違っているケース: バジェットが慢性的に枯渇するなら、チームが怠けているのではなく、SLO が現在のシステム能力より高く設定されているシグナルかもしれません。このときの正しい対応は SLO の下方修正か信頼性投資の拡大であって、アラートの無視ではありません。

まとめ #

• エラーバジェットポリシーは、バジェットの状態別の行動を障害の前に合意しておく文書です。行動は具体的に、経営層の署名と例外手続きまで含めます。
• バーンレートはバジェット消費速度の倍率です。実際のエラー率 / (1 - SLO) で計算し、1 倍がウィンドウ終了時にちょうど尽きる基準線です。
• 速い消費はページ、遅い消費はチケット。同じ脅威も速度で対応を分けます。
• バジェットはデプロイゲート、カナリアのロールバック、リスク予算の配分としてリリース判断につながったとき力を発揮します。
• バジェットが慢性的に枯渇するなら SLO 自体を疑います。次回はこのバーンレートをアラートとして実装する方法です。