発売されてすぐに買ったものの、なかなか手をつけていなかった『SLOサービスレベル目標』をようやく読んだ。
以下、読書メモ
- 繰り返し出てくるのは、「完璧を目指さないこと」…目指すのはある程度の完璧さであり、限られたリソースの中、個々の要素に囚われすぎず、全体最適を目指すこと
- サービスの信頼性は、「ユーザー目線」であるべきで、サービスを提供する側の目線では無い
- SLI、サービスレベル指標は、ユーザーにとって価値が得られたか否かの閾値、基準を示すもの……例えば、ユーザーへの画面表示は2秒以内に行われるべきである、といった定義がされる
- SLO、サービスレベル目標は、サービスレベル指標がどの程度の割合となるべきか、その目標を示すもの……例えば、ユーザーへの画面表示が2秒以内に行われる割合を8割とする、といった定義がされる
- SLOとは障害を起こしても許容される頻度の目標値であり、あるいは正常に動作していなくてもユーザーが重大な混乱に陥らないと保証する目標値
待って!!!
果たして組織の中で、「障害を起こしても許容される頻度」なるものを議論し、定義できるのだろうか……経営陣は秒で「ゼロに決まってんだろ」と言ってくるかもしれない。「障害なんて、有ってはならない」としか言ってこないかもしれない……でも、実際にはあるんだけど。
もし起きたら、全部すぐ対応して、障害が無い状態に回復させるんだろ？そこに判断の余地は無いんだろう？という議論にならないだろうか。
少なくとも、エンジニアの組織から一歩出た時に、この議論に陥らないだろうか？
エラーバジェットが貯まる前に、起きたら即対応か、優先順位が低いものはスタックに積まれ、そして、そのスタックから取り出されることは永遠になく、常に新規のサービス追加か、優先度最大の即対応が必要な障害へ対応が求められるのではないか？
伝家の宝刀「全部最優先で！」が発動しませんか？
「今月は、まだあと5000個までのエラーを出しても大丈夫だなー」とか思って運用している人、監視している人って居るのだろうか？
と、思いながら読み進めていくと、以下の意思決定ロジックが出てきた。
「エラーバジェットが余った？」→「より多くの機能をリリース」 「エラーバジェットが超過した？」→「信頼性に集中」
この意思決定ができるのはマネジメントをする側だけだ。勝手にサービスリリースは減らせないし、勝手に改善活動もできない。リソースを投下する先を決めるのは、あくまでマネジメントサイドであり、経営の問題だ。
「2.3.1 100%は不要である」という章にすごく大事なことが書かれている……それはつまり「100%は不可能だ」ということ。そして、「2.3.2 信頼性にはコストがかかる」へとつながっていくのだけど、この二つの章をマネジメントする側が納得して読めるか否かで、この本がもたらす価値が変わってくる。
「それはダメ、有ってはならない、コストはかけられないが、信頼性は下げてはいけない」となってしまうと、この先いくら読み進めても何の意味も無い。そして、そんな価値観の人が多いんじゃないかな？と思ってしまった。
ただ、お金に関する計算や、取引が一定の割合で失敗しても良い、という目標を掲げる組織はおそらく無いと思われる（有ったら怖い）。この本の中にも厳密性が担保されるべき例として出てくる。実際、SLIの事例として出てくるのは応答時間に関するものが多い。時間を担保するのもとても大変だし、応答時間が重要なビジネスの指標になる場面があることも分かる（遅いサイトは利用されず、離脱されてしまう……一方で、社内システムは遅いからとって離脱されるだろうか？
結局、何を許容して、何は許容できないか、それをきちんと議論、合意することが大事なんじゃないか？と思ったし、本の後半で出てくる指標の考え方や、信頼性を担保する仕組みも、その合意無しには何の意味もないなーと。
SLIやSLOが定義できる対象って、そんなに有るのだろうか、そしてそんなにサービス運営に於いて、優先されるべき内容なのだろうか？と考えた、答えはまだ無い。
