SLA エラーバジェット計算ツール
パーセンテージは真実を隠し、分が真実を語ります。SLA 目標と期間を選ぶと、許容ダウンタイムが計画の拠り所になる数字として表示されます。次に、実際に起きたダウンタイム(または実際に測定した稼働率)を入力すると、バジェットがどれだけ残っているか、どれだけ速く消費しているかが分かります。ブラウザ内での純粋な算術です。
両方の観測フィールドに入力がある場合、ダウンタイムの分が優先されます。そちらの方がより直接的な測定だからです。
- 許容ダウンタイム
- 平たく言えば
- 1 日あたりの平均
- これまでのダウンタイム
- バジェットの残り
- 消費したバジェット
参考:目標と期間ごとの許容ダウンタイム
| SLA 目標 | 28 日 | 30 日 | 365 日 |
|---|---|---|---|
| 99% | 6h 43m | 7h 12m | 3d 15h |
| 99.9% | 40m 19s | 43m 12s | 8h 45m |
| 99.95% | 20m 10s | 21m 36s | 4h 22m |
| 99.99% | 4m 2s | 4m 19s | 52m 34s |
なぜ「分」が議論を変えるのか
SLA のパーセンテージは、誰にも思い描けない約束です。「スリーナイン」は営業資料の中では厳格に聞こえますが、その正確な意味は 1 か月あたり 43 分 12 秒の許容ダウンタイム、つまり 1 回の悪いデプロイと遅いロールバックで使い切ってしまいます。パーセンテージしか議論しないチームは、インシデントの最中に初めて分の存在を知りますが、それは算術を学ぶ最悪のタイミングです。バジェットという枠組みはこれを解決します。許容量を残高のあるリソースにするのです。何かが壊れれば残高は減り、残高が健全なうちはリスクのある移行に意図的に使うことができ、残高が尽きたら、書面であれ暗黙であれ、信頼性が回復するまで機能開発は一時停止するという約束になります。それこそがエラーバジェットの管理上の価値のすべてです。エンジニアリングで最も古い論争である「出荷か安定化か」を、双方が同じ読み方をすることで合意した 1 つの数字に変換するのです。
消費率は、同じ考え方の早期警戒の形です。バジェットが破られるのは、それが尽きた瞬間ではありません。数週間前、支出のペースが枯渇を不可避にし、それでも誰も行動しない瞬間に破られるのです。月の第 1 週でバジェットの半分が消えているのは、変更を凍結し、不安定なものをロールバックし、修正に人員を割く時間がまだあるうちの最大級の警報信号です。同じ 50% でも月の半ばであれば、単にペース通りです。残高だけでなくペースを追跡すれば、バジェットは事後分析の統計ではなく、本来あるべき姿、つまり意思決定がまだ結果を変えられるうちに引かれる意思決定のトリガーになります。
関連ツール:オンコール・スケジューラは午前 3 時に誰がこのバジェットを守るかを計画し、バックアップ保持計算ツールは防御が失敗したときに復旧がどこまで遡れるかを計画します。
さらに読む:1 つの信頼性ルーティン — ローテーション、バックアップ保持、エラーバジェットが 1 つの計画習慣としてどう連携するか。
よくある質問
エラーバジェットとは何ですか?
SLA がすでに許容している障害の量を、時間で表したものです。30 日間で 99.9% の目標は、その期間の 0.1%、すなわち 43 分 12 秒のダウンタイムを、目標が破られるまでに許容します。これをバジェットとして捉えると、抽象的なパーセンテージが、チームが意図的に使うことのできるものに変わります。リリースも移行もメンテナンスも、すべて同じ 43 分から引き出されます。
なぜ 99.99% は 99.9% よりはるかに厳しく感じるのですか?
9 が 1 つ増えるごとに許容量が 10 分の 1 になるからです。30 日間で見ると、99% は 7 時間 12 分、99.9% は 43 分、99.95% は 21 分 36 秒、99.99% は 4 分 19 秒を許容します。これは再起動 1 回分にも満たません。目標を選ぶことは、運用が実際にどれだけのインシデントを吸収できるかを選ぶことです。だからこそ、誠実な目標は願望ではなく、測定された能力から設定されます。
バーンレートとは何ですか?
期間に対してバジェットをどれだけ速く使っているかです。このページの消費率はその単純な形で、これまでのダウンタイムを総許容量で割ったものです。期間の半分が過ぎて 50% 消費していればちょうどペース通りですが、第 1 週で 50% 消費していれば破綻に向かっており、リスクのある変更を凍結するタイミングは、選択肢が残っている今であって、99% になってからではありません。
期間は 28 日、30 日、365 日のどれにすべきですか?
期間を約束に合わせてください。顧客向け SLA は通常、暦月単位で書かれ、月によって 28 日から 31 日です。30 が標準的な計画値で、28 は最も厳しい 2 月のケースです。365 日の視点は年間目標に適し、契約が実際にあなたに約束させる年間の合計を示します。ベンダーが年間値を提示し月次で報告する場合は、比較する前に双方向に換算してください。
計画メンテナンスはバジェットにカウントされますか?
それは契約次第であり、SLA の起草で最も議論になる行の 1 つです。多くの SLA は事前に告知されたメンテナンス時間帯を除外します。一方、多くの SLO(内部目標)は、ユーザーは予定されたダウンタイムと予定外のダウンタイムを違って体験するわけではないという原則のもと、すべてをカウントします。明示的に決め、文書化し、追跡する数字が合意した定義と一致していることを確認してください。