エラーバジェットとは｜全面停止なら1.4時間で、月ぶんを使い切る

全面停止なら1.4時間で、月ぶんを使い切る

障害の重さごとに、使い切るまでの時間を数えました。軽い劣化でも数日で尽きます。

エラーバジェットがどれくらいの速さで減るのかを、実際に走らせて数えました。目標99.9%・月10万件という条件です。

この条件で許される失敗は100件です。ここから、障害の重さごとに使い切るまでの時間を出しました。

const allow = Math.round(MONTH_REQ * (1 - SLO));   // 月に許される失敗
const PER_HOUR = MONTH_REQ / (30 * 24);            // 1時間あたりの要求数

for (const rate of [0.5, 0.1, 0.05, 0.01, 0.002]) {
  const perHour = PER_HOUR * rate;
  const hours = allow / perHour;                   // 使い切るまでの時間
}

目標 99.9%・月 100,000件のとき、月に許される失敗は 100件

障害の重さ    失敗の割合  1時間あたりの失敗  使い切るまで  月の何%を消費（1時間で）
全面的に停止             50.0%             69.4件         1.4時間                 69.4%
大きく劣化              10.0%             13.9件         7.2時間                 13.9%
一部で失敗               5.0%              6.9件        14.4時間                  6.9%
軽い劣化                1.0%              1.4件          3.0日                  1.4%
ほぼ正常                0.2%              0.3件         15.0日                  0.3%

1時間あたりの平均の要求数: 138.9件

上の表を見てください。全面的に停止すると1.4時間で月ぶんを使い切ります。

気づく時間と釣り合わせる

1.4時間という数字は、気づいて直すまでの時間と直接比べられます。夜間に起きて朝まで気づかないなら、その時点で目標を割ります。

右端の列も同じ話です。全面停止の1時間で月ぶんの69.4%を消費します。1時間の対応の遅れが、月の大半を持っていきます。

軽い劣化のほうが怖い

1%の軽い劣化なら3.0日で使い切ります。全面停止より長いですが、こちらは気づきにくい形です。

100件に1件が失敗している状態は、利用者からの苦情も散発的になります。気づかないまま3日経つほうが、はるかに起こりやすいことです。

エラーバジェットとは何か

目標と100%の差が、その期間に許される失敗の量です。使い切ってよい枠として扱います。

エラーバジェットは、目標に対して許される失敗の量です。日本語では失敗の予算と呼ばれます。

差が枠になる

計算は単純です。Googleの資料も、この2つの数字の差が、その四半期に残っている信頼できなさの予算であるとしています。

目標が99.9%なら、差は0.1%です。前の節の条件では月10万件に対して100件でした。

100%を目指さない

そもそもなぜ枠を設けるのか。同じ資料は100%はおそらく正しい信頼性の目標ではない。達成できないだけでなく、利用者が望む水準や気づく水準を超えていることが多いとしています。

つまり失敗をゼロにすることは目的ではありません。決めた枠のなかに収めることが目的です。

枠は使ってよい

残っている枠は、変更を出すために使えます。資料は測定した稼働率がSLOを上回っている限り、つまりエラーバジェットが残っている限り、新しいリリースを出せるとしています。

1. 枠が大きいとき。変更を積極的に出せる
2. 枠が減ってきたとき。出す間隔を空ける
3. 枠を使い切ったとき。変更を止めて信頼性を戻す
4. 枠が余ったまま期末。目標が緩すぎる可能性がある

4番目も判断材料です。使い切らないなら、もっと速く出せたということになります。

使い切ったときの動きを先に決めておく

枠が尽きたときに何を止めるかを、あらかじめ決めておきます。決めていなければ、ただの数字で終わります。

エラーバジェットは数えるだけでは意味がありません。尽きたときに何が変わるかが決まっていて、初めて働きます。

止めるものを決める

いちばん分かりやすいのは新しい変更を止めることです。枠が戻るまで、信頼性を上げる作業に振り向けます。

決めておかないと、枠が尽きても何も起きません。数字だけが報告されて終わります。

立場をそろえる仕掛け

この決め方には副次的な効果があります。Googleの資料は、エラーバジェットは動機をそろえ、運用側と開発側の共同の責任を強めるとしています。

同じ資料は続けて、予算が大きいときは開発側がより多くの危険を取れる。予算がほぼ尽きたときは、開発側自身がより多くの検査や、出す速さを落とすことを求めるようになると述べています。

止める判断が数字で決まるので、立場ごとの主張のぶつかり合いになりません。

始め方

1. 目標の水準を決める。ここが決まらないと枠も出ない
2. 月の要求数を数える。枠を件数に直す
3. 過去の障害を当てはめる。実際にどれだけ使ったか
4. 尽きたときの動きを決める。何を止めるか、誰が決めるか

3番目をやると水準の妥当さも分かります。過去の障害で毎月使い切っているなら、目標が高すぎるか、直すべき箇所があるということです。