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

Slide 1

Slide 1 text

SLOを組織文化にするための挑戦〜 Biz/Dev/SREが一丸で進めるSLOジャーニー〜 SRE NEXT 2023 9/29 (Fri) Room A 株式会社グロービスデジタル・プラットフォーム部門金城佑治

Slide 2

Slide 2 text

GLOBIS DIGITAL PLATFORM 2 自己紹介金城佑治（Kinjo Yuji）株式会社グロービス SRE 2019年入社 @_yukin01（GitHub: yukin01） AWS/YAML/Go/TypeScript

Slide 3

Slide 3 text

GLOBIS DIGITAL PLATFORM 3 「GLOBIS 学び放題」についてビジネスパーソンに必須の知識を、スマホやPCを通じて動画で学ぶことが可能幅広い顧客（個人・法人）に展開 2017年サービス提供開始 ※数値は2023年7月時点

Slide 4

Slide 4 text

GLOBIS DIGITAL PLATFORM 4 本日のテーマ話すこと話さないこと（話せないこと）・SLOプロジェクト発足から3〜4か月の活動で直面した課題と、それに対するアプローチ　・そもそもSLOを知らないBiz/Devなどをいかに巻き込みながら進めてきたか　・SRE本などの理論やプラクティスをどう実践に落とし込んだか、あるいは諦めたか・「こうして上手くいきました！」というキラキラした成功事例

Slide 5

Slide 5 text

GLOBIS DIGITAL PLATFORM 5 プロダクトと各チームの関係性 GLOBIS 学び放題 Team A Team B Team ... Product B Product ... SRE Team (Enabling SRE + Platform SRE)

Slide 6

Slide 6 text

GLOBIS DIGITAL PLATFORM 6 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 7

Slide 7 text

GLOBIS DIGITAL PLATFORM 7 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 8

Slide 8 text

GLOBIS DIGITAL PLATFORM 8 SREチームの悩み「どうしたらSLOに対して当事者意識を持ってもらえるか？」障害が発生していないタイミングで訴えても響かないのは明白他人にお願いされるより、自分からやりたいと思える方が良いはずアプローチの方法に悩んでいたら... SLOの重要性を理解してもらう

Slide 9

Slide 9 text

GLOBIS DIGITAL PLATFORM 9 偶然、信頼性が揺らぐ出来事があったその結果、障害対応のプロセスを見直す動きが発生プロダクトチーム内で全体的にサービスの安定性に対する温度感が高くなる SLOの重要性を理解してもらう　障害タイムライン概要 ● 月初にDB高負荷によるアラートが発生 ● 数時間で自然に収まる ● 事後の調査で根本原因がわからず様子見 ● 翌月にも同様のアラートが発生 ● 実は多くのユーザーが影響を受けていた（問い合わせも発生していた）

Slide 10

Slide 10 text

GLOBIS DIGITAL PLATFORM 10 SLOの重要性を理解してもらうこの動きに乗じて「SLOアラートを導入すればユーザー影響がすぐわかる」「プロダクトチームがもっと信頼性を意識すればMTTD、MTTRを短く出来る」と訴求して、ステークホルダーの理解を得られた外部要因を利用して内発的動機に繋げる

Slide 11

Slide 11 text

GLOBIS DIGITAL PLATFORM 11 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 12

Slide 12 text

GLOBIS DIGITAL PLATFORM 12 SLOの認知度を上げるステークホルダーの後ろ盾もあり非エンジニアのメンバーにも多く参加してもらえたステークホルダーの理解は得られたが、社内での認知度はまだまだ低い SLOの詳細を知り、主体的に考えてもらうために社内でSLOワークショップを開催先日の障害を受けて、障害検知にフォーカスした内容にカスタマイズ勉強会ではなくワークショップ形式にした

Slide 13

Slide 13 text

GLOBIS DIGITAL PLATFORM 13 SLOの認知度を上げるとはいえ、SREチームにはワークショップ設計をやったことがない初心者しかいないノウハウを学びつつ、直接フィードバックをもらうことでなんとか設計を進めるありがたいことに、社内にはビジネススキルについての”プロ”が沢山いる「再現性が大事」「目的とゴールを明確にする」「道筋を迷わないように問いを磨き抜く」といったノウハウを学ぶ

