# SLI/SLO 教科書 — 基礎から応用まで > [!abstract] 概要 > 本文書は、SRE における SLI/SLO/SLA フレームワークを、基礎定義から組織的導入、応用領域まで網羅的にまとめた教科書である。wiki に蓄積された 30 以上のソース（SRE Book、SRE Workbook、SREcon 各年の発表、学術論文、国内実践事例）を横断的に統合する。 --- ## 第 0 章　歴史的起源 SLI/SLO の概念はソフトウェアに固有のものではない。1984 年の米国高速道路管理では、(1) Asset Quality Index（路面のラフネスなど材料品質の絶対尺度）と (2) Customer Happiness Index（平均渋滞時間、平均車速、交通密度）という 2 種の指標が定義され、「Levels of Service」という用語で呼ばれていた。下水道管理でも同様に、パイプあたりのひび割れ数（資産品質）と水洗の稼働率（顧客満足）が区別されていた (Source: [[notes/sre/SLOの起源]])。 2003 年、[[Ben Treynor Sloss]] が [[Google]] で SRE チームを創設し、ソフトウェアエンジニアリングの手法を運用に適用するディシプリンを確立した。SLI/SLO/SLA フレームワークとエラーバジェットは、2014 年の SREcon14 基調講演で初めて公に体系化され (Source: [[@2014__SREcon14__Keys to SRE]])、2016 年の SRE Book で理論的基盤が確立された (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 --- ## 第 1 章　基礎概念 — SLI/SLO/SLA フレームワーク ### 1.1 SLI（サービスレベル指標） SLI はサービスの振る舞いを定量的に計測する指標である。リクエストレイテンシ、エラー率、スループット、可用性などが典型例にあたる。SLI はサービスの健全性を直接反映する**計測値**であり、目標値ではない (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 SRE Workbook は SLI を「良いイベント数 / 全イベント数」の比率として設計することを推奨する。0% は何も動かない状態、100% は何も壊れていない状態という直感的な尺度になり、SLO とエラーバジェットに接続しやすい (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 重要な設計原則として、SLI は**仕様**と**実装**に分けて考える。 - **SLI 仕様**: ユーザーにとって意味のある評価（例:「リクエストが 200ms 以内に正常応答を返す」） - **SLI 実装**: それをどこでどう測るか（例:「ロードバランサのアクセスログで HTTP 5xx 以外を成功、レスポンスタイム 200ms 以下を高速と数える」） ### 1.2 SLO（サービスレベル目標） SLO は SLI の目標値あるいは許容範囲である。「SLI ≤ target」の形をとる。例:「リクエストレイテンシの p99 が 200ms 以下」。SLO はサービスの信頼性に関する**内部的な目標**であり、外部への約束ではない (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 ### 1.3 SLA（サービスレベル合意） SLA は SLO に**違反時の罰則（consequences）**を付加した明示的な契約である。SLO + 帰結 = SLA と定式化される (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。SLA は通常、外部顧客との間で締結される。 SLI → SLO → SLA は抽象度が上がる方向の階層をなす。SLI なしに SLO は定義できず、SLO なしに SLA は意味を持たない。 ### 1.4 なぜ 100% を目指さないのか SRE の核心原則の一つは、100% の可用性を追求しないことである。理由は 3 つある。 1. ユーザーは 99.99% と 99.999% の差を検知できない 2. 信頼性改善のコスト曲線は非線形であり、各増分が前回の 100 倍のコストを要する 3. 顧客側の依存関係（端末、ネットワーク）も含めると、100% の体験は物理的に不可能 (Source: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]]) --- ## 第 2 章　SLI の設計 — 何を・どこで・どう測るか ### 2.1 サービス種別ごとの優先指標 | サービス種別 | 優先 SLI | |---|---| | ユーザー向けサービス | 可用性、レイテンシ、スループット | | ストレージシステム | 耐久性、可用性、レイテンシ | | ビッグデータパイプライン | スループット、エンドツーエンドレイテンシ | (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]) SRE Workbook は、リクエスト駆動サービスには成功応答率・閾値以下レイテンシ・劣化なし応答の割合を、パイプラインにはデータ鮮度・正確性・カバレッジを、ストレージには書き込んだレコードが読み出せる割合を推奨する (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 ### 2.2 パーセンタイルの重視 レイテンシ指標を**平均値**で評価してはならない。平均はテールレイテンシの情報を潰す。推奨される計測はパーセンタイルであり、特に p50（典型的体験）、p99（テール）、p99.9（最悪体験）が重視される (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 ただしパーセンタイルには重大な実装上の制約がある。Hartmann は、時間ごとの p90 を平均すると全体分布から計算した p90 とずれることを示し、**パーセンタイルは複数時間窓・複数ノードをまたいで集約できない**ことを実務上の問題として定式化した。解決策は「しきい値以内のリクエスト数 / 全リクエスト数」という良いイベント比率に変換することである (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 ### 2.3 測定点の選択 Jones・Murphy は SREcon16 で、サーバー側レイテンシを測りがちな Google の実態を「間違い」と認め、クライアント側が実際のユーザー体験を正確に反映すると述べた。**制御しやすい場所で測る（locus of control）のと、ユーザーに意味のある場所で測る（locus of measurement）のは異なる** (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 SLI 実装の選択肢には、サーバーログ・ロードバランサ監視・ブラックボックス監視・クライアント側計装があり、それぞれ品質・カバレッジ・コストのトレードオフがある (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 ### 2.4 ケイパビリティ駆動の SLI 設計 New Relic の Binette・Flaming は、システム境界ごとに「公開するケイパビリティ」を列挙し、各ケイパビリティの「利用可能」を平易な言葉で定義してから技術的 SLI に落とす 7 ステップレシピを示した。SLI 設計で「何を測ればいいかわからない」という難点を、**「システム境界の機能一覧を作る」という操作可能な第一歩に変換**する (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]])。 ### 2.5 「成功」を定義すべき理由 SLI は「悪い挙動」ではなく「成功」を定義すべきである。エラーを定義する場合は既知の問題のみをカバーする（有限スコープ）が、成功を定義すれば「それ以外はすべて不確か」という包括的定義になる (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 ### 2.6 ユーザー幸福の 6 フレーバー Gangatirkar は SLI 候補を 6 種に整理した: Availability / Responsiveness / Freshness / Completeness / Accuracy / Breadth。この枠組みとケイパビリティ列挙を組み合わせると、SLI 候補の見落としを防ぎつつサービス固有に具体化できる (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 ### 2.7 集約インターバルの問題 SREcon16 で Jones は、同じデータが 1 分インターバルでは平坦、30 秒では散発的スパイク、1 秒では「毎分先頭に全リクエストが集中」と見えることを示した。SLI 設計において「何を測るか」の前に「**どのウィンドウで見るか**」という問いがある (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 --- ## 第 3 章　SLO の設定 — 目標値の決め方 ### 3.1 初期 SLO は正解でなくてよい 初期 SLO は正しくなくてよい。安価に測れる指標から始め、ユーザー満足・既知障害・サポートチケット・エラーバジェット損失との相関で継続改善する (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 Evernote は月次 99.95% 稼働率という単純な初期 SLO で開始し、月次レビューと半年ごとの見直しで改善した (Source: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]])。 ### 3.2 S 字曲線で痛みのしきい値を特定する Gangatirkar は可用性（横軸）対ユーザー幸福度（縦軸）の S 字曲線を用い、SLO はユーザーが不満を感じ始める前の水準に設定すべきだとした。屈曲点が痛みのしきい値であり、SLO はそれより下に設定する (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 ### 3.3 共感ギャップ Gangatirkar の 2×2 マトリクスは重要な概念を定義する。 | | SLO 達成 | SLO 未達 | |---|---|---| | **ユーザー満足** | 正常 | 過剰達成の幻影 | | **ユーザー不満** | **共感ギャップ** | 正常 | 「SLO 達成・ユーザー不満」のセルが共感ギャップ（Empathy Gap）であり、SLO がユーザーの痛みのしきい値より緩く設定されている場合に発生する (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 ### 3.4 SLO の Rationale をユーザー行動データで根拠づける Stanke は SLO Policy に "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale を添え、技術閾値が顧客行動指標と結びついた根拠を持つことを示した (Source: [[@2020__SREcon20Americas__Squish Level Objectives]])。 ### 3.5 多段パーセンタイル定義 単一の「99% の応答が X 秒以内」では、X 秒を超える 1% の分布を制御できない。多段定義（90%/30s・99%/1min・99.9%/5min）は「速い応答の大多数」と「遅い応答の尾部」を別々に制御する。SLO を「しきい値の通過/未通過」から「分布の制御」として扱うアプローチである (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]])。 ### 3.6 SLO 公表の重要性 Jones・Murphy は SREcon16 で、**SLO を公開しないサービスではユーザーが「今の性能が永遠に続く」と期待し始め、将来の設計変更・コスト最適化の選択肢が失われる**と警告した。対処として「意図的なダウンタイムを入れるシステムが Google に実在する」と明かした (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 ### 3.7 SLO 文書の構成 Appendix A の Example Game Service は、SLO 文書の構成要素を示す。 - サービス概要と対象カテゴリ - SLI 定義（何を、どこで測るか） - SLO 目標値と評価ウィンドウ（4 週間ローリング） - 根拠（履歴データと丸めルール） - エラーバジェット計算 - 但し書きと限界 SLO は可用性だけでなく、レイテンシ、鮮度、正確性、完全性など、ユーザー価値に対応する複数次元で定義できる (Source: [[@2018__Google SRE Workbook__Appendix A Example SLO Document]])。 --- ## 第 4 章　エラーバジェット — SLO を組織的意思決定へ接続する ### 4.1 定義と原理 エラーバジェットとは、SLO で許容される障害量の上限を「予算」として扱い、開発チームと SRE が共有する信頼性管理の仕組みである。SLO が 99.9% ならば 0.1% のエラーバジェットを持つ。予算を消費しきった場合はリリースを凍結して信頼性改善に集中する (Source: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]])。 エラーバジェットの最も重要な組織効果は、SRE が「ノー」から「イエス、もし〜ならば」へ転換することである。プロダクト開発チームが SRE を迂回しようとしなくなるのは、迂回するとエラーバジェットを自ら消費するだけだからである (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 ### 4.2 起源 エラーバジェットの起源は「SLA を超えすぎることへの気づき」である。Alvidrez は SREcon15 で、AdSense が 2009 年に SLA を一貫して超えた状態を「機会の損失」と語った。超過分は「速く動く・少ないリソースで動く」ために使えた。この逆転の発想が概念の個人的な起源である (Source: [[@2015__SREcon15__Error Budgets and Risks]])。 ### 4.3 エラーバジェットポリシー SRE Workbook Appendix B は具体的なポリシー例を示す。 - 直近 4 週間でエラーバジェットを超過 → P0・セキュリティ修正以外の変更停止 - 単一インシデントが 4 週間予算の 20% 超消費 → ポストモーテムと P0 アクションアイテム - 単一障害クラスが四半期予算の 20% 超消費 → 翌四半期計画に P0 項目 重要な解釈: この方針は罰ではない。変更停止は望ましい状態ではないが、信頼性データが「今は機能より信頼性を優先すべき」と示すとき、チームが信頼性に集中するための**制度的許可**として機能する (Source: [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]])。 ### 4.4 バンバン制御からプロポーショナル制御へ Jones は SREcon16 で、エラーバジェットを二値切り替え（「リリース全開」→「リリース全停止」）ではなく、バーン率の連続的な監視に基づく速度制御として使うべきだと説明した。制御工学でいう「バンバン制御」から「プロポーショナル制御」への移行である (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 ### 4.5 時間スライス vs イベントベース集計 99.95 SLO + 95% 閾値による時間スライス方式では、ピーク時（1 分 1,000 リクエスト）と深夜（1 分 10 リクエスト）を同じ 1 票として扱う。結果、「軽微なエラーが多い時間帯の 1 分」が予算を大きく削る一方、深夜の大規模障害が反映されにくい逆転現象が生じる。イベントベース集計に切り替えると深刻度に比例した消費になり、エラーバジェットが「信じられるシグナル」として機能する (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 ### 4.6 エラーバジェットの拡張適用 Thomson・Laing は SLI/SLO/ポリシーのモデルがドメイン非依存の汎用構造であることを示した。 - **脆弱性バジェット**: SLI = 依存パッチリリースからの経過日数、SLO = 最大許容日数 - **フィーチャーフレッシュネス**: SLI = フィーチャーリリースからの経過日数、SLO = ブリーディングエッジ度の範囲 Equifax 侵害（CVE-2017-5638）の事例で「30 日 SLO のパッチ適用ポリシーがあれば 67 日後の侵害は防げた」と実証した (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 --- ## 第 5 章　SLO ベースアラーティング ### 5.1 設計原則 SLO ベースアラートの目的は、エラーバジェットを大きく消費する重大イベントを、予算消費前に通知することである。アラートはエラー率の異常ではなく、エラーバジェットへの重大な脅威に対して出す (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 ### 5.2 評価軸 - **精度**: 検知されたイベントのうち重大イベントである割合 - **再現率**: 重大イベントのうちアラートされた割合 - **検知時間**: 通知までの時間 - **リセット時間**: 解決後にアラートが残る時間 ### 5.3 バーンレート バーンレートは SLO に対してどれだけ速くエラーバジェットを消費しているかを表す。 | バーンレート | エラー率 | 30 日・99.9% SLO での枯渇予測 | |---|---|---| | 1 | 0.1% | 30 日 | | 2 | 0.2% | 15 日 | | 10 | 1% | 3 日 | | 1000 | 100% | 43 分 | (Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]) ### 5.4 推奨構成: 複数ウィンドウ・複数バーンレート 推奨開始点: - **ページ用**: 1 時間 2% 予算消費 + 6 時間 5% 予算消費 - **チケット用**: 3 日 10% 予算消費 短窓を長窓の 1/12 程度に置き、長窓と短窓が同時に閾値を超えるときだけ通知すると、精度とリセット時間のバランスが改善する (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 Wilkinson は Prometheus で `delta(errors[1h]) > (expected_events * error_budget / burn_period)` を SLO Fast Burn アラート式として示した (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 ### 5.5 バーンレートグラフの読み方 EBR グラフ上で識別すべき 4 パターン: 1. **Slow burn**: 変更起因のじわじわ消費 2. **Fast burn**: 大規模インシデントによる急激消費 3. **Recovery**: バグ修正後の回復 4. **No Incident drain**: インシデントなしの緩慢消費（バグ起因の遅延劣化。バーンレートアラートだけでは捕捉困難） (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) ### 5.6 低トラフィック・極端な可用性目標 - **低トラフィック**: 10 リクエスト/時では 1 失敗が 10% エラー率。対策は人工トラフィック、関連サービスの上位集約、SLO 再交渉 - **99.999% 目標**: 100% 障害が 26 秒で予算枯渇。アラートでは守れないため、カナリアリリースなど設計で全停止確率を下げる (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]]) ### 5.7 SLO アラート発火後の設計 SLO アラートは「鳴らす条件」だけでなく「鳴った後に何を見ればよいか」を含めて設計されるべきである。池田は SRE NEXT 2023 で、Warning アラートに対し対象期間のリクエストパス別レスポンスタイムを自動集計する仕組みを示した (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 --- ## 第 6 章　可用性指標の限界と進化 ### 6.1 ナインだけでは不十分 Mogul+Wilkes は「ナインだけでは不十分」と論じ、3 つの限界を指摘した。 - 短時間断続障害と長時間大規模障害を区別できない - グレースフルデグラデーションを記述できない - ビジネス的重要日の重み付けができない (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]) ### 6.2 良い可用性メトリクスの三要件 Hauer+ は「良い可用性メトリクスは**有意義性**（ユーザー体験を捉える）・**比例性**（変化に比例する）・**実用性**（原因の洞察を与える）の三要件を同時に満たすべき」と定式化した (Source: [[@2020__NSDI__Meaningful Availability]])。 既存指標の限界: - **成功率**: 最活発ユーザーに最大 1,000 倍偏り、障害中のリクエスト断念を過少評価 - **インシデント比**: 任意の「インシデント」しきい値に依存し、大規模分散システムに不適切 - **合成プローブ**: ユーザーの実際のワークロードを代表しない ### 6.3 ウィンドウ付きユーザーアップタイム Hauer+ が Google G Suite で評価・本番展開した新指標: 1. 各ユーザーの細粒度リクエストログからアップ分・ダウン分を算出し、全ユーザーの均等加重平均で集約 2. 1 分から四半期まですべてのウィンドウサイズで最悪可用性を算出し、MCR（Maximum Contiguous Ratio）曲線として可視化。「膝」の位置で短時間断続障害と長時間大規模障害を区別 (Source: [[@2020__NSDI__Meaningful Availability]]) ### 6.4 SLE/CBE — 法律家的思考から統計家的思考へ Mogul+Wilkes は SLO 定義の困難さを統計学的意思決定との同型性として捉え、転換を提唱した。 - **SLE（サービスレベル期待）**: プロバイダが通常条件下で顧客に期待させる挙動。結果保証ではなく期待管理 - **CBE（顧客挙動期待）**: プロバイダが SLE を満たすために前提とする顧客側の挙動 (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]) ### 6.5 集計が隠す問題 SLO モデルは時間・空間で線形性を仮定しており、集約によって深刻な問題を隠蔽する。 - **時間線形性**: 1,000×1 分停止 = 1×1,000 分停止と扱われるが、ユーザー影響は全く異なる - **空間線形性**: 一部ユーザーへの完全障害 = 全ユーザーへの軽微な障害と扱われる (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]]) Palcuie は「プロバイダの集計 SLO が 99.999% を保つ一方で個別顧客が完全な障害状態になりうる」ことを GCE の実データで示し、顧客単位 SLO への移行を推進した (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]])。 ### 6.6 「5 エラーのルール」による動的ターゲット 少トラフィック顧客への一律 SLO 適用は現実的でない。Palcuie は顧客単位 SLO のターゲットをトラフィック量に応じて `target = 1 - 5 / total_requests` と動的設定する手法を示した。1 万リクエスト以上で 99.95% に収束するが、10 リクエストでは 50% となる (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]])。 --- ## 第 7 章　SLO の組織的導入 — 技術から文化へ ### 7.1 段階的導入が鍵 SLO 導入の失敗要因が「技術」より「組織・人・プロセス」であることは複数のソースで独立に確認されている (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 Takamura は SLO 違反ポリシーの段階的拡大を体系化した。 | レベル | アクション | |---|---| | Lv1 | なにもしない（計測と可視化のみ） | | Lv2 | 調査判断のトリガーとする | | Lv3 | チーム内でアクション実行 | | Lv4 | 他チームとの調整を含むアクション | | Lv5 | 開発スケジュールの意思決定に SLO を組み込む | (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) ### 7.2 「仮値から始めてフィードバックで洗練する」 4 名の独立した実践者が共通して「完璧な値を追い求めず動かしながら修正する」を成功の起点として選んでいる。 - 渡辺（Mackerel, SRE NEXT 2023）:「SLI と仮値を決めて見直しフローを作り、まずとりあえず始めた」 - Takamura（2026 神戸）:「小さく始める」4 ステップの体系化 - Durst（SREcon25 EMEA）: 4 前提条件確認後の段階的導入 - Hidalgo（SREcon19 EMEA）:「翌日障害でエラーバジェット枯渇したが許可証として即座に機能した」 (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]]) ### 7.3 ステークホルダーの「暗順応期間」 Smith は Campspot での SLO 導入事例で、営業チームを SLO ワークショップに招いたところ「Uptime 99.999% の話ではないのか」と混乱が生じたと報告した。「可用性 = 稼働率」から「良い体験の割合」への認知的転換には準備期間が必要であり、SLO 実装の前に非技術ステークホルダーとの「Adjust」フェーズを設けるべきだとする (Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]])。 ### 7.4 SLO は交渉プロセスである Coulter は SLO を技術的に「正しい値を計算する」問題ではなく、ステークホルダー交渉として扱う視点を示した。「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」という反復的交渉フローを提案し、SLO は一度合意すれば終わりではなく継続的に再交渉されるものとして設計される (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]])。 ### 7.5 組織的前提条件 近藤（SRE NEXT 2022）は、SLI/SLO の定義・観察文化を 2 プロダクト 15 チームに導入した後も、Error Budget Policy が定着しなかった原因を「**非機能要求に対処する予算・権限が開発チームになかった**」と分析した。技術戦略グループの発足と「新規:エンハンス:技術的負債解消 = 1:1:1」という予算宣言が解決をもたらした (Source: [[@2022__SRENext2022__Who owns the Service Level?]])。 Durst（SREcon25 EMEA）は導入の 4 前提条件を示した: (1) 所有権、(2) 標準プロセス、(3) 保護時間、(4) SLO 計測基盤 (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 ### 7.6 実導入事例の比較 | 組織 | 規模 | アプローチ | 結果 | |---|---|---|---| | **Evernote** | 2.2 億ユーザー | 外形監視ベースの月次 99.95% から開始、Google CRE と協働 | リリース窓 5→2 回に削減 | | **The Home Depot** | 2,200 超店舗 | VALET 枠組み + 自動収集基盤 + 管理職インセンティブ | 0→800 サービスを 1 年未満で展開 | | **Atlassian** | 大企業 | Error Budgets 0.1（13 週中 7 週未達でアクション）から開始 | 段階的に基準引き締め | | **Squarespace** | 中規模 | Ceph Object Storage に 6 ステップで SLO 実装 | プローバー計測で新規サービスの SLI 確立 | | **Spring Health** | 200 名 / 8 SRE | 3 年間の試行錯誤後にエラーバジェット起点のコードフリーズ RFC 経営承認 | スタートアップでも Lv5 到達可能を実証 | | **Riot Games** | ゲーム | Player Minutes（CCU 重み付き）+ CEO OKR 強制 | 文化変革を 3 層で推進 | | **Ant Group** | 60+ K8s クラスタ | GitOps + K8s 宣言的管理で SLO 爆発問題を吸収 | 99.999% 目標を運用 | --- ## 第 8 章　応用と拡張 ### 8.1 データ集約型サービスの SLO Booking.com では可用性・レイテンシ SLO だけではステークホルダーが関心を持たなかった。**データの一貫性・新鮮性・完全性・耐久性**を「データ品質 SLO」として計測・目標化するまでは SLO が意思決定に使われなかった。SLO が明確に定義されると、Freshness Probe がトラフィック自動停止（自動緩和）、Completeness Probe が Hadoop スナップショットからの再処理（自動修復）のトリガーとして機能した (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。 ### 8.2 非同期パイプライン eBay は可用性 SLI（SUCCESS / ABANDONED 比率）とレイテンシ SLI（累積 end-to-end histogram）の 2 種類で、非同期パイプラインの Freshness・Quality・Throughput を代替できることを実装で示した。バーンレートアラートに加えて `absent(sum(sli_valid_events{...}))` でメトリクス欠損を検知するデータ損失アラートを併置する必要がある (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 ### 8.3 SLO 拡散（高レベル→低レベル分解） Sedlak+ はマイクロサービスパイプラインにおいて高レベル SLO を自動的に低レベル SLO へ分解する 3 ステップ方法論を提案した: (1) ベイジアンネットワーク学習（BNL）によるサービス変数間の条件付き依存グラフ構築、(2) 高レベル SLO 変数からグラフを遡り変数消去法で許容範囲を推定する拡散（HLD）、(3) 重複制約の矛盾検知と自律的解決（CIR）。評価では VehicleRouting・TrafficPrediction・LiveMonitoring の 3 パイプラインで高レベル SLO 達成率 83〜100% を達成した。 制約の厳しさを決める超パラメータ **λ** には重要なトレードオフが確認された。λ を大きくする(許容範囲を狭める)と高レベル SLO 達成率は向上するが、過度に大きくすると低レベル SLO 間でコンフリクトが発生し達成率が 0 へ急落する。コンフリクトは積集合が空でない**マイナーコンフリクト**(交差区間を採用して自動解決)と、互いに素な**メジャーコンフリクト**(解決不能として開発者へ通知)の 2 種に分類される。低レベル SLO 充足率は常に高レベル SLO 充足率より高く、高レベル充足は低レベル充足の帰結として得られることも確認された (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 ### 8.4 SLX — 調査のための拡張フレームワーク SLO は検知には強いが調査には向かない。Ding+Zhang は補完概念として SLF（SLI を詳細ラベル次元でスライス）と SLD（依存サービスのメトリクス）を追加し、SLX Graph をグラフ走査することで異常 SLO 依存チェーンを自動絞り込む (Source: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]])。 ### 8.5 ハードシャードシステム 水平スケールでは 3 ノード中 1 ノード障害 = 全体 SLO 66%（比例反映）だが、ハードシャードでは SLO 0%/100%/100% が全体集計では 66% と誤って健全に見える。**ハードシャードでは論理インスタンスごとに独立した SLO が不可欠** (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]])。 ### 8.6 HPC への適応 LANL の Lueninghoener は HPC 環境で「各クラスタ四半期 30 時間」をダウンタイム予算と定義し、バーンダウンチャートで可視化した。エラーバジェットの本質は「単位（リクエスト失敗）」ではなく「リソースを追跡して意思決定に使う」構造にある (Source: [[@2016__SREcon16Europe__HPC Downtime Budgets]])。 ### 8.7 IoT・モビリティ Luup では電動キックボード・電動アシスト自転車を対象に、CUJ の代わりに CMC（Critical Machine Communication）を SLI 設計の起点とした。計測対象はデバイスの定期通信応答や通信途絶であり、SLI がリクエスト駆動から物理デバイス通信へ拡張された事例 (Source: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]])。 Luup は 2024 年、Enabling SLO の対象を iOS/Android クライアントへ拡張した。API のみの計測では BLE 通信(施錠・解錠・ライド開始終了)や Firestore への直接アクセスが SLI から漏れるため、PdM・SWE・SRE の三者協働でユーザージャーニーを再設定し、CUJ 単位のマトリクスに落とし込んだ。Latency SLI には Core Web Vitals の LCP Good Score が採用する **p75** を用い、Datadog の Time Slice SLO(2024-05-02 GA)によって Monitor 設定なしに SLO 作成中にしきい値を試行できるようにした。さらに 1 つの SLI に対して Upside(将来目指す理想値)・Downside(現実的に割りたくない現状監視水準)・Actual(既に一部割れている水準)の 3 段階を定義する **Multi-tiered SLOs** を採用し、開発フェーズが進むにつれて Actual → Downside のみを注視する状態へ収斂させる設計とした。技術的な計測基盤の整備以上に、SLI ダッシュボードの整備と Weekly レビューによる「文化醸成」が最重要と位置づけられている (Source: [[@2024__SRENext2024__Enabling Client-side SLO]])。 ### 8.8 AI サービスの SLI/SLO 生成 AI サービスでは SLI の候補が「応答の品質」へ広がる。Yoshikawa は、出力品質スコア、ハルシネーション率、RAG 検索精度を SLI に加える例を示した。LLM 推論では TTFT（Time To First Token）・ITL（Inter Token Latency）・E2EL（End-to-End Latency）・Goodput（レイテンシ要件を満たすリクエスト数）に加え、Tokens/Dollar や Tokens/User/Dollar を費用対効果指標として位置づける (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]])。 ### 8.9 カーボン認識 SLO CASCA（Carbon-Aware SLO and Control plAtform）はカーボンフットプリントを報酬関数に組み込み、SLO 充足とサステナビリティの両立を図るマイクロサービス原則ベースのプラットフォームである。インフラプロバイダーがサービスのセマンティクスを知ることなく SLO 充足のために動的再設定を行えるよう、SLO 宣言とパラメータ名を「ServiceSLO」「ServiceParam」へ匿名化する仕組みを持つ。匿名化しても意思決定システムの挙動はほぼ変化せず（SLO 充足率・カーボンフットプリントとも完全記述時と同様の序列）、プライバシー保護と SLO 充足を両立できることを実証した。 貪欲ヒューリスティック（GDS）・強化学習（RLDS）・ランダム基準（RDS）の 3 方式を 24 時間の実機評価で比較したところ、FPS SLO 充足率では GDS が最良（90.6%、RLDS: 85.2%）である一方、カーボンフットプリントの最小化では報酬関数にカーボン強度を組み込んだ RLDS が最良（72.4 vs GDS 74.9 mgCO₂/分）となり、**パフォーマンス最適化とサステナビリティ最適化はトレードオフの関係にある**ことを定量的に示した。宣言的な SLO・パラメータの追加変更は平均 2.8 秒で完了し、ソースコード修正・再ビルドを要する命令的アプローチ（平均 56.5 秒）と比べ約 54 秒短縮した (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。 ### 8.10 セルフクラフト — SLO の未来像 坪内は、2040 年代の個別化アプリケーションでは信頼性・コスト・変更速度などの基本変量の均衡点を利用者と AI が対話的かつ体験的に決めると描いた。SLO を静的な契約値ではなく、探索プロセスとして扱う視点であり、SLO の主体が事業者から利用者+AI に移行する方向性が示唆される (Source: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]])。 ### 8.11 セキュリティ領域への応用 — Security Level Objectives [[John Benninghoff]] は SREcon25 Americas で、SRE の SLO をセキュリティ領域に転用した **Security Level Objectives** を提唱した。着想は [[Safety-II]] の枠組み(悪い結果の非発生でなく良い結果の増加を目指す、分布の右シフト)に基づく。2019 年の DORA・Veracode・Sonatype という 3 つの独立データセットは、サイバーセキュリティのパフォーマンスとソフトウェアデリバリー・信頼性パフォーマンスが強く相関することを既に示しており、実証的に効果の高いセキュリティコントロールのトップ 2(攻撃面管理・パッチ頻度)は SRE の中核的な運用活動(インベントリ・構成管理、依存関係管理)と 1 対 1 で対応する (Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]])。 Security Level Objectives の候補指標には、エンドポイント当たりの脆弱性数、公開サービス当たりの開放ポート数、MFA 未使用エンドポイント率、孤立アカウント率、ログイン失敗率・成功率が挙げられる。通常の SLO との本質的な違いは損失分布の規模にある。アウテージ損失が $100–$10M(典型 $100K)であるのに対し、サイバーセキュリティ損失は $100–$10B(典型 $1M、95 パーセンタイル $52M)と桁違いに大きく、エラーバジェット的な「許容できる損失率」の設定が困難である。そのため Security Level Objectives は損失率そのものではなく、リスクと相関する先行指標に閾値を設定する設計に寄る (Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]], [[Security Level Objectives]])。この構造は第 4.6 節の脆弱性バジェット(Thomson・Laing)と同じ問題領域を扱うが、Benninghoff は「SRE の日常運用そのものがセキュリティパフォーマンスの土台である」という組織論的視点を加えている点で異なる。 ### 8.12 定常性モデル — 閾値ベース SLI/SLO を超える代替アプローチ [[Narayan Desai]](Google Cloud SRE)は SREcon21 で、SLI に固定閾値を設定する従来アプローチを「Goldilocks Reliability」と呼び、これが暗黙に依存する 4 つの荷重仮定 ―― 「ちょうどいい」の有意性・答えの一意性・問いの既知性・答えの不変性 ―― を明示化した上で批判した。閾値通過判定は元の分布を 2 バケットヒストグラムへ圧縮する操作であり、Hartmann(2019、第 2.2 節)が指摘したパーセンタイル集約不能問題と同根の「点推定によるデータ圧縮」問題を抱える (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]])。 代替として提示されたのが**定常性モデル(Stationarity-based Reliability Model)**である。信頼性を可用性・パフォーマンス・正確性の 3 次元に分解し、それぞれに定常性仮定(可用性=エラーの時空間的 i.i.d.、パフォーマンス=長時間窓での一定性、正確性=バグを除く同一入力からの同一出力)を付与し、その逸脱を信頼性劣化のシグナルとして検知する。キャリブレーション不要(閾値設定のための人間判断が不要)で、定常性違反を階層的に分解することで根本原因を識別できる(例: 「スロークエリ割合」全体の定常性違反 → 理由別に分解し IO Time が原因と特定)。この手法は 2022 年の SREcon22 Americas(Principled Performance Analytics)で正規分布 z スコアによる 2σ 手法として数理実装され、Google 本番環境で障害の 18 時間先行検知を実証した (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]], [[定常性モデル]])。 定常性モデルは SLI/SLO の閾値設計問題そのものを解消するのではなく、SLO フレームワークと**直交**する「あるべき状態からの逸脱」を検知する層として位置づけられる。SLO が「どこを超えたらアウトか」を定義するのに対し、定常性モデルは「通常どうあるべきか」を定義する点が根本的に異なる。 --- ## 第 9 章　未解決の問いとフロンティア ### 9.1 SLO 代数 複数のダウンストリームサービスを消費する上位サービスの SLO を、依存先の SLO から分析的に導出する体系的手法が存在しない。依存関係の直列/並列消費パターン・フェイルオープン/クローズド動作を考慮した代数的枠組みの確立は未解決課題 (Source: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]])。 ### 9.2 SLO の根本批判 Desai は「SLO requires recognized errors」と述べた上で、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータにとどまる」と主張した。SLO を段階的改善の対象として論じる多くの先行ソースとは異なり、「SLO そのものが計測ツールとして根本的に不完全」という結論に進んだ最も強い批判形である (Source: [[@2022__SREcon22Americas__Principled Performance Analytics]])。 ### 9.3 エラーバジェットの不確実性 エラーバジェットを設定するためのインパクト推定が桁違いに不正確でありうる。Davidovič は 3 人の独立した担当者にインシデント影響を推定させてバリアンスを観察することを推奨した (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]])。 ### 9.4 その他の未解決課題 - SLE/CBE 枠組みは概念的提案にとどまり、クラウドプロバイダでの採用事例は未報告 - AI サービスでハルシネーション率をどのユーザー幸福フレーバーに分類するか、または 7 番目のフレーバーが必要か - SLO アラート発火時に自動添付する情報の標準化範囲 - クライアント側測定とサーバー側測定の乖離を定量化する実践的手順 --- ## 付録 A　文献年表 | 年 | 文献 | 主な貢献 | |---|---|---| | 1984 | 高速道路 Levels of Service | SLI/SLO の概念的起源 | | 2007 | Hamilton, LISA | SLA を設計段階の酸性試験と位置づけ | | 2014 | Treynor Sloss, SREcon14 | 13 のキーと「ローンチオンブラック」ルール初出 | | 2015 | Alvidrez, SREcon15 | エラーバジェットの起源体験 | | 2016 | SRE Book Ch3-4 | SLI/SLO/SLA フレームワーク体系化 | | 2016 | Jones+Murphy, SREcon16 | SLO 公表理由、集約インターバル問題、バンバン制御回避 | | 2017 | Mogul+, HotOS | 可用性定義の困難さを提起 | | 2017 | Wilkinson, SREcon17 | Prometheus でのバケット比率 SLI 実装 | | 2018 | SRE Workbook | SLO 実装・アラーティング・事例・文書例を体系化 | | 2018 | Wilkinson, SREcon18 Asia | SLO バーンレートアラートとシンプトムベースドアラーティング | | 2018 | Binette+Flaming, SREcon18 Americas | ケイパビリティ駆動 SLI 設計 | | 2018 | Gangatirkar, SREcon18 Asia | 共感ギャップ、S 字曲線、6 フレーバー | | 2018 | Vieiro, SREcon18 Asia | Atlassian Error Budgets 0.1 | | 2019 | Mogul+Wilkes, HotOS | SLE/CBE、SLOgician | | 2019 | Hartmann/Moyer, SREcon19 | レイテンシ SLO のパーセンタイル集約不能問題 | | 2019 | Desai, SREcon19 EMEA | SLO の 4 ユースケース、暗黙的仮定、SLO Algebra | | 2019 | Booking.com, SREcon19 EMEA | データ品質 SLO | | 2019 | Lawson, SREcon19 Americas | 新規サービスへの SLO 実装 6 ステップ | | 2020 | Hauer+, NSDI | ウィンドウ付きユーザーアップタイム | | 2020 | Coulter, SREcon20 Americas | SLO 交渉フロー、ユーザー行動ベース SLI | | 2020 | Moyer, SREcon20 Americas | エラーバジェット民主化の 3 鍵 | | 2021 | Ding+Zhang, SREcon21 | SLX フレームワーク | | 2021 | Desai, SREcon21 | Goldilocks Reliability 批判、定常性モデル | | 2022 | Palcuie, SREcon22 EMEA | 30→3000 万 SLO、顧客単位 SLO | | 2022 | Davidovič, SREcon22 EMEA | SLO モデルの線形性問題 | | 2022 | Desai, SREcon22 Americas | SLO 根本批判 | | 2022 | 近藤, SRE NEXT 2022 | 非機能要求予算の組織的前提 | | 2023 | Koss+Goins, SREcon23 Americas | 時間スライス vs イベントベース集計 | | 2023 | Furino, SREcon23 EMEA | 成功定義 SLI、3 ペルソナ時間窓 | | 2024 | Sedlak+, SOSE | SLO 拡散方法論 | | 2024 | Tsuda, SRE NEXT 2024 | クライアントサイド SLO、Multi-tiered SLOs | | 2025 | Durst, SREcon25 EMEA | SLO 導入の 4 前提条件 | | 2025 | Riot Games, SREcon25 Americas | Player Minutes と CEO OKR | | 2025 | eBay, SREcon25 Americas | 非同期パイプライン SLO | | 2025 | Benninghoff, SREcon25 Americas | Security Level Objectives | | 2026 | Takamura, Road to SRE NEXT 2026 | SLI/SLO 段階的導入の体系化 | | 2026 | Yoshikawa | AI サービス SLI/SLO | | 2026 | CASCA | カーボン認識 SLO | --- ## 付録 B　ソース一覧 本教科書は以下の wiki ページを統合して作成した。 **概念ページ**: [[サービスレベル目標]] / [[エラーバジェット]] / [[SRE]] / [[Security Level Objectives]] / [[定常性モデル]] **ソースページ**: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] / [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__Alerting on SLOs]] / [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] / [[@2018__Google SRE Workbook__Appendix A Example SLO Document]] / [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]] / [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] / [[@2020__NSDI__Meaningful Availability]] / [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] / [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] / [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] / [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] / [[@2023__CNCF TAG Observability__Observability Whitepaper]] / [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] / [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] / [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] **実践事例ソース**: [[@2016__SREcon16__Service Levels and Error Budgets]] / [[@2015__SREcon15__Error Budgets and Risks]] / [[@2014__SREcon14__Keys to SRE]] / [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]] / [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] / [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] / [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]] / [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] / [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] / [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] / [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] / [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] / [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] / [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] / [[@2020__SREcon20Americas__Squish Level Objectives]] / [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] / [[@2021__SREcon21__Beyond-Goldilocks-Reliability]] / [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]] / [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] / [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] / [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] / [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]] / [[@2025__SREcon25Americas__Is the S in SRE for Security]] / [[@2016__SREcon16Europe__HPC Downtime Budgets]] / [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] **国内実践事例**: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] / [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] / [[@2022__SRENext2022__Who owns the Service Level?]] / [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] / [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] / [[@2024__SRENext2024__Enabling Client-side SLO]] / [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] **既存一次ノート**: [[notes/sre/SLOの起源]]