エラーバジェットは交渉の道具だ

一言でいうと

期間バジェットはこれまでに使った割合で、バーンレートは最近の消費の速さです。この2つを区別できて初めて、デプロイを許可するときと止めるときを説明できます。

なぜ必要なのか

架空のオンラインショップで、新機能をデプロイしようとしています。直近1時間は静かですが、先週の障害で30日分のバジェットをすでに超えています。逆に、月間バジェットは十分に残っているのに、今まさに決済リクエストが急速に失敗している日もあります。直近のエラー率だけを見ると前者の事故を見逃し、月間の数字だけを見ると後者の事故に対応できません。人がレポートを読んで終わりにするのではなく、2つの根拠を区別する小さな判断プログラムを作ってみましょう。Pythonの辞書・条件文・JSON入出力を知っていることを前提にします。

どう動くのか

まず、誰のどんな失敗を数えるかを決めます。このラボの合成HTTPデータでは、5xxを失敗、それ以外の観測されたリクエストを成功とします。これは教育用サービスの定義であり、すべての4xxがいつも顧客の落ち度だという意味ではありません。サービスが作り出した誤った認証応答や過負荷による429がユーザーにとっての失敗であれば、別のSLI定義が必要です。ボットや内部の死活確認リクエストを含めるかどうかも文書化し、分子と分母に同じ範囲を適用します。

リクエストベースの99.9% SLOの許容エラー率は0.001です。同じ30日間の全リクエストが100万件なら、許容されるエラーバジェットは1,000件です。失敗が200件なら使用率は200/1000=0.2、つまり20%で、1200件なら1.2となってバジェットを超過しています。この計算には、その30日間全体の失敗件数とリクエスト件数が必要です。

バーンレートは、短いウィンドウのエラー率を許容エラー率で割ったものです。1時間に1万件のうち200件が失敗したなら、0.02/0.001=20倍です。12時間のウィンドウで計算しても、それは12時間のバーンレートにすぎず、自動的に月間バジェットの使用量になるわけではありません。ウィンドウの長さは単位を変えません。最近の速度が20倍でも月間の使用率は0.2のことがあり、今の速度が0でも、過去の障害によって使用率が1.2になっていることがあります。

時間ベースの可用性バジェットは、別の概念です。30日は43,200分なので、99.9%の時間SLOで許容される利用不可時間は43.2分です。99.99%なら4.32分、つまり4分19.2秒です。この数字をリクエストの失敗件数と置き換えて使ってはいけません。静かな時間帯の1分と注文が集中する1分では、リクエストベースのSLOへの影響が異なることがあります。ラボのステップ2は時間バジェットの桁感覚を養う練習で、最後のプログラムではリクエストバジェットを使います。

14.4というアラートの基準も、単位で理解しましょう。30日を720時間とし、1時間に全バジェットの2%を使い続ける一定の速度を考えると、0.02×720=14.4です。残りのバジェットが手つかずで、リクエスト量とエラー率が一定だと仮定すると、約50時間で使い切る見通しになります。すでに使ったバジェット、トラフィックの変化、ローリングウィンドウから抜けていく古い失敗があれば、この見通しは変わります。未来を確定した数字として語ってはいけません。

2つのウィンドウをなぜ一緒に見るのか

障害が終わっても、1時間の平均には失敗が残ります。1時間のバーンレートが20で、直近5分が0なら、長いウィンドウだけを見てページし続けてしまうことがあります。1時間と5分の両方が14.4を超えたときにページする条件は、直近も問題が続いているかを確認します。andをorに変えると、この解消条件がなくなります。ちょうど14.4は、超過ではありません。

少ないリクエストにも注意します。5分間のリクエスト3件のうち1件が失敗すると比率は大きくなりますが、その1件が重要な注文なのか無害なリトライなのかは、数字だけではわかりません。最小トラフィック条件を無条件に付けて、低トラフィック時の失敗をすべて隠してはいけません。この合成実験では、リクエスト0件を正常と推定せず、保留にします。実際のサービスでは、業務への影響に合った別のポリシーと、トラフィック途絶の監視が必要です。

現場での姿

データを取得できなかったのに、空の結果を0に置き換えると「障害なし」と誤解します。同じサービス・同じ終了時刻か、必要なウィンドウ全体を集めたかを、まず確認します。ラボのPrometheusには、約12時間の合成履歴があります。そこに30日のクエリを使ったからといって、30日が観測されたことにはなりません。最後の課題では、別に提供される合成の期間集計を使い、実際のPrometheusから抽出した月間記録を装うことはしません。

この架空のチームの機能デプロイのポリシーは、3段階です。データが不明確ならhold、期間バジェット使用率が1以上ならfreeze、それ以外でも1時間と5分のバーンレートがともに14.4を超えていればfreezeです。残りだけがallowです。使用率の境界は以上、速度の境界は超過という違いに注意してください。保留と凍結はどちらもデプロイを進めませんが、理由が違います。保留はまず観測を復旧し、バジェットの凍結は信頼性の作業を優先します。実際の組織での緊急のセキュリティ変更やロールバックには別の承認ポリシーが必要で、このプログラムは承認しません。

次のラボですること

実際のPrometheusに対して、成功率と2つのウィンドウのバーンレートを問い合わせ、アラートルールを検査します。最後に、合成集計をstdinから読み取るPythonプログラムを書きます。月間バジェットの超過、進行中の障害、回復、データ欠落を互いに区別しながら、レポートと終了コードを残します。明け方にデプロイボタンの前で必要なのは、自信に満ちた文章ではなく、確認できる根拠です。

参考: SREのSLOアラート設計、バジェットポリシーの例。上記の30日・判定境界・保留ルールは、このラボで明示した教育用ポリシーです。