Slide 14

Slide 14 text

GLOBIS DIGITAL PLATFORM 14 SLOの認知度を上げる非エンジニア向けの資料作りも難航事前に発表のフィードバックをもらったところ　認識のギャップがかなりあった SLI/SLO/SLAといった略語やIT系の専門用語が　多いとハードルが高くなってしまう当初説明する予定だったページを一部抜粋「Appendix」と書いてある通り、付録に回して本編では一切触れなかった専門用語多めの意識高いページは全カットなるべく平易な表現になるよう見直す

Slide 15

Slide 15 text

GLOBIS DIGITAL PLATFORM 15 SLOの認知度を上げる反省点はありつつも、一定の効果は得られた結果的に、幅広い職種のメンバーを集めてSLOプロジェクトを発足することができた非エンジニアを巻き込む工夫が重要

Slide 16

Slide 16 text

GLOBIS DIGITAL PLATFORM 16 SLOの認知度を上げる GLOBIS 学び放題 Team A Team B Team ... SRE Team SLO Project Team SREチームはなるべく後方支援や事務局の役割に徹する

Slide 17

Slide 17 text

GLOBIS DIGITAL PLATFORM 17 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 18

Slide 18 text

GLOBIS DIGITAL PLATFORM 18 ドメインエキスパートを巻き込む Site Reliability Workbookの日本語訳では「あるユーザーの体験の中核部分となるタスクの並び」？？？ CUJ（クリティカルユーザージャーニー）とは？プロダクト側ではユーザーストーリーやカスタマージャーニーマップを扱うため、それを参考にしつつ「プロダクトにフォーカスしたユーザー体験の一連の行動」をUJ（ユーザージャーニー）その中でビジネス的にクリティカルなものをCUJとして扱うことにした

Slide 19

Slide 19 text

GLOBIS DIGITAL PLATFORM 19 ドメインエキスパートを巻き込む UJは先日のSLOワークショップでチームに分かれて既に作っていたしかし、クリティカルかどうかの判断基準は誰が決める？様々な職種からの視点がないとCUJは決められない POやビジネスサイド、カスタマーサポートなど、プロダクトに詳しい人の視点が必要　　例）最も売上に直結するUJは？　満たせないときすぐ問い合わせに繋がるUJは？もちろん、SLI実装上の制約もあるためエンジニアの視点も必要

Slide 20

Slide 20 text

GLOBIS DIGITAL PLATFORM 20 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 21

Slide 21 text

GLOBIS DIGITAL PLATFORM 21 オブザーバビリティを上げる ※可用性とレイテンシを採用 Datadogでの実装方針全てのイベントをログとして記録 → カスタムメトリクス → メトリクスベースSLO （インテグレーションによるCloudWatch経由のELBメトリクス等は利用しなかった） SLI = × 100 Good Events Total Events 前提

Slide 22

Slide 22 text

GLOBIS DIGITAL PLATFORM 22 オブザーバビリティを上げる基本構成 Ruby on Rails + React GraphQLとREST APIを使い分け Sidekiqによる非同期ジョブインフラはAWS（右図参照）課題 SLIを計算可能なログになっていない

Slide 23

Slide 23 text

GLOBIS DIGITAL PLATFORM 23 パスとステータスコードが固定されていて一般的なアクセスログからは計測できない APMのサンプリングレートを1にしてもトレースの全件取得を保証できなかったオブザーバビリティを上げる GraphQL Operation Nameをリクエストヘッダに追加して Nginxログに出力同じく、GraphQLのエラーコードをレスポンスヘッダ経由でNginxログに出力ステータスコードが200でもシステムエラーと　クライアントエラーを区別できるようになった

Slide 24

Slide 24 text

GLOBIS DIGITAL PLATFORM 24 非同期処理はHTTPリクエストでは計測できない SidekiqのWorkerが出力するログを整備して　　可用性とレイテンシを計測可能にしたオブザーバビリティを上げる Sidekiq 可用性は status、レイテンシは completed_at と enqueued_at の差分を計算してログに出力する構造化ログで統一する

