「99.9% を目標にする」と決めたあとで、では今月はあと何分まで落としてよいのでしょうか。
その問いに数字で答えるのがエラーバジェットです。
信頼性と開発速度は、放っておくと現場の力関係で決まってしまう。
「もっと安全に」と「もっと速く」がぶつかったとき、声の大きいほうが通ってしまう——その決め方を数字に置き換える道具なのです。
エラーバジェットはSLOの裏返し
計算式そのものは、拍子抜けするほど単純です。
SLO が 99.9% なら、残りの 0.1% がそのまま「落としてよい量」になる。
Google の SRE 本は、この予算をプロダクト開発チームと SRE が四半期ごとに合意するものとして説明しています。
同書の例では、SLO が「四半期のクエリの 99.999% を成功させる」なら予算は 0.001% で、0.0002% を落とした障害は予算の 20% を使ったと数える。
30 日ウィンドウで 99.9% を掲げた場合なら、使ってよい時間は 43 分ほど。
「三つ九」と口で言うより、43 分と言われたほうが体感としてつかみやすいのではないでしょうか。
数字にすると対立がほどける
エラーバジェットの効きどころは、計算よりも交渉の場にあります。
SRE 本は、開発チームがプロダクトの速度で評価され、SRE が信頼性で評価されるという評価軸のねじれを出発点に置いている。
しかも両者は持っている情報が違い、開発側はリリースの手間を、SRE 側は本番の状態をよく知っている、という非対称も重なります。
そこで同書は、政治や恐れや希望で決めるのではなく、双方が合意した客観的な指標で交渉しようと提案するのです。
Google SRE の非公式なモットーとして紹介されているのが「Hope is not a strategy」という一文。
予算が残っていればリリースを進めてよく、尽きたら止める。
ルールが先に決まっていれば、障害のたびに誰が悪いかを探す会議が要らなくなるわけですね。
SRE という役割そのものの成り立ちは、別記事にまとめました。
減り方の速さはバーンレートで測る
残量だけを見ていると、判断が手遅れになります。
そこで使うのがバーンレート、つまり SLO に対して予算をどれくらいの速さで消費しているかという比率。
SRE ワークブックの表では、99.9% の SLO に対してバーンレート 1 は誤り率 0.1% で、ちょうど 30 日で使い切る速度と説明されています。
同じ表で、バーンレート 2 なら 15 日、10 なら 3 日、1,000 なら43 分で全部溶ける。
残量ではなく速度を見れば、まだ余っているうちに手を打てるようになる。
同書が出発点として推している閾値は、ページ通知が 1 時間で予算の 2%、6 時間で 5%、チケット起票が 3 日で 10% という組み合わせです。
使い切ったあとの選択肢は一つではない
「予算が尽きたらリリース停止」という説明だけが独り歩きしがち。
実際には SRE 本も、単純なオンオフよりリリース速度を落とす、あるいは巻き戻すといった段階的なやり方を挙げています。
ネットワーク障害やデータセンター障害のような自分たちの過失でない事象も、同じように予算を削る扱いになる。
だからこそ、予算は開発と運用が共同で持つという建て付けが効いてきます。
逆に、機能が出せないほど予算が窮屈なら SLO を緩めて予算を増やす、という判断も同書は認めているのです。
予算が毎回ほとんど余るなら、それは目標が厳しすぎて速度を捨てているサインと読めますよね。
導入でつまずきやすい三つの前提
道具が効くかどうかは、周辺の条件でかなり変わります。
一つ目は、SLI と SLO が先に決まっていること。
測り方と目標値が無いところに予算は作れないので、順番を飛ばせません。
二つ目は、計測を中立な立場が担うこと。
SRE 本は実際の稼働時間を「中立な第三者」である監視システムが測る、と明記しています。
三つ目が、いちばん抜けやすい前提。
SLO を割ったときに本当にリリースを止められる権限が無いと、予算はただの数字になるという但し書きが、同書にははっきり書かれている。
権限とセットで導入して初めて、自己抑制が働く仕組みになると考えておくとよさそうです。
DevOps との関係を先に押さえておくと、この予算の位置づけも入りやすいはず。
予算の考え方そのものはGoogle SRE Book「Embracing Risk」にまとまっています。
バーンレートと閾値の根拠はSRE Workbook「Alerting on SLOs」。
予算を使い切らないために手で回している作業そのものも、トイルとして測って減らす対象になります。
最後に
エラーバジェットは、信頼性を上げるための道具ではありませんでした。
どこまで落としてよいかを先に決めて、そのぶんを開発速度に回すための道具。
だから SLO を決めた時点で予算は自動的に決まり、あとは減り方を速度で見て、尽きる前に手を打つという運用に落ちます。
私もまだ学んでいる側なので、まずは「今月あと何分」を言える状態を作るところから。
以上です。
コメントを残す