エラーバジェット とは？

信頼性を守りながら新機能も届けたいからだよ。目標の信頼性をSLOとして決め、どこまでの失敗を許容するかを数値にする。残量や消費速度を共有すると、開発と運用で判断するための共通のものさしになるんだ。

成功率のSLOが99.9%なら、失敗の許容割合は100% − 99.9% = 0.1%だよ。対象のリクエストが100万件なら、許容枠は1,000件。時間ベースで30日間の稼働率を測る場合なら43.2分になる。同じ99.9%でも、測る対象によって件数か時間かが変わるんだ。

意図的に利用者を困らせるための枠ではないよ。残っていてもテストや安全なリリース手順は必要。どれだけのリスクを取れるか、信頼性の改善をいつ優先するかを考えるために使うんだ。

事前に合意したエラーバジェットポリシーで決めるよ。新機能の変更を控えて信頼性改善を優先する方法がある。一方、Googleの公開例では緊急対応やセキュリティ修正に例外を設けている。どの変更を止めるか、誰が判断するかも明文化しよう。

月ごとの固定期間なら区切りが変わるけれど、直近4週間などの移動する期間で測る方法もあるよ。古い失敗が期間外に出ると状況が変わる。まず測定期間と成功・失敗の数え方をそろえ、消費が急増したときにも気づけるようにしよう。