開発プロセス・方法論

SLO・エラーバジェット

（えすえるおー・えらーばじぇっと／SLO / Error Budget）

一言でいうと

サービスの信頼性に目標値を定め、その未達分を変更の許容枠として使う考え方です。安定と変更のどちらを優先するかを、数字で決められるようにします。

Googleが自社の運用から整理し、2016年に公開したSRE本で広く知られるようになりました。第4章がSLOを、第3章がリスクの受容とエラーバジェットの動機を扱っています。国内での普及時期は特定していません。日本語版の刊行を経て使われています。

安定を優先する立場と、変更を出したい立場の対立は、どちらも正しいために議論では決着しません。可用性の目標を決め、目標に対する余裕を数値で持つことで、この対立を判断可能な形にします。

余裕が残っていれば変更を出してよい。使い切ったら、信頼性の回復を優先する。判断の基準を事前に合意しておくため、障害のたびに力関係で決まる状態を避けられます。

まず利用者が体感する指標を選びます。応答時間、成功率、可用性などから、そのサービスで意味のあるものを選び、目標値を決めます。100パーセントは目標に置きません。到達できないうえに、到達しようとすると変更が出せなくなります。

目標との差分がエラーバジェットです。期間ごとに消費量を見て、残っていれば変更を進め、使い切ったら回復を優先します。合意の相手には、事業側も含めてください。

信頼性を数値で管理している組織です。SREやDevOpsエンジニアの募集で使われることが多く、運用が属人的でない可能性を示します。

候補者を引くならSREという職種名です。SLOはむしろ、SREの募集要項に書かれていることのほうが多くなります。

自社側では、エラーバジェットを使い切ったときに実際に何をしたかを確認します。具体例がなければ、数値を見ているだけで運用は変わっていません。オンコールの当番の頻度と手当の扱いも、この職種の候補者が必ず確認する項目です。候補者には、目標値を誰と合意して決めていたかを聞きます。