こんにちは。プロダクト本部プラットフォーム部SREチームの id:ut61z です。
SREチームが主体となってSLO本読書会を社内で実施しました。
そしてなんと贅沢なことに、監訳、翻訳に携わった Google Cloud の Developer Relations Engineer である山口能迪さん(@ymotongpoo、以下山口さん)にゲストとしてお越しいただき、読書会で出てきた疑問をぶつけてSLOについて理解を深める会を開催しました。
今回は読書会、そして山口さんを囲んでSLOの理解を深める会について、経緯や読書会の進め方、学んだことなどをレポートしたいと思います。
SLO本とは?
O'REILLY から翻訳書が出版されているこちらの『SLO サービスレベル目標』という書籍(以後：SLO本)です。
SLI・SLO・エラーバジェットの3つについて、概念の説明、どのように設計・運用するか、さらには組織にそれらを浸透させるためにどのような文化の醸成が必要かなどがわかりやすく記されています。
第Ⅰ部 〜第Ⅲ部の三部構成で、以下のようなトピックを扱っています。
- "第Ⅰ部 SLOの開発" では主にSLI・SLO・エラーバジェットの概念と考え方についての紹介
- "第Ⅱ部 SLOの実装" ではSLI・SLO・エラーバジェットの導入・運用の実践的なプラクティスや事例の紹介
- "第Ⅲ部 SLOの文化" ではいかに組織にSLOを根付かせるか、実践的なプラクティスの紹介
SLO本読書会をしようと思ったきっかけ
読書会をしようと思ったきっかけは、2点あります。
1点目は、弊社では一部の機能で限定的にSLOを設定していますが、その他の多くのコンポーネント、あるいはサービス全体に対してのSLOの設定・運用ができているわけではなく、この本を通してSLOへの理解を深め、導入・運用の再出発を図りたかった点が挙げられます。
以下の記事でSLOを導入した機能について紹介しているので、興味があればぜひご覧ください。
2点目はSLO本を先行して読んでみて、SLI・SLO・エラーバジェットは、エンジニアだけでなく幅広い職種のメンバーと一緒になってつくりあげる必要性を感じたので、エンジニアに限らず広く社内で読書会参加者を募り、読書会を通じて概念の共通理解を得たかった、という点がありました。
読書会をどう進めたか
2点目の観点から、社内の全メンバーに対して参加の呼びかけを行いました。
結果、エンジニアに限らず、QA、デザイナー、プロダクトマネージャーなど多様な職種のメンバーが参加してくれました。
また、エンジニア以外のメンバーも参加することも踏まえ、読書会のゴールを概念の理解とし、第Ⅰ部のみを読み進めるかたちとしました。
例外的に第1章で、第17章(最終章)を読むことを強く推奨していたので、第17章も読書会で扱いました。
1章ずつ担当を割り振り、担当者はその章を事前にまとめ、発表し、参加者同士で気になったことをディスカッションをするかたちで読書会を進めました。
読書会を通して学んだこと・浮かんだ疑問
学んだことは多岐にわたりますが、前提となる考え方について、エンジニア以外のメンバーも含めて共通理解を得られたことは大きかったと思います。
たとえば以下のような点は、ディスカッションでもたびたび言及され、参加者の多くが従来の考え方をUnlearnした内容でした。
- ユーザーを基準にして考える
- ユーザージャーニーをベースにしてSLIを設計する
- 信頼性は高ければ高いほどよいというわけではない、コストとのトレードオフ
- ユーザーが不満に思わないところを見定めて目標とする
- 信頼性についてすべてを網羅的に管理することは不可能
- エラーバジェットは"使う"ことができる
- SLI・SLO・エラーバジェットはプロジェクト的に設定するものではなく、継続的に文化として取り組むもの
また、エンジニア以外のメンバーから以下のような意見も出ました。
- QA: CUJ*1からSLIを定めるという考え方は、テスト項目をつくるうえでも参考になるかもしれない
- デザイナー: ユーザーを基準にして考えるというのは「人間中心設計」と通じるものがある
- プロダクトマネージャー: むやみにKPI等の数値を追って完璧を目指すのではなく、重要な指標がある値であるとき、それはユーザーにとってどういう状態なのか？という会話ができるようにしたい
多様な職種のメンバー間でディスカッションすることで、多角的にSLOを捉えることができ、さらには考え方の応用ができないかの議論にも発展して、とても実りのある時間になりました。
一方で、実際にClassiでSLI・SLO・エラーバジェットを運用するとしたらここはどう捉えるべきかなど、実践的な問いもいくつか出てきました。
- ユーザーが満足しているかはどう計測すればよいか
- CUJとはなにかを考えてみたとき、逆にCUJじゃないジャーニーはあるのか
- 特定のコンテキスト(時間帯・繁忙期・ユーザー種別など)によって、ユーザーの期待値は異なるのでコンテキストを加味してSLIに重み付け等をしたほうがよいか、複雑にならないか
- エラーバジェットのバーンレートアラート*2がうまく機能していれば従来のアラートの多くはなくせる、とあるが、なくすと困るケースも出てくるのではないか
これらの疑問を携えて、山口さんを囲んでお話を伺いました。
山口さんを囲んでSLOの理解を深める会
山口さんを囲む会と題して、SLO本を読んで浮かんだ疑問や、翻訳業についてなど様々な質問をさせていただきました。
「この本の中で和訳に困った章はありましたか」と伺ったところ、第9章は統計についての話ゆえ、専門用語を正しく使うことに気をつかい、別の統計の本も参考にしながら翻訳を進められていたということを仰っていて、翻訳者としての苦労が伺えたのが印象的でした。
計算式を正しく理解するために自分で検算してみたら、原書の誤りを見つけたりもしたそうで、そういった丁寧な正確さの追求があって翻訳が成し遂げられていると思うと、改めて感謝の念を抱きました。
さて、前述の疑問をぶつけてみてお話をしていただきましたので紹介したいと思います。
Q. ユーザーが満足しているかはどう計測すればよいか
Google のUXリサーチャーチームでは、ユーザーをお呼びし、CUJのフローの操作をしてもらいながら、どこで詰まっているか(いないか)を観察する、なんでも思ったことを喋ってもらう、操作後に全体の感想をもらう、など様々なフィードバックをもらうということを行っています。
それらを踏まえて、そのCUJのSLIの妥当性をチェックします。
あくまで例えですが、ユーザーがレイテンシよりエラーに不満を持っていたなら、エラー率のSLOの優先度を上げる、といったように対応することができます。
あるいは、機能リリースなどのSLIが変化するようなイベント前後で、問い合わせがどう変化したかを見て、間接的に評価するというのも手段のひとつです。
SLIでとれるデータは、実際のエンドユーザーの満足度を直接測っているわけではなく、相関を持っているだろうとしかいえません。
最後は決めの部分もありますが、使えそうなデータはすべて用いてSLIをユーザーの満足度に近づけていくというプロセスが大事だと思います。
Q. CUJとはなにかを考えてみたとき、逆にCUJじゃないジャーニーはあるのか
たとえばあるジャーニーに対してSLI・SLOを設定してみてSLO違反が起きたときに、ビジネス上影響がないとか、問い合わせがとくにあがってこないとか、そのコンポーネントを使っている別チームも困っていない、ということであれば、実際にはそこまで信頼性が高くなくてもよかった、という気づきになり、クリティカルかどうかを見直す機会になります。
あらゆるジャーニーにSLOを定めなくてはいけないということではなくて、SLOは自分たちが効率よく信頼性を管理するために使うものなので、関係者間で「ここはSLOを定めなくてもそんなに影響がない」という合意形成ができれば定める必要はないと思います。
Q. 特定のコンテキスト(時間帯・繁忙期・ユーザー種別など)によって、ユーザーの期待値は異なるのでコンテキストを加味してSLIに重み付け等をしたほうがよいか、複雑にならないか
ブラックフライデーの時期の売上が全体の大部分を占めるというようなサービスにおいては、その時期はSLOを厳し目に変更して設定する、というのはよく聞きますし、実際にそうすべきだと思います。
SLI・SLO・エラーバジェットなどのプラクティスはあくまでプラクティスとしてまとめたものであって、実際に会社が何を優先し、何を目指すか、サービスを利用しているユーザーがどう思うかなどに寄り添うようなかたちで決めていくべきだと思います。
ユーザー種別という文脈では、 Google の例だと、 Borg という共通インフラがあり、顧客が利用するサービスも社内のレポート用に使っているサービスもすべてその共通インフラ上で稼働しています。そうすると、それぞれのサービスがリソースの取り合いになるわけですが、優先すべき顧客のサービスに対してSLOを設定して運用しています。
提供するサービスによりますが、優先したい条件のユーザーがいるのであれば、それらを識別する情報でメトリクスをフィルタし、SLI・SLOを設計することはよくあることだと思います。
複雑になってしまうという点については、そうならざるを得ない部分はあります。
なぜならビジネスが複雑だからです。
振り返りなどを通して、複雑なメトリクスのなかからユーザーの満足度に最も近いものを探っていくプロセスが大事であり、また難しい点だと思います。
Q. エラーバジェットのバーンレートアラートがうまく機能していれば従来のアラートの多くはなくせる、とあるが、なくすと困るケースも出てくるのではないか
アクショナブルなアラートかどうかというのが大事なポイントになってきます。
バーンレートアラートは、このペースでメトリクスが悪化すると、確実に信頼性が落ちていくのが目に見えているので早めにアクションを取りましょう、といったかたちで使うことができます。
一方で従来のアラートは、あるしきい値を超えると発報するように設定することが多いので、それを基準にしてアクションすることが難しい(少なくともアクションすべきかどうか判断する必要がある)という点で差異があります。
従来のアラートをやめるためには2つ条件があり、まずはバーンレートアラートがアクショナブルであるということを関係者間で実感してもらうこと、そして、従来のアラートとバーンレートアラートを比較したときに、従来のアラートがどれぐらい無視されているかを確認することです。
バーンレートアラートを通してアクションした結果、従来のアラートを無視しても大丈夫でしたよね、という事実を積み重ね、関係者間で合意ができれば、納得感をもって従来のアラートを消すことができると思います。
もちろん、バーンレートアラート以外のアラートが有効である、アクショナブルであると実感できる場合はそれを使えばよいですし、バーンレートアラート OR NOT というように考える必要はないと思います。
全体の感想
山口さんにエンジニア以外のメンバーも巻き込んでSLO本の読書会を実施している点はすばらしいというお言葉をいただき、進め方は間違ってなかったという自信が持てました。
SLO本の序文冒頭に「信頼性は会話です」とありますが、その一言にSLI・SLO・エラーバジェットをどう考えるべきかについてあらゆるエッセンスが詰まっているように感じます。
読書会や山口さんとの会を通じて、絶えずチーム・組織で会話を重ね、ユーザーが満足しているとはどのような状態か、どうすればその値を計測することができるかを追求していく姿勢、プロセスが大事だということを学べました。
改めて山口さんにはすばらしい翻訳と、理解を深める会へのご参加にこの場を借りてお礼申し上げます。
まだまだClassiはSLOを運用できていると自信を持って言える段階にはありませんが、SLOの文化を築けるように取り組んでいきたいと思います。
