Development Division / Platform Team の村上です。

Repro では数年前から組織横断の SLO 運用を始めています。
SLO 運用をはじめた話については、前回の記事「Repro における組織横断な SLO のはじまり」で紹介しました。

今回はその続編で、SLO 運用における 0→1 が終わった後にどのような活動を進めていったのかを紹介します。

SLO の利用拡大へ向けて

組織横断で運用する最初の SLO が完了した後、暫くしてから今後の方針を検討しました。

SLO を推進していくことは前提として、次の半期で誰が何をどのように進めていくか、について最初の SLO 策定に関わったメンバーで話し合いました。

結果、大枠の方針は次の通りになりました。

Platform Team が SLO 推進のオーナーシップを持つ
Repro の既存機能に対し、Platform Team が主導で SLO を策定する
SLO を策定する過程で Feature Team を巻き込んでいく

Platform Team は、Core Unit と Sys-Infra Unit という 2 つの Unit で構成されています。
担当領域はちょっと違うものの、どちらも Repro の共通基盤を運用し、機能横断的にみている Unit であり、Sys-Infra はより SRE に近い役割を担っています。また、最初の SLO 策定は Core Unit で進めたこともあり、Platform Team で SLO 推進をリードすることになりました。

SLO を推進するとしても、SLO はまだ 1 つしか策定されておらず、Platform Team の中で経験値をためていく必要があると考え、既存機能の SLO 策定を Platform Team のメンバーで作り上げることにしました。

そして、SLO 運用は Platform Team だけではなく、顧客向けの機能開発チームである Feature Team にも担っていただきたいと考えていたので、今回のプロセスには Feature Team も関わってもらう想定で進めました。

SLO 推進チームの発足

SLO の利用拡大していくにあたり、SLO 推進のためのプロジェクトチームを作りました。

SLO を推進していく活動は、ユーザー体験と向き合っていくことが特に重要であると考え、直接お客様とコミュニケーションをとっている Customer Support (CS) の人達にも声をかけ、一緒に SLO 推進を進めていくことにしました。
最終的なプロジェクトチームの構成は、 Platform Team 4人、CS 2人、そして VPoE の計 7 人の布陣です¹。

SLO 推進チームを立ち上げた後は、キックオフをして、半期のゴールやロードマップの共有、お互いの責務と期待値の擦り合わせを行いました。

SLO のための重要なユーザー体験を見つける

Repro の全機能に対して片っ端から SLO を作っていくわけにはいかないので、まずは多くのお客様から使われている「アプリ内メッセージ」と「プッシュ配信」に絞って進めることにしました。
これらの機能を対象に、ユーザーにとって重要である体験を抽出し、そこから SLO を策定します。
「ユーザー」とは、Repro をご利用いただいているお客様と、お客様が運用しているサービスのエンドユーザーを指しています。

SLO 策定対象の抽出は、プロジェクトメンバーで Miro² を使って同期的に行いました。進め方は次のような感じです。

対象機能を使う上で重要だと考えるユーザーの体験を各自洗い出す
それぞれが出した内容をグルーピングする
- 機能固有の体験と、セグメンテーションや効果測定などの共通項で大きく分ける
「プッシュ配信」「アプリ内メッセージ」「共通」のそれぞれで、より重要度が高い体験を絞り込む
絞り込んだユーザー体験から SLO として策定する対象を選定し、重要ポイントをまとめる
- ユーザーの体験として重要ではあるものの SLO として扱う必要性が薄いものは省く。例えば、プッシュ配信などのマーケティング施策を作成・更新できない、という事象は 1 回でも発生したら即座に修正すべきであり、そのようなものに対しては SLO は設けない。

このようにして洗い出した「SLO を策定する重要なユーザー体験」をもとに、SLO 策定を進めていきます。

余談ですが、当初「ユーザー体験」というワードではなく CUJ(クリティカルユーザージャーニー)を使ってコミュニケーションしてました。しかし、大枠の CUJ になるであろう対象機能は最初から絞っていましたし、巷にあった CUJ の事例だと今回のケースはちょっとイメージしにくく、メンバー間で CUJ に対する解釈のズレが生まれそうだなと感じたので CUJ というワードの使用は控えるようにしてました。
期待通りに動かないとユーザーが強い不満を抱えてしまう箇所、の洗い出しがやりたかったことなので「重要なユーザー体験」という表現にしました。

SLO 説明会の開催

