【SRE】エラーバジェットとは
前提
先日、こちらの本を読んだので軽くアウトプット。(まだ読書中)
エラーバジェットとは
エラーバジェットは、サービスの信頼性がどの程度損なわれても許容できるかを示す指標です。
例えば、例えば、サービスレベル目標（SLO）が「99.99%」のリクエスト応答率を維持することである場合、エラーバジェットは、エラー応答率を「0.01%」以下に抑えることになります。
引用
なぜ必要なのか？
結論としては、開発チームと運用チームの対立を避けるためにあります。
前提として、開発チームと運用チームは対立関係にあります。
なぜなら、運用チームにとっての目標は、「システムの安定稼働」である一方で、開発チームにとっての目標は「新機能を迅速にリリースしてプロダクトに変化を与えること」だからです。
エンジニアの方ならわかりますが、往々にして不具合や障害発生は、新機能リリースなどのイベント発生時によく起こるため、2つのチームの目標は本質的に相反するものとなっています。
そこでGoogleのSREの考え方では、「100%の信頼性を目標とすることはいかなる場合でも間違っている」と考えます(例外あり。ex. ペースメーカー等)。100%の可用性と99.99%の可用性をもつシステムの違いはユーザにとっては違いがなく、エラーバジェットを持つことで開発チームと運用チームの対立を避けることができます
どう運用すべきか
エラーバジェットに余裕がある際は、開発チームはある程度のリスクをとってもローンチをしたいと考えます。
一方運用チームもバジェットがあるため、そこに対して協力的になります。
逆に、システムの信頼性が損なわれてしまいエラーバジェットを使い果たしてしまった場合、
開発チームは新機能のリリースを中止し、信頼性を高めるための対策を優先させる運用 を行うでしょう。
エラーバジェットが底をつきそうな状態では、開発チームは、新機能のリリースを中止したくないと考える一方で、リスクを取ることができません。そのため信頼性を高めるためのテスト作業の割合を増やす、リリースの速度を落とす等の対応を行うことが必要になります。
このように、エラーバジェットがあることで、両チームのイノベーションと信頼性の適切なバランスが取れるよう共通目標を持って協力し合うことができます。
まとめ
開発と運用という構造だけでなく、ビジネスとエンジニアという構造でも適用できそうな考え方だなと私は思いました。（Biz側は早くいいものを届けたいと考える一方、エンジニアチームもそうは考えつつも、バグを生み出したくないと考えて消極的になりがち）
こういう考え方1つでかなり組織運営がしやすくなるのかなと思いました。。。。
すげええいい勉強になる、、この本。
Discussion