SLI/SLO、「完全に理解した」から「チョットデキル」へ

at https://sre-lounge.connpass.com/event/381852/

Transcript

1. © LY Corporation © LY Corporation Public SLI/SLO、 「完全に理解した」から「チョットデキル」へ LINEヤフー株式会社 SRE @maru in Road to SRE NEXT 2026 at 名古屋 1 / 49
2. © LY Corporation © LY Corporation Public 今日話すこと SLI/SLOは広く知られたプラクティスです。 しかし、実際に定義し、意思決定・アラート・コミュニケーションに活用できているチームは多くありま せん。 今日は「正しい定義のしかた」そのものよりも、次の解像度を一緒に上げていきたいです。 なぜ始めにくいのか 途中で何が起きるのか どう始めると現実的か ぜひ、この後の休憩・懇親会でも皆さんのお話も聞かせてください！ 2 / 49
3. © LY Corporation © LY Corporation Public 今日の結論 SLI/SLOは、完成した組織だけのためのものではありません。 ただし、いきなり意思決定に使えるものでもありません。 まずは、ユーザー体験・技術課題・事業判断をつなぐ 共通言語を作るためのマイルストーンとして扱うと、現実的に始めやすくなります。 3 / 49
4. © LY Corporation © LY Corporation Public 会場の皆さんへの質問 手を挙げなくて大丈夫です 該当する人は、私に目を合わせてください！ 該当しない人は、さっと目線を外したり、周りの方をキョロキョロ見回してください 4 / 49
5. © LY Corporation © LY Corporation Public 会場の皆さんへの質問 手を挙げなくて大丈夫です 該当する人は、私に目を合わせてください！ 該当しない人は、さっと目線を外したり、周りの方をキョロキョロ見回してください SLI/SLOを聞いたことがある人？ “ “ 5 / 49
6. © LY Corporation © LY Corporation Public 会場の皆さんへの質問 手を挙げなくて大丈夫です 該当する人は、私に目を合わせてください！ 該当しない人は、さっと目線を外したり、周りの方をキョロキョロ見回してください 業務で実際に定義したことがある人？ “ “ 6 / 49
7. © LY Corporation © LY Corporation Public 会場の皆さんへの質問 手を挙げなくて大丈夫です 該当する人は、私に目を合わせてください！ 該当しない人は、さっと目線を外したり、周りの方をキョロキョロ見回してください 意思決定やアラート設定などに活用できている人？ “ “ 7 / 49
8. © LY Corporation © LY Corporation Public 会場の皆さんへの質問 手を挙げなくて大丈夫です 該当する人は、私に目を合わせてください！ 該当しない人は、さっと目線を外したり、周りの方をキョロキョロ見回してください 開発だけでなく、事業側も含めて合意できている人？ “ “ 8 / 49
9. © LY Corporation © LY Corporation Public SRE Kaigi 2026でのMIXI社のブースでのアンケート結果 9 / 49
10. © LY Corporation © LY Corporation Public 認知と活用のあいだにあるギャップ 多くのチームでは、SLI/SLOを「知っている」ことと、 実際に「使えている」ことのあいだに大きな差があります。 聞いたことはある 定義したこともある でも、意思決定や優先順位づけには使えていない 事業側との共通言語にはなっていない 今日は、このギャップがなぜ生まれるのかを考えます。 10 / 49
11. © LY Corporation © LY Corporation Public SLI/SLOについて簡単なおさらい サービスレベル指標(SLI)は、ユーザーの観点からサービスがどのように動作しているかの指標 サービスレベル目標(SLO)は、その指標の目標値 SLOを高くすればするほど、冗長化などのためにコストが多くかかります。 SLOを低く設定しすぎると、ユーザーが離れてしまいます。 11 / 49
12. © LY Corporation © LY Corporation Public SLI/SLOは“スタート地点”に見えやすい SLI/SLOは「定義そのもの」よりも「活用」に価値がある、と語られがちです。 例えば 1. 費用対効果の妥当なアーキテクチャにできる 2. 障害注入試験(カオスエンジニアリング)ができる 3. ユーザーに影響があるアラートだけ、深夜休日に鳴らすことができる という思われていることが多いです。 定義するだけだと意味がなくて、そこから本番が始まるもの “ “ 12 / 49
13. © LY Corporation © LY Corporation Public さらに、ユーザーや市場自体が変わりうる場合は...? まだ十分なユーザーを獲得しておらず、来週には 別のユーザー市場を狙った 機能開発をしているかも しれません リリースした小さな機能が、想定とは全く別の使われ方をして、突然、想定外のユーザー を獲得する かもしれません ビッグテックやAI企業が参入してきて、ピボットして別のプロダクト を開発しないといけなくなるか もしれません ユーザーや市場が変わるなら、求められる期待値も変わります。 その度にSLI/SLOの再定義と活用をやり直すのでしょうか？ 13 / 49
14. © LY Corporation © LY Corporation Public SLI/SLOが"不安定なスタート地点"に見える Default Alive寄り 1ヶ月リフレッシュ休暇を取ってもプロダクトが存続している SLI/SLOへ取り組んでも、外的要因で振り出しに戻りにくい Default Dead寄り 走り続けないと、いつ終わってしまうかわからない 十分な合意形成よりも、素早い仮説検証が優先されることがある 多くのSREsは、Default Deadとは言わないまでも、 外的要因で市場やユーザーが変わりにくいとは言えないと思います。 14 / 49
15. © LY Corporation © LY Corporation Public SRE以前から、同じような仕事はやってた SREという言葉が一般化する前から、安定性やコスト削減のための仕事は存在していた。 監視 障害対応 キャパシティプランニング テスト 運用改善 SLI/SLOがなくても似たような仕事はできてた。 “ “ 15 / 49
16. © LY Corporation © LY Corporation Public もしかして、SLI/SLOはNot for Me? 定義するだけでなく、高度な活用をしないと意味がない気がする SLI/SLOを定義しても、外的要因で容易に変わりうる気がする SREが一般化する前と今で、あまりやっていることに差がない気がする 16 / 49
17. © LY Corporation © LY Corporation Public もしかして、SLI/SLOはNot for Me? 定義するだけでなく、高度な活用をしないと意味がない気がする SLI/SLOを定義しても、外的要因で容易に変わりうる気がする SREが一般化する前と今で、あまりやっていることに差がない気がする SLI/SLOは、良いプラクティスかもしれないけど、 私たちには不要では？？ “ “ 17 / 49
18. © LY Corporation © LY Corporation Public SLI/SLOをスタート地点ではなく 通過点(マイルストーン)だと考えよう 18 / 49
19. © LY Corporation © LY Corporation Public 信頼性の階層構造から考える 『サイトリライアビリティエンジニアリング』(通称Google SRE本)で紹介 その後『SREをはじめよう』で現代風に変更されたものが紹介された UXを十分検討するためには、下位を満たす必要があるという図 当たり前に見える内容だが、 なぜこれが優れているのか？ 引用: SREをはじめよう https://www.oreilly.co.jp/books/9784814400904/ 19 / 49
20. © LY Corporation © LY Corporation Public ロールによる視界差を認識できることが素晴らしい 企画 / デザイナ / 営業 / マネージャー 頂点側のUXが見えやすい 事業影響が見える 顧客説明や期待値調整が気になる ユーザー行動の変化が見える UX/開発のために、土台が重要なことがわかる SRE / インフラ / バックエンド 観測できない箇所が気になる 障害対応や運用負荷が見える 技術的負債の影響が見える 土台はUXや開発のためにあることがわかる 20 / 49
21. © LY Corporation © LY Corporation Public 信頼性の階層構造が良い出発点と言われるワケ さまざまな人が協力・合意をするときに、 前提のすり合わせはとても重要ですよね？ この信頼性の階層構造が、 SREにとって良い出発点となるのは、 それを1枚の図で説明して、会話の出発点にできるからです。 21 / 49
22. © LY Corporation © LY Corporation Public 信頼性の階層構造が良い出発点と言われるワケ さまざまな人が協力・合意をするときに、 前提のすり合わせはとても重要ですよね？ この信頼性の階層構造が、 SREにとって良い出発点となるのは、 それを1枚の図で説明して、会話の出発点にできるからです。 良い出発点である信頼性の階層構造から、 SLI/SLOに向かって歩いていきましょう。 “ “ 22 / 49
23. © LY Corporation © LY Corporation Public SLI/SLOと信頼性の階層構造を紐づける SLIは、ユーザーの観点からサービスがどのように動作しているか、つまりUXの指標です。 本来、非エンジニアからよく見える位置にあるものです。 エンジニア側からSLIを共通言語として使うことで、視界の差を超えた対話がしやすくなります。 これは例えば、以下に似ています。 ネットワークエンジニアとネットワーク用語で議論する アプリケーション開発者とデザインパターンで議論する 経理や事業戦略チームと会計用語で議論する 経営陣とROIなどで議論する 23 / 49
24. © LY Corporation © LY Corporation Public ヒント: ビジネスKPIとSLIをつなぐ 24 / 49
25. © LY Corporation © LY Corporation Public ビジネスKPIの手前にSLIを置く 売上や継続率などのビジネスKPIは重要です。 それに関連した先行指標がKPIとして定義されているなら、そのままSLIのよい候補になります。 例えば 初回利用後のコア体験到達率 重要導線の完了率 重要操作の成功率 期待時間内の完了率 これをより解像度を高く、技術的に継続計測しやすくしたものがSLI候補です。 25 / 49
26. © LY Corporation © LY Corporation Public SLI候補を技術的な観測点へ翻訳する 例えば、次のように分解していきます。 1. コア体験中に、画面表示が遅くて離脱していそう 2. 画面表示のレイテンシーを計測したい 3. ただし、画面表示の継続計測はまだ難しい 4. まずはAPIレイテンシーで代用する ここで大事なのは、たまたま測れているものから始めるのではなく、 守りたい体験から逆算することです。 26 / 49
27. © LY Corporation © LY Corporation Public 改めて、この発表におけるSLI/SLO この発表では、SLI/SLOを次のように扱います。 ビジネスKPIとつながる指標 ビジネスの結果指標に対する先行指標になれるもの 既存KPIを、技術的に継続計測しやすい形へ翻訳したもの ユーザー体験の指標の近似値 信頼性の階層構造の頂点付近にあるもの 27 / 49
28. © LY Corporation © LY Corporation Public で、SLI/SLOはどう役にたつの？ 28 / 49
29. © LY Corporation © LY Corporation Public SLI/SLOから逆算して、何がどれだけ必要かがわかる メトリクスの観測間隔は？保持期間は？どんなテストまで必要？ リリースはどれだけ効率化・自動化されている？キャパシティはどれだけ余裕を持たせる？ 29 / 49
30. © LY Corporation © LY Corporation Public このプロセスをフェーズで分解すると 30 / 49
31. © LY Corporation © LY Corporation Public SLI/SLOを中間地点とした道のり 定義はスタートではなく、信頼性を高めていくための通過点 31 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 中間地点 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
32. © LY Corporation © LY Corporation Public SLI/SLOプロセス全体がチームで信頼性を扱う力を育てる 認識を共有するだけでも、何を正常・異常とみなすのか、 判断に必要なのに、まだ見えていないものは何かがわかる “ “ 32 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
33. © LY Corporation © LY Corporation Public 現実直面期: 仮SLI/SLOを置いたけど使い物にならない 意思決定やコミュニケーションには使えない 指標が粗い / 解像度が低い / 重要な要因が抜けている / 継続測定できない 33 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
34. © LY Corporation © LY Corporation Public 現実直面期 「SLI/SLOが使い物にならない」状態は失敗ではありません。 むしろ、チームで認識を共有できたという意味で順調です。 34 / 49
35. © LY Corporation © LY Corporation Public SLI/SLOの進め方のよくある失敗パターン 35 / 49
36. © LY Corporation © LY Corporation Public 現実直面期を避けようとして、導入を閉じてしまう 結果として起こること： 土台の改善が終わるまでステークホルダーを巻き込まない なんのために改善をしているかがステークホルダーに伝わらない 改善の優先度を上げにくく、いつまでも意思決定に使える品質にならない 土台の改善中にステークホルダーを巻き込み始める 後から参加した人からすると、意思決定に使えない指標にしか見えない SLI/SLOの取組は役に立たないとみなされる まずはエンジニアだけ、またはサーバーサイドだけで進める。 “ “ 36 / 49
37. © LY Corporation © LY Corporation Public スモールスタートと、狭いスタートは違う 対象サービスを小さくする 最初のSLI候補を少なくする 仮置きの精度を高く求めすぎない ビジネスKPIとは一致していないが、近い既存のメトリクスを使う妥協をする これはよいスモールスタートです。 一方で、必要な人を最初から巻き込まないと、共通言語にはなりにくいです。 結果として、SLI/SLOを無価値とみなされるリスクがあります。 37 / 49
38. © LY Corporation © LY Corporation Public 手段と目的の入れ替わりに注意する 既存の監視ダッシュボードから始めること自体は悪くありません。 ただし、それだけで閉じると、 「守りたい体験」ではなく、たまたま測れているものを守ってしまいます。 問いは、メトリクス名からではなく、体験から始めます。 KPIを支えるユーザー行動ってなんでしょうか？ “ “ 38 / 49
39. © LY Corporation © LY Corporation Public Q.少なくともどのフェーズまでやればいい？ 39 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
40. © LY Corporation © LY Corporation Public Q.少なくともどのフェーズまでやればいい？ A.会社やチームの状況による 個人的には、検証フェーズで1-2人で開発しているフェーズでは暗黙の了解で十分です。 一方で、チームが組織されているなら、認識の共有期にはたどり着いて欲しいです。 40 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
41. © LY Corporation © LY Corporation Public では具体的に、どう始めるか 41 / 49
42. © LY Corporation © LY Corporation Public 信頼性の階層構造の土台に「共通理解」の層を足す まず、幅広い職種の方と一緒に、暗黙的な共通認識と差異をあぶり出しましょう。 そして出来るなら、サービスのミッションや未来についても語りましょう。 まずは、何を守りたいのかを揃えることです。 42 / 49
43. © LY Corporation © LY Corporation Public 私たちが実際にやっている進め方の例 1. 関係者の認識を集める 非エンジニアも含む全員を対象にする AIチャットインタビューで、個別に考えをヒアリングする ヒアリング結果を整理して、関係者に周知し、議論する 2. チームの認識を揃える 3. SLI/SLOが使い物になるまで改善する 4. 活用する 43 / 49
44. © LY Corporation © LY Corporation Public なぜAIチャットインタビューなのか 共通理解を作るには、本来は全員に丁寧に話を聞く必要があります。 しかし、現実にはコストが高いです。 チーム会議では、声の大きい人の意見・表現が優先されがち 個々人の認識を、個々人の言葉では聞きにくい 全員と1on1するのは大変 1on1を手分けすると、聞き出せる品質や粒度が変わる そこで、AIチャットインタビューを使います。 44 / 49
45. © LY Corporation © LY Corporation Public AIチャットインタビューで聞くこと AIインタビューアーには、下記の質問をして会話の中で、考えをヒアリングします。 Identity: このサービスは何か？なんのため・誰のためにあるのか？ Failure: このサービスにおける失敗とは何か？どこまでなら許容されるか？ Decision 誰がどのように優先度を決めているか？ Clarity その決断のための情報は明確で、決定に再現性はあるか？ 45 / 49
46. © LY Corporation © LY Corporation Public デモ / 実例の流れ https://chatgpt.com/share/6a01571b-1748-83a2-b919-6d2b64311391 インタビューAI(カスタムGPT) 46 / 49
47. © LY Corporation © LY Corporation Public まとめ: SLI/SLOは、プロセス全体に価値がある SLI/SLOは導入するものというより、 チームで信頼性を扱う力を育てるためのプロセスそのものです。 47 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
48. © LY Corporation © LY Corporation Public おまけ: そもそも暗黙運用期はAIで揺らいでいる ここ数年はAI活用のため、暗黙知を形式知化する動きが活発です。 そのため、AI活用のための準備自体がSLI/SLOにも活き、 意識せずとも自然に通り過ぎていることもあります。 48 / 49 1 暗黙の了解で 運用期 💬 これまでの経験や 暗黙知で運用している 2 認識の 共有期 💡 関係者の認識を集め 共通理解と差異を 明らかにする 3 仮SLI/SLO 定義期 🎯 仮のSLI/SLOを定義し 目指す姿をチームで設定 4 現実直面期 🔍 仮置きした指標の 限界や課題に直面する 5 土台の 改善期 🧱 観測や仕組みなど 土台を改善・拡張する 6 活用拡大期 📈 指標を活用して 意思決定・改善に使う
49. © LY Corporation © LY Corporation Public おまけ: 共通理解のための余白は、日々の改善で作る ここまで聞いて、 「大事なのはわかるけど、正直そんな余裕はない」と思った方もいるかもしれません。 それは自然なことです。共通理解には、時間だけでなく、考えるための注意力も必要です。 その余白は、最初から用意されているとは限りません。 だからこそ、日々のトイル削減や自動化、障害対応の改善などには意味があります。 目の前の運用改善は、次にチームで信頼性を話すための余白を作る仕事でもあります。 49 / 49