はじめに
サイトリライアビリティエンジニアリング（SRE）について学んだことをアウトプットしたいと思います。
今回は、エラーバジェット編です。
エラーバジェットとは？
エラーバジェットとは、サービスの信頼性がどの程度損なわれても許容できるかを示す指標です。
例えば、サービスレベル目標（SLO）が「99.99%」のリクエスト応答率を維持することである場合、エラーバジェットは、エラー応答率を「0.01%」以下に抑えることになります。
開発チームと運用チームは、エラーバジェットの条件を満たしてシステムの信頼性を維持するという共通目標に向かってお互いに協力し合いながら働きます。
なぜ必要なのか？
エラーバジェットの説明をみると当然の内容のように感じますが、なぜエラーバジェットという共通目標の設定が必要なのでしょうか？
これは、開発チームと運用チームの目標の違いから生じる行動の対立を避ける為になります。
-
開発チームの目標
新機能を出来るだけ迅速にリリースすることが目標になります。
なので、たくさんの新機能を迅速にリリースしたいと考えます。 -
運用チームの目標
システムを安定運用させることが目標になります。
なので、システム変更による問題発生を抑えるためにリリースはできるだけ少なくしたいと考えます。
上記のような目標の違いから両チームの行動に対立が生じてしまうことになります。
この対立を避ける為にエラーバジェット（エラーの予算）という指標を設定します。
どのように運用するのか？
エラーバジェットは、運用チームがエラー対処に充てることができる予算となります。
もし、システムの信頼性が損なわれてしまいエラーバジェットを使い果たしてしまった場合、
開発チームは新機能のリリースを中止し、信頼性を高めるための対策を優先させる運用とします。
このような運用を行うことで開発チームはエラーバジェットに余裕があるときは、新機能の開発に対する速度を優先してリスクを大きく取ることができます。
しかし、エラーバジェットが底をつきそうな状態ではどうでしょうか？
開発チームは、新機能のリリースを中止したくないと考える為、信頼性を高めるためのテスト作業の割合を増やす、リリースの速度を落とす等の対応を行うことが必要になります。
エラーバジェットの最大のメリットは、両チームのイノベーションと信頼性の適切なバランスが取れるよう共通目標を持って協力し合うことができることです。
さいごに
エラーバジェットは、開発チームと運用チームを対立関係から協力関係へ変えるためのとても良い仕組みだと思いました。