ネガティブな解釈をされがちなエラーバジェットの誤解を解いてみる。
はじめに
こんにちは、SRE Unitの北浦です。
私達がSRE活動を推進していく中で、行き詰まった点や逆にうまくいった方法などの知見を共有していこうと思い、筆を取りました。
“アプリケーション"のシステムとは違い、"人"のシステムを改善・介入していくためには、 関係各者へたくさんの説明や知見を共有していかないといけないのは当然のこと。 重要なポイントを割愛してしまうと、要らぬ誤解を生んでしまい、物事がうまく推進できないという自体に陥ります。
今回は、我々の体験談としてエラーバジェットというものがネガティブに誤解されてしまった過程と、その軌道修正に必要だった説明をまとめてみました。
エラーバジェットって何よ
まずはエラーバジェットそのものについて、足並みを揃えていきましょう。
Googleで検索をかけると以下のような説明が出てきます。
エラーバジェット(Error Budgets)とはエラーに対する予算であり、SLOに基づき算出される損失可能な信頼性である。 サービスの計測された稼働時間がSLOを超えている、換言すればエラーバジェットがまだ残っている状態であれば、チームは新しいリリースをプッシュ(デプロイ)できる。
例えば、正常な稼働時間という切り口のSLIを設定し、そのSLOを99.9%と定義したとしましょう。
そうした場合、残りの0.1%がエラーバジェットになります。
100% - SLO(99.9%) = 0.1%
1ヶ月を30日間とした場合、残りの0.1%は43.2分です。
1ヶ月(43,200分)/1000 = 43.2分
この場合、仮にダウンタイムが1ヶ月のうちに43.2分未満であれば新規開発を続行し、 43.2分を超過する自体に陥っていた場合は、新規開発を中断し、この値が回復するまでの間はダウンタイムの時間を減らす活動を行う。
このように使われるのがエラーバジェットです。
生まれる誤解
エラーバジェット自体はDevとOpsの課題を絶妙なバランスで解決した良い手法なのですが、 これを良いものと認識するためには、いくつかの前提知識が必要であり、 加えて、何を解決しているものなのか、課題を捉える必要があります。
前提知識と課題、ここの相互理解がないまま導入を提案しても、
「うちは予算取って動いているプロダクトなので、なかなか柔軟に舵切ることは難しい」
「納期があるから、新規開発中断は困る」
「うちは組織形態として大きいから・・・SREってスタートアップやテックリードのような企業で導入するやつでしょ?」
…などの反応が返ってきそうです。
上記の反応は、見方によれば至極真っ当で、 そもそも開発プロダクトとして、開発への投資を信頼性に向けるか新規開発に向けるかといった意思決定は、プロダクトの命運を左右する重要な要素でしょう。
そんな重要な要素の一つをエラーバジェットなるものに背を預けて良いものでしょうか。 こう考えると、なかなか心理的にもハードルが高そうです。
ということで、エラーバジェットを理解するための知見、そして何が解決されて嬉しいのかというポイントをふかぼっていきたいと思います。
暗黙のエラーバジェット
ところで、システム開発に関わりのある読者の方には質問なのですが、 「あなたが担当しているシステムのエラーバジェットは最適化されていますか?」
・
・
・
「いや、エラーバジェット導入してねーよ」 と言われてしまいそうなのですが、 実はそうとも言い切れないケースが多いのではないかと思っています。
例えば、
システムに致命的な欠陥が見つかり、予定していた開発を中断、
回復作業に注力した。
という状況はイメージできないでしょうか。
この場合は、エラーバジェットを大幅に超過しているということが、 関係者全員の共通認識となった時に起こる状態です。
・・・ふむ。こう考えると、どうやらエラーバジェットというものは、 暗黙的には存在しているもののようです。
暗黙のエラーバジェットが引き起こすもの
エラーバジェットが暗黙的であるものの場合、言い換えれば、 ”人”それぞれの感覚値に依存していることになります。
Aさんは0.1%の感覚かもしれませんし、Bさんは0.01%の感覚かもしれません。
プロダクトとしての意思決定を行う際、この感覚の乖離を埋める手段はコミュニケーションになることと思いますが、 この感覚値は各役割にも影響されることが多く、 そして、正解が存在しないところが実に厄介なところで手をこまねいているプロダクトも多くありそうです。
「あなたが担当しているシステムのエラーバジェットは最適化されていますか?そしてその感覚は関係者各位で共通しているものですか?」 もしかしたら、あなたのチームはこの暗黙のエラーバジェットのコミュニケーションに多大な工数と労力を強いられてるかもしれません。
この質問にYesと答えられず、且つ、コミュニケーションや実態に課題を感じているのであれば、 プロダクトとして指針を決めることに一度注力し、エラーバジェットの運用をしてみるのも良い選択肢かもしれませんね。
機能性と信頼性、ユーザーはどっちが欲しい?
一つ、エラーバジェットの嬉しみポイントが見えたところですが、 以下に、極端ですがToDo管理アプリケーションの例を二つあげてみます。
ケースA
ユーザーからも評価の高い機能性のあるアプリケーションだが、
3日に1日くらいのペースで利用ができなくなる。
ケースB
24時間365日正常に稼働するが、ToDoの登録と削除の機能しかない
上記、どちらかのアプリケーションを使いたいと思いますか?
・・・どちらも使いたくないと思ったことでしょう。 実際に市場に出してもユーザーから選んでもらえることは無さそうです。
つまり、ビジネスとしてプロダクトが成功するには、 新機能の開発と信頼性の向上、両方のタスクをバランスよくおこなっていかなければならなそうです。
しかし、ここで二つ立ち塞がる障壁があります。
- 新機能開発を行うとバグが発生する可能性があるため、信頼性が低下する。
- SLOに9を加えるには、その前の9を実装するのにかかったコストの10倍かかる。99%から99.9%にするためには99%にするためにかかったコストの10倍かかる。99.99%にするためには、それのさらに10倍のコストがかかると言われています。
どうやら新機能開発と信頼性の向上は、お互いにトレードオフの関係性にあるようです。
<参考> https://cloud.google.com/architecture/defining-SLOs?hl=ja#why_slos
高すぎるSLOが引き起こすもの
例えば、暗黙的にSLO99.99999…%のように高い水準のSLOを設定してしまい、 エラーバジェットがとても少ない状況下にあったとしましょう。
その場合、信頼性の担保に対して必要なコストがかなり高い水準で必要とされ、 結果的に新規開発への着手が困難という自体に陥るわけです。
ただし、そんな状況下だったとしても、プロダクトとして新機能開発がゼロということは考えづらいですから、 信頼性が担保できていない状態なのに新機能も開発しなくちゃいけないという大変な状況になるかもしれません。
思い当たる節があるようであれば、まずは今のシステムがどれほどの水準で信頼性があるのか、 SLIを定義し、計測するところから始めると良いでしょう。
SLOをあげてしまうと新規開発に投資できるだけのコストが失われてしまうという前提のもと、 実現可能性が高い値を定義できると、少しづつ新規開発にも投資できるようになるかもしれませんし、それでも今の現状で信頼性が担保できていないと考えるのであれば、定量的な指標によって、現在行っている信頼性向上の施策が効果があるのかないのか。判断することができるでしょう。
まとめ
ネガティブな解釈をされがちなエラーバジェットに関して、 今回は課題の背景や解決アプローチを説明させていただきましたが、誤解は解けましたでしょうか。
エラーバジェットを定義するのは良いかも。とか、 改めて自分の担当しているプロダクトには、緊急的には必要なさそう。など、諸々考えてくれたら嬉しいです。
さいごに
medibaでは、現在、各プロダクトの価値を向上すべく、 日々SRE活動を積極的に行っております。
次回は、エラーバジェットをより有効なものにするために、信頼性を上がると何が嬉しいのか、下がってしまうとどんなことが起こりうるのかという点を深堀し、より効果の高いSLI定義についてのナレッジを共有しようかと考えてます。お楽しみに・・・!