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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

GLOBIS 学び放題
Team A Team B Team ...
SRE Team
SLO Project Team
SREチームはなるべく後方支援
や事務局の役割に徹する

View Slide


View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

基本構成
Ruby on Rails + React
GraphQLとREST APIを使い分け
Sidekiqによる非同期ジョブ
インフラはAWS（右図参照）
課題
SLIを計算可能なログになっていない

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

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

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

Yuji Kinjo

More Decks by Yuji Kinjo

Other Decks in Technology

Featured

Transcript