# SLI/SLO 教科書 — 基礎から応用まで > [!abstract] 概要 > 本文書は、SRE における SLI/SLO/SLA フレームワークを、基礎定義から組織的導入、応用領域まで網羅的にまとめた教科書である。wiki に蓄積された 40 以上のソース（SRE Book、SRE Workbook、SREcon 各年の発表、学術論文、国内実践事例）を横断的に統合する。第 9 章は AI エージェントが運用の実行主体になる時代の SLI/SLO を扱う（詳細版は [[agentic時代のSLI-SLO運用]]）。 --- ## 第 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]])。 ![[_attachments/srecon14-keys-sre/frame-010.jpg]] **図0-1**:エラーバジェットの初出スライド。「Then what? / Error budgets! / First you must have an SLA...」の 2 行で、公開の体系化が SLA を前提にエラーバジェットを置いたことが分かる。 (Source: [[@2014__SREcon14__Keys to SRE]], frame-010) ![[_attachments/srecon14-keys-sre/frame-012.jpg]] **図0-2**:エラーバジェットの使い道。変更が障害の第 1 原因である以上、予算はローンチに使うか、使わなければサービスの不安定さに使われる。 (Source: [[@2014__SREcon14__Keys to SRE]], frame-012) --- ## 第 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]])。 ![[_attachments/srecon19emea-latency-slos-done-right/page-018.png]] **図2-1**:24 時間の API レイテンシ分布で、全体から求めた p90 は 35.8ms だが、時間ごとの p90 を平均すると 60.3ms となり誤差は 68.5% に達する。パーセンタイルは複数の時間窓をまたいで集約できない。 (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], p.18) ![[_attachments/srecon19emea-latency-slos-done-right/page-023.png]] **図2-2**:50ms より遅いリクエスト数をカウンタで持つと、9.5K / 106K = 8.9% のように SLO 判定をリクエスト数の比として直接計算できる。良いイベント比率への変換がパーセンタイル集約不能問題の実務解である。 (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], p.23) ### 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]])。 ![[_attachments/2018__SREcon18Americas__Real-World-SLOs-SLIs-Deep-Dive/page-005.png]] **図2-3**:監視プロダクトを UI/API、ログイン、データ格納/クエリ、レガシー、取り込みの 5 層に分解する。ケイパビリティ駆動の SLI 設計は、まずシステム境界を列挙するところから始まる。 (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], p.5) ![[_attachments/2018__SREcon18Americas__Real-World-SLOs-SLIs-Deep-Dive/page-006.png]] **図2-4**:SLI/SLO 定義の 7 ステップ。境界の特定、公開ケイパビリティの列挙、「利用可能」の平易な定義、技術的 SLI、ベースライン計測、目標設定、反復までを操作可能な手順に落とす。 (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], p.6) ### 2.5 「成功」を定義すべき理由 SLI は「悪い挙動」ではなく「成功」を定義すべきである。エラーを定義する場合は既知の問題のみをカバーする（有限スコープ）が、成功を定義すれば「それ以外はすべて不確か」という包括的定義になる (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 ![[_attachments/2023__SREcon23EMEA__9-Things-You-Should-Do-When-Starting-to-Use-SLOs/page-008.png]] **図2-5**:測るべきは CPU 使用率やディスク I/O ではなく、光のビーム内にあるカスタマージャーニーとインタラクションである。成功の定義はユーザーに意味のある事象から始める。 (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]], p.8) ### 2.6 ユーザー幸福の 6 フレーバー Gangatirkar は SLI 候補を 6 種に整理した: Availability / Responsiveness / Freshness / Completeness / Accuracy / Breadth。この枠組みとケイパビリティ列挙を組み合わせると、SLI 候補の見落としを防ぎつつサービス固有に具体化できる (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-091.png]] **図2-6**:ユーザー幸福の 6 フレーバー。Availability、Responsiveness、Freshness、Completeness、Accuracy、Breadth。候補の見落としを防ぐ点検リストになる。 (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], p.91) ### 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]])。 ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-095.png]] **図3-1**:可用性対生産性の S 字曲線。99.95% 付近に「仕事ができる」ゾーンと「耐えられる」ゾーンの境界が現れ、これを下回ると契約解除へ向かう。SLO は痛みのしきい値より下に置く。 (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], p.95) ### 3.3 共感ギャップ Gangatirkar の 2×2 マトリクスは重要な概念を定義する。 | | SLO 達成 | SLO 未達 | |---|---|---| | **ユーザー満足** | 正常 | 過剰達成の幻影 | | **ユーザー不満** | **共感ギャップ** | 正常 | 「SLO 達成・ユーザー不満」のセルが共感ギャップ（Empathy Gap）であり、SLO がユーザーの痛みのしきい値より緩く設定されている場合に発生する (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 ![[_attachments/2018__SREcon18Asia__Quantifying-Empathy-with-SLOs/page-145.png]] **図3-2**:共感ギャップの 2×2。SLO 達成かつユーザー不満が共感ギャップ、SLO 未達かつユーザー満足が過剰達成である。理想の SLO はユーザー体験の正確な模擬になる。 (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], p.145) ### 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]])。 ![[_attachments/2020__SREcon20Americas__Squish-Level-Objectives/page-037.png]] **図3-3**:SLO Policy の例。ページ読み込み 1500ms 未満を 99.95%(28 日窓)とし、エラー率 0.05% 超がサポートチケット増加と相関するという根拠を添える。技術閾値をユーザー行動で根拠づける。 (Source: [[@2020__SREcon20Americas__Squish Level Objectives]], p.37) ### 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]])。 ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-023.png]] **図3-4**:多段パーセンタイル SLO。90%/30s、99%/1min、99.9%/5min で応答分布の胴体と尾部を別々に制御する。単一しきい値では抑えられない 1% の遅れを目標として明示する。 (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], p.23) ### 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]])。 ![[_attachments/2015__SREcon15__Error-Budgets-and-Risks/page-012.png]] **図4-1**:エラーバジェットの定義式。availability = successful requests / total requests、error budget = availability − SLA target。量化が計測・分析・改善の循環を可能にする。 (Source: [[@2015__SREcon15__Error Budgets and Risks]], p.12) エラーバジェットの最も重要な組織効果は、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]])。 ![[_attachments/2015__SREcon15__Error-Budgets-and-Risks/page-006.png]] **図4-2**:稼働率ベースとリクエスト成功率ベースの 2 定義。分散環境では部分稼働が続くため、後者がエラーバジェットの定量化に適する。 (Source: [[@2015__SREcon15__Error Budgets and Risks]], p.6) ### 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]])。 ![[_attachments/2023__SREcon23Americas__Not-All-Minutes-Are-Equal/page-010.png]] **図4-3**:時間スライス方式の 6 分間例。Minute 3 は Good:1 / Total:100 でも「良い分」扱いになり、ピーク時の大量エラーが予算に届かない。 (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]], p.10) ![[_attachments/2023__SREcon23Americas__Not-All-Minutes-Are-Equal/page-015.png]] **図4-4**:時間スライスの EBR。Badder Incident が 0% 減、Baddest Incident が 400% 減という逆転が起き、深刻度が予算消費に比例しない。 (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]], p.15) ![[_attachments/2023__SREcon23Americas__Not-All-Minutes-Are-Equal/page-019.png]] **図4-5**:同一データをイベントベース集計すると Badder が 18.1% 減、Baddest が 36.6% 減と深刻度に比例する。エラーバジェットが信じられるシグナルになる条件である。 (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]], p.19) ### 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]])。 ![[_attachments/2019__SREcon19Americas__Extending-the-Error-Budget-Model/page-021.png]] **図4-6**:脆弱性バジェットの完成形。SLI は依存パッチリリースからの経過日数、SLO は最大年齢、閾値接近でパッチ適用ポリシーが発火する。エラーバジェット模型のドメイン非依存な構造を示す。 (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]], p.21) ![[_attachments/2019__SREcon19Americas__Extending-the-Error-Budget-Model/page-033.png]] **図4-7**:Equifax 侵害。脆弱性公開から侵害成功まで 67 日あり、30 日 SLO なら 4 月 7 日時点でパッチが完了し、5 月 13 日の侵害は成立しなかった。 (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]], p.33) --- ## 第 5 章　SLO ベースアラーティング ### 5.1 設計原則 SLO ベースアラートの目的は、エラーバジェットを大きく消費する重大イベントを、予算消費前に通知することである。アラートはエラー率の異常ではなく、エラーバジェットへの重大な脅威に対して出す (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 ![[_attachments/srecon18asia-wilkinson-slo-alerting/page-014.png]] **図5-1**:シンプトムベースアラートの定義。シンプトムは SLO で測れるものであり、アラートは SLO 未達の危険に対して出す。閾値超えそのものではなく予算への脅威を通知する。 (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]], p.14) ### 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]]) ![[_attachments/srecon18asia-wilkinson-slo-alerting/page-022.png]] **図5-2**:累積エラーが許容レートの点線を超えた瞬間にアラーティングウィンドウ上端へ達する。スケールしたエラーバジェットと通知窓の関係がバーンレートの幾何である。 (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]], p.22) ### 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]])。 ![[_attachments/srecon18asia-wilkinson-slo-alerting/page-026.png]] **図5-3**:Prometheus の SLO Fast Burn 式。`delta(errors[1h]) > (expected_events * error_budget / burn_period)` を 1000 qps・7 日・誤差 1%・24 時間の具体値で示す。 (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]], p.26) ### 5.5 バーンレートグラフの読み方 EBR グラフ上で識別すべき 4 パターン: 1. **Slow burn**: 変更起因のじわじわ消費 2. **Fast burn**: 大規模インシデントによる急激消費 3. **Recovery**: バグ修正後の回復 4. **No Incident drain**: インシデントなしの緩慢消費（バグ起因の遅延劣化。バーンレートアラートだけでは捕捉困難） (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) ![[_attachments/2023__SREcon23Americas__Not-All-Minutes-Are-Equal/page-024.png]] **図5-4**:EBR 上の Slow burn、Fast burn、Recovery。変更導入から急激消費、緩慢消費、回復までの読み方が、複数ウィンドウ・複数バーンレート設計の前提になる。 (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]], p.24) ![[_attachments/2023__SREcon23Americas__Not-All-Minutes-Are-Equal/page-025.png]] **図5-5**:インシデントなしの緩慢消費(No Incident 49.5% 減)が Badder インシデント(18.1% 減)より大きい。バーンレートアラートだけでは捕捉しにくい遅延劣化を示す。 (Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]], p.25) ### 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アラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 ![[_attachments/warning-alert-driven-log-metric-collection/page-012.png]] **図5-6**:Warning アラートを Webhook から Lambda、SQS、ログ基盤へ分岐し、結果をアラートメモへ戻す制御フロー。鳴らしたあとに見るべき材料を自動添付する。 (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], p.12) --- ## 第 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 倍偏り、障害中のリクエスト断念を過少評価 - **インシデント比**: 任意の「インシデント」しきい値に依存し、大規模分散システムに不適切 - **合成プローブ**: ユーザーの実際のワークロードを代表しない ![[_attachments/nsdi20-paper-hauer/fig1-figure.png]] **図6-1**:等間隔プローバでは成功率 67% とユーザーアップタイム 67% が一致して見える。合成プローブがユーザー負荷を代表しない問題の対照条件である。 (Source: [[@2020__NSDI__Meaningful Availability]], 図 1) ![[_attachments/nsdi20-paper-hauer/fig2-figure.png]] **図6-2**:単一ユーザーの不均等なリクエストでは成功率 68%、ユーザーアップタイム 65%。障害中のリクエスト断念を成功率が過少評価する。 (Source: [[@2020__NSDI__Meaningful Availability]], 図 2) ### 6.3 ウィンドウ付きユーザーアップタイム Hauer+ が Google G Suite で評価・本番展開した新指標: 1. 各ユーザーの細粒度リクエストログからアップ分・ダウン分を算出し、全ユーザーの均等加重平均で集約 2. 1 分から四半期まですべてのウィンドウサイズで最悪可用性を算出し、MCR（Maximum Contiguous Ratio）曲線として可視化。「膝」の位置で短時間断続障害と長時間大規模障害を区別 (Source: [[@2020__NSDI__Meaningful Availability]]) ![[_attachments/nsdi20-paper-hauer/fig9-figure.png]] **図6-3**:ウィンドウ付きユーザーアップタイム(左)と 1 分粒度の可用性(右)。窓サイズごとの最悪可用性を MCR 曲線として描き、膝の位置で短時間断続障害と長時間大規模障害を区別する。 (Source: [[@2020__NSDI__Meaningful Availability]], 図 9–10) ### 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]]) ![[_attachments/2022__SREcon22EMEA__Measuring-Reliability/page-027.png]] **図6-4**:空間線形性の問題。一部ユーザーへの完全障害と全ユーザーへの軽微な障害が集計 SLO では等価に見える。時間軸でも 1,000×1 分停止が 1×1,000 分停止と扱われる。 (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]], p.27) 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]])。 ![[_attachments/srecon22emea-palcuie-30-to-30m-slos/page-022.png]] **図6-5**:5 エラーのルール。横軸はリクエスト数、縦軸は SLO ターゲット。10 リクエストなら 50%、1 万で 99.95% に収束し、少トラフィック顧客への一律目標を避ける。 (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], p.22) --- ## 第 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 育てながら組織に定着させる実践知]]) ![[_attachments/road-to-sre-next-kobe/page-036.png]] **図7-1**:SLO 違反ポリシーの Lv1(可視化のみ)から Lv5(開発スケジュールの意思決定)まで。最初から開発停止を発火させる必要はなく、認知が広がるにつれて範囲を広げる。 (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], p.36) ### 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]]) ![[_attachments/road-to-sre-next-kobe/page-025.png]] **図7-2**:小さく始める 4 ステップ。改善ループを細かく回し、各ステップの難易度と対応範囲を明示する。「仮値から始めてフィードバックで洗練する」の操作手順である。 (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], p.25) ### 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]])。 ![[_attachments/sre22amer-smith-dark-sky-camping/page-030.png]] **図7-3**:実装の前に Adjust フェーズを置く改善版タイムライン。営業チームが SLO を稼働率 99.999% の話と誤解した教訓を、実装前の合意形成として位置づける。 (Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], p.30) ### 7.4 SLO は交渉プロセスである Coulter は SLO を技術的に「正しい値を計算する」問題ではなく、ステークホルダー交渉として扱う視点を示した。「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」という反復的交渉フローを提案し、SLO は一度合意すれば終わりではなく継続的に再交渉されるものとして設計される (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]])。 ![[_attachments/2020__SREcon20Americas__Avoiding-Goodharts-Law/page-031.png]] **図7-4**:SLO 交渉フロー。Warmup → Test Drive → Assess → Propose → [RECUR] → Agree。一度の合意で終わらず、再交渉し続けるものとして設計する。 (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], p.31) ### 7.5 組織的前提条件 近藤（SRE NEXT 2022）は、SLI/SLO の定義・観察文化を 2 プロダクト 15 チームに導入した後も、Error Budget Policy が定着しなかった原因を「**非機能要求に対処する予算・権限が開発チームになかった**」と分析した。技術戦略グループの発足と「新規:エンハンス:技術的負債解消 = 1:1:1」という予算宣言が解決をもたらした (Source: [[@2022__SRENext2022__Who owns the Service Level?]])。 ![[_attachments/srenext2022-chaspy-who-owns-service-level/page-035.png]] **図7-5**:SLI/SLO の定義と見直しはできたが、Error Budget Policy に従って行動することはできなかった循環。非機能要求の予算と権限が開発チームになかったことが原因である。 (Source: [[@2022__SRENext2022__Who owns the Service Level?]], p.35) Durst（SREcon25 EMEA）は導入の 4 前提条件を示した: (1) 所有権、(2) 標準プロセス、(3) 保護時間、(4) SLO 計測基盤 (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 ![[_attachments/2025__SREcon25EMEA__Run-Walk-Crawl/page-050.png]] **図7-6**:導入の 4 前提。基本的オブザーバビリティ、名目状態の理解、所有権、保護時間。Run / Walk / Crawl の段階と対応させ、準備が揃ってから SLO を正式化する。 (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], p.50) ### 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]])。 ![[_attachments/srecon19emea-fouquet-slo-data-intensive/fig02-missing-slos.png]] **図8-1**:可用性・レイテンシでは捉えられない Durability / Accuracy / Consistency / Freshness。データ集約型サービスではデータ品質 SLO が意思決定の前提になる。 (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]], p.9) ### 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]])。 ![[_attachments/SOSE_2024_B_Sedlak/fig2-figure.png]] **図8-2**:高レベル SLO 拡散の 3 ステップ。ベイジアンネットワーク学習、グラフを遡る拡散、矛盾検知と解決。高レベル目標を低レベル制約へ分解する手順である。 (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]], 図 2) ![[_attachments/SOSE_2024_B_Sedlak/fig5-figure.png]] **図8-3**:状態受容率 λ に対する高レベル/低レベル SLO 充足率。λ を大きくすると達成率は上がるが、LiveMonitoring では 0.7 超で急落し 0 へ落ちる。本文のトレードオフの根拠である。 (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]], 図 5) ### 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]])。 ![[_attachments/2018__SREcon18Americas__Real-World-SLOs-SLIs-Deep-Dive/page-014.png]] **図8-4**:3 ノード中 1 障害のとき、水平スケールでは全体 SLO 66% として比例するのに対し、ハードシャードでは 0%/100%/100% が集計 66% と誤って健全に見える。シャード単位の独立 SLO が不可欠である。 (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], p.14) ### 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.8.1 Goodput — SLO を内包したスループット指標 生の TPS/RPS は SLO を無視した指標である。Goodput は「SLO を満たすスループット」と定義され、この乖離を補正する。秒間 10 RPS を捌けるシステムでも、TTFT 200ms 以下・ITL 50ms 以下という制約を課すと Goodput は **3 RPS まで低下**する (Source: [[LLM推論]])。学習側には ML Productivity Goodput = Scheduling Goodput × Runtime Goodput × Program Goodput という三層分解があり、見かけ上 100% 利用率のクラスタでも、プリエンプション・リソース断片化・ネットワーク輻輳・障害復旧により 70〜75% の計算が実質的に失われうる (Source: [[ML Productivity Goodput]], [[Goodput]])。 ただし指標名の一致は実装の一致を意味しない。ITL は GenAI-Perf では TTFT を含まないが LLMPerf では含み、TPS の分母定義もツールで異なる (Source: [[LLM推論]])。第 1.1 節の「SLI 仕様と SLI 実装の分離」がこの領域では最初から破綻の危険とともに現れるため、SLO 文書には計測ツールとその定義まで明記する必要がある。 #### 8.8.2 従来 SLI が原理的に取り逃す次元 可用性・レイテンシ SLI では検知できない失敗モードが存在する。**コスト起因劣化（cost-induced degradation）**は、短いコンテキストウィンドウ、小型モデルへの切り替え、低サンプリング、積極的なキャッシュ利用といったコスト制約が、**サービスエラーを一切出さずに**推論品質を劣化させる現象である (Source: [[LLMアプリケーション信頼性]], [[LLM推論]])。生成 AI サービスでは人手検知率 38.3%、監視メトリクス種類 25.9 対 74.4、収束時間 1.83 倍という定量報告もある (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 ![[_attachments/reliability-in-the-age-of-ai-engineering-for-ai-velocity/page-010.png]] **図8-5**:生成 AI 運用では人手検知率 38.3%、監視メトリクス種類 25.9 対 74.4、収束時間 1.83 倍。可用性・レイテンシ SLI だけでは品質劣化を取り逃す。 (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], p.10) レイテンシ指標そのものにも死角がある。投機的 LLM 呼び出しは TTFT 中央値を 2 秒短縮する一方、最終的に使われない対話でも発火し、レイテンシ指標には一切現れない無駄なコストを生んだ。「呼び出しが起きたか」でなく「呼び出しが使われたか」まで追跡しないとコスト異常が完全に不可視になる (Source: [[GenAI オブザーバビリティ]])。 #### 8.8.3 非決定的な出力に SLO を張る三つの実務解 非決定的な出力に対する SLO 目標値の統計的定式化は確立していないが、実務上機能している方式が 3 系統ある。 1. **成功率型 SLI へ落とす** — Honeycomb の MCP サーバーはクエリ成功率 90% の SLO を実運用し、モデルのフィールド名誤認や時間範囲解釈の失敗パターン発見に用いた (Source: [[GenAI オブザーバビリティ]])。 2. **三値評価を許容する** — 単一の正解を持たない task evals は本番テレメトリで LLM-as-a-Judge 採点し、pass・fail・maybe の三値を許す (Source: [[LLM評価]])。 3. **決定論的ハーネスで囲う** — 構造誤りを再訓練や再プロンプトでなく後処理で機械的に除去し、エラー率を 25% → 14% → 1% 未満まで低減した (Source: [[LLMアプリケーション信頼性]])。 #### 8.8.4 コストの SLO 化 コストを SLO の対象に載せた最も直接的な実例は Intercom の Fin である。**対話あたりコストを分散トレースの独自属性として追加し、それに SLO を設定**した。OpenTelemetry GenAI セマンティック規約にコストの標準キーが存在しないため規約外の方式だが、財務データウェアハウス経由で数分から数時間かかっていたコスト劣化検知がほぼリアルタイムになった (Source: [[GenAI オブザーバビリティ]])。第 4 章のエラーバジェットと同様に「コスト予算」を消費管理する枠組みへ展開できるかは未確立である。 ### 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 の日常運用そのものがセキュリティパフォーマンスの土台である」という組織論的視点を加えている点で異なる。 ![[_attachments/2025__SREcon25Americas__Is-the-S-in-SRE-for-Security/page-023.png]] **図8-6**:サイバーセキュリティ損失は 100 ドルから 100 億ドル(典型 100 万ドル)、アウテージは 100 ドルから 1000 万ドル(典型 10 万ドル)。桁違いの損失分布が、エラーバジェット的な許容損失率を置きにくくする。 (Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]], p.23) ### 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]], [[定常性モデル]])。 ![[_attachments/2021__SREcon21__Beyond-Goldilocks-Reliability/page-019.png]] **図8-7**:スロークエリ総時間割合の定常性違反。閾値監視では見落とすゆっくりした劣化が、期待からの乖離として時系列に現れる。定常性モデルが「通常どうあるべきか」を定義する例である。 (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]], p.19) 定常性モデルは SLI/SLO の閾値設計問題そのものを解消するのではなく、SLO フレームワークと**直交**する「あるべき状態からの逸脱」を検知する層として位置づけられる。SLO が「どこを超えたらアウトか」を定義するのに対し、定常性モデルは「通常どうあるべきか」を定義する点が根本的に異なる。 --- ## 第 9 章　Agentic 時代の SLI/SLO — エージェントを統治する 第 8.8 節が扱ったのは「AI ワークロードをどう測るか」という問いだった。本章はそれと区別すべき別の問いを扱う。**AI エージェントが運用の実行主体になるとき、SLI/SLO とエラーバジェットは何を担うのか**という問いである。 「Agentic 時代の SLI/SLO」という一語には、性質の異なる 3 つの問いが混在している。 | 問い | 内容 | 本章での扱い | |---|---|---| | A. 対象としての AI | AI ワークロード自体をどう測るか | 第 8.8 節 | | B. 道具としての AI | SLI/SLO の策定・運用を AI が助ける | 9.1 | | C. 統治対象としての AI | SLO でエージェントの権限を律する | 9.2〜9.5 | 3 者で必要な知識体系はまったく異なる。A は指標設計、B は組織的導入の律速段階、C は安全仕様と契約の問題であり、A の成熟が C の成熟をもたらすわけではない。詳細は [[agentic時代のSLI-SLO運用]] に分離して記述した。 ### 9.1 SLI/SLO 策定の道具としての AI *Observability Engineering* 第 2 版第 11 章は、LLM が SLI/SLO の**最初の仮値**の起草を高速化できることを実例で示す。EC チェックアウトの信頼性目標をコストへの疑問で追い込むと、gpt-oss 20b・Claude Opus 4.6 の両モデルとも five-nines から 99.95〜99.99% へ妥当な理由づけとともに自己修正した。 一方、OpenTelemetry セマンティック規約に基づく SLI 式生成では、内部スパン除外フィルタのような重要な条件を両モデルとも初期応答で省略しており、「LLM はドラフト生成器であり権威ではない」という注意が付される (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]])。 ![[_attachments/reliability-in-the-age-of-ai-engineering-for-ai-velocity/page-020.png]] **図9-1**:リポジトリ、既存メトリクス、過去ポストモーテムから SLI/SLO 候補と予兆仮説を起草する構成。LLM はドラフト生成器であり、権威ではない。 (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], p.20) この位置づけは第 7.2 節の組織論と噛み合う。SLO 導入の成功パターンは一貫して「完璧な値を追い求めず仮値から始めてフィードバックで洗練する」であり、LLM はその律速段階の一方（起草）を短縮する。もう一方の律速段階であるテレメトリ標準化への先行投資は依然として人間の仕事である (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。書き込み権限より手前の判断支援（SLI/SLO 候補提案、PRC 観点レビュー、障害対応中の状況要約、ポストモーテム下書き）が実務導入の入口とされるのも同じ理由による (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 ### 9.2 自律度レベルと権限契約 エージェントに実行を委ねる度合いは、複数の枠組みで段階化されている。 Google の **SRE AI Autonomy Levels** はインシデント対応を Monitor / Investigate / Mitigate / Actuate / Self-Direct の 5 軸に分解し、各軸が人間から自動へ移る度合いで L0〜L4 を定める。L1 は緩和の判断と実行の両方を人間が保持し、**L2 は判断のみを人間が保持して実行は自動化**する。L3 は判断も実行も自動だが「軽微なインシデントに限定」という但し書きが付く (Source: [[SRE AI Autonomy Levels]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]])。 学術側はこれを**権限契約**として形式化する。自律度の段 `k` ごとに **assurance contract** `Ck = (Tk, Rk, Gk, Uk, Bk)`（許可ツール面・必須証拠・迂回不能ゲート・ロールアウトプロトコル・予算）を定義し、契約充足を `τ ⊨ Ck` という測定可能な主張へ落とす。書き込みツールは `T^write = T^propose ∪ T^exec` と分割され、差分を起草できるが適用はできない段が区別される。これが Google の L2 と同型の分割である (Source: [[エージェント運用安全性]], [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]])。 ![[_attachments/arxiv-2605.12729/fig1-taxonomy.png]] **図9-2**:自律度のはしご。読み取り支援から書き込み実行へ進むほど、許可ツール面と必須の安全ゲートが厚くなる。L4 では段階的ロールアウトに SLO がガードレールとして載る。 (Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], 図 1) 組織の受容度はこれと直交する軸として現れる。Observe（AI を見守る・約 60%）→ Advise（推奨を受け入れる・約 22%）→ Assist（AI が実行し人間が承認・約 16%）→ Partner という **Trust Spectrum** は、技術的自律度が上がっても組織が追随するとは限らないことを示す (Source: [[SRE AI Autonomy Levels]])。 ### 9.3 エラーバジェットを自律度のゲートに使う 第 4 章のエラーバジェットは、開発チームと SRE という**人間同士**の協調を前提に設計されている。エージェントが実行主体に加わると、この前提が崩れる。 現在この空白を埋めかけている議論は 1 件のみである。Yoshikawa は、**エラーバジェットが残っている間は AI 補助による自動承認を許容し、消費されれば人間承認へ戻す**運用を示した。これはエラーバジェットを「リリース停止/許可」だけでなく「**AI に任せる権限レベル**」の制御信号として使う拡張である (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[エラーバジェット]])。 この一点が重要なのは、[[SRE AI Autonomy Levels]] の最大の欠落と正確に噛み合うからである。L0→L1 はツールの可用性と採用、L1→L2 は信頼できる識別と安全な経路、L2→L3 は実証された精度・信頼・堅牢な安全制御——という昇格基準はすべて定性的であり、ページ自身が「**昇格を判定する定量基準は本ソースでは未明示**」と認めている。エラーバジェットのバーンレートはその最有力候補でありながら、まだ誰もそう定式化していない。 構造的にも整合する。第 4.4 節のバンバン制御からプロポーショナル制御へという設計思想は、二値の「AI に任せる/任せない」ではなく**連続的な自律度調整**と同型である。バーンレートが低いほど高い自律度を許し、高いほど権限を巻き取るという写像が自然に描ける。 ### 9.4 SLO を機械判定可能な不変条件へ変換できるか エージェントの安全設計には既に精緻な語彙がある。**verification wall（検証の壁）**は、すべての書き込み行動が健全なゲート `g` を通過する場合にのみ、実行された書き込み列がポリシー `Π` と不変条件 `I` を満たすことを保証する。設計パターンとしては「提案とコミットの間の迂回不能な界面」である (Source: [[エージェント運用安全性]])。 ![[_attachments/arxiv-2605.12729/fig10-figure.png]] **図9-3**:verification wall の不変条件。到達可能性や隔離のようにチェッカ化できる対象を壁のゲートへ載せる。SLO は集約的で、同型の述語化がまだ難しい。 (Source: [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]], 図 10) **[[Transactional No-Regression]]**（TNR）は「試行が現状の信頼性指標を後退させない」ことを Alpern–Schneider の安全性として形式化し、Checkpoint → Execute → Commit/Abort の実行構造を与える (Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]])。 ![[_attachments/arxiv-2506.02009/fig2-figure.png]] **図9-4**:STRATUS の状態機械。検知、診断、緩和、取り消しのエージェントを制御フローでつなぎ、緩和の失敗を Undo へ戻す。TNR の Checkpoint → Execute → Commit/Abort を実行構造へ落とす。 (Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], 図 2) 問題は、**この語彙と SLO/エラーバジェットの接続点が 2 つしかない**ことである。 1. verification wall のゲートが参照する不変条件 `I` の候補として SLO・エラーバジェット・blast radius が挙がるが、「NetOps の到達可能性/隔離ほど明確に**チェッカ化できない**ため、サービス層の verification wall はどこまで健全たりうるか」と留保される (Source: [[エージェント運用安全性]])。 2. TNR の重大度関数 `µ(s) = w1·|A| + w2·|V| + w3·|L|`（`A` はアラート、`V` は SLA 違反、`L` は容量損失）の第 2 項が SLA 違反数である。SLO 体系ではなく、SLA 違反件数が行動可否判定の目的関数の一項として現れるにとどまる (Source: [[Transactional No-Regression]])。 到達可能性や隔離は行動の直前に単発で判定できるが、SLO は集約的かつ時間依存であり、単一行動の可否をその場で決める述語に変換しにくい。バーンレート予測を述語化する設計が要るが、確立した手法はない。 ### 9.5 三つの壁 エラーバジェットを自律度のゲートに使う設計は、以下の 3 点に阻まれる。 **壁 1 — 能力天井とゲート強度のトレードオフ**。エージェントの能力天井は 6 割前後である。契約 `(Rk, Gk, Bk)` を厳しくすれば refusal storm（過剰な拒否）、緩めれば over-permissive execution（過剰な許可）となる。「能力が低いまま安全な契約は成立するか」が未解決の問いとして立つ (Source: [[エージェント運用安全性]], [[agentic SRE]])。 **壁 2 — 人間側のゲートが形骸化する**。「AI 出力を検証せず承認するだけ」という**ゴム印問題**が AI 関連侵害の 97% の原因として報告された。ジュニアが手動スキルを学ばず、シニアが過剰依存でスキル退化するという二重のスキル劣化を伴う。verification wall は技術的には迂回不能だが、組織慣行としては形骸化しうる (Source: [[エージェント運用安全性]], [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]])。凍結判断を人間の承認に依存させる設計はここで破れる。 ![[_attachments/sre26amer-budichenko/page-013.png]] **図9-5**:AI 関連侵害の 97% は人間の監視欠如に起因する。ジュニアは手動スキルを学ばず、シニアは過剰依存で劣化する。ゴム印承認が verification wall を形骸化させる。 (Source: [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]], p.13) **壁 3 — エージェントの失敗が沈黙する**。障害注入実験では、警告なしの誤出力である **Silent 失敗が AutoGen で 65.71%、Mini-SE で 61.09%** に達した。頑健性はモデル能力でなくシステム実装に依存し、パイプラインパターンが最も脆く反復パターンが最も頑健である (Source: [[エージェントシステム運用]], [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]])。SLI の分母に載らない失敗が過半を占める状況では、成功率型 SLI そのものが機能しない。 ![[_attachments/arxiv-2608.06790/fig01-fault-propagation-example.png]] **図9-6**:上流 Planner の切り詰め障害が、警告なしの不完全な修正として Coder へ伝播する。Silent 失敗が成功率型 SLI の分母に載らない理由の構造である。 (Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]], 図 1) 加えて**過剰介入（over-control）**という失敗モードがある。Hurt ケースは平均 29.3 回、Helped ケースは 11.3 回の介入で、同じガードが必須行動の周りで繰り返し発火するとエージェントが行動を確定できず再計画を続ける (Source: [[エージェント修復]])。ゲートを増やせば安全になるという単純な関係は成り立たない。 ### 9.6 SLO の主体が移る — 長期構想と自動化のアイロニー 第 8.10 節のセルフクラフト構想は、SLO の主体を事業者から利用者 + AI へ移す。[[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] はこれを一段進め、利用者・情報システム・開発運用者の間にエージェントネットワークを張り、「変更 → 外乱 → 不満」という因果をコンテキストとして流通させることで、深層学習の自動微分のように **SLI/SLO をフィードバック循環から事後的に自動調整し続ける**モデルを提示した。工学への要求は事前性から事後性へ転換する。 ![[_attachments/iots2025_presentation/page-068.png]] **図9-7**:変更 → 外乱 → 不満の因果をコンテキストとして流通させ、SLI/SLO をフィードバック循環から事後的に自動調整する構想。SLO の主体が事業者から利用者と AI へ移るときの制御像である。 (Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], p.68) > [!warning] 監視のアイロニー > Bainbridge の**監視のアイロニー**——自動制御系はオペレータより良い判断ができるから導入されたのに、そのオペレータに自動制御系の正しさを監視させるのは不可能な課題である。[[自動化のアイロニー]] はこれを SLO 文脈へこう翻訳する。「専門オペレータでない利用者が、**短時間の体験だけで長期的な信頼性リスクを判断できるか**」。 > > 同型の警告が自律コンピューティングの原典にもある。自律システムは人間の誤りを大幅に減らす一方、**目標指定における人間の誤りの帰結を大きく増幅する**。ポリシーの誤りは構成と振る舞いへの間接的な効果を通じて現れるため、追跡と是正が非常に困難になる (Source: [[@2003__Computer__The Vision of Autonomic Computing]], [[自律コンピューティング]])。SLO を自動調整ループに委ねるとき、誤った SLO は誤ったまま増幅される。 最後に、エージェント導入は緩和対象を減らすだけでなく**複雑性を足す**。非決定的に振る舞う別システムを既存システムに加えるため、系全体は元より複雑になる (Source: [[agentic SRE]])。DORA 2024 の「AI 採用 +25% とデリバリー安定性 −7.2%・スループット −1.5%」、DORA 2025 の「スループットが反転しても不安定さの悪化は継続」という数値は、この警告の経験的裏づけとして読める (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]])。 --- ## 第 10 章　未解決の問いとフロンティア ### 10.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]])。 ### 10.2 SLO の根本批判 Desai は「SLO requires recognized errors」と述べた上で、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータにとどまる」と主張した。SLO を段階的改善の対象として論じる多くの先行ソースとは異なり、「SLO そのものが計測ツールとして根本的に不完全」という結論に進んだ最も強い批判形である (Source: [[@2022__SREcon22Americas__Principled Performance Analytics]])。 ### 10.3 エラーバジェットの不確実性 エラーバジェットを設定するためのインパクト推定が桁違いに不正確でありうる。Davidovič は 3 人の独立した担当者にインシデント影響を推定させてバリアンスを観察することを推奨した (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]])。 ### 10.4 Agentic 時代の五つの空白 第 9 章が示した空白を、次に埋めるべき課題として列挙する。5 点は互いに独立ではなく、「**SLO を人間同士の社会契約から、人間と機械の権限契約へ拡張する**」という単一の未解決課題の 5 つの側面である。 1. **エラーバジェットをエージェント自律度のゲートに使う設計**。Yoshikawa の 1 件を除き前例がない。[[SRE AI Autonomy Levels]] の昇格定量基準の空白と正確に対応する（9.3）。 2. **SLO/エラーバジェットを機械判定可能な不変条件へ変換する方法**。集約的・時間依存の性質を単一行動の可否述語へ落とす手法が確立していない（9.4）。 3. **エージェント自身への SLO 設定**。Silent 失敗率が 6 割を超えうる前提で成功率型 SLI をどう設計するか。PolicyViolations・RollbackRate・StopScore といった安全性指標を SLI として束ねる作業は未着手（9.5）。 4. **エージェントが自律緩和したときのバジェット消費判断・凍結判断の主体**。エージェントが自らのバジェット消費を判定する場合の利益相反をどう扱うか (Source: [[エラーバジェット]])。 5. **ハルシネーション率をユーザー幸福の 6 フレーバー（第 2.6 節）のどこへ置くか**。Accuracy に含めるのか、7 番目のフレーバーが要るのか。 有望な足がかりは第 6.4 節の SLE/CBE である。Mogul+Wilkes の「法律家的思考から統計家的思考へ」の転換は、agentic SRE の assurance contract と「契約 = 期待 + 帰結」という点で同型である。SLE/CBE がプロバイダと顧客の双方向期待管理を定式化したのと同じ構造で、人間とエージェントの双方向期待管理を定式化できる可能性がある (Source: [[サービスレベル目標]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 ### 10.5 その他の未解決課題 - SLE/CBE 枠組みは概念的提案にとどまり、クラウドプロバイダでの採用事例は未報告 - SLO アラート発火時に自動添付する情報の標準化範囲 - クライアント側測定とサーバー側測定の乖離を定量化する実践的手順 - 非決定的な出力に対する SLO 目標値の統計的定式化（第 8.8.3 節の 3 実務解はいずれも経験則にとどまる） - LLM 推論で TTFT・ITL・Goodput・Tokens/Dollar・出力品質を同時に SLO 化する場合、どの指標を契約上の SLA へ上げ、どの指標を内部運用 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 | | 2025 | STRATUS, NeurIPS | Transactional No-Regression（SLA 違反を重大度関数へ組み込む） | | 2026 | Takamura, Road to SRE NEXT 2026 | SLI/SLO 段階的導入の体系化 | | 2026 | Yoshikawa | AI サービス SLI/SLO、エラーバジェットによる AI 承認権限の制御 | | 2026 | CASCA | カーボン認識 SLO | | 2026 | Google SRE | SRE AI Autonomy Levels L0–L4 | | 2026 | Observability Engineering 2E Ch.11 | LLM による SLI/SLO 草稿生成とその限界 | | 2026 | NetOps/AIOps サーベイ | assurance contract、verification wall | --- ## 付録 B　ソース一覧 本教科書は以下の wiki ページを統合して作成した。 **概念ページ**: [[サービスレベル目標]] / [[エラーバジェット]] / [[SRE]] / [[Security Level Objectives]] / [[定常性モデル]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[エージェント運用安全性]] / [[Transactional No-Regression]] / [[エージェントシステム運用]] / [[エージェント修復]] / [[LLMアプリケーション信頼性]] / [[GenAI オブザーバビリティ]] / [[LLM評価]] / [[LLM推論]] / [[Goodput]] / [[ML Productivity Goodput]] / [[自動化のアイロニー]] / [[自律コンピューティング]] **姉妹編**: [[agentic時代のSLI-SLO運用]]（第 9 章を独立ページとして展開したもの） **ソースページ**: [[@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の起源]]