Slide 25

Slide 25 text

GLOBIS DIGITAL PLATFORM 25 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 26

Slide 26 text

GLOBIS DIGITAL PLATFORM 26 SLOプロジェクトにはプロダクトチームの開発者ももちろんいるが普段の業務で忙しい SLIの詳細な実装などはSREが担当して、メンバーには議論や意思決定に注力してもらっていた背景成果物を早く見せる SREの実装に対する（SRE以外の）開発者のレビューの難易度が上がってエンジニア間のコミュニケーションコストが余計にかかってしまうさらにプロジェクト定例の議題がSLIの実装メインになると非エンジニアメンバーのエンゲージメント低下に繋がるという悪循環

Slide 27

Slide 27 text

GLOBIS DIGITAL PLATFORM 27 成果物でやりとりした方がイメージしやすく、コミュニケーションコストが下がる結果的に全員に対して納得感を出すことが出来る丁寧なレビュープロセスで合意をもらうのはもちろん大事だが... 成果物を早く見せる正解がわからないような未知の実装は成果物をはやく見せてフィードバックを貰うオブザーバビリティ向上 → 開発環境でサクッと実装してデモを見せる SLOのターゲット → 目安となる値をいくつか仮置きしてデータを提示する

Slide 28

Slide 28 text

GLOBIS DIGITAL PLATFORM 28 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ（クリティカルユーザージャーニー）の決め方がわからない 4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる課題（PJ発足〜CUJ決定〜SLO運用開始）

Slide 29

Slide 29 text

GLOBIS DIGITAL PLATFORM 29 小さく運用を始める SLOドキュメント、バーンレートアラート、エラーバジェットポリシー etc... 段階を踏まず、最初から完璧な運用ルールを作ってプロダクト全体に広めようとしてしまった背景現実は、誰も導入プロセスの正解を知らないし、経験もない知っているのはSRE本にあるようなベストプラクティスだけ「次はSRE本にあるこのプラクティスを組織に導入したいです」「わかりました（イマイチよくわからないな...）」という実体のない議論が続く

Slide 30

Slide 30 text

GLOBIS DIGITAL PLATFORM 30 小さく運用を始める一旦、組織全体に適用するのはやめたプロジェクトメンバー+αで運用のサイクルを回すことを優先するまずは小さく運用して経験値を貯める

Slide 31

Slide 31 text

GLOBIS DIGITAL PLATFORM 31 小さく運用を始めるエラーバジェットポリシー組織全体ではなく各チームのプロダクトオーナーやチームリーダーに直接交渉する例えばレイテンシSLOの場合、アラートが出たタイミングで即時対応するのはまだ難しい次回スプリントで対応チケットを積むようにすることで合意 SLOのターゲットまずは「問い合わせ数や離脱率が上がっていない期間」を顧客満足に沿っていると定義するその期間でちょうど満たすような値を設定する

Slide 32

Slide 32 text

GLOBIS DIGITAL PLATFORM 32 結論小さく運用を回し始めたおかげで、さらに広げていくために必要なアクションがプロジェクトメンバーから出てくるようになったこのような動きがプロダクトチーム（not SREチーム）がSLOを運用していくことに繋がっていくはずこれからもトップダウン・ボトムアップ両方のアプローチを続けていく 3〜4ヶ月取り組んだ結果、組織文化への一歩を踏み出せた

Slide 33

Slide 33 text

GLOBIS DIGITAL PLATFORM 33 今後やっていくこと ● 信頼性回復の時間を確保するため、プロダクトチームのOKRにSLOを取り入れる ● オブザーバビリティが上がったことを開発者に周知し、Datadogを通じてSLOへの関心をさらに高めてもらう ● カスタマーサポートが問い合わせを受けたとき、SLOダッシュボードを使って障害かユーザー起因か判断できるようにする ● MTTD、MTTRを計測して障害検知が改善したことをデータで示す

Slide 34

Slide 34 text

No content