エラーバジェットとは

エラーバジェット（Error Budgets）とはエラーに対する予算であり、SLOに基づき算出される損失可能な信頼性である。サービスの計測された稼働時間がSLOを超えている、換言すればエラーバジェットがまだ残っている状態であれば、チームは新しいリリースをプッシュ（デプロイ）できる。エラーバジェットはプロダクトマネージャーによって規定される客観的なメトリクスであり、SREとプロダクト開発者の緊張を取り除くものである。

SREにおけるエラーバジェット

一般的にプロダクト開発チームとSREチームは目的が異なるため、しばしば両者の間に緊張が生じる可能性がある。

例えば、プロダクト開発チームのパフォーマンスは、主にプロダクトの開発速度で評価されるが、SREチームのパフォーマンスはサービスの信頼性によって評価される。プロダクト開発チームができる限り早く新しいコードを投入することにインセンティブを感じる一方で、SREチームは変更頻度を高めることとは反対の方向にインセンティブを感じるのである。これはSREの前身ともいえるDevOpsでも提起されている根本的な問題である。

以下はこうした緊張の典型的なケースである。

・ソフトウェア障害の許容度
予想外の出来事に対して強いソフトウェアを作成しているかどうか。

・テスト
テストが不足していればサービス障害のリスクは高まるが、やり過ぎてしまうと市場を失うことになる。

・プッシュの頻度
プッシュ（デプロイ）はリスクを伴うため、同時にリスクの低減についても考える必要がある。

・カナリアテストの期間と規模
新しいリリースは、典型的なワークロードの一部を使ってテストするのがベストプラクティスである。

エラーバジェットの策定

エラーバジェットを客観的なデータに基づいて策定するために、以下のやり方が考えられる。

・プロダクトマネージャーがSLOを規定し、四半期に期待されるサービスの稼働時間を設定する

・実際の稼働時間は、中立的な第三者であるモニタリングシステムによって計測される

・この二つの値の差異が、その四半期内の「損失可能な信頼性」という「予算」の残分となる

・計測された稼働時間がSLOを超えている、言い換えればエラーバジェットがまだ残っているなら新しいリリースをプッシュできる

仮に、サービスのSLOが四半期の全クエリの99.999%に正常にレスポンスを返すことである場合、サービスのエラーバジェットは0.001%の失敗率となる。もし何らかの原因によって0.0002%のクエリが失敗したならば、エラーバジェットは20%消費されたことになる。

エラーバジェットのメリット

エラーバジェットの主なメリットは、プロダクト開発者とSREに共通のインセンティブを提供することである。

エラーバジェットに余裕がある場合、プロダクト開発者はどんどんリスクを取って開発することができる。逆にエラーバジェットがほとんど尽きているなら、プロダクト開発者もエラーバジェットを使い切ってリリースできなくなることは避けたいので、もっとテストするようになる。つまり、SREに頼らずともプロダクト開発者自身でリスクを管理できるようになるのである。

上記の前提として、エラーバジェットが尽きた時にローンチを止める権限をSREチームが持っている必要があるが、仮にうまく仕組み化することができれば、チーム全体で責任を持ちながらSLOを緩めてリリース速度を上げたり、逆に引き締めて可用性を高めたりすることが可能になるのである。

想定外のイベントとエラーバジェット

例えば、計測されているSLOがネットワークやデータセンターの障害によって減ってしまった場合でもエラーバジェットは消費される。結果として新しいリリースを減らさざるを得なくなるかもしれないが、稼働時間に対する責任はSREだけではなく全員で共有するものなので、この削減はチーム全体が支持することになるのである。