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

SRE NEXT 2023 登壇資料

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. View Slide