Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SLOを組織文化にするための挑戦
Search
Yuji Kinjo
September 29, 2023
Technology
1
2.9k
SLOを組織文化にするための挑戦
SRE NEXT 2023 登壇資料
Yuji Kinjo
September 29, 2023
Tweet
Share
More Decks by Yuji Kinjo
See All by Yuji Kinjo
Firestore で CQRS やってみた
yukin01
23
4.8k
Other Decks in Technology
See All in Technology
プロダクトマネージャーは 事業責任者の夢をみるのか pmconf2024
gimupop
1
1.5k
Microsoft 365と開発者ツールの素敵な関係
kkamegawa
1
1.4k
LINEヤフーにおける超大規模プラットフォーム実現への挑戦と学び / Challenges and Lessons in Building an Ultra-Large-Scale Platform at LY Corporation
hhiroshell
2
960
Engineer Recruting Deck
siva_official
PRO
1
3.2k
AWS re:Invent 2024 予選落ちのBedrockアプデをまとめて解説!
minorun365
PRO
2
240
「品質とスピードはトレード・オンできる」に向き合い続けた2年半を振り返る / Quality and speed can be traded on.
mii3king
0
470
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
30
16k
メインテーマはKubernetes
nwiizo
2
330
Amazon CloudFrontを活用したゼロダウンタイム実現する安定的なデプロイメント / 20241129 Yoshiki Shinagawa
shift_evolve
0
130
総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用
kymmt90
3
2.8k
12/4(水)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #3 with AWS Heroes)
minorun365
PRO
2
190
専門領域に特化したチームの挑戦
leveragestech
0
240
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
4
150
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
470
Done Done
chrislema
181
16k
Music & Morning Musume
bryan
46
6.2k
Statistics for Hackers
jakevdp
796
220k
The Cost Of JavaScript in 2023
addyosmani
45
6.9k
Designing for Performance
lara
604
68k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
400
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.3k
It's Worth the Effort
3n
183
27k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Transcript
SLOを組織文化にするための挑戦 〜 Biz/Dev/SREが一丸で進めるSLOジャーニー 〜 SRE NEXT 2023 9/29 (Fri) Room
A 株式会社グロービス デジタル・プラットフォーム部門 金城 佑治
GLOBIS DIGITAL PLATFORM 2 自己紹介 金城 佑治(Kinjo Yuji) 株式会社グロービス SRE
2019年入社 @_yukin01(GitHub: yukin01) AWS/YAML/Go/TypeScript
GLOBIS DIGITAL PLATFORM 3 「GLOBIS 学び放題」について ビジネスパーソンに必須の知識 を、スマホやPCを通じて動画で 学ぶことが可能 幅広い顧客(個人・法人)に展開
2017年サービス提供開始 ※数値は2023年7月時点
GLOBIS DIGITAL PLATFORM 4 本日のテーマ 話すこと 話さないこと(話せないこと) ・SLOプロジェクト発足から3〜4か月の活動で直面した課題と、それに対するアプローチ ・そもそもSLOを知らないBiz/Devなどをいかに巻き込みながら進めてきたか ・SRE本などの理論やプラクティスをどう実践に落とし込んだか、あるいは諦めたか
・「こうして上手くいきました!」というキラキラした成功事例
GLOBIS DIGITAL PLATFORM 5 プロダクトと各チームの関係性 GLOBIS 学び放題 Team A Team
B Team ... Product B Product ... SRE Team (Enabling SRE + Platform SRE)
GLOBIS DIGITAL PLATFORM 6 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 7 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 8 SREチームの悩み 「どうしたらSLOに対して当事者意識を持ってもらえるか?」 障害が発生していないタイミングで訴えても響かないのは明白 他人にお願いされるより、自分からやりたいと思える方が良いはず アプローチの方法に悩んでいたら... SLOの重要性を理解してもらう
GLOBIS DIGITAL PLATFORM 9 偶然、信頼性が揺らぐ出来事があった その結果、 障害対応のプロセスを見直す動きが発生 プロダクトチーム内で全体的に サービスの安定性に対する温度感が高くなる SLOの重要性を理解してもらう
障害タイムライン概要 • 月初にDB高負荷によるアラートが発生 • 数時間で自然に収まる • 事後の調査で根本原因がわからず様子見 • 翌月にも同様のアラートが発生 • 実は多くのユーザーが影響を受けていた (問い合わせも発生していた)
GLOBIS DIGITAL PLATFORM 10 SLOの重要性を理解してもらう この動きに乗じて 「SLOアラートを導入すればユーザー影響がすぐわかる」 「プロダクトチームがもっと信頼性を意識すればMTTD、MTTRを短く出来る」 と訴求して、ステークホルダーの理解を得られた 外部要因を利用して内発的動機に繋げる
GLOBIS DIGITAL PLATFORM 11 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 12 SLOの認知度を上げる ステークホルダーの後ろ盾もあり 非エンジニアのメンバーにも多く参加してもらえた ステークホルダーの理解は得られたが、社内での 認知度はまだまだ低い SLOの詳細を知り、主体的に考えてもらうために
社内でSLOワークショップを開催 先日の障害を受けて、障害検知にフォーカスした 内容にカスタマイズ 勉強会ではなくワークショップ形式にした
GLOBIS DIGITAL PLATFORM 13 SLOの認知度を上げる とはいえ、SREチームにはワークショップ設計を やったことがない初心者しかいない ノウハウを学びつつ、直接フィードバックをもら うことでなんとか設計を進める ありがたいことに、社内にはビジネススキルにつ
いての”プロ”が沢山いる 「再現性が大事」 「目的とゴールを明確にする」 「道筋を迷わないように問いを磨き抜く」 といったノウハウを学ぶ
GLOBIS DIGITAL PLATFORM 14 SLOの認知度を上げる 非エンジニア向けの資料作りも難航 事前に発表のフィードバックをもらったところ 認識のギャップがかなりあった SLI/SLO/SLAといった略語やIT系の専門用語が 多いとハードルが高くなってしまう
当初説明する予定だったページを一部抜粋 「Appendix」と書いてある通り、付録に回して 本編では一切触れなかった 専門用語多めの意識高いページは全カット なるべく平易な表現になるよう見直す
GLOBIS DIGITAL PLATFORM 15 SLOの認知度を上げる 反省点はありつつも、一定の効果は得られた 結果的に、幅広い職種のメンバーを集めてSLOプ ロジェクトを発足することができた 非エンジニアを巻き込む工夫が重要
GLOBIS DIGITAL PLATFORM 16 SLOの認知度を上げる GLOBIS 学び放題 Team A Team
B Team ... SRE Team SLO Project Team SREチームはなるべく後方支援 や事務局の役割に徹する
GLOBIS DIGITAL PLATFORM 17 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 18 ドメインエキスパートを巻き込む Site Reliability Workbookの日本語訳では 「あるユーザーの体験の中核部分となるタスクの並び」??? CUJ(クリティカルユーザージャーニー)とは?
プロダクト側ではユーザーストーリーやカスタマージャーニーマップを扱うため、 それを参考にしつつ 「プロダクトにフォーカスしたユーザー体験の一連の行動」をUJ(ユーザージャーニー) その中でビジネス的にクリティカルなものをCUJとして扱うことにした
GLOBIS DIGITAL PLATFORM 19 ドメインエキスパートを巻き込む UJは先日のSLOワークショップでチームに分かれて既に作っていた しかし、クリティカルかどうかの判断基準は誰が決める? 様々な職種からの視点がないとCUJは決められない POやビジネスサイド、カスタマーサポートなど、プロダクトに詳しい人の視点が必要 例)最も売上に直結するUJは? 満たせないときすぐ問い合わせに繋がるUJは?
もちろん、SLI実装上の制約もあるためエンジニアの視点も必要
GLOBIS DIGITAL PLATFORM 20 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 21 オブザーバビリティを上げる ※可用性とレイテンシを採用 Datadogでの実装方針 全てのイベントをログとして記録 → カスタムメトリクス
→ メトリクスベースSLO (インテグレーションによるCloudWatch経由のELBメトリクス等は利用しなかった) SLI = × 100 Good Events Total Events 前提
GLOBIS DIGITAL PLATFORM 22 オブザーバビリティを上げる 基本構成 Ruby on Rails +
React GraphQLとREST APIを使い分け Sidekiqによる非同期ジョブ インフラはAWS(右図参照) 課題 SLIを計算可能なログになっていない
GLOBIS DIGITAL PLATFORM 23 パスとステータスコードが固定されていて一般的 なアクセスログからは計測できない APMのサンプリングレートを1にしてもトレース の全件取得を保証できなかった オブザーバビリティを上げる GraphQL
Operation Nameをリクエストヘッダに追加して Nginxログに出力 同じく、GraphQLのエラーコードをレスポンス ヘッダ経由でNginxログに出力 ステータスコードが200でもシステムエラーと クライアントエラーを区別できるようになった
GLOBIS DIGITAL PLATFORM 24 非同期処理はHTTPリクエストでは計測できない SidekiqのWorkerが出力するログを整備して 可用性とレイテンシを計測可能にした オブザーバビリティを上げる Sidekiq 可用性は
status、レイテンシは completed_at と enqueued_at の差分を計算してログに出力する 構造化ログで統一する
GLOBIS DIGITAL PLATFORM 25 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 26 SLOプロジェクトにはプロダクトチームの開発者ももちろんいるが普段の業務で忙しい SLIの詳細な実装などはSREが担当して、メンバーには議論や意思決定に注力してもらっていた 背景 成果物を早く見せる SREの実装に対する(SRE以外の)開発者のレビューの難易度が上がって エンジニア間のコミュニケーションコストが余計にかかってしまう
さらにプロジェクト定例の議題がSLIの実装メインになると 非エンジニアメンバーのエンゲージメント低下に繋がるという悪循環
GLOBIS DIGITAL PLATFORM 27 成果物でやりとりした方がイメージしやすく、コミュニケーションコストが下がる 結果的に全員に対して納得感を出すことが出来る 丁寧なレビュープロセスで合意をもらうのはもちろん大事だが... 成果物を早く見せる 正解がわからないような未知の実装は 成果物をはやく見せてフィードバックを貰う
オブザーバビリティ向上 → 開発環境でサクッと実装してデモを見せる SLOのターゲット → 目安となる値をいくつか仮置きしてデータを提示する
GLOBIS DIGITAL PLATFORM 28 1. 平常時にSLOの重要性を訴えても、当事者意識を持ってもらうのは難しい 2. そもそも社内でのSLOの認知度が低い 3. CUJ(クリティカルユーザージャーニー)の決め方がわからない
4. オブザーバビリティが低く、SLIを定義するのが難しい 5. 合意を求めすぎてコミュニケーションコストが高くなる 6. 各種プラクティスを一気に導入しようとした結果、先が見えなくなる 課題(PJ発足〜CUJ決定〜SLO運用開始)
GLOBIS DIGITAL PLATFORM 29 小さく運用を始める SLOドキュメント、バーンレートアラート、エラーバジェットポリシー etc... 段階を踏まず、最初から完璧な運用ルールを作ってプロダクト全体に広めようとしてしまった 背景 現実は、誰も導入プロセスの正解を知らないし、経験もない
知っているのはSRE本にあるようなベストプラクティスだけ 「次はSRE本にあるこのプラクティスを組織に導入したいです」 「わかりました(イマイチよくわからないな...)」という実体のない議論が続く
GLOBIS DIGITAL PLATFORM 30 小さく運用を始める 一旦、組織全体に適用するのはやめた プロジェクトメンバー+αで運用のサイクルを回すことを優先する まずは小さく運用して経験値を貯める
GLOBIS DIGITAL PLATFORM 31 小さく運用を始める エラーバジェットポリシー 組織全体ではなく各チームのプロダクトオーナーやチームリーダーに直接交渉する 例えばレイテンシSLOの場合、アラートが出たタイミングで即時対応するのはまだ難しい 次回スプリントで対応チケットを積むようにすることで合意 SLOのターゲット
まずは「問い合わせ数や離脱率が上がっていない期間」を顧客満足に沿っていると定義する その期間でちょうど満たすような値を設定する
GLOBIS DIGITAL PLATFORM 32 結論 小さく運用を回し始めたおかげで、さらに広げていくために必要なアクションが プロジェクトメンバーから出てくるようになった このような動きが プロダクトチーム(not SREチーム)がSLOを運用していくことに繋がっていくはず
これからもトップダウン・ボトムアップ両方のアプローチを続けていく 3〜4ヶ月取り組んだ結果、組織文化への一歩を踏み出せた
GLOBIS DIGITAL PLATFORM 33 今後やっていくこと • 信頼性回復の時間を確保するため、プロダクトチームのOKRにSLOを取り入れる • オブザーバビリティが上がったことを開発者に周知し、Datadogを通じてSLOへの 関心をさらに高めてもらう
• カスタマーサポートが問い合わせを受けたとき、SLOダッシュボードを使って障害 かユーザー起因か判断できるようにする • MTTD、MTTRを計測して障害検知が改善したことをデータで示す
None