# SLI-SLO 段階的導入 ## 定義 SLI/SLO の段階的導入とは、SLI/SLO を最初から完璧な形で組み込もうとせず、小さな価値検証から始めてフィードバックループを回しながら組織全体へ広げていくアプローチである。SLI/SLO には定義・運用・定着の 3 つの固有の難点があり、一気に完成形を目指すと合意形成や計装に多大な時間がかかり形骸化しやすい。SRE 自体の段階的導入フレームワーク（小さく始める→チームを支援する→スケールする→データドリブン思考を具体化する）を援用することで、この障壁を下げられる (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 ### 3 つの難点 | 難点 | 理想 | 現実 | |---|---|---| | 定義 | 最適な SLI/SLO がサクッと決まる | CUJ〜SLO までの合意形成・追加計装に時間がかかりすぎる | | 運用 | 健全な SLI/SLO が維持される | メンテ時間の除外されない・新機能が考慮されない・見直しが行われない | | 定着 | SLI/SLO をもとに意思決定が行われる | SRE チームしか興味がない・SLI/SLO 会議がやや気まずい | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.17) ### 段階的導入の 4 ステップ Takamura が提案する「段階的な SLI/SLO 導入（改）」のフレームワーク: 1. **特定のチーム内で価値検証を行う**: 自チームのみで達成可能な課題に取り組み、小さな成果を積み重ねる 2. **SLO 違反時に行う小さなアクションを定める**: 極端なアクション（開発停止等）ではなく最小限のアクションから始める 3. **ユーザー満足度に関わる指標の一部を SLI/SLO に反映し、運用する**: 必要に応じて SLO ドキュメント・エラーバジェットポリシーを作成 4. **ユーザー満足度に関わるすべての指標を特定し、SLI/SLO に反映し、運用する** (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.25) ### SLO 違反ポリシーの 5 段階拡大 | レベル | アクション | |---|---| | Level1 | なにもしない（様子を見る） | | Level2 | SRE チームが原因を特定と対策を行う | | Level3 | SRE チームが原因を特定し、開発チームが対策を行う | | Level4 | 各チームに SLO 正常化の責任（原因特定〜対策やしきい値検討）を移譲する | | Level5 | 上記に加え、イテレーションあたりの開発スケジュールやリリースタイミングの意思決定に SLO を組み込む | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.36) ### SLI-SLO 成熟度モデル（3 軸 × 5 段階） SLI/SLO の状態を「定義」「運用」「定着」の 3 軸で評価し、各軸を 5 段階に分類する。現在地と目標についてのディスカッションの起点として機能する。 **定義を育てる**: | レベル | 状態 | |---|---| | Lv1 | SLI/SLO が存在しない、または担当者の経験則で定義されている | | Lv2 | 可用性などの代表的な SLI を用いて各サービスで SLI/SLO を定義できる | | Lv3 | SLI/SLO の設計プロセスが標準化され、SLO Document などで管理されている | | Lv4 | CUJ や顧客満足度との関係が測定され、SLI/SLO の妥当性を定量的に評価できる | | Lv5 | 事業目標やユーザー行動の変化に応じて SLI/SLO を継続的に改善している | **運用を育てる**: | レベル | 状態 | |---|---| | Lv1 | SLI/SLO は存在するが活用されていない | | Lv2 | 定期的な SLO レビューや振り返りが特定の担当者によって実施されている | | Lv3 | Error Budget Policy やレビュー手順が文書化され、チームで運用されている | | Lv4 | Error Budget 消費率や SLO 達成率などを継続的に計測し、改善活動へ反映している | | Lv5 | 運用結果をもとにポリシーや運用フローを継続的に改善している | **定着を育てる**: | レベル | 状態 | |---|---| | Lv1 | SRE チームのみが SLI/SLO を利用している | | Lv2 | 一部の開発チームが SLI/SLO を参照し改善活動へ参加している | | Lv3 | SLI/SLO の活用方法が組織標準となり、複数チームで利用されている | | Lv4 | リリース判断や改善優先度の決定に SLI/SLO が利用されている | | Lv5 | 信頼性が組織の共通言語となり、事業・開発・運用の意思決定に組み込まれている | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.44-46) ### SLO Document チームを巻き込む際に有効な文書化手段。以下の項目を含む: - サービスの名前・SLO の定義 - サービスの概要 - SLI/SLO - 見直しのスケジュール - エラーバジェットポリシー 参考: O'Reilly「SLO サービスレベル目標」、[[SRE Workbook]] Appendix A。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] p.39) ## 横断的知見 - **SRE Workbook の導入事例（Evernote・The Home Depot）も段階的・外部化アプローチを採用している**: SLO Engineering Case Studies は、顧客信頼性エンジニアリング（CRE）を通じた外部組織への SLO 導入で、最初から完全な実装を求めず、運用チームと開発チームが SLO をもとに対話する土台を先に作ることを重視した。Takamura の「特定チームで価値検証してからスケール」という戦略と同じ方向性を持つ (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2018__Google SRE Workbook__SLO Engineering Case Studies]])。 - **新規サービスへの SLO 導入では「実績がない」問題をプローバーで解決できる**: Lawson の COS 事例では、まだユーザートラフィックが少ない新規サービスに対して 4 週間プローバーを稼働させて SLI データを収集し、それを初期 SLO の推定に使った。Takamura の「最初のステップは代表的な SLI を仮決めすること」と対応しており、仮決め SLI の実績を短期間集中収集してから SLO を公開する流れが確認できる。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **SLO 公開ドキュメントは利用者がサービス適合性を自己判断するためのもの**: Lawson は SLO 公開の効果として「ユーザーが SLO を見て自サービスへの適合性を自己判断できる」を挙げた。これは Takamura の「SLO 文書化→チームを巻き込む」のステップと同じ方向だが、対象が内部開発チームではなくサービスの外部利用者（内部 API ユーザーやバックアップ担当チーム）である点が異なる。インフラ型サービスへの SLO 展開では、内部ステークホルダーと外部（内部）ユーザーを同時に対象にする必要がある。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **データ集約型サービスでは「ステークホルダーが無関心」という問題が SLO の次元不足から生じる**: Booking.com の検索サービスでは、可用性・レイテンシ SLO を最初に設定したが開発・ビジネスステークホルダーは無関心だった。検索サービスのステークホルダーが気にしていたのはデータの一貫性・新鮮性という「データ品質」であり、SLO の対象次元がユーザー（ステークホルダー）の関心と合っていなかった。段階的導入の文脈では「ステークホルダーが価値を見出す次元を先に特定する」ことの重要性を示している (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。 - **グッドハートの法則への対処として「3 次元 SLI/SLO/SLA」フレームワークが有効**: Coulter（2020）は、単一次元の技術指標 SLO が「棍棒（cudgel）」になると、チームはシステムを改善せず指標を操作するようになると論じた（例：キュー深度 SLO に対してメッセージ削除でゲームする）。対処として Code（トランザクション成功率）・Infrastructure（パフォーマンスカーブ SLO）・Business & CX（行動ベース SLI）の 3 次元で SLI/SLO/SLA を評価することで、単一次元のゲーミングを別次元が露出できるようにする。段階的導入の観点では、最初に Code 次元（技術指標）から始め、CX 次元（ユーザー行動）を後から加えることで「定着 Lv4（リリース判断への組み込み）」へ進みやすくなる可能性がある (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]])。 - **SLO 交渉を反復的プロセスとして制度化することが「定着 Lv5」への橋渡しになる**: Coulter（2020）の「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」フローは、SLO を一回合意して終わりにせず RECUR（繰り返し再交渉）する設計である。Takamura の 5 段階ポリシー拡大と対応しており、Level2 から Level5 へ移行するにつれて SLO の交渉相手が「SRE チーム内」から「開発チーム」「事業意思決定者」へ広がる。Coulter の交渉フレームをポリシーレベルの移行と組み合わせると、どの段階でどのステークホルダーと交渉するかのロードマップが描ける (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **非技術ステークホルダーへの「暗順応期間」の必要性は導入戦略に影響する**: [[サービスレベル目標]] の横断的知見で記録されているように（Smith SREcon22）、営業チームなど非技術部門は「可用性 = 稼働率」から「良い体験の割合」への認知転換に時間を要する。Takamura の「SLO の認知と価値が伝わるにつれてアクション範囲を広げる」5 段階ポリシーは、この暗順応問題への実践的な対処法として読める (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO Policy の Rationale フィールドが定義成熟度「Lv3→Lv4」の具体的差分になる**: Stanke（2020）の SLO Policy は "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale フィールドを含み、技術閾値とビジネス指標の対応関係を SLO ドキュメント内に文書化する。Takamura の成熟度モデル「定義 Lv4: CUJ や顧客満足度との関係が測定され、SLI/SLO の妥当性を定量的に評価できる」を SLO ドキュメントの 1 フィールドとして実装した形式と読める。Rationale フィールドを SLO Document の必須項目として位置づけると、Lv3（標準化・文書管理）→Lv4 の差分が「ユーザー行動シグナルと SLO 閾値の相関を定量的に示す記述を持つか否か」になる (Source: [[@2020__SREcon20Americas__Squish Level Objectives]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO の分割軸を「サービス単位」→「API × リージョン」→「顧客（プロジェクト）単位」へ進化させることが大規模 IaaS での定着 Lv5 への道**: [[Alex Palcuie]]（SREcon22 EMEA）の GCE 事例は、30 SLO（リージョン × 3 指標）→ 約 1,000 SLO（API メソッド × リージョン × 3 指標）→ 3,000 万 SLO（さらに顧客単位）という 3 段階の進化を 6 年間で実践した最大級の本番事例である。Takamura の成熟度モデルの「定着 Lv5: 信頼性が組織の共通言語となり事業・開発・運用の意思決定に組み込まれている」は組織内部の話だが、Palcuie の per-customer SLO は「外部顧客にも自分の SLO 逸脱を可視化する」という定着の外向き拡張として読める。SLO 数の増加は「何次元で切るか」という設計判断の変遷であり、大規模マルチテナント IaaS での次の自然なステップが顧客単位の粒度であることを示す (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **SLO 導入の失敗律速は「技術」より「組織・人・プロセス」（socio 側）であることが実務で繰り返し確認されている**: [[Rob Durst]]（Spring Health、SREcon25 EMEA）は 4 度の試みを通じて、オブザーバビリティ基盤が整っていても所有権・標準プロセス・保護時間が揃わなければ SLO 導入は頓挫することを示した。Takamura の「SLO 採用は社会技術的問題」という主張を、実際の失敗系列（担当者交代による TAG IN、空白テーブル、STOP）で補強する証拠となる (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **「SLO 準備度チェックリスト」は段階的導入の前提条件診断ツールとして機能する**: Durst の 4 条件（オブザーバビリティ基盤・ノミナル所有権・標準プロセス・保護時間）は、Takamura の「4 ステップフレームワーク」や SRE Workbook の「SLO 文書化」より前の*前提条件*を整理したものである。「条件が揃わないうちに SLO を定義しようとする」ことが失敗パターンであり、段階的導入の第 0 ステップとして準備度診断を行うべきという主張として読める (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **担当者交代（TAG IN）問題は所有権の曖昧さの症状であり、Attempt #2 の失敗（異なる SLI 定義の非互換）は標準プロセス欠如の症状である**: 段階的導入の文脈では、「SLO を書いた人が変わっても同じフォーマットで続けられる」という標準化レベルに達するまでは、どれだけ良い SLO を定義しても持続しない。Takamura の成熟度モデルの「定着 Lv3（標準化・文書管理）」到達がこれに対応する (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **エラーバジェット起点のコードフリーズが「承認」まで到達した事実は、SLO が組織意思決定に組み込まれた（定着 Lv5）証拠として読める**: Durst が RFC: Error Budget Based Code Freeze（Holidays '25）を経営承認まで通したことは、Takamura の成熟度モデルで「定着 Lv5: 信頼性が組織の共通言語となり事業・開発・運用の意思決定に組み込まれている」に到達した実例である。小規模スタートアップ（8 SRE）でもこのレベルへの到達が可能であることを示す (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **SLODLC は SLO 導入を「プロジェクト」から「継続的ライフサイクル」へ変換するフレームワーク**: [[SLODLC]] の 5 フェーズ（INITIATE→DISCOVER→DESIGN→IMPLEMENT→OPERATE）は、Takamura の 4 ステップ（特定チームで価値検証→小さなアクション→ユーザー満足度の一部→すべてのユーザー満足度指標）と並列に読める。SLODLC の INITIATE（ビジネスケース・ステークホルダー・成果目標の定義）が Takamura の前提整備と、DISCOVER（ジャーニー優先化・依存分析・挙動観察）が「代表的 SLI を仮決めする」作業と対応する。OPERATE に「Review Periodically」を含み、段階的導入の「育てながら定着させる」サイクルが制度化されている (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 - **SLO 文書化に WWWWHW（What/Where/Who/When/How/Why）の 6 要素を明示することで「誰でも保守できる」状態になる**: Furino は SLO 文書化の要素として「この SLO は何か・どこに展開されているか・誰が所有するか・いつから運用するか・どう修正するか・なぜこの指標が重要か」の 6 要素を挙げた。SRE Workbook の SLO Document と Stanke（2020）の SLO Policy（Rationale フィールド）に加わる整理軸として、組織記憶に残る形での文書化基準を示す。Durst（2025）の Attempt #2 失敗要因「担当者交代時の所有権喪失・異なる SLI 定義の非互換」を防ぐ実践的対処として機能する (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 - **クライアントサイド SLO では「文化醸成・運用の軌道乗せ」が技術実装よりも難しい**: [[Luup]]（[[Wataru Tsuda]]、SRE NEXT 2024）はクライアントサイド SLO を CUJ 再設定 → SLI 設定 → 文化醸成 → SLO 設定の順で進めたが、「文化醸成や運用を軌道に乗せる部分が一番重要」と述べた。Takamura の成熟度モデルの「定着」軸と対応しており、SRE 初出身（バックエンド/インフラ）者がクライアントの信頼性に馴染みのない組織では定着が律速になりやすいことを裏付ける (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **PdM・SWE・SRE の三者でユーザージャーニーマトリクスを作ることが CUJ 再設定の有効な手法**: Luup は PdM が Figma でユーザージャーニー一覧を作成し、それを基に PdM・SWE・SRE が議論してユーザージャーニーマトリクス（UserJourney / SRE Activities / Priority / SLO / TraceName / 関連WebAPI などを列とする表）にまとめた。単に「SRE が CUJ を決める」のではなく、PdM の製品視点とSWEの実装知識を組み合わせることで CUJ の妥当性と SLO の意味が組織横断で共有される。Takamura の段階的導入の「特定チームで価値検証」の前提として三者合意のプロセスを置くのが実務上有効と読める (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **クライアントサイドの Latency SLI の %ile 設定に Web 標準（Core Web Vitals）を参照することで合意コストを下げられる**: Luup は p75 を選んだ根拠として Core Web Vitals の Good LCP Score が 75th percentile を採用していることを挙げた。SRE が独自に閾値を提案すると PdM・SWE との合意が困難になるが、業界標準を参照することで「なぜ p75 か」の議論を省けた。この手法は Latency SLI の %ile 設定に限らず、組織外部の権威を根拠として使うことで SLO 合意コストを下げる一般的なパターンとして読める (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 - **Multi-tiered SLOs（Upside/Downside/Actual）はフェーズ移行の見取り図と PdM 向け説明の両方として機能する**: Luup は 1 つの SLI に Upside（理想：99%/1sec）/ Downside（割りたくない：99%/3sec）/ Actual（現実：99%/5sec）の 3 段階 SLO を設定した。Downside を割っている間のみ Actual を作成し、将来的に Actual を廃止して Downside だけを見る状態を「Future」として定義している。段階的導入の文脈では、「今の自分たち（Actual）・守るライン（Downside）・目指す姿（Upside）」を一つの表に示すことで、PdM が意思決定に使う SLO とSWEが運用する SLO を役割別に整理できる (Source: [[@2024__SRENext2024__Enabling Client-side SLO]], 参考: Alex Ewerlöf Notes)。 ## 未解決の問い - クライアントサイド SLO でユーザー側都合（ネットワーク・端末・途中キャンセル）をどう除外するか、またはどこまで SLO に含めるべきか。Luup は p75 で外れ値を緩和する方針としたが、除外ロジックの詳細は未明（transcript なし）。 - Multi-tiered SLOs の Upside/Downside/Actual はどのように数値を決めるか。Luup の発表ではプロセスの説明のみで具体的な決定フローは公開されていない。 - 成熟度モデルの 3 軸（定義・運用・定着）は独立して育てるべきか、連動させるべきか。例えば「定義 Lv3、運用 Lv1」という状態は有効か。 - SLO 違反ポリシーの Level1（なにもしない）から Level2（SRE チームが対応）への移行タイミングはどう判断するか。 - 成熟度モデルを組織診断ツールとして使う場合、自己評価と外部評価の乖離をどう扱うか。 - CUJ（Critical User Journey）の特定が難しい複雑なシステムで、Lv2（代表的な SLI を仮決め）からどう Lv4（CUJ との関係を測定）へ進化させるか。 - The Art of SLOs で推奨される CUJ 特定手法は具体的にどのようなものか（本スライドでは参考として言及のみ）。 - SLO Rationale フィールドに「ユーザー行動シグナルとの相関」を記述する際、どの粒度・どの観察期間のデータが根拠として十分か。Stanke の例（エラー率 0.05% 超 → サポートチケット増加）はシンプルだが、行動指標とエラー率の関係が非線形または遅延を持つ場合の扱いはどうなるか。 - SLO が「棍棒」として使われているかどうかを組織的にどう診断するか（SLO 指標だけ達成していてシステム改善が停滞している状態を成熟度モデルのどの軸で検出するか）。 - Coulter（2020）の 3 次元 SLI/SLO フレームワークを段階的に導入する場合、Code・Infrastructure・CX の 3 次元をどの順序でどの成熟度レベルから導入するのが効果的か。 - Durst の 4 条件「SLO 準備度チェックリスト」を組織自己評価ツールとして使う場合、各条件の「充足」をどう判定するか（特に「ノミナル所有権の概念」と「標準プロセスの確立」の境界は曖昧）。 - ハイパーグロース環境での「保護時間（protected time）」はどう確保するか。Sprint への組み込み・ロードマップ入り・四半期 OKR との連動など複数の制度設計があるが、どれが最も効果的か。 ## 関連 - 概念: [[サービスレベル目標]] / [[エラーバジェット]] / [[SRE]] - エンティティ: [[Narimichi Takamura]] / [[Topotal]] / [[Dave Stanke]] / [[Google]] / [[Rob Durst]] / [[Spring Health]] / [[Wataru Tsuda]] / [[Luup]] - 概念: [[グッドハートの法則]]（SLO ゲーミングの原因と対策） - ソース: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] / [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] / [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] / [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] / [[@2020__SREcon20Americas__Squish Level Objectives]] / [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] / [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] - エンティティ: [[Alex Palcuie]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]（3 つの難点・4 ステップフレームワーク・5 段階ポリシー・成熟度モデル・SLO Document） - [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]（段階的 SLO 構築、ステークホルダー合意、継続改善） - [[@2018__Google SRE Workbook__SLO Engineering Case Studies]]（外部組織への SLO 導入パターン） - [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]]（Squarespace COS への 6 ステップ新規サービス SLO 実装・プローバー活用・SLO 公開ドキュメント） - [[@2020__SREcon20Americas__Avoiding Goodhart's Law]]（グッドハートの法則の SRE 文脈応用・3 次元 SLI/SLO フレームワーク・反復的 SLO 交渉プロセス） - [[@2020__SREcon20Americas__Squish Level Objectives]]（SLO Policy への Rationale フィールド追加・顧客行動データによる SLO 根拠づけ・エラーバジェットの UX 実験活用）