エラーバジェットが0.1件ならデプロイしてよいか
一言でいうと
エラーバジェットは、ダッシュボードの飾りではなく、検証された観測と合意されたポリシーによって、変更するかどうかを決める入力です。データがないのに、エラーが0件だという理由でデプロイを承認すれば、安全な判断ではなく、証拠のない判断です。
なぜ必要なのか
仮想のプラットフォームチームが、30日間の払い出しの可用性99.9%、速い成功の割合99%を目標に定めました。今回のウィンドウには、有効な試行10000件、可用な成功9995件、速い成功9850件があります。可用性だけを見れば99.95%で目標を超えていますが、速い成功は98.5%で足りません。チームが可用性の1項目だけを見て新機能をデプロイすれば、すでに悪いレイテンシの体験を、さらに悪化させるおそれがあります。
この単元の数値は、ポリシーの判断を学ぶための例です。すべてのプラットフォームにとっての適正な目標という意味ではありません。緩すぎる目標も、ユーザーが区別できない極端な目標も、コストと優先順位を歪めるおそれがあります。どんなユーザー体験を守ろうとしているのかを、まず説明できる必要があります。
どう動くのか
リクエストベースのバジェットの4つの数字
同じ観測ウィンドウで、Nは有効な試行数、Gは良い試行数、Tは目標の割合です。許容される失敗量はN × (1 − T)、実際の失敗量はN − G、残りのバジェットは、許容される失敗量から実際の失敗量を引いた値です。消費割合は、実際の失敗量を許容される失敗量で割ります。ラボは、sli・consumedを小数6桁で表示しますが、バジェットの境界の比較のために、許容される失敗量を整数に丸めません。
N=10000、T=0.999なら、許容される失敗は10件です。失敗が5件なら、5件が残り、半分を消費したことになります。失敗が10件なら、残りはちょうど0です。失敗が20件なら、残り-10、消費割合2で、超過使用を示します。画面をきれいに見せようとして、負の数を0に切り捨てると、超過量が失われます。
N=100のとき、同じ目標を適用すると、許容される失敗量は0.1件です。実際の失敗が0.1件あるという意味ではなく、割合の目標が許容する算術上の量です。失敗が1件なら、この小さなウィンドウのバジェットを10倍使うことになります。0.1を先に0に丸めると、分母が0になり、ポリシーの解釈までおかしくなります。少ないサンプルの敏感さと、代表的な観測ウィンドウを合わせて説明する必要があります。
バジェットの枯渇と変更ポリシーは合意する
Google SREのエラーバジェットポリシーの例は、バジェットの状態を変更の優先順位と結びつけ、責任と例外を文書化するための参考資料です。今回のラボの単純なポリシーは、残りのバジェットが0以下なら、通常の機能変更をfreeze、残っていればshipです。freezeを「すべての作業の禁止」と読まないでください。障害の復旧や緊急のセキュリティ修正には、別の判断・レビュー手順が必要です。ここの関数は、実際のデプロイシステムを呼び出さず、学習用の結論だけを返します。
観測の空白があるか、有効な試行が0件なら、investigateです。この場合、成功率・バジェットの数字をnullとして残し、計算する根拠がないことを明らかにします。ウィンドウで本当にリクエストがなかったのか、コレクターが止まっていたのか、ルーティングが変わったのか、次の調査をする必要があります。入力のcoveredは、観測範囲についての証拠を要約したフラグであり、コードがtrueと書いたからといって、実際の観測の完全性が証明されるわけではありません。
異なるウィンドウの数字を混ぜない
今回のラボのsteady・slow・gapは、同じサービスの連続する3日間ではなく、独立した30日の観測ウィンドウの仮想の事例です。それぞれのウィンドウの中で、分母と分子を合わせます。昨日の分母で今日の失敗量を割ったり、30日全体のバジェットと5分間の失敗件数を、そのまま同じ消費率と呼んだりしません。短い期間の消費速度を利用したアラートの設計には、別の時間区間と割合の定義が必要です。
可用性とレイテンシの判断を合わせるときは、investigateが優先で、次にfreeze、最後にshipです。1つの指標の根拠がないのに、ほかの指標がよいという理由で承認しないためです。優先順位は今回の課題の契約であり、より複雑なサービスのポリシーには、サービスの重要度・依存関係・変更のリスクも含まれることがあります。
現場での姿
steadyは、可用な成功が9995/10000、速い成功が9950/10000で、観測が完全なので、2つのバジェットがどちらも残ります。slowは、同じ可用性でも、速い成功が9850件しかないため、freezeです。gapは、収集された数字が100%でも、covered=Falseなので、investigateです。3つの事例を、1つの状態の文字列だけで提出せず、それぞれのSLI・許容量・残量・消費割合を合わせて残し、次の人が判断の根拠を計算し直せるようにします。
このような判断は、ツールのインストール以上の職務能力です。2026-09-11に確認したSupabase SRE求人は、ユーザー体験に基づくSLI/SLO、エラーバジェットポリシー、運用準備のレビューを結びつけています。このラボは、そのうちの小さな計算・検証のループを扱うもので、大規模な運用経験や、採用要件のすべてを満たしたという意味ではありません。
次のラボですること
まず、HTTPの失敗を分母から落とさないように分類し、実際のリクエストで検証します。そのあと、集計・バジェット・レポートを実装し、正常な事例と反例を合わせて作ります。最後のステップでは、5種類の誤った実装を、自分の事例が区別できるかを検査します。期待値を間違えて書いて失敗させるのではなく、正しい実装は通過させ、誤った実装だけを拒否する必要があります。