こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
サービスレベル目標（SLO）とは、ユーザーの満足度に強い相関があるメトリクスを用いた、開発と運用の目安となるものです。SLOに基づいた運用は、ユーザー視点で高い信頼性を持つサービスを提供する上で最も重要なプラクティスであるとともに、ビジネス指標に紐づく運用方法でもあります。
今回は本書を監訳した山口氏に、サービスレベル目標が何を実現するものなのか、DevOps指標として挙げられているfour keysなどと比較しながら、解説していただきます。
事例講演では、株式会社タイミー バックエンドエンジニアの岡野兼也氏にご登壇いただき、タイミー社でSLOを導入・運用して分かった失敗と変化についてお話いただきます。
会の様子
基調講演〜SLOは何を実現するのか〜
SRE文脈でのSLO
ビジネスをする上で全ての部署が信頼性を基準にして開発が行えるようにすることが重要だという話からスタートしました。
信頼性は、計測可能なものである必要があり、「求められる機能が実行される確率」を明らかにしようという文脈で、SLI/SLOが挙がってくるということです。
また、SLI/SLOは組織に共有することが重要だということで、定期的に見直ししながら本当にユーザーが求めている機能で計測できているか？などを議論していく必要があるということでした。
エラーバジェット
SLOが決まればエラーバジェットも決まるため、サービスの余裕度を明らかにするためにエラーバジェットを監視することが重要だというお話がありました。
また、エラーバジェットの消費速度を監視するという文脈では、バーンレートを確認することも有用だということで、エンジニアが夜中に障害対応するような事態を未然に防ぐことができる可能性があるということでした。
同様に、エラーバジェットに関するポリシーを定義することも有用だということです。
Four Keysとの比較
Four Keysでは、安定して動いている際の運用を計測することが難しいということで、2022年からは、Four keysだけではなく信頼性も指標として盛り込まれているということでした。
また、エラーバジェットの消費具合によって、機能改善を優先するか信頼性の改善を優先するかが変わってくるため、エラーバジェットの計測がここでも生きてくるということです。
事例講演〜ボトムアップでSLOを導入 2年半運用してわかった失敗と変化〜
続いて、岡野さんから事例講演がありました。
タイミーのSLO
タイミーさんでは、当初は職能によってチームが分かれていたため、SREチームがSLOを作り、その後に顧客ベースのチームに組織再編を行う段階で、ワーカーチームのみにSLOを適用するようにしたそうです。
その後はSLOをスクラムイベントに組み込んだりして、よりSLOの運用を本格化したそうです。
なお、SLOを導入した背景としては、適切な目標をチームに設定したかったことが大きかったそうです。
SLOの失敗
続いて、SLOを運用していて失敗した点の紹介がありました。以下、ポイントを箇条書きで記載していきます。
- エンジニア以外には丁寧にSLOの説明をしていた一方で、エンジニアにはあまり説明していなかった(特に反対意見がなかったため)。結果、導入自体はできたが、エンジニアが行動変容を起こすのが遅れてしまった
- チームのミッションは解像度が上がったタイミングで整理されるのだが、そこに依存するようにすると運用にエネルギーが多く必要になった
- 重要すぎる指標をSLOにしない。信頼性の高さという意味では問題ないかもしれないが、SLOをもとに開発にフィードバックることができなくなってしまった。
続けることの重要性
人を巻き込み、運用を続けることが重要だという話がありました。
ただし、一人であってもSLOの運用を続けることは重要だということで、多少クオリティや期待値を落としても運用を続けていく方がよいのではないか？ということです。
Q&A
講演のあとは、Q&Aセッションがありました。以下、内容と回答を常体かつ一問一答形式で記載していきます。
マイクロサービスで運用している場合はSREがSLOを共通化しないほうがよいのか？
- 各チームで各々のSLOを決めていくという形になると思う。ただし、外部サービスを考慮してSLOを定義するということも勿論あるはず
- 結局チームで開発した機能はチームで責任を持つ。そのため、最終的には開発チームでボールを持てるようにしたほうがよい
初めてSLOを導入するときはどれくらいの期間をかけてどれくらいのタイミングで切り上げるのか？
- 開発の傍ら進めるなら1ヶ月くらいが準備期間として必要
- SLIを決めて最低4週間くらいは計測する。サービスが存在する限り切り上げることはないと思うが、1ヶ月に一回とかは見直したほうがよい
SLI/SLOを定めるためにクリティカルジャーニーはどのように考えたのか？
- CTOやCS、営業などの人と一緒に「最低限お金がもらえる機能は？」という切り口で考えた
- 基本的にはビジネス系の部署やPdM、UXデザイナー、営業、CSなどを巻き込むのがよさそう
APIやサービスの利用頻度が人によって大きく異なるため、結局サービス単位で決めようとなりがちなのだが、うまく定めるコツはあるか？
過剰な方向にSLOが倒れがちなのだがどのように調整するとよいか？
- そもそも計測していれば「そんなの達成できないですよ」といえる。また、実際に高い目標を立てた場合にどれくらい投資が必要なのか？という話をするとよい
- 一旦調整せずに対応しちゃってもよいと思う。違反して、その際の反応を見る
継続的にSLO違反している場合、目標が高すぎるからSLOを下げようという話にはならないのか？
- エンジニアリングの余地があるか？や競合優位性などをもとに下げない判断をしている
- 「XX割の顧客がいなくなった場合、XX円損失が出てしまう」といった考え方をする
会全体を通した感想
SLOの運用に関してあるべき姿と現実的にはこうなるという話の両面で話が聞けて非常に学びになりました。
普段のイベントに比べ、「実際にこういう風に運用しているんですけど...」という形の質問が多く、皆さんが運用した上で苦労が多い領域だというのが実感できたのも収穫でした。
