前回は、リスクの受容に関して、学びました。信頼性の向上のみを行うのではなく、必要に応じて、トレードオフを行うことで、より意味のある改善を行うことができます。
今回は、受容したリスクによって、生まれたリソースを用いるためにエラーバジェットの考えを導入し、活用する方法を学びます。
どこにでもあるありふれた対立
以前の回で、プロダクト開発チームとSREチームの間に文代が生まれているという話をしました。これは、自分のチームの利益を増やすことは、相手のチームの利益を抑えることで成り立つような関係になっていたからでした。
しかし、そのような対立やトレードオフは、どこにでもあります。予想外のことに強いソフトウェアは、ユーザーが安心して、使うことができますが、強すぎれば、使いずらく、弱すぎれば、使い物になりません。サービス障害やサービスの信頼を落とすようなことをしないために、様々なテストをする必要がありますが、やりすぎれば、市場を失うかもしれません。リリースに伴うリスクの低減とその他の作業とのバランスをどのようにとるべきでしょうか？この線引きは、個人やチームの中の何ならの基準によってなされることが多いです。
そういった判断は、政治、恐怖、あるいは願望によってきめられているかもしれません。1
この決定を下すうえで、客観的なメトリクスがあることは、より良い交渉の結果を導くためにとても重要です。
エラーバジェットは、そのため指標の一つとなります。
エラーバジェットの形成
エラーバジェットとは、リスクを受け入れたことにより、生まれる余剰のリソースです。
どの程度のリスクを受け入れるのかを求めるためには、まずサービスレベルの目標、すなわちSLO（Service Level Objective)を決定する必要があります。その後、実際の稼働時間を計測します。SLOと実際の稼働時間の差分が「損失可能な信頼性」という「予算」の残分となります。計測された稼働時間がSLOを超えている、言い換えれば、エラーバジェットがまだ残っているなら新しいリリースをプッシュできます。
仮に0.001%の失敗率をエラーバジェットとした場合、0.0002%が失敗すると、エラーバジェットは20%消費されます。失敗が少ないほど、エラーバジェットを確保でき、プロダクトの開発に取り組めることになります。
メリット
エラーバジェットを用いると、開発とSRE、双方にメリットがあります。
システムのSLOを満たしている限り、リリースを継続できます。SLOを満たせないことが頻発し、エラーバジェットを使い切りそうなら、リリースを一旦中断し、システムの弾力性を上げたり、パフォーマンス改善のための取り組みをします。
エラーバジェットをもとに次の取り組みを柔軟に判断することもできます。プロタクト開発チームがテストをそこそこにリリースを早く行いたいと考えるとき、エラーバジェットが多いなら、失敗率が上がるリスクを取ってでも、リリースを早めることができます。エラーバジェットが少ないなら、エラーバジェットが底をつき、リリースができなくなるというリスクを取らないためにテストを多くしたり、リリースを遅くするということもできます。
このように開発チームは、エラーバジェットをできるだけ使いたいですが、使いすぎている場合は、失敗率を減らす試みを行います。SREチームは、失敗率を下げたいので、結果的にエラーバジェットを節約することになります。
エラーバジェットは、信頼性に過剰に向きすぎている観点を柔軟性や開発を早めることへ導くものでもあります。
まとめ
今回は、エラーバジェットの形成方法とそのメリットについて、学びました。
次回は、今回のエラーバジェットで定められたとした、SLOについて、具体的に学んでいきます。
- エラーバジェットは、SLOと実際の稼働時間の差分であり、リリースや保守への取り組みの判断の指針になる。
雑感
- エラーバジェット的な感覚があると、タスクの進め方の参考にもなるなとも思いました。
引用
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 36-38