SLO, SLO, SLO.
言葉の意味は理解しつつも、実際に身をもって使うことができてない言葉だ。そんなこんなでいよいよSLOちゃんとやりますかねと言ったところでSLOってなんだっけってのを深いレベルでちゃんと理解しないとなと思ったので筆を執った次第。
重たい1st SRE bookを引っ張り出してきた。
1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する / Pursuing Maximum Change Velocity Without Violating a Service’s SLO
- 信頼性目標は100%であってはならない
- エラーバジェットを使い切ると新規開発はできない
100%からSLOを引いたものがエラーバジェットである。SLOを下回った場合は、SLOを回復させるための作業に注力する。ただそれだけだ。
エラーバジェットがなぜあるかというと、開発と運用の対立構造が前提にあるように感じる。それを客観的指標で解決しようとしたのがエラーバジェットという考え方だろう。
4. サービスレベル目標 / Service Level Objectives
結局、SLOというか、SLIをどうやって、それに決めればいいかわからないからもやもやしているのだと気づいた。
4.2.1 サービスの提供者とユーザの関心事
にあるように、すべての指標がSLOになるわけではない。ユーザが何に関心を持っているか。そしてそれによってプロダクトとして何を重要指標とするか。それで決まる。
したがってやっぱりこれはテクニカルに、SREとそのサービスの技術者だけでは決めることができず、プロダクトという単位で決める必要がある。
おわりに
現在、Microservicesを受け入れる基盤ができ、少しずつMicroservicesが生まれ始めている。その中で、テクニカルな（microservices文脈での）サービスに対して、技術的な責任を持つサービスオーナーと、ビジネス的な責任を持つプロダクトオーナーを定めようとしている。（プロダクトオーナーはプロダクトマネージャという言葉でのプロダクトという言葉があるし、言葉の定義はまた変わると思うけど、とにかくmicroservices文脈/単位での技術的責任と、それらを包含し利用するプロダクト/ビジネス責任を定める必要があるが、現状様々な歪があるという状況だ。）
SLOは、この後者のビジネス的責任を負う組織が決まらないと、決めることができない気がする。
Production Readiness ChecklistでStakeholderを決め、Service Owner / Business・Product Owner / SRE とでSLI ・SLOを合意、その共通認識を持って進めていこうね。この基準だけは守るようにみんなでうまいことやっていこうね。そういうのが目指す姿な気がしている。
