エラーバジェットの導入戦略を考えてみる

著者：

2024-08-01

はじめに

はじめまして、KDDIアジャイル開発センター(KAG) でリードSREを勤めてる北浦と申します。最近はプロダクト開発を行いながら、全社横断的にSREのプラクティスを広める活動や、運用周りの技術支援をしています。社外ではJAWS-UG SRE支部 & コンテナ支部やNRUG SRE支部の運営に携わっています。

数あるSREのプラクティスの中でもエラーバジェットが特に好きなのですが、 SRE Magazine（vol.1〜3）にエラーバジェットをテーマとした記事が見当たらないことに気付きました。「これは僕が書かなければならない！」という謎の使命感に駆られ、寄稿を決意しました。

本記事では、エラーバジェットについて深掘りし、初めの一歩を踏み出すための提案を行います。 SLOの計測を始めたものの、計測結果から生じる意見を現場に反映できていないなどの課題をお持ちの方には、ぜひ参考にしていただければ幸いです。

エラーバジェットとは

足並みを揃えるために、まずエラーバジェットのおさらいをしましょう。エラーバジェットとは、システムがどれくらい問題を許容できるかを定義する指標です。

例えば、ECサイトの開発を行っていたとして、アイテム購入に至るまでの一連の動作(アイテムの閲覧、カートの操作、決済など)を重要なユーザージャーニーとし、可用性のSLOとして99.5%/月と定義していたとします。

このケースの場合、1000回、このユーザージャーニーが実行されたとき、 SLOを達成するためには995回、成功する必要があります。裏の見方をすると、1000回中、5回の失敗は許容されることになります。

許容される5回を予算と見立て、予算が超過しそうなのであれば、信頼性を上げる活動を行い、そうでなければ、機能開発に注力する。このように使われるのがエラーバジェットです。

エラーバジェットを適切に扱うことができると、プロダクト開発において、信頼性の向上に注力するべきなのか、新機能の開発などに取り組むべきなのか、合理的に判断することができます。

ユーザーのいないサービスというものはこの世に存在しないので、僕たちはユーザーが最も望むものを提供するべきなのですが、この信頼性向上と機能開発の優先づけを最適化することは難しいものです。

僕のこれまでの開発経験上でも、機能開発を優先するあまり信頼性が軽視されるプロダクトや、過剰に信頼性を重視するため機能開発の進みが悪いプロダクトがありました。主にスタートアップでは前者、エンタープライズでは後者の傾向が多いようです。

エラーバジェットの運用をすることで、この問題を解決しようとするSREの方は多いのではないでしょうか。

エラーバジェットの導入は難しい

しかし、エラーバジェットの運用を定義し、実際にプロダクト開発タスクの意思決定に活用するのは難しいものです。

これまで多くのSREの方々と交流してきましたが、SLOの計測まではできていても、エラーバジェットの運用までできているケースは多くないようです。僕自身もその一人で、これまでエラーバジェットをプロダクトのステークホルダーと共有し、指標ドリブンな意思決定として活用できたことはありません。

導入のハードルをあげている要因はいくつかあると思いますが、大きく以下の二つを取り上げてみます。

開発タスクの割り込みが許容されない

例えば、新機能を追加するプロジェクトを進行していたとします。プロジェクト進行中にエラーバジェットの超過が発生し、信頼性向上の活動を提案します。

その提案内容がプロジェクトの完了期日を伸ばして信頼性向上の活動を行うというものであった場合、それを受け入れてもらえないことがあります。エラーバジェットの理屈から考えれば、この状況においてユーザーに最も喜ばれるのは新機能の追加ではなく、信頼性向上のはずです。

しかし、「いつまでに何を完成させる」というガバナンスの強い文化があると、この提案はなかなか通りづらくなります。

ステークホルダー間での取り決めやコミットメントが既にされていたり、マーケティングの観点からユーザー告知が行われている場合など、理屈は理解してもらえても、様々な人との約束があるため、機能追加を優先して欲しいと言われることが多いのではないでしょうか。

ステークホルダーからみたSLOが100%

これまでシステム開発・運用を経験した方なら、SLOを100%に設定することが如何に無謀であるかは説明する必要がないと思います。しかし、エラーを出してしまうことがいけないことであり、即刻修正せよというモチベーションを持つステークホルダーはまだ多くいます。

SREのプラクティスでは、「エラーバジェットを消化していないということはイノベーションを起こしていないということ」と表現されるように、予算を積極的に使う行動が推奨されています。

例えば、デプロイメントの改善などは予算がなければなかなか取り組みづらい活動ですが、予算があるおかげで取り組めることが期待できます。しかし、ここでもガバナンスが強いと取り組みづらくなります。

エラーバジェットという言葉を使わずに提案ベースの活動を行う

このようにエラーバジェットを運用で扱うには一定のハードルがあり、そのハードルは文化などの根深い要因に起因しているため、変えるのに長い時間を要することが多いと思います。

ここでようやく主題に入りますが、この状況下でもエラーバジェットを有効に扱う方法を考え、実行した知見を共有します。まずは、エラーバジェットを指標化することではなく、信頼性を基にした提案が開発チームから出せるようにすることを目指しました。

SLOがユーザーの定着に直結する的を得た指標で機能している場合、例えば、SLOを満たせていない場合はユーザーが満足にサービスを利用できていない可能性があるという懸念があります。それを解決するための手段をプロダクト全体に提供したり、逆に、SLOが十分に満たされているにも関わらず品質向上の施策を打とうとしている場合には、それが十分であることを伝え、別のことに注力するよう提案したりすることができます。

これは開発者にとって最もイメージしやすい活動であり、固有の価値があると考えています。

当時、週に一度パフォーマンス定点観測会を開き、そこでSLOの状況をチームで確認するイベントを行っていました。その際、状況の推察と提案について議論するようにしていました。方法はなんでも良いと思いますが、取り組んだ所感としては、チーム内で話し合う場を設けたことは効果が高かったと思います。振り返ってみれば、参加者の意識として、この活動を提案に繋げるという意識が高かったように思います。同様の活動を試みるのであれば、ファシリテーターがそのあたりを意識できるとよいかもしれません。

その後はプロダクトの全体定例会で状況を開発者から説明し、ネクストアクションを提案していました。提案自体は、文化的な事情により全てが承認されるわけではありませんでしたが、理屈としては納得してもらえる場面が多かったように思います。

このプロダクトは残念ながら長く続きませんでしたが、この活動を長く継続していたら、エラーバジェットという指標の存在を説明し、その重要性や効果をステークホルダー全体に浸透させることも夢ではなかったのではないかと思います。

さいごに

エラーバジェットの導入が難しい背景と、それを踏まえた活動について紹介しましたが、いかがでしたでしょうか。皆様のSREライフに何かしらのポジティブな影響を与えられたなら幸いです。

最後に宣伝させてください!

冒頭にも紹介しましたが、JAWS-UG SRE支部とNRUG SRE支部が絶賛活動中です。

各SRE支部では、AWSやNew Relicを使って、どうSREのプラクティスを実現させていくかという議題で、子テーマを設けて勉強会を開いています。

ご興味ある方は、是非、connpassを登録していただいて参加をご検討くださいませ！！