SLOを組織文化にするための挑戦

SRE NEXT 2023 登壇資料

Transcript

1. SLOを組織文化にするための挑戦 〜 Biz/Dev/SREが一丸で進めるSLOジャーニー 〜 SRE NEXT 2023 9/29 (Fri) Room A 株式会社グロービス デジタル・プラットフォーム部門 金城 佑治
2. GLOBIS DIGITAL PLATFORM 2 自己紹介 金城 佑治（Kinjo Yuji） 株式会社グロービス SRE 2019年入社 @_yukin01（GitHub: yukin01） AWS/YAML/Go/TypeScript
3. GLOBIS DIGITAL PLATFORM 3 「GLOBIS 学び放題」について ビジネスパーソンに必須の知識 を、スマホやPCを通じて動画で 学ぶことが可能 幅広い顧客（個人・法人）に展開 2017年サービス提供開始 ※数値は2023年7月時点
4. GLOBIS DIGITAL PLATFORM 4 本日のテーマ 話すこと 話さないこと（話せないこと） ・SLOプロジェクト発足から3〜4か月の活動で直面した課題と、それに対するアプローチ 　・そもそもSLOを知らないBiz/Devなどをいかに巻き込みながら進めてきたか 　・SRE本などの理論やプラクティスをどう実践に落とし込んだか、あるいは諦めたか ・「こうして上手くいきました！」というキラキラした成功事例
5. GLOBIS DIGITAL PLATFORM 5 プロダクトと各チームの関係性 GLOBIS 学び放題 Team A Team B Team ... Product B Product ... SRE Team (Enabling SRE + Platform SRE)
6. GLOBIS DIGITAL PLATFORM 6 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
7. GLOBIS DIGITAL PLATFORM 7 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
8. GLOBIS DIGITAL PLATFORM 8 SREチームの悩み 「どうしたらSLOに対して当事者意識を持ってもらえるか？」 障害が発生していないタイミングで訴えても響かないのは明白 他人にお願いされるより、自分からやりたいと思える方が良いはず アプローチの方法に悩んでいたら... SLOの重要性を理解してもらう
9. GLOBIS DIGITAL PLATFORM 9 偶然、信頼性が揺らぐ出来事があった その結果、 障害対応のプロセスを見直す動きが発生 プロダクトチーム内で全体的に サービスの安定性に対する温度感が高くなる SLOの重要性を理解してもらう 　障害タイムライン概要 • 月初にDB高負荷によるアラートが発生 • 数時間で自然に収まる • 事後の調査で根本原因がわからず様子見 • 翌月にも同様のアラートが発生 • 実は多くのユーザーが影響を受けていた （問い合わせも発生していた）
10. GLOBIS DIGITAL PLATFORM 10 SLOの重要性を理解してもらう この動きに乗じて 「SLOアラートを導入すればユーザー影響がすぐわかる」 「プロダクトチームがもっと信頼性を意識すればMTTD、MTTRを短く出来る」 と訴求して、ステークホルダーの理解を得られた 外部要因を利用して内発的動機に繋げる
11. GLOBIS DIGITAL PLATFORM 11 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
12. GLOBIS DIGITAL PLATFORM 12 SLOの認知度を上げる ステークホルダーの後ろ盾もあり 非エンジニアのメンバーにも多く参加してもらえた ステークホルダーの理解は得られたが、社内での 認知度はまだまだ低い SLOの詳細を知り、主体的に考えてもらうために 社内でSLOワークショップを開催 先日の障害を受けて、障害検知にフォーカスした 内容にカスタマイズ 勉強会ではなくワークショップ形式にした
13. GLOBIS DIGITAL PLATFORM 13 SLOの認知度を上げる とはいえ、SREチームにはワークショップ設計を やったことがない初心者しかいない ノウハウを学びつつ、直接フィードバックをもら うことでなんとか設計を進める ありがたいことに、社内にはビジネススキルにつ いての”プロ”が沢山いる 「再現性が大事」 「目的とゴールを明確にする」 「道筋を迷わないように問いを磨き抜く」 といったノウハウを学ぶ
14. GLOBIS DIGITAL PLATFORM 14 SLOの認知度を上げる 非エンジニア向けの資料作りも難航 事前に発表のフィードバックをもらったところ　 認識のギャップがかなりあった SLI/SLO/SLAといった略語やIT系の専門用語が　 多いとハードルが高くなってしまう 当初説明する予定だったページを一部抜粋 「Appendix」と書いてある通り、付録に回して 本編では一切触れなかった 専門用語多めの意識高いページは全カット なるべく平易な表現になるよう見直す
15. GLOBIS DIGITAL PLATFORM 15 SLOの認知度を上げる 反省点はありつつも、一定の効果は得られた 結果的に、幅広い職種のメンバーを集めてSLOプ ロジェクトを発足することができた 非エンジニアを巻き込む工夫が重要
16. GLOBIS DIGITAL PLATFORM 16 SLOの認知度を上げる GLOBIS 学び放題 Team A Team B Team ... SRE Team SLO Project Team SREチームはなるべく後方支援 や事務局の役割に徹する
17. GLOBIS DIGITAL PLATFORM 17 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
18. GLOBIS DIGITAL PLATFORM 18 ドメインエキスパートを巻き込む Site Reliability Workbookの日本語訳では 「あるユーザーの体験の中核部分となるタスクの並び」？？？ CUJ（クリティカルユーザージャーニー）とは？ プロダクト側ではユーザーストーリーやカスタマージャーニーマップを扱うため、 それを参考にしつつ 「プロダクトにフォーカスしたユーザー体験の一連の行動」をUJ（ユーザージャーニー） その中でビジネス的にクリティカルなものをCUJとして扱うことにした
19. GLOBIS DIGITAL PLATFORM 19 ドメインエキスパートを巻き込む UJは先日のSLOワークショップでチームに分かれて既に作っていた しかし、クリティカルかどうかの判断基準は誰が決める？ 様々な職種からの視点がないとCUJは決められない POやビジネスサイド、カスタマーサポートなど、プロダクトに詳しい人の視点が必要 　　例）最も売上に直結するUJは？　満たせないときすぐ問い合わせに繋がるUJは？ もちろん、SLI実装上の制約もあるためエンジニアの視点も必要
20. GLOBIS DIGITAL PLATFORM 20 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
21. GLOBIS DIGITAL PLATFORM 21 オブザーバビリティを上げる ※可用性とレイテンシを採用 Datadogでの実装方針 全てのイベントをログとして記録 → カスタムメトリクス → メトリクスベースSLO （インテグレーションによるCloudWatch経由のELBメトリクス等は利用しなかった） SLI = × 100 Good Events Total Events 前提
22. GLOBIS DIGITAL PLATFORM 22 オブザーバビリティを上げる 基本構成 Ruby on Rails + React GraphQLとREST APIを使い分け Sidekiqによる非同期ジョブ インフラはAWS（右図参照） 課題 SLIを計算可能なログになっていない
23. GLOBIS DIGITAL PLATFORM 23 パスとステータスコードが固定されていて一般的 なアクセスログからは計測できない APMのサンプリングレートを1にしてもトレース の全件取得を保証できなかった オブザーバビリティを上げる GraphQL Operation Nameをリクエストヘッダに追加して Nginxログに出力 同じく、GraphQLのエラーコードをレスポンス ヘッダ経由でNginxログに出力 ステータスコードが200でもシステムエラーと　 クライアントエラーを区別できるようになった
24. GLOBIS DIGITAL PLATFORM 24 非同期処理はHTTPリクエストでは計測できない SidekiqのWorkerが出力するログを整備して　　 可用性とレイテンシを計測可能にした オブザーバビリティを上げる Sidekiq 可用性は status、レイテンシは completed_at と enqueued_at の差分を計算してログに出力する 構造化ログで統一する
25. GLOBIS DIGITAL PLATFORM 25 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
26. GLOBIS DIGITAL PLATFORM 26 SLOプロジェクトにはプロダクトチームの開発者ももちろんいるが普段の業務で忙しい SLIの詳細な実装などはSREが担当して、メンバーには議論や意思決定に注力してもらっていた 背景 成果物を早く見せる SREの実装に対する（SRE以外の）開発者のレビューの難易度が上がって エンジニア間のコミュニケーションコストが余計にかかってしまう さらにプロジェクト定例の議題がSLIの実装メインになると 非エンジニアメンバーのエンゲージメント低下に繋がるという悪循環
27. GLOBIS DIGITAL PLATFORM 27 成果物でやりとりした方がイメージしやすく、コミュニケーションコストが下がる 結果的に全員に対して納得感を出すことが出来る 丁寧なレビュープロセスで合意をもらうのはもちろん大事だが... 成果物を早く見せる 正解がわからないような未知の実装は 成果物をはやく見せてフィードバックを貰う オブザーバビリティ向上 → 開発環境でサクッと実装してデモを見せる SLOのターゲット → 目安となる値をいくつか仮置きしてデータを提示する
28. GLOBIS DIGITAL PLATFORM 28 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題（PJ発足〜CUJ決定〜SLO運用開始）
29. GLOBIS DIGITAL PLATFORM 29 小さく運用を始める SLOドキュメント、バーンレートアラート、エラーバジェットポリシー etc... 段階を踏まず、最初から完璧な運用ルールを作ってプロダクト全体に広めようとしてしまった 背景 現実は、誰も導入プロセスの正解を知らないし、経験もない 知っているのはSRE本にあるようなベストプラクティスだけ 「次はSRE本にあるこのプラクティスを組織に導入したいです」 「わかりました（イマイチよくわからないな...）」という実体のない議論が続く
30. GLOBIS DIGITAL PLATFORM 30 小さく運用を始める 一旦、組織全体に適用するのはやめた プロジェクトメンバー+αで運用のサイクルを回すことを優先する まずは小さく運用して経験値を貯める
31. GLOBIS DIGITAL PLATFORM 31 小さく運用を始める エラーバジェットポリシー 組織全体ではなく各チームのプロダクトオーナーやチームリーダーに直接交渉する 例えばレイテンシSLOの場合、アラートが出たタイミングで即時対応するのはまだ難しい 次回スプリントで対応チケットを積むようにすることで合意 SLOのターゲット まずは「問い合わせ数や離脱率が上がっていない期間」を顧客満足に沿っていると定義する その期間でちょうど満たすような値を設定する
32. GLOBIS DIGITAL PLATFORM 32 結論 小さく運用を回し始めたおかげで、さらに広げていくために必要なアクションが プロジェクトメンバーから出てくるようになった このような動きが プロダクトチーム（not SREチーム）がSLOを運用していくことに繋がっていくはず これからもトップダウン・ボトムアップ両方のアプローチを続けていく 3〜4ヶ月取り組んだ結果、組織文化への一歩を踏み出せた
33. GLOBIS DIGITAL PLATFORM 33 今後やっていくこと • 信頼性回復の時間を確保するため、プロダクトチームのOKRにSLOを取り入れる • オブザーバビリティが上がったことを開発者に周知し、Datadogを通じてSLOへの 関心をさらに高めてもらう • カスタマーサポートが問い合わせを受けたとき、SLOダッシュボードを使って障害 かユーザー起因か判断できるようにする • MTTD、MTTRを計測して障害検知が改善したことをデータで示す