## 定義 サービスレベル目標（SLO）とは、サービスの信頼性・性能に関する定量的な目標値である。SLI（サービスレベル指標）を計測し、SLO を満たすか否かを判定する。SLA（サービスレベル合意）は SLO に違反時の帰結（返金等）を付した契約上の約束であり、SLO + 帰結 = SLA と定式化される (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 「ナイン」表現（99.9%、99.99% 等）はクラウドの可用性を要約する事実上の標準だが、Mogul+Wilkes は「ナインだけでは不十分」と論じ、短時間断続障害と長時間大規模障害の区別・グレースフルデグラデーションの記述・ビジネス的重要日の重み付けができないと指摘する (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 この概念は SRE Book（2016）の SLI/SLO/SLA 三層化を起点に、可用性指標の測定論（Mogul+, Hauer+）、レイテンシ SLO の実装手法、SLO ベースアラーティング、SLI 設計とカバレッジ、ステークホルダーごとの合意形成、組織的定着、そして SLA/SLO の理論的定式化という 7 系統へ枝分かれして蓄積されてきた。実務者の間では「完璧な値を追い求めず動かしながら修正する」という段階的定着パターンと、「SLO 代数・エラー認識の曖昧さ」という測定論の未解決問題が並走しており、生成 AI・LLM 推論・IoT といった新領域は SLI の候補そのものを拡張しつつある。 ## 子概念 - [[agentic SRE]] - [[インターネットスケールサービス設計]] ## 可用性指標の設計と測定 Hauer+ は「良い可用性メトリクスは**有意義性**（ユーザー体験を捉える）・**比例性**（変化に比例する）・**実用性**（原因の洞察を与える）の三要件を同時に満たすべき」と定式化した (Source: [[@2020__NSDI__Meaningful Availability]])。 既存指標の限界: - **成功率**（成功リクエスト数 / 総リクエスト数）: 最活発ユーザーに最大 1,000 倍偏り、障害中のユーザー行動変化（リクエスト断念）で実際の影響を過少評価する (Source: [[@2020__NSDI__Meaningful Availability]])。 - **インシデント比**（稼働分 / 総分）: 任意の「インシデント」しきい値に依存し、大規模分散システムは「完全に停止」も「完全に稼働」もほぼないため不適切 (Source: [[@2020__NSDI__Meaningful Availability]])。 - **合成プローブ**: ユーザーの実際のワークロードを代表しない (Source: [[@2020__NSDI__Meaningful Availability]])。 Hauer+ が Google G Suite で評価・本番展開した新指標 (Source: [[@2020__NSDI__Meaningful Availability]]): 1. **ユーザーアップタイム**: 各ユーザーの細粒度リクエストログからアップ分・ダウン分を算出し、全ユーザーの均等加重平均で集約する。カットオフ（99 パーセンタイル到着間隔、Gmail では 30 分）を設け非活性期間を除外することで有意義性と比例性を同時に実現する。 2. **ウィンドウ付き拡張**: 1 分から四半期まですべてのウィンドウサイズで同時に最悪可用性を算出し、MCR（Maximum Contiguous Ratio）曲線として可視化する。曲線上の「膝」の位置で短時間断続障害と長時間大規模障害を区別でき、実用性を担保する。 - **測定点は「ロカス・オブ・コントロール」ではなく「ロカス・オブ・メジャーメント」を優先すべきである。** Jones・Murphy は SREcon16 でサーバー側レイテンシを測りがちな Google の実態を「間違い」と認め、クライアント側が実際のユーザー体験を正確に反映すると述べた。制御しやすい場所で測るのと、ユーザーに意味のある場所で測るのは異なる。 - 根拠: [[@2016__SREcon16__Service Levels and Error Budgets]] - **集約インターバルの選択がサービス動作の解釈を根本的に変える。** SREcon16 トランスクリプトでは、同じデータが 1 分インターバルでは平坦、30 秒では散発的スパイク、1 秒では「毎分先頭に全リクエストが集中」と見えることを示した。クライアント同期の問題（修正必要）とピーク性能支配（キャパシティプランニング影響）が見えなくなる。「何を測るか」の前に「どのウィンドウで見るか」という問いがある。 - 根拠: [[@2016__SREcon16__Service Levels and Error Budgets]] - 関連: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] — パーセンタイル集約不能問題とは別軸の問題 - **CCU 重み付き可用性計測（Player Minutes）は均等加重ユーザーアップタイムの「重み付き変形」である。** Hauer+ のウィンドウ付きユーザーアップタイムは全ユーザーを均等加重で集約するが、Riot Games の Player Minutes は CCU（同時接続ユーザー数）で各分を重み付けする。大規模インシデントほど大きく反映され、季節変動（ピーク時の CCU 増減）も自動的に吸収される。有意義性と比例性を Hauer+ と同様に満たしつつ、重み付けロジックが「ユーザー均等」ではなく「CCU 比例」である点が異なる。 - 根拠: [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] - 関連: [[@2020__NSDI__Meaningful Availability]] - **達成率型SLOは、レイテンシ・可用性型SLOとは異なる「非対称な誤差コスト」の設計論を要求する。** ソフトウェアアップグレードの SLO（「アップグレード窓内に 95% 以上のアップグレードを完了させる」）は good/bad イベント比率という点で SRE Workbook 型 SLI と同型だが、SLI の値自体が「期間予測器の出力」という中間モデルの誤差を経由して決まる点が特徴的である。SLO 達成率を予測器の目的関数に直接組み込む（過小予測により重いペナルティを課す分位点損失、達成率が SLO を下回る場合にのみペナルティを加えるカスタムスコア関数）ことで、「予測精度の最大化」と「SLO 達成」のミスマッチを解消する、「予測ベースのシステムで SLO を直接最適化対象に組み込む」という第三の設計パターンを示す。 - 根拠: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §4.2-4.3 ## レイテンシSLOの実装 - **レイテンシSLOはパーセンタイル時系列ではなく、しきい値内の良いイベント比率として実装する必要がある。** 時間ごとの p90 を平均すると全体分布から計算した p90 とずれる例が示され、パーセンタイルが複数時間窓・複数ノードをまたいで集約できないことが実務上の SLO 問題として定式化された。SRE Workbook の「良いイベント数 / 全イベント数」型 SLI をレイテンシに適用するなら、ログ、しきい値別カウンタ、[[ヒストグラムメトリクス]] のいずれかで「しきい値以内のリクエスト数」を数える必要がある。 - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **Moyer(SREcon19 Americas) は同タイトル発表(Hartmann, SREcon19 EMEA) と共通して「パーセンタイル平均化の誤り」を中心命題に置き、3手法の優劣構造を確立した。** 2 登壇者の主張は同社の共通知見を裏付けると同時に、「SLO をカウンタまたはヒストグラムで実装せよ」という結論が 1 社の実装経験を超えて 2 つの独立した発表として提示されていることの重みを増す。Wilkinson (SREcon17 Americas) がアラート設計でバケット比率を先に示し、Hartmann・Moyer がレイテンシ SLO 計算の 3 手法として体系化し、Prometheus native histograms（2022〜）などが後続したという系譜が確認できる。 - 根拠: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 根拠: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] - **パフォーマンスカーブ SLO は単一パーセンタイル閾値より「予測可能な変動」を提供する。** パーセンタイルの平均化不能問題と同じ問題意識から、インフラ SLO に多段パーセンタイル定義（90%/30s・99%/1min・99.9%/5min）を使う手法が提案された。単一の「99% の応答が X 秒以内」では X 秒を超える 1% の分布を制御できないが、多段定義は「速い応答の大多数」と「遅い応答の尾部」を別々に制御し、性能劣化パターンがコンシューマ側に予測可能になる。「P50 括弧付き SLO を P99 SLO に並置」という提案と方向性が同じで、SLO を「しきい値の通過/未通過」から「分布の制御」として扱うアプローチの収束として読める。 - 根拠: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 関連: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - **レイテンシSLOを「fast requests / total requests」に変換するトリックは、複数 API のレイテンシ目標を可用性 SLI と同一計算基盤で管理可能にする。** ターゲットレイテンシ以内のリクエストを「fast request」と定義し、SLO ターゲットをパーセンタイル値と同値（P90 なら目標 90%）とすることで、複数 API・複数レイテンシ閾値を混在させたままカウンタ基盤で評価できることを GCE の本番 SLO として示した。「パーセンタイルは時間窓・ノードをまたいで集計できない」という問題提起への「ターゲット以内の良いイベント比率への変換」という手法の、大規模本番実装事例として位置づけられる。 - 根拠: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 根拠: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] - **複合 SLI（Latency AND Availability）は OR 結合により単一のエラーバジェットで両次元を管理できる。** 可用性 SLI「response code != 5xx」とレイテンシ SLI「served in < 100ms」を OR で結合し、一つの SLI として扱うことで単一 SLO・単一エラーバジェットで両方を管理する手法が示された。「レイテンシ SLO はしきい値内の good event 比率で実装する」という原則を、可用性との複合に拡張した事例として読める。 - 根拠: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - **Moyer は 2 年連続の連作で「レイテンシ実装 → 複合 SLI・組織展開」の階層を進んだ。** SREcon19 でパーセンタイル集約の誤りとヒストグラム計装を示し、SREcon20 でその実装を Zendesk 1,000 名規模に展開するための公式化・複合 SLI・マルチサービス EB 問題へ発展させた。「何を測るか → どう実装するか → どう組織に展開するか」という SLO 導入の 3 段階を一人の実践者が連続発表でカバーした稀有な事例。 - 根拠: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] - 根拠: [[@2019__SREcon19 Americas__Latency SLOs Done Right]] ## SLOベースアラーティングの系譜 - **Wilkinson(2018) は SLO を「工学的許容差（engineering tolerance）」と同型に位置づけた。** 機械工学の部品許容差（Upper/Lower Deviation・International Tolerance Grade）の比喩を用い、SLO を「何 % の可用性を許容するか」という設計上の許容差として直感的に説明する。可用性バーチャート（99%/99.5%/99.9%/100%）は差分が右端の小領域に集中することを示し、100% を追求しないことの視覚的論拠となる。さらに「symptom = SLO で計測できるもの」「symptom-based alert = SLO が危険になったときのアラート」という簡潔な定義で、アラーティングを SLO の自然な帰結として位置づける。 - 根拠: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]] - **「高レベルサービス目標へアラートし、個別コンポーネントを調査可能に保つ」原則は SLO ベース呼び出しの前史である。** [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise|Rabenstein SREcon16 Europe]] は、監視システムには高レベルサービス目標へアラートする能力と、必要時に個別コンポーネントを調査できるグラニュラリティの両方が必要だとする。これは Wilkinson 2018 の「symptom = SLO で計測できるもの」へ直接つながる発想であり、ページ条件を高レベル目標に寄せ、原因調査のためのホワイトボックス詳細を別に保持する分離は、SLO をアラーティングの中心に置く設計の前段階と読める。 - 根拠: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] - 根拠: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]] - **Wilkinson(2017) は SLO ベース呼び出しの実装部品として、分布・人間の修復時間・Prometheus 記録ルールを先に置いていた。** SLI を「10 分間の応答レイテンシやエラー率」、SLO を「99.9 パーセンタイル 5ms 未満やエラー 1% 未満」、SLA を経済的帰結と整理する。そのうえで、ページングするアラートは SLO 違反を示すべきだとし、レイテンシ分布のバケット比率や Prometheus の記録ルールを使って実装する。2018 年の SLO バーンレートアラート発表へ進む前に、SLO アラーティングを支えるデータ構造と運用分離を説明した資料と位置づけられる。 - 根拠: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] - 根拠: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]] - **SLO 由来の Warning アラートには「原因をすぐ集める」運用層が必要になる。** `response time` の p99 が 1.5 秒を超える Warning アラートに対し、対象期間のリクエストパス別レスポンスタイムを自動集計し、画像アップロード API 1 件が 17.9 秒だったと判断できる仕組みが示された。SLO を良いイベント比率として設計するだけでなく、違反または予算消費が起きた時点で判断に必要なログ・メトリクスをアラートに添える運用が必要であり、SLO アラートは「鳴らす条件」だけでなく「鳴った後に何を見ればよいか」を含めて設計されるべきである。 - 根拠: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - **SLO は検知に強いが調査（Investigation）には向かない——SLF と SLD が補完する。** SLO を「メトリクス構築・検知・SLO レポーティング」には適しているが「クロスサービス調査の認知負荷を下げる」ことができないと指摘される。補完概念として、SLF（Service Level Factor: SLI を詳細ラベル次元でスライスしたもの）と SLD（Service Level Dependency: 依存サービスとのメトリクス）を追加し、これら 3 要素を結んだ SLX Graph をグラフ走査することで「時系列相関のある異常 SLO 依存チェーン」を自動絞り込む。SLO は 4 ユースケースのうち Incident Response においてプロバイダとコンシューマで優先度が異なるという問題の、実装側での対処と読める。 - 根拠: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] - 根拠: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - **SLO 爆発問題は GitOps + Kubernetes 宣言的管理で吸収する。** Ant Group（60+ K8s クラスタ、99.999% 目標）では「コンポーネント × ユーザージャーニー × SLO 種別 × 実行環境」の組み合わせ爆発により数百件の SLO を手動管理しきれなくなった。対策として SLO 定義 YAML → Git レビュー → ArgoCD → Kubernetes → Prometheus/Grafana という宣言的パイプラインを構築した。SLO 拡散方法論が「SLO をベイズネットで分解する」という垂直方向の問題を扱うのに対し、SLX の GitOps 管理は「膨大な SLO をどう一元管理するか」という水平方向の問題を扱い、両者は相補的である。 - 根拠: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] - 根拠: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - **SLO は「潜在原因ベースアラート」と「症状ベースアラート」を分離する枠組みとして定式化され、SRE Book の 4 基準をより厳密な 2 条件へ整理し直した。** *Observability Engineering* 第 2 版第 11 章は、閾値ベース監視が「何が起きているか(what)」と「なぜ起きているか(why)」を融合させるため誤解を招くと論じ、SLO ベースアラートがこの 2 つを分離すると位置づける。SRE Book の「緊急なユーザー影響・アクショナブル・新規性・調査を要する」という良いアラートの 4 基準を、「ユーザー体験劣化の信頼できる指標であること」「体系的に解決可能であること」という 2 条件のサブセットとして再定式化した。さらに、分散システムでは失敗モードが「既知の未知(known-unknowns)」から「未知の未知(unknown-unknowns)」へ組み合わせ的に爆発するため、閾値アラートは前者にしか通用しないと論じており、Rabenstein の「症状へページする」原則の理論的基礎づけを補強する。 - 根拠: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] - 根拠: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] - 根拠: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] ## SLI設計とカバレッジ ### ケイパビリティとカバレッジ設計 - **ケイパビリティ（機能）を SLI 設計の起点とすることで「SLI 前に何を測るか」が決まる。** システム境界ごとに「公開するケイパビリティ」を列挙し、各ケイパビリティの「利用可能」を平易な英語で定義してから技術的 SLI に落とす 7 ステップレシピが示された。SRE Workbook の「ユーザーに意味のある SLI 仕様」とロジックは共通するが、ケイパビリティを中間概念として挟むことで、SLI の候補を絞り込む具体的な手順が得られる。SLI 設計で「何を測ればいいかわからない」という難点を、「システム境界の機能一覧を作る」という操作可能な第一歩に変換する。 - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **SLO がカバーする範囲とユーザーが気にする範囲のズレは「カバー不足」と「カバー過剰」の 2 方向に起きる。** SLO カバレッジの問題を Venn 図で視覚化し、SLO がユーザーの気にする機能を網羅できていない「カバー不足」と、ユーザーが気にしない項目を SLO でカバーする「カバー過剰」の 2 方向のリスクを示した。「ケイパビリティを SLI 設計の起点」とする手法は前者を防ごうとするもので、「6 フレーバー」フレームワークと相補的——6 フレーバーは SLI 候補カテゴリを提供し、ケイパビリティ列挙はそのカテゴリをサービス固有に具体化する。 - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - **SLI は「悪い挙動」ではなく「成功」を定義すべきである。** エラーを定義する場合は既知の問題のみをカバーする（有限スコープ）が、成功を定義すれば「それ以外はすべて不確か」という包括的定義になる。Availability SLI = Service Connect API への 2XX/3XX/4XX のリクエスト割合（ロードバランサ計測）という具体例も示された。SRE Workbook の「良いイベント数 / 全イベント数」型 SLI を「良い = 成功の定義から導く」という設計原則として再解釈したものと読める。 - 根拠: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] ### 粒度とコンポーネント別SLI設計 - **ハードシャードシステムでは全体集計 SLO が障害を隠蔽する。** 水平スケールでは 3 ノード中 1 ノード障害 = 全体 SLO 66%（比例的に反映）だが、ハードシャードでは SLO 0%/100%/100%（シャード単位）なのに全体集計では 66% と誤って健全に見える。ハードシャードでは論理インスタンス（シャード）ごとに独立した SLO が不可欠と主張された。SLO 拡散方法論でも「サービスチェーンの各コンポーネントへ SLO を分解する」問題が扱われているが、シャードという同一サービスの並列インスタンス間での SLO 粒度は別の問題として明示されていない。 - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - 根拠: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - **コアインフラの SLO は上位サービスの SLO より高く設定しなければならない。** ネットワーク層は上位すべてのサービスへのハード依存であるため、99.99% goal が妥当と示される（アプリケーション層が 99.9% SLO であれば、依存インフラは少なくとも 1 桁高い必要がある）。「インフラ SLO = アプリ SLO の二次依存」という設計則は SRE Book・Workbook では明示されていないが、実装事例として具体的な目標値とともに示されており、SRE Workbook の「ステークホルダー合意」と「コンポーネント依存の考慮」を実務に落とした事例として読める。 - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - **異種コンポーネントを持つサービスでは SLI タイプをコンポーネント種別ごとに分ける。** Ceph Object Storage において、リクエスト駆動 RESTful インターフェース側に「可用性 SLI」「レイテンシ SLI」を、分散ストレージバックエンド側に「耐久性 SLI（書き込んだオブジェクトが障害後も無損傷で再読み取りできる割合）」を別途定義した。SRE Workbook の「サービスコンポーネントを理解して SLI タイプを選ぶ」という原則を、「リクエスト処理」と「データ永続性」が混在するサービスに具体的に適用した最初の公開事例の一つ。新規サービスへの SLO 適用では、ユーザーのアクセスパターンをサーバーログで分析してから SLI タイプを選ぶプロセスも示された。 - 根拠: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **プローバーを使った能動的計測が新規・低トラフィックサービスへの SLO 導入の現実的な起点である。** ロードバランサーログ・S3 クライアントのインストルメンテーション・プローバーの三層計測を組み合わせ、プローバーを主な SLI データ源とした。ユーザートラフィックが少ない新規サービスでは受動的計測だけでは統計的に不安定なため、能動的プローバーが SLO 設定の 4〜5 週間の実績収集を支える。「全体 dumb SLI」と同じ発想（合成テストによる全体健全性確認）を、新規サービス立ち上げに特化した形で適用している。 - 根拠: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - **エンドツーエンドの「dumb SLI」（全体サニティチェック SLI）が個別 SLI の盲点を補完する。** 各層の細粒度 SLI に加えて、「サンプルワークフローが成功するか」という粗い全体 SLI を設けることが推奨される。個々の SLI が全て正常でも全体として壊れている場合（例: 複数層の障害が互いにキャンセルし合う状況）を検知できる。「素朴なサブシステム SLO 分解は相関を見落とす」という指摘への実践的な対処でもあり、個別層の SLI と全体 SLI を両方持つ二層設計が推奨される。 - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - 根拠: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] ### 新領域のSLI候補 - **生成 AI サービスでは SLI の候補が「応答の品質」へ広がる。** AI による変更が信頼性へ与える影響を SLO 達成率で可視化するだけでなく、出力品質スコア、ハルシネーション率、RAG 検索精度を SLI に加える例が示された。従来のリクエスト成功率・レイテンシ中心の SLI/SLO 体系に、意味的品質や検索品質をどう接続するかが AI 組み込みサービスの新しい設計課題になる。 - 根拠: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] - 根拠: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] - **LLM 推論の SLO はレイテンシ・スループット・費用を同時に束ねる。** TTFT・ITL・E2EL・RPS・TPS・Goodput をユーザー体験の候補指標として整理し、Goodput を「レイテンシ要件を満たすリクエスト数」として位置づける。さらに Tokens/Dollar や Tokens/User/Dollar を費用対効果の指標として示し、SLO/SLA を満たしながらコスト最小化するループを推論基盤最適化の中心に置く。SRE Workbook の「ユーザーに意味のある SLI を選ぶ」原則が、GPU コストと推論フェーズの制約へ拡張された例である。 - 根拠: [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **IoT/モビリティ領域では車両稼働率のような非ウェブ型 SLI が実践されている。** ウェブサービスではエンドポイント（決済 API 等）ごとにレイテンシ SLO を分けて「ブレないように」設定するのが一般的だが、モビリティサービスでは「車両が壊れている・壊れていない」ではなく、全体のうち何台が稼働しているかを分母に SLI を構成する例がある。SLO が「リクエスト駆動サービスの指標」を超えて物理世界のオペレーション指標へ拡張されつつあることの実務的証言である。 - 根拠: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]]（Q&A） - **IoT 領域では CUJ の代わりに CMC（Critical Machine Communication）が SLI 設計の起点になる。** 電動キックボード・電動アシスト自転車という物理デバイスを対象に「マシンが期待通りに動作できる状態であるか」を測定する CMC という概念が作成された（CUJ と区別するための用語）。計測対象は定期通信（MQTT/LwM2M）の応答や通信途絶、ハードウェアエラーなど。「現実世界に染み出してくるともっと面白い SLI が出てくる」という方向を、実際の CMC 概念と IoT 自動サービスアウト実装として具体化した事例と読める。SRE Workbook の CUJ 定義（「あるユーザーの体験の中核部分となるタスクの並びで、サービスのきわめて重要な側面」）を物理デバイスに拡張した場合、計測対象がアプリリクエストからデバイス通信に切り替わる。 - 根拠: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] - 根拠: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **可用性・レイテンシ SLO だけではデータ集約型サービスのステークホルダーが関心を持たない。** Booking.com では検索サービスに可用性・レイテンシ SLO を設定しても開発・ビジネスステークホルダーは無関心だった。彼らが気にするのはデータの一貫性・新鮮性・完全性・耐久性であり、これらを「データ品質 SLO」として計測・目標化するまでは SLO が意思決定に使われなかった。可用性・レイテンシは「サービスが動いているか」を示すが「正しいデータを返しているか」は示さない（[[データ品質SLO]]）。 - 根拠: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] - **SLO が明確に定義されると自動緩和・自動修復の根拠が生まれる。** Booking.com では Freshness Probe が新鮮性 SLO 違反を検知した際にトラフィックを自動停止し（自動緩和）、Completeness Probe が欠損を検知した際に Hadoop スナップショットから再処理する（自動修復）ことで、SLO が単なる監視指標から自動化アクションのトリガーへ進化した。SLO 導入の最大の恩恵として「Awareness（可視化）」と「Confidence（行動根拠）」が挙げられた。 - 根拠: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] ## SLOのステークホルダーと合意形成 ### ユースケース別のSLOモデル - **SLO の 4 ユースケースはプロバイダ・コンシューマで優先項目が異なり、単一の SLO では全てに対応できない。** Ongoing（日常の管理）/ Design（設計時の期待設定）/ Incident Response（インシデント時の影響評価）/ Bounding the Tail（テール事象の管理）という 4 ユースケース×プロバイダ/コンシューマのマトリクスが提示された。例えば Incident Response ではプロバイダは「問題の大きさを把握したい」、コンシューマは「依存先が問題を認識して修復してほしい」という互いに似て非なる優先順位を持つ。この差異を無視した単一汎用 SLO はいずれのニーズも中途半端にしか満たさない。 - 根拠: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - **SLI/SLO モデルは「信頼性の測定」ではなく特定の問いへの回答モデルであり、ステークホルダーごとに問いが異なる。** オンコールエンジニア（1 分窓/1 SLI）〜 CEO（>1 年窓/1,000 SLI）という 5 つの問いを挙げ、それぞれが時間窓・対象 SLI 数で全く異なる空間を占めることをバブルチャートで示した。Richard Hamming の「コンピューティングの目的は数字ではなく洞察だ」という引用を持ち出し、単一の SLO 集計がどの問いにも等しく答えられるわけではないことを強調する。「問い先行・モデル後続」の原則は、顧客単位 SLO やユーザー幸福定義と同じ方向を持つが、分解軸が「ステークホルダーの認識目的」である点で新しい切り口を加える。 - 根拠: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] - **同一 SLI を異なる時間窓で評価することで 3 つのステークホルダーペルソナに対応できる。** SRE/Ops（24h/48h）・開発チーム（14D/2W）・アーキテクト/リーダーシップ（Monthly/Quarterly）という 3 ペルソナ別の時間窓が提案された。「5 つの問いの空間」をバブルチャートで示した知見を、実装可能な時間窓マッピングとして具体化した実践的解釈と読める。5 ペルソナ（オンコール〜CEO）を実務的な 3 カテゴリに整理し直した形でもある。 - 根拠: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] - 根拠: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] - **SLI/SLO/SLA の 3 次元（Code・Infrastructure・CX）はそれぞれ適切な SLA 時間窓が異なる。** Code は 28 日間・Infrastructure は 24 時間・Business & CX は 8 時間という事例がある。この差は各次元のビジネスインパクト即時性を反映しており、CX が最も短い。Booking.com がデータ品質 SLO を可用性 SLO と別に設定した事例と同様に、次元ごとに SLO の性質（評価指標・時間窓・SLA アクション）が異なることを示す。SRE Workbook の SLO 文書化では時間窓を明示することが求められており、次元別に最適時間窓を選ぶというフレームがそこに加わる。 - 根拠: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] ### ユーザー体験とのギャップと対応設計 - **「SLO を満たしているのに悲しいユーザー」が存在する状態（共感ギャップ）は、SLO 設計の根本的な失敗を示す。** 2×2 マトリクス（Failing/Meeting SLO × Sad/Happy user）では、「SLO 達成・ユーザー不満」セルを「Empathy gap」と命名し、SLO がユーザーの痛みのしきい値より高く設定されている（ユーザーが感じる閾値よりゆるい）場合に発生すると説明する。「SLO を公表しないと現状性能への無言の期待が生まれる」と指摘した問題とは別軸——こちらは SLO 目標値そのものがユーザー体験から乖離している問題である。 - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] - 根拠: [[@2016__SREcon16__Service Levels and Error Budgets]] - **SLO の目標値は S 字曲線で特定した痛みのしきい値より下に設定する。** 可用性（横軸）対ユーザー幸福度（縦軸）の S 字曲線を用いて、B2B ツール Tenfold の例で SLO 99.95% が "tolerable" ゾーンの上限にあることを示した。S 字の屈曲点（"We're paying how much?!?!" ゾーンの開始点）が痛みのしきい値であり、SLO はそれより下——つまりユーザーが不満を感じ始める前の水準——に設定すべきだとする。SRE Workbook の「ユーザーが気にする SLI を選ぶ」原則に「目標値を S 字で決める」という操作手順を加えた実践的拡張と読める。 - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - **ユーザー行動ベース SLI は技術的エラーシグナルと独立してゲーミングを補足できる。** CX 次元の SLI として「10 秒以上経ってから 5 分以内に再試行された患者検索」が定義された。この SLI はサーバーエラーが発生していなくても（HTTP 200 でも）ユーザー不満を検知でき、技術指標の SLO を満たすながら CX が悪化しているシナリオを露出する。「SLO 達成・ユーザー不満（共感ギャップ）」を検知する実装上の解の一つであり、データ品質 SLO（可用性 SLO では見えない「正しいデータを返しているか」を計測）と同様に、単一次元 SLO のカバー不足を補完するアプローチである。 - 根拠: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] - 根拠: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]] - **SLO Rationale をユーザー行動データで根拠づけることが「SLO を技術閾値から顧客観察結果」へ変換する最短経路である。** SLO Policy は "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale を一行添え、技術閾値が顧客行動指標と結びついた根拠を持つことを示した。S 字曲線は「ユーザーが痛みを感じる閾値を特定してから SLO を設定する」手法を示したが、Stanke はその結果を SLO Policy ドキュメントの Rationale フィールドとして記述する形式を具体化した。SLO の目標値を「技術的最良実践」ではなく「ユーザー行動観察に基づく設計判断」として文書化する最も直接的な実装例である。 - 根拠: [[@2020__SREcon20Americas__Squish Level Objectives]] - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] ### SLO文書化と合意形成のプロセス化 - **SLO は合意形成プロセス（交渉スキル）として設計する必要がある。** 「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」という反復的交渉フローが提案された。SLO を技術的に「正しい値を計算する」問題ではなく、リスク許容量・期待境界・戦略を事前に把握したうえでのステークホルダー交渉として扱う視点は、SRE Workbook の「ステークホルダー合意」をプロセス論として展開したものと読める。RECUR という反復要素が入っているのが重要で、SLO は一度合意すれば終わりではなく、継続的に再交渉されるものとして設計される。 - 根拠: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] - 根拠: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] - 関連: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]] — 営業チームとの共感ギャップへの処方箋と重なる ### SLOモデルの限界と批判 - **「エラー認識は人間のゲシュタルト的判断に依存するため SLO は実現不可能（not feasible）」という根本批判が 2022 年に明示された。** 「SLO requires recognized errors」と述べた上で、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータ（shallow data）」にとどまると主張する。これは自身の 2019 年発表（SLO の暗黙的仮定批判）と 2021 年発表（Goldilocks Reliability 批判）を踏まえ、「SLO そのものが計測ツールとして根本的に不完全」という結論へ進んだ最も強い批判形である。SLO を段階的改善の対象として論じる多くの先行ソースとは立場が異なる。 - 根拠: [[@2022__SREcon22Americas__Principled Performance Analytics]] - 根拠: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - 根拠: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]] - **実務者はすでに SLO ウィンドウと目標値を無視したアドホックモデルを構築している。** インシデント対応中のオンコールエンジニアが「緩和後の SLI が SLO 以上かどうか」を見ると言いながら実際には 15 分という恣意的な短窓を使い、SLO ウィンドウも目標値も参照していないことが赤注釈付きスライドで示された。SLO の「時間窓・目標・評価頻度の 3 自由パラメータ」が現場では全て無視される場面があることを意味し、「直感的アドホックモデルの形式化こそが次のステップ」という論旨の出発点となる。MTTx メトリクスが実際の意思決定に使われていないことを O'Reilly レポートで示した流れの続編として読める。 - 根拠: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] - 根拠: [[@2021__OReilly__Incident Metrics in SRE]] - **SLO モデルは時間・空間で線形性を仮定しており、集約によって深刻な問題を隠蔽する。** 「1,000×1 分停止 = 1×1,000 分停止」という SLO の時間線形性問題と、「一部ユーザーへの完全障害 = 全ユーザーへの軽微な障害」という空間線形性問題が示された。後者は「Your nines are not my nines」問題（顧客単位 SLO の動機）と接続するが、「ユーザーへの完全障害がグローバル集計では検知不能になる」ことを US-West/US-East→User ヒエラルキーの合成ヒストグラムで視覚的に示した点が新しい。「集計は深刻な問題を隠す」という共通の限界が複数ソースで記録され、信頼性測定の根本的構造問題として浮上する。 - 根拠: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] - 根拠: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] - 根拠: [[@2020__NSDI__Meaningful Availability]] ## SLO導入の組織的定着 ### 導入の失敗要因と前提条件 - **SLO 導入の失敗要因が「技術」より「組織・人・プロセス」であることは複数のソースで独立に確認されている。** Takamura は「SLO 採用は社会技術的問題」と明示し、Durst は 4 度の失敗事例でオブザーバビリティ基盤が揃っていても所有権・標準プロセス・保護時間がなければ SLO は定着しないことを示した。Smith が「営業チームへの暗順応期間」を指摘した文脈と合わせると、SLO 導入の障壁は測定技術ではなく組織横断の調整コストにあるという観察が SRE 実務コミュニティの共通認識になっていると読める。SRE Workbook の「ステークホルダー合意」をプロセス論として実装するのが Coulter の交渉フローであり、それに先んじる「前提条件診断」が Durst の 4 条件チェックリストとして体系化された。 - 根拠: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] - 根拠: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]] - 根拠: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] - **SLI/SLO の「定義・観察」と「Error Budget Policy に従って行動する」は別の困難として分離して管理する必要がある。** 2 プロダクト 15 チームへの SLI/SLO 導入（定義・観察）には成功したが、SLO 違反時のアーキテクチャ変更・インフラ分離といった根本対処まで至らなかった失敗が報告された。失敗の根本原因は「測定・観察の文化不足」ではなく「非機能要求への予算・権限が開発チームになかった」という組織的制約であり、技術戦略グループの発足と予算配分（新規:エンハンス:技術的負債 = 1:1:1）という制度的変更が解決をもたらした。Durst が 4 前提条件（所有権・標準プロセス・保護時間・SLO 計測基盤）を導入前に確認すべきと論じた観点に「非機能要求の予算配分権限」という第 5 の前提条件が加わる。 - 根拠: [[@2022__SRENext2022__Who owns the Service Level?]] - 根拠: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] - **SLO の組織的導入には非技術ステークホルダーの「暗順応期間」が必要である。** Campspot での SLO 導入事例で、技術チームが SLO の考え方に馴染んだ後に営業チームを SLO ワークショップに招いたところ「Uptime 99.999% の話ではないのか」と混乱が生じたと報告した。人間の瞳孔が明所から暗所に順応するのに 30 分を要するように、「可用性 = 稼働率」から「良い体験の割合」への認知的転換には準備期間が必要であり、SLO 実装の前に非技術ステークホルダーとの「Adjust」フェーズを設けるべきだったとする。SRE Workbook の「ステークホルダー合意」プロセスと Case Studies の知見はこの問題の解を含むが、営業チームという SRE 文脈で見落とされがちなステークホルダーを名指しした点で実践的に重要。 - 根拠: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]] - 根拠: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] ### 段階的定着のパターン - **SLI/SLO の組織導入には「定義・運用・定着」3 つの難点があり、段階的アプローチが有効である。** SLI/SLO を最初から完璧に作ろうとすると合意形成・追加計装に時間がかかり形骸化しやすい。SRE 自体の 4 ステップ導入法（小さく始める→チームを支援する→スケールする→データドリブン思考を具体化する）を SLI/SLO 導入に転用し、SLO 違反ポリシーを Level1（何もしない）から Level5（意思決定に組み込む）へ段階的に拡大する方法が体系化された。定義・運用・定着をそれぞれ 5 段階成熟度モデルで評価することで、現在地の対話起点として使える（[[SLI-SLO段階的導入]]）。 - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] - **「仮値から始めてフィードバックで洗練する」アプローチが SLO 定着の共通パターンとして独立に確認される。** 「SLI と仮値を決めて見直しフローを作り、まずとりあえず始めた」という報告に加え、「小さく始める」4 ステップの体系化、4 前提条件確認後の段階的導入、「翌日障害でエラーバジェット枯渇したが許可証として即座に機能した」という報告がある。3 社 4 名の実践者が独立に「完璧な値を追い求めず動かしながら修正する」を成功の起点として選んでいる——これは SLO 導入の技術的困難（SLI 設計の難しさ・ステークホルダー合意）より「動かした実績が合意を作る」という組織的ダイナミクスを優先した判断と読める。 - 根拠: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] - 根拠: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] - 根拠: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]] - **Enabling SLO の組織的アプローチとして「習熟度調査→勉強会→Lead 直接コミュニケーション」が有効である。** Luup SRE チームは「開発者・PdM に SLO を伝導・導入する」ために、まず SLO 習熟度調査（14 問、エンジニア＋PdM 対象）で現在地を把握し、その結果をフィードバックして構成した SLO 勉強会（背景・SLI/SLO 基本・Luup SRE の運用状況の 3 部構成）を実施した。特定チームには Embedded SRE の代わりに Developer Lead との直接コミュニケーションで導入を進めた。「小さく始める 4 ステップ」と並び、SLO の組織横断定着を「知識普及→個別導入」の二段階で設計した実践事例として記録される。 - 根拠: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] ### 定着を後押しする組織的動因 - **エラーバジェット起点のコードフリーズ RFC を経営承認まで通したことは、SLO 定着の到達点が小規模スタートアップでも到達可能であることを示す。** GCE や Zendesk の大規模組織での SLO 成熟と同じゴール（信頼性が組織の意思決定に組み込まれた状態）を、Spring Health（200 名エンジニア・8 SRE）が達成した。「定着 Lv5」は大組織の話として受け取られがちだが、ハイパーグロース・スタートアップでも 3 年間（Attempt #1: 2022 → 成功: 2025）で到達可能であることが実証された。 - 根拠: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] - 根拠: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] - 根拠: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] - **SLO 定着の最速経路として「CEO 強制の OKR 接続」が有効である。** SLO 導入失敗の主要因が「組織・人・プロセス」であることは複数ソースで確認されている。Riot Games はこれを「CEO が会社レベル OKR を強制する」という最強の手段で突破した。同時に「CTO スポンサー」「グラスルーツ（テックリード層）」「スタジオリード向け幹部トレーニング」という三層も機能しており、トップダウン単独では組織定着が難しいことを示唆する。 - 根拠: [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] - 根拠: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] - 根拠: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]] - **SLO を PO（プロダクトオーナー）が使う主動機は「チームで判断を回す」ことである。** Mackerel の SLO 導入動機を「判断と改善をチームで回したい」と明示した。PO が信頼性に関わる技術的判断を個人で担う代わりに、SLO という数値基準でチームが自律的に判断できるようにする——判断が減ることが PO にとっての嬉しいポイントと述べた。SRE Book が SLO を「開発チームと SRE の共通インセンティブへの変換」として位置づけた方向の延長だが、PO という「ビジネス側の意思決定者」も受益者になるという視点を実践ベースで追加する。「SRE が No から Yes/if へ転換する」という帰結が、PO 視点では「PO の判断依頼が減る」という形で発現する。 - 根拠: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - 根拠: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]] - 根拠: [[@2016__SREcon16__Service Levels and Error Budgets]] - **SRE Book 著者が「SLO を公表しないと現状性能への無言の期待が生まれる」と明示した。** SLO を公開しないサービスではユーザーが「今の性能が永遠に続く」と期待し始め、将来の設計変更・コスト最適化の選択肢が失われると口頭で警告した。書籍第 4 章でも言及されているが、SREcon16 ではこれを「SLO を公表する最初の理由」として最初に挙げた。なお対処として「意図的なダウンタイムを入れるシステムが Google に実在する」と述べ、過達成（over-achieving）が引き起こす期待インフレへの組織的対処を明かした。 - 根拠: [[@2016__SREcon16__Service Levels and Error Budgets]] - 根拠: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] ### 合意形成の基礎付け - **SRE Workbook は SLO を「測定指標」から「運用意思決定システム」へ拡張する。** Implementing SLOs は、SLI を「良いイベント数 / 全イベント数」として設計し、ユーザーに意味のある SLI 仕様と、ログ・ロードバランサ・ブラックボックス・クライアント計装による SLI 実装を分ける。さらに SLO 文書、ステークホルダー合意、4 週間ローリングウィンドウ、継続改善、エラーバジェットポリシー、アラートルールまでを一体で扱う。Example Game Service は、可用性・レイテンシだけでなく、データ鮮度・正確性・完全性を SLO に含め、SLO がサービスのユーザー体験モデルを文書化する器であることを示す。 - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - 根拠: [[@2018__Google SRE Workbook__Appendix A Example SLO Document]] - **SLO は外部組織で「開発対運用」の主観対立をデータ対話へ変える。** Evernote と The Home Depot の導入事例を通じ、SLO が Google 内部の用語にとどまらず、運用チームと開発チームの品質判断を共通メトリクスへ寄せる道具になることを示す。SRE Book が原則を定義し、Workbook が顧客信頼性エンジニアリング（CRE）を通じた導入パターンを示したことで、SLO は「Google 固有の運用慣行」から「組織間で移植可能な合意形成プロセス」へ移った。 - 根拠: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] - **「信頼性の 3 原則」は SLI/SLO 設計の前提として 2019 年に実践者視点から整理された。** [[Alex Hidalgo]] は信頼性スタック（SLI→SLO→エラーバジェット）の導入前に「3 原則」を置いた——(1) 信頼性がサービスにとって最も重要な特性である、(2) ユーザーが「信頼できる」とはどういうことかを決める、(3) どんなものも常に動き続けるわけではないので目標にするな——。SRE Book が「99.9% の可用性」の計算から始めるのに対し、Hidalgo は「なぜ SLO を作るのか」という動機の合意を最初に求めた。Squarespace ELK の SLO（99% / 5 分以内）は 1 日後の障害でエラーバジェット枯渇が宣言できたことで、「組織的に信頼性対応を優先する許可証」として即座に機能した。単一コンポーネント障害の対応をやめ「ELK 全体の全力修復」に入れたのは、SLO + エラーバジェットという仕組みがあってはじめて組織内で正当化できた。 - 根拠: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]] - **信頼性をユーザー主語で定義することが SLI 選択の出発点になる。** O'Reilly SLO 本を引用し「ユーザーの期待に沿っているか」を信頼性の定義として採用した。レイテンシ・エラー率という技術指標から出発するのでなく、ユーザーが感じる信頼性から逆算して指標を選ぶ動機付けとして機能する。S 字曲線でユーザーが痛みを感じる閾値を特定して SLO を設定する原則と同方向であり、SRE Book の「ユーザーが気にする SLI を選ぶ」原則をチームが腹落ちする前提として機能する。Mackerel では外形監視で「サービスに到達できない状態が正しい挙動」になる場合もあるという特殊ケースが示すように、ユーザー主語の定義はサービス固有の難しさも露出させる。 - 根拠: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - 根拠: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] - 根拠: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] ## SLA/SLOの理論的定式化とリスク分担 ### リスク分担と統計的思考への転換 Mogul+Wilkes は SLO 定義の困難さを統計学的意思決定（仮説検定・サンプリング・推論手法選択）との同型性として捉え、「法律家的思考から統計家的思考への転換」を提唱する (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]): - **SLE（サービスレベル期待）**: プロバイダが通常条件下で顧客に期待させる挙動。結果保証ではなく期待管理。 - **CBE（顧客挙動期待）**: プロバイダが SLE を満たすために前提とする顧客側の挙動。統計多重化に伴う不確実性を SLO 枠組みに内在化させるための仕組み。 - 「SLOgician」という専門職の必要性——統計家と同様の謙虚さ（不確実性下での限界認識）が不可欠と論じる。 - **「法律家から統計家へ」の転換は AIOps エージェントの保証契約設計に直結する。** [[エージェント運用安全性]] の assurance contract / verification wall の語彙と、SLE/CBE のリスク分担枠組みは「契約 = 期待 + 帰結」という点で同型であり、agentic SRE の安全仕様（[[Transactional No-Regression]]）に SLE/CBE 的な双方向期待管理を載せることが自然な拡張方向だ。 - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - **「証拠(SLI/SLO)が結論(SLA)を後押しするようにする」という定式化は、Mogul+Wilkes の「法律家的思考から統計家的思考への転換」を大企業向けの一言に圧縮したものである。** SLO/SLI がビジネスコミットメントによってその正確さ・妥当性を左右されないようにし、あなたの理論をサポートする都合の良いデータポイントを選ぶのでなく顧客が何を望むかを理解するために時間を費やすべきだとし、「証拠(SLI/SLO)があなたの結論(SLA)を後押しするようにする」と要約する。SLA という結論を先に決めてから SLI/SLO を後付けで揃える（法律家的思考）のではなく、SLI という一次データから SLO・SLA を導出する（統計家的思考）という順序の逆転を、学術論文が抽象的な専門職概念で述べたのに対し、実務書は一文に凝縮して大企業の意思決定者へ届けている。 - 根拠: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]] - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - 留保: 再検証 2026-09-11 — 両出典は各半分(SLI から始め証拠が結論を後押しする / 法律家的思考から統計家的思考へ)を個別に述べるだけで、前者が後者を「圧縮したもの」だという対応づけはどちらにも無い。対応づけは wiki 側の解釈であり、両者が同じ順序の逆転を述べるという読みとして扱う。 ### 可用性への「セキュリティ的思考」 大規模インフラストラクチャの可用性にはセキュリティと同様の「敵対的思考」が必要と主張される (Source: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]): - スレットモデリング: 障害の脅威モデルを明示化する。 - 深層防御: 単一のメカニズムに依存しない。 - フェイル・スタティック: 依存先が停止しても直前の状態で継続動作する（セキュリティの「デフォルト拒否」に相当）。 - Wheel of Misfortune: SRE のインシデント訓練をペネトレーションテストの類似と位置づける。 - 素朴なサブシステム SLO 分解（確率の積算等）は依存関係の相関を見落とし誤りを生む。 ### SLO拡散と分解の自動化 マイクロサービスパイプラインにおいて高レベル SLO（応答時間・顧客満足度等）を自動的に低レベル SLO とパラメータ割り当てへ分解する 3 ステップ方法論が提案される (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]): 1. マイクロサービスパイプラインのベイズネットワークモデル化。 2. 条件付き依存関係に基づく SLO 制約伝播。 3. 矛盾検知と自律的解決。 評価では複数パイプラインで SLO 達成率 83〜100% を達成し、許容範囲パラメータ λ の過度な厳格化と SLO 間のコンフリクトが充足率を急激に低下させるリスクを定量化した。 - **コンポーネント別 SLA による手動 SLO 分解(原著 2018 年)は、SLO 拡散(2024 年)が自動化しようとした問題を 6 年先取りする。** メッセージ配信サービスの 4 コンポーネント（データレシーバー→データトランスフォーマー→ディストリビューター→コンシューマー）それぞれに独自の通過時間 SLI を割り当て、入力/出力比を実験的に測定して伝播するトラフィック量を近似し、性能・エラー・通過時間という 3 基準を同時に満たす最大スループットとしてブレイクポイントを手作業で特定する手順が示された(§9.2)。これは、[[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines|Sedlak+]] がベイズネットワークモデル化・条件付き依存関係に基づく SLO 制約伝播・矛盾検知という 3 ステップで自動化しようとした問題と同型である。「入力/出力比の実験的測定によるトラフィック近似」は「条件付き依存関係に基づく制約伝播」の手動版に相当し、「ブレイクポイントに基づくボトルネック特定」は Sedlak+ が自動検知しようとする「コンポーネント間のSLOコンフリクト」と同じ現象を指す。6 年の間隔を置いて、同じ問題が「実務者の手作業手順」から「機械学習パイプラインの自動化対象」へ移行した。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.2 - 根拠: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - **異常検知システムは SLO 違反を検知トリガーとして流用するが、粒度はアプリケーション全体にとどまる。** CauseInfer・Microscope・ε-diagnosis という 3 つの異常検知システムが、フロントエンドサービスの応答時間/テールレイテンシを SLO 宣言値と比較し、違反があればアプリケーション全体を性能異常と判定する実装が報告される(§3.3.3)。これは、ハードシャードでは全体集計 SLO が障害を隠蔽する・集約 SLO は個別顧客の完全障害を隠すという SRE 実務論と同型の限界を、異常検知システムの設計としても持つことを示す。SLO をサービス単位・顧客単位に分解する SRE 側の解法（per-shard SLO・顧客単位動的ターゲット）と、SLO 拡散によるサービス単位分解は、異常検知の粒度不足を解消する潜在的な橋渡しになりうる。 - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]] - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] - 根拠: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] - **ε-diagnosis の小ウィンドウ・テールレイテンシ SLO check は、パーセンタイル集約不能性への一つの回避策として読める。** データストリームを 1 分/1 秒という小さなウィンドウへ分割し、ウィンドウごとにテールレイテンシを計算して SLO しきい値と比較する(§3.3.3が要約)。「時間ごとのパーセンタイルを平均すると全体分布のパーセンタイルとずれる」問題を、集約せず小ウィンドウ単位で判定することで回避する設計であり、オンコールエンジニアの実務として観察された「SLO ウィンドウ・目標値を無視した 15 分程度の短窓アドホック判断」を、システム側で形式化した実装と位置づけられる。 - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] - 根拠: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]] ### カーボン認識SLO管理 CASCA はマイクロサービスアーキテクチャ原則に基づき、コンピューティングコンティニュアム環境でプロバイダのプライバシーを保護しながら SLO を充足するプラットフォームを実装する (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。EMMa マイクロサービスを通じてカーボンフットプリントを報酬関数に組み込み、SLO 充足とサステナビリティの両立を図る。宣言的設定管理（設定ファイル修正 + コンテナ再起動）は命令的手法比で約 53.7 秒の短縮を実現し、SLO の動的変更コストを低減する。 - **SLO とサステナビリティの緊張関係が浮上する。** FPS SLO 充足率ではカーボン非認識の貪欲方式（90.6%）に劣る（RLDS: 85.2%）が、カーボンフットプリントでは最良（72.4 vs 74.9 mgCO₂/分）。性能 SLO とサステナビリティ SLO のトレードオフは AIOps の既存 4 段タクソノミ（検知→箇所特定→RCA→緩和）に「コスト/持続可能性」という第 5 の軸を加える可能性がある。 - 根拠: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]] ### SLO代数と設計思想の対立 - **SLO 代数（SLO Algebra）はいまだ未解決の重要課題である。** 複数のダウンストリームサービスを消費する上位サービスの SLO を、依存先の SLO から分析的に導出する体系的手法が存在しない。「現状の最良は桁でパッドするだけ」という指摘は、「素朴なサブシステム SLO 分解は相関を見落とす」という警告と同じ問題を別角度から指摘している。依存関係の直列/並列消費パターン・フェイルオープン/クローズド動作を考慮した代数的枠組みの確立は、SRE 分野の未解決課題として残っている。 - 根拠: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - 根拠: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - **「SLO Algebra は未解決」という課題に、McGhee（SLOconf 2021）は集合論の語彙で具体的な合成式を与えている。** 「依存関係の直列/並列消費パターンを考慮した代数的枠組みが存在せず、現状の最良は桁でパッドするだけ」という指摘に対し、McGhee は intersection availability（全依存が必須、SLO^depth）と union availability（いずれか 1 つで十分、1-(1-SLO)^redundancy）という 2 式を提示する。これは『SLO サービスレベル目標』9 章がベルヌーイ試行から導いた「2 拠点独立フェイルオーバーでは各拠点の SLO はフロントエンド要求より 2 桁緩くてよい」という結果の一般化に相当する——2 拠点独立フェイルオーバーは union availability で redundancy=2 とした特殊ケースであり、両ソースの数式は同型である。ただし McGhee 自身も「各試行が真に独立」という前提が崩れる（ネットワーク・ロードバランサーのような共有依存）ことを bottleneck の主要因として明示しており、「素朴なサブシステム分解は相関を見落とす」という警告は解消されていない。SLO Algebra は「独立性を仮定すれば」定式化されたが、依存の相関（shared fate）をモデルに組み込む部分は依然未解決のまま残る。 - 根拠: [[@2021__SLOconf__SLO Math]] - 根拠: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] - 根拠: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 9 SLIとSLOの確率と統計]] - 根拠: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - **「ナインを積み上げる」という素朴な信頼性モデルと「集約可用性」モデルは、SRE Book 以前から対立する 2 つの設計思想として存在していた。** McGhee は component-level reliability（各コンポーネントを完璧に保ち total availability を目指す正三角形）と scalable reliability（下層ほど信頼性が低くてよい逆三角形、aggregate availability が目標）を対比する。この対比は、「MLE・MAP 推定で事前分布を強く設定しすぎると障害を見逃す」という統計的リスクとは異なる軸——「設計段階でどちらの信頼性思想を採用するか」という建築的選択——を扱っており、[[信頼性スタック]] の「resilience via engineering（信頼性の低いものの上に信頼性の高いものを構築できる）」という発想の直接の起点になっている。 - 根拠: [[@2021__SLOconf__SLO Math]] ### SLA/SLOの当事者区分と歴史的系譜 - **SRE Book が SLI/SLO/SLA の実践的定義を最初に体系化し、メトリクスの進化に 10 年の系譜がある。** SLI を定量的サービス計測、SLO を SLI の目標値、SLA を帰結付き契約と 3 段階で定義し、「パーセンタイルを使え、平均は使うな」「測りやすさでなくユーザー優先度でメトリクスを選べ」「完璧を求めるな、エラーバジェットを維持せよ」の 3 原則を提示した。Mogul+（2017）が可用性定義の困難さを提起 → Mogul+Wilkes（2019）が SLE/CBE で期待管理への転換を提唱 → Hauer+（2020）がウィンドウ付きユーザーアップタイムで三要件を同時に満たす指標を G Suite 本番で実証、という系譜が見える。3 本を並べると「何を測るべきか」→「どう約束すべきか」→「どう測るか」の 3 段階が見え、指標設計はいまだ探索段階にある。 - 根拠: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - 根拠: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - 根拠: [[@2020__NSDI__Meaningful Availability]] - **高レベル SLO の自動分解と可用性指標は相補的である。** ウィンドウ付きユーザーアップタイムが「何が起きたか」を測り、SLO 拡散方法論が「何を設定すべきか」を決める。前者は事後的な計測、後者は事前的な制約伝播であり、両者をフィードバックループで結ぶことで SLO 管理の閉ループが構成できる。 - 根拠: [[@2020__NSDI__Meaningful Availability]] - 根拠: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - **SLA は「設計段階で組み込む制約」として 2007 年に位置づけられていた。** Hamilton は SLA を可用性メトリクスの議論以前に、サービス設計の酸性試験（acid test）として定義した——「任意のサーバをいつでもワークロードのドレインなしに停止でき、かつ SLA を満たせるか」。Mogul+（2017/2019）が SLO/SLE の測定・約束の難しさを論じたのに対し、Hamilton（2007）は SLA を同期冗長と自動フェイルオーバの設計判断の帰結として扱う。測定の精緻化（Hauer+ 2020）と設計段階での SLA 組み込み（Hamilton 2007）は相補的な視座である。 - 根拠: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] - 根拠: [[@2020__NSDI__Meaningful Availability]] - **DDIA 2E(2026) は SLO/SLA を「SLO + 違反時の帰結 = SLA」という一般読者向け教科書の定式化で紹介しつつ、本 concept が蓄積した測定論の困難さを一文で予告する。** SLO を「中央値200ms未満・p99が1秒未満・99.9%が非エラー応答」のような具体例で導入し、SLA を「SLO 未達時の帰結（返金等）を定めた契約」と定義する。同時に「実務上、SLO・SLA に良い可用性指標を定義することは簡単ではない」と一文で釘を刺し、Mogul+Wilkes（2019）・Hauer+（2020）を参考文献に挙げる。教科書レベルの定義と、本 concept が蓄積した数十件の実務知見（集計 SLO の隠蔽問題・パーセンタイル平均化不能性・SLO Algebra 未解決問題等）との間には大きな詳細度の落差があり、DDIA の一文はこの落差そのものを読者に警告する役割を果たしている。 - 根拠: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Use of Response Time Metrics" - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - 根拠: [[@2020__NSDI__Meaningful Availability]] - **Hidalgo は SREcon19 EMEA の「信頼性の 3 原則」を、著書『SLO サービスレベル目標』1 章で「サービスの 3 つの真実」として再定式化した。** SREcon19 EMEA（2019）の 3 原則（信頼性が最重要の特性・ユーザーが信頼を決める・完璧を目標にするな）は、書籍 1 章では (1) 信頼性が最重要の運用要件である、(2) ユーザーからどう見えるかが信頼性を決める、(3) 完璧は存在せずコストは非線形に増大する、という「常に真実な 3 点」として整理され、信頼性スタック（SLI→SLO→エラーバジェット）を導入する土台に位置づけ直された（[[信頼性スタック]]）。口頭発表の原則が書籍で体系的な三層モデルの前提として明文化された事例であり、2 ソース間で表現は変わるが核となる主張は一貫している。 - 根拠: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]] - 根拠: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]] - **SLA が定式化する「違反時の帰結」モデルは、プライバシー「障害」には構造的に適用しにくい——不可逆性が SLO/SLA の枠組みの外側にある。** SLO を「SLI の目標値」、SLA を「SLO 違反時の帰結（返金等）を付した契約上の約束」（SLO + 帰結 = SLA）と定義してきたが、『SREの探求』15章は、この SLA モデルが前提とする「違反したら帰結（補償）で清算する」という発想が、プライバシーの「障害」には根本的に成立しないと指摘する——合意した SLA にサービスが違反しないようにすることとは異なり、プライバシーに関連する落とし穴のほとんどは「はまったが最後、後戻りはできない」。可用性が年間99%であればユーザーは満足しても、適切に処理されるユーザーデータが99%では満足しないかもしれないという非対称性を示す。信頼性の障害は元の稼働状態に戻すことで「修復」できるが、データベースからの情報漏洩を「修復」する方法はない。SLA が持つ「帰結による事後清算」という設計思想は、可逆な信頼性障害には機能するが、不可逆なプライバシー侵害には原理的に適用できない。 - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] §15.4 - **「SLA は外部・SLO は内部」という実務家の直感的区別は、SLE/CBE 枠組みと同じ分割線を、契約論ではなく当事者の数で引いている。** SLO+帰結=SLA という定式化に対し、Schlossnagle（『SREの探求』21章）は同じ区別を「SLA は二者以上の当事者が『合意』した SLO」「SLA は『外部の』複数当事者による合意、SLO は『内部の』単独当事者による目標」という、契約の有無ではなく当事者の数で言い換える。これは SLE（サービスレベル期待: 結果保証ではなく期待管理）が「プロバイダが内部で持つ期待」であるのに対し、SLA が顧客との外部合意である点と対応関係にあり、学術論文（HotOS）が「保証か期待か」という認識論的な軸で区別したのに対し、実務書は「単独か複数か」という当事者論の軸で同じ現象を捉え直している。監訳注はさらに「SLA 違反は契約不履行として裁判になりうるが、違反時の規定がなければそれは SLO にすぎない」と補足しており、「SLO+帰結=SLA」という等式に「帰結の法的強制力の有無」という判定基準を追加する。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1 - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - **時間量方式の欠陥(1日1億件のトランザクション例)は、Hauer+ が批判する「インシデント比」指標の欠陥と同型であり、5 年早く同じ問題を独立に指摘していた。** Hauer+（NSDI 2020）の「インシデント比（稼働分/総分）は任意のしきい値に依存し、大規模分散システムでは完全停止も完全稼働もほぼないため不適切」という批判に対し、Schlossnagle（2018年執筆）の「時間量(time quantum)方式」批判——1日1億件のトランザクションで、失敗が均等分散する場合（成功率99.998%）と30分間の利用ウィンドウに集中する場合（認識される稼働時間96.666%）とで顧客体験がまったく異なるにもかかわらず、同じ「99.9%稼働」という判定になりうる——は、「分」を計測単位とする点で同一の計測構造を持ち、同じ欠陥（トラフィックの疎密を無視する）を指摘している。ウィンドウ付きユーザーアップタイム（Hauer+）がこの欠陥への解決策として複数ウィンドウサイズでの最悪可用性を提案したのに対し、Schlossnagle はトランザクション方式との折衷（クォンタイルズ・オーバー・クォンタムズ）という異なる解決策を提案しており、同じ問題に対して独立に異なる処方箋が示された。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.2.1 - 根拠: [[@2020__NSDI__Meaningful Availability]] - **「SLA は外部・SLO は内部」という当事者数区分は、サードパーティ統合の現場では「ベンダーの SLA を鵜呑みにせず自社の SLI/SLO を持ち込め」という具体的な戦術に翻訳される。** Schlossnagle の当事者数区分は、Mercereau（『SREの探求』5章）が示すベンダー協働の実務でそのまま検証できる。5章は、ベンダーとの SLA を計算・定義するのは難しく「ベンダーの SLA を流用すればよいという単純な話ではない」とし、SRE は自社と同じ SLI・SLO をベンダーにも適用させ、可用性・性能について説明責任（accountability）を果たさせるべきだと述べる。外部当事者（ベンダー）が独自に定める SLA を無批判に受け入れると、内部（自社）の SLO 基準と乖離しうるという当事者数モデルの帰結を、契約交渉の具体的な行動指針（自社 SLI/SLO を持ち込んで交渉する）にまで落とし込んだものである。ベンダーの SLA が典型的には稼働時間 99.5%（未達率 0.5%）という比較的緩い水準にとどまる一方、自社が求める CDN スループットやログ処理レイテンシなど「特殊なニーズ」を満たす SLA は容易ではないとも指摘しており、SLA の閾値そのものが交渉可能な変数であることを示す。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] §5.2.3.2 - **9章の1分粒度・1年ローリングウィンドウ可用性計算は、21章が「時間量方式」に指摘する欠陥への、時期的に先行する独立した実務的回答である。** Schlossnagle（21章）は時間量方式の欠陥を「利用が1日を通じて均等に分布しないほとんどのサービスで、過剰な提供に陥るか利用者にとって無意味な保証になるかのいずれかに陥る」と定式化する。Legeza（9章、原著2018年）は全く同じ失敗モードを、ロードバランサー配下2台・10件のメッセージという小さな例で先取りする——1日単位の粗い集計では「15件中5件の障害」が可用性計算上「100% − (5/15 × 100) = 66.67%」という結果を生み、顧客には何の影響もないのに33.33%もの見かけ上の低下になる。Legeza の解決策は、時間量の粒度を1日から1分（利用可能なデータポイント間の最少の持続時間）まで細分化し、同じ例を1分粒度で再計算するとダウンタイムはわずか0.5分（日次可用性1,439.5分）にとどまる、というものである。さらに1年間のローリングウィンドウ（「昨日時点の稼働時間 − 昨年同日の日次稼働時間 + 本日の日次稼働時間」）により、いったん消費されたエラーバジェットが時間経過とともに回復可能になる。同じ「粗い時間量が可用性を過大に押し下げる」問題に対し、21章はトランザクション方式との折衷という測定方式そのものの再設計を提案するのに対し、9章は時間量方式の枠内でグラニュラリティとウィンドウ設計を調整するだけで同じ効果を得ており、診断は共通しながら解法のレイヤーが異なる。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.5 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.2.1, §21.2.3 - **SLA/SLO の「外部・内部」区別は、21章・5章に続き9章の独立した監訳注でも三重に裏付けられる。** 21章の監訳注は「SLAは外部の複数当事者による合意、SLOは内部の単独当事者による目標」という一般的区別を示し、5章はベンダー協働の実務でこの区別を検証する。9章の監訳注もまた独立に同じ点を指摘する——「一般にSLAとSLOの区別はユーザーに対する契約の有無であり、SLAにはその契約における規約が含まれる。本章の『SLA』は『SLO』と読み替えると一般的な定義に沿う」。9章本文は説明の簡略化のためSLAとSLOを交換可能な用語として扱うが、これは訳者側から見て一般的定義からの逸脱であり、9章が論じる「コンポーネント別SLA」（§9.2、顧客に開示されない内部合意）の大半は、契約を伴わない内部目標という点で本来は「コンポーネント別SLO」と呼ぶべき対象である。同一書籍内で異なる著者（Legeza, Mercereau, Schlossnagle）が各章で独自にSLA/SLOを定義し、監訳注がそのたびに一般的定義との差分を補正するという構造は、SLA/SLOという用語が実務家の間で厳密な合意なく使われている実態そのものを示す。 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.1.3 - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1 - **Burgess(2004)は「SLA」一語だけで、SRE Book(2016)のSLI/SLO/SLA三層化を待たずにMogul+Wilkes(2019)の「統計家的思考への転換」を先取りしていた。** *Principles of Network and System Administration* 第10章§10.8.1は、パケットサイズと到着率という独立な不確かさをピタゴラス和で合成し(`Δλ ≒ PΔr`)、SLAを「S ± ΔSをT間隔で保証する」という誤差論（theory of errors）に基づく統計的言明として定式化する。Mogul+Wilkes（2019）は「法律家的思考から統計家的思考への転換」「SLOgicianという専門職の必要性」を提唱したが、Burgess はその15年前に、SLA自体を統計的推定値として書くという同じ発想を数式レベルで実装済みだった。ただし語彙は「SLA」のみで、SLI/SLOという中間層は存在せず、Predictability（予測可能性）とDeterminism（決定論）の区別がSLI相当の役割を代替している。 - 根拠: [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] §10.8.1 - 根拠: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - **§10.10の9項目SLAチェックリストは、SRE Workbook Appendix A(2018)のSLO文書構成を14年先取りする骨格を持つが、資源配分をゲーム理論に外部化する点で異なる。** Burgess のチェックリスト（提供サービス・利用者の責務・体験から測定可能量への写像・監視方法・修復・見直し頻度・応答時間・セキュリティ・知的財産権）は、SRE Workbook の Example SLO Document（可用性・レイテンシに加えデータ鮮度・正確性・完全性を含む）と同じ「サービスのユーザー体験モデルを文書化する器」という役割を果たす。決定的な違いは、Burgess がSLAの数値そのものの導出根拠を同章§10.9のゲーム理論（競合か協調かで資源配分が変わる）に置いているのに対し、SRE Workbook 以降の文献は資源配分をエラーバジェットという運用ポリシーの言葉で扱い、顧客間の競合をゲームとして明示的に定式化する記述は本 concept の他ソースに見当たらない点である。SLAの前提となる「有限資源をどう分けるか」という問いに対し、2004年の教科書はゲーム理論という数理的な答えを与えていたが、その後のSRE文献はこの問いを主に組織的合意形成（Coulter 2020の交渉フロー等）として扱っており、数理的資源配分論と組織論という2つの異なる解法系譜が存在する。 - 根拠: [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] §10.9-10.10 - 根拠: [[@2018__Google SRE Workbook__Appendix A Example SLO Document]] ### AI・自律システムとSLOの将来像 - **セルフクラフト構想は SLO を「事業者が宣言する目標」から「利用者と AI が探索する均衡点」へ拡張する。** [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] は、2040 年代の個別化アプリケーションでは、信頼性・コスト・変更速度などの基本変量の均衡点を、利用者と AI が対話的かつ体験的に決めると描く。SLO を静的な契約値ではなく、短時間の劣化体験やコスト提示を含む探索プロセスとして扱う視点である。 - 根拠: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] - **なめらかなシステム構想では SLI/SLO がフィードバック循環から自動調整される。** 利用者・情報システム・開発運用者の 3 者間で AI エージェントがコンテキストを流通させ、深層学習の自動微分のようにパラメータが事後的に最適化されるモデルが提示された。この構想では SLI/SLO は人間が事前に合意して設定するのではなく、フィードバック循環から自動的に調整される。[[セルフクラフト]]の「利用者が信頼性目標を体験的に収束させる」構想と合わせると、SLO の主体が事業者から利用者+AI に移行する方向性が示唆される。 - 根拠: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] - 根拠: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] - **LLM による SLI/SLO 草稿生成は「仮値から始めてフィードバックで洗練する」という既存の組織定着パターンを技術的に加速する。** 渡辺・Takamura・Durst・Hidalgo の 4 者独立の知見が示す「完璧な値を追い求めず動かしながら修正する」という組織的成功パターンに対し、*Observability Engineering* 第 2 版第 11 章は、LLM（gpt-oss 20b・Claude Opus 4.6）がその「最初の仮値」自体の起草を高速化できることを実例で示す。EC チェックアウトの信頼性目標をコストへの疑問で追い込むと、両モデルとも five-nines から 99.95〜99.99% へ妥当な理由づけとともに自己修正した。ただし、OpenTelemetry セマンティック規約に基づく SLI 式生成では、内部スパン除外フィルタのような重要な条件を両モデルとも初期応答で省略しており、「LLM はドラフト生成器であり権威ではない」という注意が付される。これは Mat Vine のケーススタディにおける「標準化されたテレメトリへの早期投資が合意形成の時間を生む」という洞察と補完関係にあり、テレメトリ標準化（人間の先行投資）と草稿生成（LLM の加速）が SLO 導入の異なる律速段階を短縮する。 - 根拠: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] - 根拠: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] - **SLO は監視上の判定値にとどまらず、制御系の目標値として扱える。** 2002 年の Lotus Notes 論文は、キュー長をサービスレベル指標、基準キュー長を目標値、`MAXUSERS` を制御入力として閉ループを構成した。既存の SRE 文献が SLO の意味・測定・合意形成を主に論じるのに対し、この論文は SLO 達成を応答速度と安定性の設計問題へ接続し、測定遅延を精度と応答性のトレードオフとして定量化する。 - 根拠: [[@2002__Real-Time Systems__Using Control Theory to Achieve Service Level Objectives In Performance Management]] - 根拠: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] - 根拠: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] ## 未解決の問い - SLO を制御系の目標値として運用する場合、現代のサービスで制御入力にできるパラメータと、遅延を含む測定モデルをどのように安全に同定するか。 - ウィンドウ付きユーザーアップタイムは Google G Suite（プロダクティビティスイート）で評価されたが、マイクロサービスベースのクラウドインフラ（IaaS/PaaS）に直接適用可能か。IaaS ではユーザーの「リクエスト」を定義すること自体が困難では。 - SLO 拡散のベイズネットワークモデルは静的なパイプライン構造を前提とするが、動的にスケーリングするマイクロサービス環境でのリアルタイム更新は実現可能か。 - SLE/CBE 枠組みは概念的提案にとどまり、実装・評価は未着手。実際のクラウドプロバイダでの採用事例は報告されていない。 - SRE Workbook の「良いイベント数 / 全イベント数」型 SLI はリクエスト駆動サービスに適用しやすいが、ユーザー行動が断続的な低トラフィックサービスや非同期パイプラインでは、どこまで同じ形に正規化できるか。→ **部分的解決**: eBay（SREcon25 Americas）は可用性 SLI（SUCCESS / ABANDONED 比率）とレイテンシ SLI（累積 end-to-end histogram）の 2 種類で、Freshness・Quality・Throughput の 3 種類を代替できることを実装で示した。ただし「代替できる」根拠の数学的証明は論じられておらず、エラーバジェット代数と非同期パイプラインの依存構造にどう対応するかは未解決のまま(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 - CASCA のカーボン認識 SLO は小規模テストベッド（5 マイクロサービス）での評価にとどまり、大規模本番での有効性は未検証。 - 可用性への「セキュリティ的思考」の有用性は定性的に論じられているが、その適用がどの程度可用性改善に寄与するかの定量的評価は存在しない。 - 利用者と AI が対話的・体験的に決めた信頼性目標は、プロバイダ側の SLO 文書・エラーバジェット・SLA のどの層へ落とし込むべきか。個人ごとに異なる目標値を本番運用でどう集約するか。 - LLM 推論で TTFT・ITL・Goodput・Tokens/Dollar・出力品質を同時に SLO 化する場合、どの指標を契約上の SLA に上げ、どの指標を内部運用 SLO に留めるべきか。 - レイテンシ SLO の実装で近似ヒストグラムを使う場合、DD-Sketch や t-digest の近似誤差を SLO 達成率・エラーバジェット消費率へどう伝播させて説明すべきか。 - SLO アラート発火時に自動添付する情報は、どの粒度まで標準化できるか。パス別集計・ログ抜粋・依存先メトリクスを増やしすぎると、判断材料ではなくノイズになる境界はどこか。 - 集約インターバルを短くすると精度が上がるが、ノイズも増える。SLI/SLO 設計において最適な集約インターバルを決める基準は何か（サービス種別・リクエスト到着分布・CUJ の時間スケールなど）。 - クライアント側測定とサーバー側測定の乖離を定量化し、どちらを SLO に使うか判断する実践的な手順はあるか。 - ハードシャードシステムでシャード数が増えた場合（例: 数百シャード）、個々のシャード SLO を実際にどう追跡・報告するか。ダッシュボードの複雑性とオンコール負荷はどうなるか。 - 複合 SLO（複数 SLI の AND 結合）では達成確率が乗算で下がる。SLI を増やすほど合成 SLO が下がるが、ケイパビリティごとに何個まで SLI を設けるべきか設計上の上限はあるか。 - コアインフラ SLI 定義のために「上位サービス（顧客）へ聞く」プロセスは、コアインフラチームと開発チームの間にどう制度化されているか（レビュープロセス、頻度、担当者）。 - ユーザー幸福の 6 フレーバー（Availability/Responsiveness/Freshness/Completeness/Accuracy/Breadth）は exhaustive か。特に AI 生成コンテンツの品質評価（ハルシネーション率等）はどのフレーバーに分類されるか、または 7 番目のフレーバーが必要か。 - S 字曲線のしきい値をデータから特定する具体的手法は何か（アンケート、離脱率分析、サポートチケット数等）。データでユーザーの痛みを探すとだけ述べられており、手法は不明。 - 共感ギャップの発見と解消を組織として継続するプロセス（定期レビュー頻度、担当者、合意形成方法）はどう設計するか。 - SLX の SLF（Service Level Factor）と SLD（Service Level Dependency）を大規模サービスで全網羅的に定義・維持するコストは妥当か。高カーディナリティ爆発（コンテナ ID など）を避けながら調査に有用な粒度を維持する実践的な基準はあるか。 - SLX Graph を用いた「時系列相関のある異常 SLO 依存チェーン」の絞り込みは、相関 ≠ 因果の罠を引き起こさないか。検知（Detection）と根本原因分析（RCA）の責任境界をどう設けるか。 - CCU ベースのプレイヤー分計測はゲームサービスに特有のユーザー行動量計測だが、同様のアプローチをストリーミングサービス（視聴中ユーザー数 × 分）や EC（セッション中ユーザー数 × 分）へ拡張する場合、「アクティブセッション」の定義をどう標準化するか。 - SLO check ベースの異常検知（CauseInfer、Microscope、ε-diagnosis）はアプリケーション全体の判定にとどまるが、SLO 拡散（サービス単位への自動分解）や per-shard/per-customer SLO の発想を組み合わせれば、サービス単位の異常検知トリガーへ拡張できるか。既存の教師なし/教師あり学習ベースの異常検知（サービス単位で KPI をモデル化）と比べて、どちらが実装コストと検知精度の面で優位か。 - SLO 代数の体系化に向けて、依存関係の共有障害（shared fate）・フェイルオープン/クローズド挙動・直列/並列消費を数学的にどうモデル化するか。→ **部分的解決**: McGhee（SLOconf 2021）が intersection availability（SLO^depth）・union availability（1-(1-SLO)^redundancy）という合成式を示した。ただし前提は「各依存が独立」であり、共有障害（shared fate）・フェイルオープン/クローズド挙動・CBE（顧客挙動期待）枠組みとの統合は未解決のまま残る。独立性が崩れる実際のケース（ネットワーク・ロードバランサーの共有）をどう合成式に組み込むかが次の問い(Source: [[@2021__SLOconf__SLO Math]])。 ## 未編纂の観察 （現時点で保留する項目はない。次回 ingest 時にここへ追記する。） > [!note]- 編纂前の観察 2026-09 > - **SRE Book が SLI/SLO/SLA の実践的定義を最初に体系化した**: SLI を定量的サービス計測、SLO を SLI の目標値、SLA を帰結付き契約と 3 段階で定義し、「パーセンタイルを使え、平均は使うな」「測りやすさでなくユーザー優先度でメトリクスを選べ」「完璧を求めるな、エラーバジェットを維持せよ」の 3 原則を提示した。Mogul+ (2017/2019) の測定論、Hauer+ (2020) の指標設計はこの実践的基盤の上に構築されている (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 > - **メトリクスの進化に 10 年の系譜がある**: Mogul+ (2017) が可用性定義の困難さを提起 → Mogul+Wilkes (2019) が SLE/CBE で期待管理への転換を提唱 → Hauer+ (2020) がウィンドウ付きユーザーアップタイムで三要件を同時に満たす指標を G Suite 本番で実証。3 本を並べると「何を測るべきか」→「どう約束すべきか」→「どう測るか」の 3 段階が見え、指標設計はいまだ探索段階にある (Source: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]], [[@2020__NSDI__Meaningful Availability]])。 > - **高レベル SLO の自動分解と可用性指標は相補的**: Hauer+ のウィンドウ付きユーザーアップタイムが「何が起きたか」を測り、Sedlak+ の拡散方法論が「何を設定すべきか」を決める (Source: [[@2020__NSDI__Meaningful Availability]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 > - **SLO とサステナビリティの緊張関係が浮上**: CASCA は FPS SLO 充足率ではカーボン非認識の貪欲方式に劣るが、カーボンフットプリントでは最良 (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。 > - **「法律家から統計家へ」の転換は AIOps エージェントの保証契約設計に直結する** (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 > - **SLA は「設計段階で組み込む制約」として 2007 年に位置づけられていた** (Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2020__NSDI__Meaningful Availability]])。 > - **SRE Workbook は SLO を「測定指標」から「運用意思決定システム」へ拡張する** (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]], [[@2018__Google SRE Workbook__Appendix A Example SLO Document]])。 > - **SLO は外部組織で「開発対運用」の主観対立をデータ対話へ変える** (Source: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]])。 > - **Wilkinson（2018）は SLO を「工学的許容差（engineering tolerance）」と同型に位置づけた** (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 > - **生成 AI サービスでは SLI の候補が「応答の品質」へ広がる** (Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]) > - **セルフクラフト構想は SLO を「事業者が宣言する目標」から「利用者と AI が探索する均衡点」へ拡張する** (Source: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) > - **LLM 推論の SLO はレイテンシ・スループット・費用を同時に束ねる** (Source: [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) > - **レイテンシ SLO はパーセンタイル時系列ではなく、しきい値内の良いイベント比率として実装する必要がある** (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 > - **SLO 由来の Warning アラートには「原因をすぐ集める」運用層が必要になる** (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) > - **「高レベルサービス目標へアラートし、個別コンポーネントを調査可能に保つ」原則は SLO ベース呼び出しの前史である** (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]]) > - **Wilkinson 2017 は SLO ベース呼び出しの実装部品として、分布・人間の修復時間・Prometheus 記録ルールを先に置いていた** (Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]], [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]]) > - **SRE Book 著者が「SLO を公表しないと現状性能への無言の期待が生まれる」と明示した** (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 > - **SLI の測定点は「ロカス・オブ・コントロール」ではなく「ロカス・オブ・メジャーメント」を優先すべき** (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 > - **集約インターバルの選択がサービス動作の解釈を根本的に変える** (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 > - **SLO/SLI は機能別・ドメイン別に分けて設定され、IoT/モビリティ領域では車両稼働率のような非ウェブ型 SLI が実践されている** (Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]]) > - **なめらかなシステム構想では SLI/SLO がフィードバック循環から自動調整される** (Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) > - **SLI/SLO の組織導入には「定義・運用・定着」3 つの難点があり、段階的アプローチが有効** (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) > - **SLO の組織的導入には非技術ステークホルダーの「暗順応期間」が必要** (Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], [[@2018__Google SRE Workbook__SLO Engineering Case Studies]]) > - **ケイパビリティ（機能）を SLI 設計の起点とすることで「SLI 前に何を測るか」が決まる** (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 > - **ハードシャードシステムでは全体集計 SLO が障害を隠蔽する** (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]) > - **コアインフラの SLO は上位サービスの SLO より高く設定しなければならない** (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]]) > - **異種コンポーネントを持つサービスでは SLI タイプをコンポーネント種別ごとに分ける** (Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) > - **プローバーを使った能動的計測が新規・低トラフィックサービスへの SLO 導入の現実的な起点** (Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]]) > - **エンドツーエンドの「dumb SLI」（全体サニティチェック SLI）が個別 SLI の盲点を補完する** (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]])。 > - **SLO は検知に強いが調査（Investigation）には向かない——SLF と SLD が補完する** (Source: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]], [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]])。 > - **SLO 爆発問題は GitOps + Kubernetes 宣言的管理で吸収する** (Source: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 > - **SLO がカバーする範囲とユーザーが気にする範囲のズレは「カバー不足」と「カバー過剰」の 2 方向に起きる** (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]]) > - **可用性・レイテンシ SLO だけではデータ集約型サービスのステークホルダーが関心を持たない** (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]]) > - **SLO が明確に定義されると自動緩和・自動修復の根拠が生まれる** (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]]) > - **SLO の 4 ユースケースはプロバイダ・コンシューマで優先項目が異なる** (Source: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]]) > - **P50「括弧付き SLO」を P99 SLO に並置することで日常体験を保証できる** (Source: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]]) > - **パフォーマンスカーブ SLO は単一パーセンタイル閾値より「予測可能な変動」を提供する** (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]]) > - **ユーザー行動ベース SLI は技術的エラーシグナルと独立してゲーミングを補足できる** (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]]) > - **SLI/SLO/SLA の 3 次元（Code・Infrastructure・CX）はそれぞれ適切な SLA 時間窓が異なる** (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) > - **SLO は合意形成プロセス（交渉スキル）として設計する必要がある** (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2018__Google SRE Workbook__SLO Engineering Case Studies]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) > - **「エラー認識は人間のゲシュタルト的判断に依存するため SLO は実現不可能（not feasible）」という根本批判が 2022 年に明示された** (Source: [[@2022__SREcon22Americas__Principled Performance Analytics]], [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]], [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]) > - **SLO 代数（SLO Algebra）はいまだ未解決の重要課題である** (Source: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]], [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]) > - **「SLO を満たしているのに悲しいユーザー」が存在する状態（共感ギャップ）は、SLO 設計の根本的な失敗を示す** (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2016__SREcon16__Service Levels and Error Budgets]]) > - **SLO の目標値は S 字曲線で特定した痛みのしきい値より下に設定する** (Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) > - **Moyer (SREcon19 Americas) は同タイトル発表 (Hartmann, SREcon19 EMEA) と共通して「パーセンタイル平均化の誤り」を中心命題に置き、3 手法の優劣構造を確立した** (Source: [[@2019__SREcon19 Americas__Latency SLOs Done Right]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]]) > - **SLO Rationale をユーザー行動データで根拠づけることが「SLO を技術閾値から顧客観察結果」へ変換する最短経路** (Source: [[@2020__SREcon20Americas__Squish Level Objectives]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]]) > - **集計 SLO は「少数の大規模障害」を検知するが「多数の少量顧客への障害」を隠蔽する** (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]]) > - **少トラフィック顧客への一律 SLO 適用は「5 エラーのルール」で動的化する必要がある** (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]], [[@2020__NSDI__Meaningful Availability]]) > - **レイテンシ SLO を「fast requests / total requests」に変換するトリックは、複数 API のレイテンシ目標を可用性 SLI と同一計算基盤で管理可能にする** (Source: [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2019__SREcon19 Americas__Latency SLOs Done Right]]) > - **SLI/SLO モデルは「信頼性の測定」ではなく特定の問いへの回答モデルであり、ステークホルダーごとに問いが異なる** (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]]) > - **実務者はすでに SLO ウィンドウと目標値を無視したアドホックモデルを構築している** (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]], [[@2021__OReilly__Incident Metrics in SRE]]) > - **SLO モデルは時間・空間で線形性を仮定しており、集約によって深刻な問題を隠蔽する** (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]], [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2020__NSDI__Meaningful Availability]]) > - **SLO 導入の失敗要因が「技術」より「組織・人・プロセス」であることは複数のソースで独立に確認されている** (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], [[@2020__SREcon20Americas__Avoiding Goodhart's Law]]) > - **エラーバジェット起点のコードフリーズ RFC を経営承認まで通したことは、SLO 定着の到達点が小規模スタートアップでも到達可能であることを示す** (Source: [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]], [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]]) > - **「信頼性の 3 原則」は SLI/SLO 設計の前提として 2019 年に実践者視点から整理された** (Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) > - **SLI は「悪い挙動」ではなく「成功」を定義すべきである** (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]]) > - **同一 SLI を異なる時間窓で評価することで 3 つのステークホルダーペルソナに対応できる** (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]], [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]]) > - **CCU 重み付き可用性計測（Player Minutes）は均等加重ユーザーアップタイムの「重み付き変形」である** (Source: [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]], [[@2020__NSDI__Meaningful Availability]]) > - **SLO 定着の最速経路として「CEO 強制の OKR 接続」が有効** (Source: [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]], [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) > - **SLO を PO（プロダクトオーナー）が使う主動機は「チームで判断を回す」こと** (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2016__SREcon16__Service Levels and Error Budgets]]) > - **信頼性をユーザー主語で定義することが SLI 選択の出発点になる** (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]) > - **SLI/SLO の「定義・観察」と「Error Budget Policy に従って行動する」は別の困難として分離して管理する必要がある** (Source: [[@2022__SRENext2022__Who owns the Service Level?]], [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]]) > - **「仮値から始めてフィードバックで洗練する」アプローチが SLO 定着の共通パターンとして独立に確認される** (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]], [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) > - **IoT 領域では CUJ の代わりに CMC（Critical Machine Communication）が SLI 設計の起点になる** (Source: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]], [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) > - **Enabling SLO の組織的アプローチとして「習熟度調査→勉強会→Lead 直接コミュニケーション」が有効** (Source: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) > - **達成率(completion-rate)型SLOは、レイテンシ・可用性型SLOとは異なる「非対称な誤差コスト」の設計論を要求する** (Source: [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] §4.2-4.3)。 > - **SLO は「潜在原因ベースアラート」と「症状ベースアラート」を分離する枠組みとして定式化され、SRE Book の 4 基準をより厳密な 2 条件へ整理し直した** (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]], [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 > - **DDIA 2E(2026)は SLO/SLA を「SLO + 違反時の帰結 = SLA」という一般読者向け教科書の定式化で紹介しつつ、本 concept が蓄積した測定論の困難さを一文で予告する** (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Use of Response Time Metrics", [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]], [[@2020__NSDI__Meaningful Availability]]) > - **LLM による SLI/SLO 草稿生成は「仮値から始めてフィードバックで洗練する」という既存の組織定着パターンを技術的に加速する** (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]], [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 > - **Hidalgo は SREcon19 EMEA の「信頼性の 3 原則」を、著書『SLO サービスレベル目標』1 章で「サービスの 3 つの真実」として再定式化した** (Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]]) > - **「SLO Algebra は未解決」という課題に、McGhee (SLOconf 2021) は集合論の語彙で具体的な合成式を与えている** (Source: [[@2021__SLOconf__SLO Math]], [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 9 SLIとSLOの確率と統計]], [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]) > - **「ナインを積み上げる」という素朴な信頼性モデルと「集約可用性」モデルは、SRE Book 以前から対立する 2 つの設計思想として存在していた** (Source: [[@2021__SLOconf__SLO Math]]) > - **「証拠(SLI/SLO)が結論(SLA)を後押しするようにする」という定式化は、Mogul+Wilkes の「法律家的思考から統計家的思考への転換」を大企業向けの一言に圧縮したものである** (Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]) > - **SLA が定式化する「違反時の帰結」モデルは、プライバシー「障害」には構造的に適用しにくい** (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]], [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] §15.4) > - **「SLA は外部・SLO は内部」という実務家の直感的区別は、Mogul+Wilkes の SLE/CBE 枠組みと同じ分割線を、契約論ではなく当事者の数で引いている** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1, [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]) > - **時間量方式の欠陥(1日1億件のトランザクション例)は、Hauer+ が批判する「インシデント比」指標の欠陥と同型であり、5年早く同じ問題を独立に指摘していた** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.2.1, [[@2020__NSDI__Meaningful Availability]]) > - **「SLA は外部・SLO は内部」という当事者数区分は、サードパーティ統合の現場では「ベンダーの SLA を鵜呑みにせず自社の SLI/SLO を持ち込め」という具体的な戦術に翻訳される** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1, [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] §5.2.3.2) > - **9章の1分粒度・1年ローリングウィンドウ可用性計算は、21章が「時間量方式」に指摘する欠陥への、時期的に先行する独立した実務的回答である** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.5, [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.2.1, §21.2.3) > - **SLA/SLO の「外部・内部」区別は、21章・5章に続き9章の独立した監訳注でも三重に裏付けられる** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.1.3, [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.1) > - **コンポーネント別SLAによる手動SLO分解(原著2018年)は、Sedlak+のSLO拡散(2024年)が自動化しようとした問題を6年先取りする** (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] §9.2, [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]) > - **Burgess(2004)は「SLA」一語だけで、SRE Book(2016)のSLI/SLO/SLA三層化を待たずにMogul+Wilkes(2019)の「統計家的思考への転換」を先取りしていた** (Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] §10.8.1, [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]) > - **§10.10の9項目SLAチェックリストは、SRE Workbook Appendix A(2018)のSLO文書構成を14年先取りする骨格を持つが、資源配分をゲーム理論に外部化する点で異なる** (Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] §10.9-10.10, [[@2018__Google SRE Workbook__Appendix A Example SLO Document]]) > - **異常検知システムは SLO 違反を検知トリガーとして流用するが、粒度はアプリケーション全体にとどまる** (Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]], [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]]) > - **ε-diagnosis の小ウィンドウ・テールレイテンシ SLO check は、SRE 実務論のパーセンタイル集約不能性への一つの回避策として読める** (Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]]) > - **SLO は監視上の判定値にとどまらず、制御系の目標値として扱える** (Source: [[@2002__Real-Time Systems__Using Control Theory to Achieve Service Level Objectives In Performance Management]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) > - **複合 SLI（Latency AND Availability）は OR 結合により単一のエラーバジェットで両次元を管理できる** (Source: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) > - **Moyer (SREcon20 Americas) は 2 年連続の連作で「レイテンシ実装 → 複合 SLI・組織展開」の階層を進んだ** (Source: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]], [[@2019__SREcon19 Americas__Latency SLOs Done Right]]) ## 関連 - ソース: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]] / [[@2021__SLOconf__SLO Math]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] / [[@2022__SREcon22EMEA__Going-from-30-to-30-Million-SLOs]] / [[@2020__SREcon20Americas__Squish Level Objectives]] / [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]] / [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]] / [[@2020__SREcon20Americas__Avoiding Goodhart's Law]] / [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] / [[@2016__SREcon16__Service Levels and Error Budgets]] / [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] / [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] / [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] / [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] / [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] / [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] / [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] / [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]] / [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] / [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]] / [[@2018__Google SRE Workbook__SLO Engineering Case Studies]] / [[@2018__Google SRE Workbook__Appendix A Example SLO Document]] / [[@2018__Google SRE Workbook__Alerting on SLOs]] / [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] / [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] / [[@2020__NSDI__Meaningful Availability]] / [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 4 適切なサービスレベル目標の選択]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]] / [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] / [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] / [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] / [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]] / [[@2022__SREcon22Americas__Principled Performance Analytics]] / [[@2021__SREcon21__Beyond-Goldilocks-Reliability]] / [[@2021__OReilly__Incident Metrics in SRE]] / [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]] / [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]] / [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] / [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] / [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] / [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] / [[@2018__SREcon18Europe__SLOs and SLIs in the Real World - A Deep Dive]] / [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]] / [[@2019__SREcon19 Americas__Latency SLOs Done Right]] / [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]] / [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] / [[@2022__SRENext2022__Who owns the Service Level?]] / [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] / [[@2026__MLSys2026__Cost-aware Duration Prediction for Software Upgrades in Datacenters]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] / [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] / [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]] / [[@2002__Real-Time Systems__Using Control Theory to Achieve Service Level Objectives In Performance Management]] / [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]] - エンティティ: [[Vladimir Legeza]] / [[Amazon Japan]] / [[Theo Schlossnagle]] / [[Circonus]] / [[Steve McGhee]] / [[Alex Hidalgo]] / [[Alex Palcuie]] / [[Jeffrey C. Mogul]] / [[John Wilkes]] / [[Tamás Hauer]] / [[Google]] / [[Boris Sedlak]] / [[Schahram Dustdar]] / [[CASCA]] / [[SRE Book]] / [[Ben Treynor Sloss]] / [[Jamie Wilkinson]] / [[Chris Jones]] / [[Niall Murphy]] / [[Matthew Flaming]] / [[Elisa Binette]] / [[New Relic]] / [[Ketan Gangatirkar]] / [[Indeed]] / [[Arnaud Lawson]] / [[Squarespace]] / [[Yoann Fouquet]] / [[Booking.com]] / [[Narayan Desai]] / [[Brent Bryan]] / [[Fred Moyer]] / [[Zendesk]] / [[Dave Stanke]] / [[Qian Ding]] / [[Xuan Zhang (Ant Group)]] / [[Ant Group]] / [[Rob Durst]] / [[Spring Health]] / [[Maxfield Stewart]] / [[Riot Games]] / [[Mark Burgess]] - 概念: [[AIOps]] / [[agentic SRE]] / [[エージェント運用安全性]] / [[Transactional No-Regression]] / [[インシデント管理]] / [[エラーバジェット]] / [[信頼性スタック]] / [[SLI-SLO段階的導入]] / [[データ品質SLO]] / [[Player Journey]] / [[アラート疲労]] / [[逸脱の正常化]] / [[アクショナブルアラート]] / [[イベントベースSLO]] / [[SLO目標値の選定]] / [[プライバシーエンジニアリング]] / [[ヒストグラムメトリクス]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 3.3 Monitoring-based Anomaly Detection Techniques]](§3.3.3: SLO check ベースの異常検知（CauseInfer、Microscope、ε-diagnosis）がアプリケーション全体粒度で SLO 違反を判定する実装) - [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]](§21.1: SLA=外部・SLO=内部の当事者数による区別、§21.2.1: 時間量方式の欠陥) - [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]](§5.2.3.2: ベンダーとの SLA 交渉で自社の SLI/SLO を持ち込むべきだという実務指針) - [[@2021__OReillyJapan__SREの探求 - Chapter 9 25ページでシステム管理者からSREへ]](§9.1.3: SLA/SLOの監訳注、§9.2: コンポーネント別SLAによる手動SLO分解、§9.5: 1分粒度・1年ローリングウィンドウ可用性計算) - [[@2021__SLOconf__SLO Math]](intersection/union availability の合成式、SLO の集合論、ダイスアナロジー、ボトルネックとしてのネットワーク/ロードバランサー) - [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]](閾値アラートの逸脱の正常化批判、既知の未知/未知の未知、SLO の what/why 分離、ANZ Bank ケーススタディ、LLM による SLI/SLO 草稿生成) - [[@2007__LISA__On Designing and Deploying Internet-Scale Services]]（Overall Application Design: SLA を同期冗長設計の酸性試験として位置づけ） - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - [[@2020__NSDI__Meaningful Availability]] - [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]] - [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]](エラーバジェットの体系的定義、100% 可用性の非追求) - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]](SLI/SLO/SLA の実践的定義、パーセンタイル原則、エラーバジェット運用) - [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]](SLI 仕様/実装の分離、ユーザー中心 SLO、ステークホルダー合意、継続改善) - [[@2018__Google SRE Workbook__Appendix A Example SLO Document]](Example Game Service の SLO 文書例、鮮度・正確性・完全性 SLO) - [[@2018__Google SRE Workbook__Alerting on SLOs]](SLO からエラーバジェットバーン率アラートへの変換) - [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]](LLM 推論 SLO と TTFT/ITL/Goodput/Tokens-Dollars 指標、SLO ベース最適化ループ) - [[@2019__SREcon19 EMEA__Latency SLOs Done Right]](レイテンシ SLO におけるパーセンタイル集約不能性、ログ・カウンタ・ヒストグラムによる正しい実装) - [[@2016__SREcon16__Service Levels and Error Budgets]](SLO 公表の理由、意図的ダウンタイム、クライアント側測定の重要性、集約インターバル問題) - [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]](ケイパビリティ駆動 SLI 設計・7 ステップレシピ・ハードシャード per-shard SLO・複合 SLO・インフラ SLO 設計・全体 dumb SLI) - [[@2018__SREcon18Europe__SLOs and SLIs in the Real World - A Deep Dive]]（SREcon18 Europe/EMEA での再演版・音声収録あり） - [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]]（Squarespace COS への SLO 実装 6 ステップ・耐久性 SLI・プローバー計測・SLO 公開ドキュメント） - [[@2019__SREcon19 Americas__Latency SLOs Done Right]](パーセンタイル平均化の誤り・3 手法比較・libcircllhist ログリニアヒストグラム。SREcon19 EMEA 版 (Hartmann) との収束確認) - [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]](データ集約型サービスにおけるデータ品質 SLO：一貫性・新鮮性・完全性・耐久性の定義プロセスと自動緩和・修復への活用) - [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]](SLO の 4 ユースケース分類・暗黙的仮定の明示化・テール管理への SLO 不適用論・SLO Algebra の未解決問題・P50 括弧付き SLO 推奨) - [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]](Riot Games における Player Minutes SLO 導入事例・CCU 重み付き可用性計測・CEO OKR による定着手法) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 2 Defining Nonfunctional Requirements]] "Use of Response Time Metrics"(SLO/SLA の教科書的定義と、良い可用性メトリクス定義の困難さへの言及) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]](信頼性スタック(SLI→SLO→エラーバジェット)の導入、サービスの 3 つの真実、SLO/SLA の区別) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]](James Brookbank, Steve McGhee, 2022, 第3章)— 「証拠(SLI/SLO)が結論(SLA)を後押しするようにする」という定式化、既存ビジネスコミットメントにSLO/SLIを左右されないという原則 - [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]](§15.4: SLA の「違反時の帰結」モデルがプライバシー障害の不可逆性には適用できないという指摘) - Mark Burgess, *Principles of Network and System Administration*, 2nd ed., Wiley, 2004, Chapter 10 §10.8.1・§10.9-10.10(誤差論に基づくSLA定式化、9項目チェックリスト、資源配分ゲーム)。