はじめに
SRE (Service Reliability Engineering) 部の村上です！
突然ですが、SRE と言えば SLO ですよね？（そーなんです？）
はい、SRE が単なる「インフラ管理部隊」でないのは「SLOという仕組みで、指標で以て新規開発を進めるか運用を改善するかを決定し、実行する」ということからだそうです。なるほど。
…というわけで、本記事は、SLO 初心者である私が「SLO とはなんぞや」ということを掘り下げていく記事になります。
SLOとは？
まず、SLO とはなんでしょうか。
SLO は “Service Level Objective” の略で、即ち「サービスレベル目標」と訳せます。
これだけで「つまり SLO の取り組みっていうのは、サービスの何らかの品質に関する目標を立ててなにかするんだな」というのが想像つくかと思います。
これを更に詳細に述べると、以下のような営みです:
- ユーザ視点で重要な機能や体験を抽出し、（CUJ の策定）
- 抽出した機能の信頼性を測定し、（SLI の測定）
- ユーザが満足するラインの目標を設定し、（SLO の策定）
- SLO と実際の信頼性とを対比し、行動を決定する（Error Budget の測定と行動計画）
このように、サービスにおける重要な項目で信頼性を測定し、同時に目標を立て、行動していくというのが SLO の取り組みということになります。
また、これらは「一度決めたら終わり」のものではありません。 日々の開発や運用に応じて変更されるべきものです。 開発によって機能が変更になれば大幅な見直しが発生しますし、SLO / Error Budget の設定などは実際に回し見直すことでブラッシュアップされていきます。
さて、SLO では “Service Level Objective” と言われるように目標を立てていくわけですが、ここで特徴的だと感じるのは、目標を著しく高く設定しないという点です。
全く落ちないシステムはない…即ち、100% の信頼性はありえないということ、 また、システムの信頼性を上げるためにはコストがかかるということを前提とし、 SLO では、目標を「ユーザが満足するライン」というのを見極め設定されます。
なので、過剰に SLO を満たしている場合は逆に適切に運用レベルを下げるといった方策も取り得ます。
SRE といえば SLO？
なぜ SRE と言えば SLO になるのでしょうか。
それは、改めて SRE の定義に戻るとよいでしょう。
SRE とは “Site Reliability Engineering” の略で、『組織がシステム、サービス、製品に おいて適切なレベルの信頼性を持続的に達成できるよう支援することを目的とし た工学分野（引用: 「SREをはじめよう」David N. Blank-Edelman 著 山口能迪 訳）』のことです。
この中で、適切なレベルの信頼性を持続的に達成しているかどうかをどう判断するでしょうか？
経験者による当て感？
それは（実際は非常に役に立つものですが、しかし）関係者との共通言語とは言えないでしょう。
そこで、これをどうにか可視化し、その数値で以て信頼性があるか否かを判定しよう…これが SLO の取り組みになります。
SLO って嬉しいの？
SLO の取り組みの嬉しさってどれくらいあるのでしょうか？
正直、非常に地味な活動であることは間違いありません。
しかし、「新規機能開発 vs 運用改善」の議論に対して、客観的な数値で以て方針を決定できるというのは大きいのではないでしょうか。
つまり:
勿論、ビジネス的には新しい機能をもっと作りたいし、開発チームとしてもそれに応えたい。
しかし、開発を急いだ結果、様々な負債が溜まってきているのはなんとなく体感している。
障害も多い気がする。そろそろ内部のコードを改善する方向に動きたい。
これに対して客観的な解を与えるために SLO は発明されたと言えます。
これは、サービスの持続性に影響を与えると考えられます。
いくら有用な機能が沢山あろうと、障害が多発してはユーザとしてはそのサービスを信頼できず、利用したいとは思えません。
サービスから離脱者を生み、損害に繋がります。
また、障害が多発しては開発・運用チームが疲弊してしまいます。
最悪、休職・退職するメンバーが出てしまうでしょう。
そうするとやはり損害に繋がります。また、新規機能開発どころではないでしょう。
こういった事象を防ぐためにも計画的な改善活動は必要であり、そのシグナルとして SLO は重要な役目を担っていると言えます。
その他のメリット
また、SLO を取り組む中で副産物としてのメリットは多くあります。
CUJ の策定によるサービスに対する目線合わせ
まず、SLO を定めるためには「ユーザ視点で重要な機能や体験を抽出する（CUJの策定）」必要があります。
この営みによって、「この機能こそがサービスにおける重要項目なのだ」と関係者間で目線を揃えることができます。
チームは年月を経るごとに入れ替わりも発生し、時には新卒等の非常に若いメンバーも参画するでしょう。
すると、サービスの肝が何かの目線が少しずつズレてくる可能性があります。
SLO の取り組みでは、CUJ の策定を行うことで、この目線合わせを助けることができます。
SLI の測定による、サービスの監視体制の改善
SLI を測定し始めると、「このメトリクス・ログは取らないと駄目だよね」といった議論が発生することがあります。
ログやメトリクスの改良はサービスの状況を正確に把握し、異常を通知したりトラブルシューティングのために非常に重要であり、 SLO の取り組みをきっかけに、メトリクスやログに関する改良が走り出すことがあります。
現状の体制での実現可能なサービスレベルの明確化
SLO は、現在の体制で実現可能な目標を定めるものです。
なので、SLO を適切に定めることができれば、上から「もっと信頼性上げて」と要求されたときも「このリソースが必要です」とちゃんと根拠を持って言えるようになります。
サービスの改善の指針
SLOはサービス改善の指針にもなるということです。
もし今のSLOを満たせていないなら、それはサービスのどこかに改善すべき課題があるということになるため、それを起点に議論を始めることで、より良いサービスを目指すことができます。
以上、SLO のメリットをお伝えしてきました。 地味ですが、しかし長期の開発・運用では非常に重要な内容ばかりだと思います。
もしかしたら、SLO の取り組みを始める切っ掛けとして上記の内容を最初に当てるのは一つ戦略かもしれません。
ここまで SLO に関する取り組みについての説明をざっくりとしてきました。 やりたいこと等はおおよそおわかりいただけたかと思います。
次回は、実際の SLO に関する取り組みを、私が担当する A-Flow を例にとって見ていきたいと思います。