重要なユーザー体験を洗い出した後は、SLI の選定と実装・SLO の数値決め・エラーバジェットポリシー策定など、SLO の策定を進めていきます。以降のフェーズでは機能開発チームである Feature Team にも策定までの一連のプロセスに関与してもらいたかったので、まずは Feature Team 向けの SLO 説明会を開催しました。

説明会で作った資料は、The Art of SLOs のスライドをところどころ参考にしました。
掴みにくい SLI や SLO の概念を良い具合に図示しているところがあり、自分のスライドにも同じようなものを挿入してます。実際に作った対象のスライドを貼っておきます。

ユーザー体験から SLI を決定する

ユーザー体験の良し悪しを測定するための SLI をディスカッションしながら固めていきました。

対象機能は「プッシュ配信」「アプリ内メッセージ」の 2 つの機能であり、Feature Team も当時 2 つの Unit で構成されていたので、2 グループに分けてディスカッションする場を用意しました。このとき、SLO 推進チームのメンバーは各グループに散らばっています。
このディスカッションも Miro を使って進めました。

SLI を固めるときのステップは以下です。

ユーザー体験に対して、どのようなデータがあれば測れそうかを諸々の制約は考えずに案出しする
出した案を SLI 定義に当てはめてみる

SLI として定義するときは、次のような観点が満たされているかをチェックしてもらいます。

パーセンテージで表現できるか？
ユーザー体験に沿っているか？
測定データの取得は困難でないか？
そもそも SLO を作る必要があるのか？

ディスカッションの時間内では SLI を決めきるところまで至らなかったものの、SLI の仕様や実装で使うデータはある程度固まったので、それらを基に最終的な形を仕上げました。

SLO の策定

SLI/SLO やエラーバジェットポリシーの決定し SLO ドキュメントに書き起こす、ステークホルダーの承諾を獲得する、Datadog SLO の作成とダッシュボードを更新する、など SLO 策定に関する作業は Platform Team が行いました。

Platform Team が構築した SLO の中には「SLOを満たすことに責任を負うメンバー」が Feature Team になる場合もあり、その場合は SLI の閾値や SLO、エラーバジェットポリシーが妥当かどうかを Feature Team にレビューしてもらいました。

SLO の定義をする上で「サービスの信頼性」や「ユーザーの満足度」みたいな曖昧な概念を定量化して、その妥当性を誰がみてもわかる状態にすることが求められます。SLO 策定を進めていく中で、これがやっぱり難しいところだなと改めて実感しました。
SLO ドキュメントでは前提知識として関連するサービス概要を記載していますが、SLO 承諾判断を行ってもらうため対象のユーザー体験を正しく理解してもらう必要があり、サービス概要だけで 1 記事分くらいの量になることもありました（もはや"概要"ではないですね…）。
また、SLI の閾値や SLO の数値についても「なぜその数値にしているのか？」が誰にでもわかるようにしておくことが不可欠で、それが感覚的なものだとしても背景や根拠を言語化する必要があります。ある程度自社におけるパターンが出来てしまえば踏襲はできますが、このときは SLO がまだ 1 つしかなかったので、数値の論拠の記載は難しいポイントの 1 つでした。

そうこうして、新たな SLO をいくつか策定したのですが、どれも丁寧に作り上げ良質な事例として使えるものに仕上がっているので、SLO 運用を広げていく上で役に立つ資産にもなりました。

おわりに

SLO 運用における 0→1 が終わった後の、SLO 利用拡大に向けた取り組みについて紹介しました。

SLO を増やしたことにより、実際にエラーバジェットポリシーに基づくアクションを取る機会が出てきました。
優先したい他の作業があるからエラーバジェットポリシーのアクションは後回しにする、といったような行動を許容すると、SLO 自体の信頼性が損なわれて策定する意味がなくなってしまいます。
そのため、自チームが持つ SLO は勿論、他チームでも適切にエラーバジェットポリシーが守れているかにも気を配るようになりました。

いちばん最初の SLO を策定したとき、利用拡大における課題は「SLO 策定の各プロセスを可能な限り省力化してリードタイムを短くすること」だと考えていました。
素早く SLO を策定できるよう整えることは利用拡大において大切です。ただ、SLO 策定の過程で「ユーザーにとって大事なことは何か」という問いに、時間をかけてでも全員でちゃんと向き合うことも、ユーザーへの価値提供の質を高める上で同じように大切です。
重要なユーザー体験やそれを測るための SLI をディスカションする中で、そのことをより実感できました。

SLO 策定した後のメリットに意識が向きがちでしたが、今回紹介した取り組みを経て、SLO を策定するその過程にも価値があるのだなと感じるようになりました。