## 定義 サービスレベル目標（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]])。 ## 三つの要件と既存指標の限界 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）曲線として可視化する。曲線上の「膝」の位置で短時間断続障害と長時間大規模障害を区別でき、実用性を担保する。 ## SLE/CBE によるリスク明示的分担 Mogul+Wilkes は SLO 定義の困難さを統計学的意思決定（仮説検定・サンプリング・推論手法選択）との同型性として捉え、「法律家的思考から統計家的思考への転換」を提唱する (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]): - **SLE（サービスレベル期待）**: プロバイダが通常条件下で顧客に期待させる挙動。結果保証ではなく期待管理。 - **CBE（顧客挙動期待）**: プロバイダが SLE を満たすために前提とする顧客側の挙動。統計多重化に伴う不確実性を SLO 枠組みに内在化させるための仕組み。 - 「SLOgician」という専門職の必要性——統計家と同様の謙虚さ（不確実性下での限界認識）が不可欠と論じる。 ## 可用性への「セキュリティ的思考」 Mogul+ は大規模インフラストラクチャの可用性にはセキュリティと同様の「敵対的思考」が必要と主張する (Source: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]): - スレットモデリング: 障害の脅威モデルを明示化する。 - 深層防御: 単一のメカニズムに依存しない。 - フェイル・スタティック: 依存先が停止しても直前の状態で継続動作する（セキュリティの「デフォルト拒否」に相当）。 - Wheel of Misfortune: SRE のインシデント訓練をペネトレーションテストの類似と位置づける。 - 素朴なサブシステム SLO 分解（確率の積算等）は依存関係の相関を見落とし誤りを生む。 ## SLO 拡散（高レベル→低レベル分解） Sedlak+ はマイクロサービスパイプラインにおいて高レベル SLO（応答時間・顧客満足度等）を自動的に低レベル SLO とパラメータ割り当てへ分解する 3 ステップ方法論を提案する (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]): 1. マイクロサービスパイプラインのベイズネットワークモデル化。 2. 条件付き依存関係に基づく SLO 制約伝播。 3. 矛盾検知と自律的解決。 評価では複数パイプラインで SLO 達成率 83〜100% を達成し、許容範囲パラメータ λ の過度な厳格化と SLO 間のコンフリクトが充足率を急激に低下させるリスクを定量化した。 ## カーボン認識 SLO 管理 CASCA はマイクロサービスアーキテクチャ原則に基づき、コンピューティングコンティニュアム環境でプロバイダのプライバシーを保護しながら SLO を充足するプラットフォームを実装する (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。EMMa マイクロサービスを通じてカーボンフットプリントを報酬関数に組み込み、SLO 充足とサステナビリティの両立を図る。宣言的設定管理（設定ファイル修正 + コンテナ再起動）は命令的手法比で約 53.7 秒の短縮を実現し、SLO の動的変更コストを低減する。 ## 横断的知見 - **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+ の拡散方法論が「何を設定すべきか」を決める。前者は事後的な計測、後者は事前的な制約伝播であり、両者をフィードバックループで結ぶことで SLO 管理の閉ループが構成できる (Source: [[@2020__NSDI__Meaningful Availability]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 - **SLO とサステナビリティの緊張関係が浮上**: CASCA は FPS SLO 充足率ではカーボン非認識の貪欲方式（90.6%）に劣る（RLDS: 85.2%）が、カーボンフットプリントでは最良（72.4 vs 74.9 mgCO₂/分）。性能 SLO とサステナビリティ SLO のトレードオフは AIOps の既存 4 段タクソノミ（検知→箇所特定→RCA→緩和）に「コスト/持続可能性」という第 5 の軸を加える可能性がある (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。 - **「法律家から統計家へ」の転換は AIOps エージェントの保証契約設計に直結する**: [[エージェント運用安全性]] の assurance contract / verification wall の語彙と、SLE/CBE のリスク分担枠組みは「契約 = 期待 + 帰結」という点で同型であり、agentic SRE の安全仕様（[[Transactional No-Regression]]）に SLE/CBE 的な双方向期待管理を載せることが自然な拡張方向だ (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 - **SLA は「設計段階で組み込む制約」として 2007 年に位置づけられていた**: Hamilton は SLA を可用性メトリクスの議論以前に、サービス設計の酸性試験（acid test）として定義した——「任意のサーバをいつでもワークロードのドレインなしに停止でき、かつ SLA を満たせるか」。Mogul+ (2017/2019) が SLO/SLE の測定・約束の難しさを論じたのに対し、Hamilton (2007) は SLA を同期冗長と自動フェイルオーバの設計判断の帰結として扱う。測定の精緻化（Hauer+ 2020）と設計段階での SLA 組み込み（Hamilton 2007）は相補的な視座である (Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2020__NSDI__Meaningful Availability]])。 - **SRE Workbook は SLO を「測定指標」から「運用意思決定システム」へ拡張する**: Implementing SLOs は、SLI を「良いイベント数 / 全イベント数」として設計し、ユーザーに意味のある SLI 仕様と、ログ・ロードバランサ・ブラックボックス・クライアント計装による SLI 実装を分ける。さらに SLO 文書、ステークホルダー合意、4 週間ローリングウィンドウ、継続改善、エラーバジェットポリシー、アラートルールまでを一体で扱う。Appendix A の Example Game Service は、可用性・レイテンシだけでなく、データ鮮度・正確性・完全性を SLO に含め、SLO がサービスのユーザー体験モデルを文書化する器であることを示す (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]], [[@2018__Google SRE Workbook__Appendix A Example SLO Document]])。 - **SLO は外部組織で「開発対運用」の主観対立をデータ対話へ変える**: SLO Engineering Case Studies は Evernote と The Home Depot の導入事例を通じ、SLO が Google 内部の用語にとどまらず、運用チームと開発チームの品質判断を共通メトリクスへ寄せる道具になることを示す。SRE Book が原則を定義し、Workbook が顧客信頼性エンジニアリング（CRE）を通じた導入パターンを示したことで、SLO は「Google 固有の運用慣行」から「組織間で移植可能な合意形成プロセス」へ移った (Source: [[@2018__Google SRE Workbook__SLO Engineering Case Studies]])。 - **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 の自然な帰結として位置づける (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 - **生成 AI サービスでは SLI の候補が「応答の品質」へ広がる**: Yoshikawa は、AI による変更が信頼性へ与える影響を SLO 達成率で可視化するだけでなく、出力品質スコア、ハルシネーション率、RAG 検索精度を SLI に加える例を示す。従来のリクエスト成功率・レイテンシ中心の SLI/SLO 体系に、意味的品質や検索品質をどう接続するかが AI 組み込みサービスの新しい設計課題になる。(Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]) - **セルフクラフト構想は SLO を「事業者が宣言する目標」から「利用者と AI が探索する均衡点」へ拡張する**: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] は、2040 年代の個別化アプリケーションでは、信頼性・コスト・変更速度などの基本変量の均衡点を、利用者と AI が対話的かつ体験的に決めると描く。これは SLO を静的な契約値ではなく、短時間の劣化体験やコスト提示を含む探索プロセスとして扱う視点である。(Source: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) - **LLM 推論の SLO はレイテンシ・スループット・費用を同時に束ねる**: 道下幹也の SpeakerDeck は、TTFT・ITL・E2EL・RPS・TPS・Goodput をユーザー体験の候補指標として整理し、Goodput を「レイテンシ要件を満たすリクエスト数」として位置づける。さらに Tokens/Dollar や Tokens/User/Dollar を費用対効果の指標として示し、SLO/SLA を満たしながらコスト最小化するループを推論基盤最適化の中心に置く。これは SRE Workbook の「ユーザーに意味のある SLI を選ぶ」原則が、GPU コストと推論フェーズの制約へ拡張された例である。(Source: [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) - **レイテンシ SLO はパーセンタイル時系列ではなく、しきい値内の良いイベント比率として実装する必要がある**: Hartmann の SREcon19 EMEA 資料は、時間ごとの p90 を平均すると全体分布から計算した p90 とずれる例を示し、パーセンタイルが複数時間窓・複数ノードをまたいで集約できないことを実務上の SLO 問題として定式化した。SRE Workbook の「良いイベント数 / 全イベント数」型 SLI をレイテンシに適用するなら、ログ、しきい値別カウンタ、[[ヒストグラムメトリクス]] のいずれかで「しきい値以内のリクエスト数」を数える必要がある。これは SLO を「代表値を眺める監視」ではなく「対象期間全体のイベント集合に対する判定」として扱うことを要求する (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 - **SLO 由来の Warning アラートには「原因をすぐ集める」運用層が必要になる**: 池田の発表は、`response time` の p99 が 1.5 秒を超える Warning アラートに対し、対象期間のリクエストパス別レスポンスタイムを自動集計し、画像アップロード API 1 件が 17.9 秒だったと判断できる例を示す。これは SLO を良いイベント比率として設計するだけでなく、違反または予算消費が起きた時点で、判断に必要なログ・メトリクスをアラートに添える運用が必要なことを示す。SLO アラートは「鳴らす条件」だけでなく「鳴った後に何を見ればよいか」を含めて設計されるべきである。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) - **「高レベルサービス目標へアラートし、個別コンポーネントを調査可能に保つ」原則は SLO ベース呼び出しの前史である**: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise|Rabenstein SREcon16 Europe]] は、監視システムには高レベルサービス目標へアラートする能力と、必要時に個別コンポーネントを調査できるグラニュラリティの両方が必要だとする。これは Wilkinson 2018 の「symptom = SLO で計測できるもの」「symptom-based alert = SLO が危険になったときのアラート」へ直接つながる発想である。ページ条件を高レベル目標に寄せ、原因調査のためのホワイトボックス詳細を別に保持する分離は、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 記録ルールを先に置いていた**: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] は、SLI を「10 分間の応答レイテンシやエラー率」、SLO を「99.9 パーセンタイル 5ms 未満やエラー 1% 未満」、SLA を経済的帰結と整理する。そのうえで、ページングするアラートは SLO 違反を示すべきだとし、レイテンシ分布のバケット比率や Prometheus の記録ルールを使って実装する。これは 2018 年の SLO バーンレートアラート発表へ進む前に、SLO アラーティングを支えるデータ構造と運用分離を説明した資料と位置づけられる。(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 を公表しないと現状性能への無言の期待が生まれる」と明示した**: Jones・Murphy は SREcon16 で、SLO を公開しないサービスではユーザーが「今の性能が永遠に続く」と期待し始め、将来の設計変更・コスト最適化の選択肢が失われると口頭で警告した。書籍第 4 章でも言及されているが、SREcon16 ではこれを「SLO を公表する最初の理由」として最初に挙げた。なお対処として「意図的なダウンタイムを入れるシステムが Google に実在する」と述べ、過達成（over-achieving）が引き起こす期待インフレへの組織的対処を明かした (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 - **SLI の測定点は「ロカス・オブ・コントロール」ではなく「ロカス・オブ・メジャーメント」を優先すべきで、Google 自身が誤りを犯してきた**: Jones・Murphy は SREcon16 でサーバー側レイテンシを測りがちな Google の実態を「間違い」と認め、クライアント側が実際のユーザー体験を正確に反映すると述べた。制御しやすい場所で測るのと、ユーザーに意味のある場所で測るのは異なる (Source: [[@2016__SREcon16__Service Levels and Error Budgets]])。 - **集約インターバルの選択がサービス動作の解釈を根本的に変える**: SREcon16 トランスクリプトでは、同じデータが 1 分インターバルでは平坦、30 秒では散発的スパイク、1 秒では「毎分先頭に全リクエストが集中」と見えることを示した。クライアント同期の問題（修正必要）とピーク性能支配（キャパシティプランニング影響）が見えなくなる。これは既存の SLI 実装論（Hartmann 2019 のパーセンタイル集約不能問題）と別軸の問題であり、「何を測るか」の前に「どのウィンドウで見るか」という問いがある (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 - **SLO/SLI は機能別・ドメイン別に分けて設定され、IoT/モビリティ領域では車両稼働率のような非ウェブ型 SLI が実践されている**: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] の Q&A で坪内は、ウェブサービスではエンドポイント(決済 API 等)ごとにレイテンシ SLO を分けて「ブレないように」設定するのが一般的と述べた。さらにモビリティサービスでは「車両が壊れている・壊れていない」ではなく、全体のうち何台が稼働しているかを分母に SLI を構成する例を挙げ、「現実世界に染み出してくるともっと面白い SLI が出てくる」と展望した。これは SLO が「リクエスト駆動サービスの指標」を超えて物理世界のオペレーション指標へ拡張されつつあることの実務的証言である。（Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], Q&A） - **なめらかなシステム構想では SLI/SLO がフィードバック循環から自動調整される**: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] は、利用者・情報システム・開発運用者の 3 者間で AI エージェントがコンテキストを流通させ、深層学習の自動微分のようにパラメータが事後的に最適化されるモデルを提示した。この構想では SLI/SLO は人間が事前に合意して設定するのではなく、フィードバック循環から自動的に調整される。[[セルフクラフト]]の「利用者が信頼性目標を体験的に収束させる」構想と合わせると、SLO の主体が事業者から利用者+AI に移行する方向性が示唆される。（Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]） - **SLI/SLO の組織導入には「定義・運用・定着」3 つの難点があり、段階的アプローチが有効**: Takamura は、SLI/SLO を最初から完璧に作ろうとすると合意形成・追加計装に時間がかかり形骸化しやすいと整理する。SRE 自体の 4 ステップ導入法（小さく始める→チームを支援する→スケールする→データドリブン思考を具体化する）を SLI/SLO 導入に転用し、SLO 違反ポリシーを Level1（何もしない）から Level5（意思決定に組み込む）へ段階的に拡大する方法を体系化した。定義・運用・定着をそれぞれ 5 段階成熟度モデルで評価することで、現在地の対話起点として使える（[[SLI-SLO段階的導入]]）。(Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]) - **SLO の組織的導入には非技術ステークホルダーの「暗順応期間」が必要**: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices|Smith SREcon22]] は、Campspot での SLO 導入事例で、技術チームが SLO の考え方に馴染んだ後に営業チームを SLO ワークショップに招いたところ「Uptime 99.999% の話ではないのか」と混乱が生じたと報告した。人間の瞳孔が明所から暗所に順応するのに 30 分を要するように、「可用性 = 稼働率」から「良い体験の割合」への認知的転換には準備期間が必要であり、SLO 実装の前に非技術ステークホルダーとの「Adjust」フェーズを設けるべきだったとする。SRE Workbook の「ステークホルダー合意」プロセスと Case Studies の「外部組織で開発対運用の主観対立をデータ対話へ変える」知見はこの問題の解を含むが、Smith の事例は**営業チームという SRE 文脈で見落とされがちなステークホルダー**を名指しした点で実践的に重要。(Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], [[@2018__Google SRE Workbook__SLO Engineering Case Studies]]) - **ケイパビリティ（機能）を SLI 設計の起点とすることで「SLI 前に何を測るか」が決まる**: New Relic の Binette・Flaming は、システム境界ごとに「公開するケイパビリティ」を列挙し、各ケイパビリティの「利用可能」を平易な英語で定義してから技術的 SLI に落とす 7 ステップレシピを示した。SRE Workbook の「ユーザーに意味のある SLI 仕様」とロジックは共通するが、**ケイパビリティを中間概念として挟む**ことで、SLI の候補を絞り込む具体的な手順が得られる。SLI 設計で「何を測ればいいかわからない」という難点を、「システム境界の機能一覧を作る」という操作可能な第一歩に変換する (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 - **ハードシャードシステムでは全体集計 SLO が障害を隠蔽する**: 水平スケールでは 3 ノード中 1 ノード障害 = 全体 SLO 66%（比例的に反映）だが、ハードシャードでは SLO 0%/100%/100%（シャード単位）なのに全体集計では 66% と誤って健全に見える。Binette・Flaming はこれを視覚的に示し、**ハードシャードでは論理インスタンス（シャード）ごとに独立した SLO が不可欠**と主張した。Sedlak+ (2024) の SLO 拡散方法論でも「サービスチェーンの各コンポーネントへ SLO を分解する」問題が扱われているが、シャードという**同一サービスの並列インスタンス間での 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 より高く設定しなければならない**: ネットワーク層は上位すべてのサービスへのハード依存であるため、99.99% goal が妥当と示される（アプリケーション層が 99.9% SLO であれば、依存インフラは少なくとも 1 桁高い必要がある）。**「インフラ SLO = アプリ SLO の二次依存」という設計則**は SRE Book・Workbook では明示されていないが、New Relic の実装事例として具体的な目標値とともに示されており、SRE Workbook の「ステークホルダー合意」と「コンポーネント依存の考慮」を実務に落とした事例として読める (Source: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]])。 - **異種コンポーネントを持つサービスでは SLI タイプをコンポーネント種別ごとに分ける**: Lawson (2019) は Ceph Object Storage において、リクエスト駆動 RESTful インターフェース側に「可用性 SLI」「レイテンシ SLI」を、分散ストレージバックエンド側に「耐久性 SLI（書き込んだオブジェクトが障害後も無損傷で再読み取りできる割合）」を別途定義した。SRE Workbook の「サービスコンポーネントを理解して SLI タイプを選ぶ」という原則を、「リクエスト処理」と「データ永続性」が混在するサービスに具体的に適用した最初の公開事例の一つ。新規サービスへの SLO 適用では、ユーザーのアクセスパターンをサーバーログで分析してから SLI タイプを選ぶプロセスも示した。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]) - **プローバーを使った能動的計測が新規・低トラフィックサービスへの SLO 導入の現実的な起点**: Lawson はロードバランサーログ・S3 クライアントのインストルメンテーション・プローバーの三層計測を組み合わせ、プローバーを主な SLI データ源とした。ユーザートラフィックが少ない新規サービスでは受動的計測だけでは統計的に不安定なため、能動的プローバーが SLO 設定の 4〜5 週間の実績収集を支える。Binette・Flaming の「全体 dumb SLI」と同じ発想（合成テストによる全体健全性確認）を、新規サービス立ち上げに特化した形で適用している。(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 の盲点を補完する**: Binette・Flaming は各層の細粒度 SLI に加えて、「サンプルワークフローが成功するか」という粗い全体 SLI を設けることを推奨した。個々の SLI が全て正常でも全体として壊れている場合（例: 複数層の障害が互いにキャンセルし合う状況）を検知できる。これは Mogul+ (2017) の「素朴なサブシステム SLO 分解は相関を見落とす」という指摘への実践的な対処でもあり、**個別層の 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 が補完する**: Ding+Zhang（SREcon21）は SLO を「メトリクス構築・検知・SLO レポーティング」には適しているが、「クロスサービス調査の認知負荷を下げる」ことができないと指摘する。補完概念として、SLF（Service Level Factor: SLI を詳細ラベル次元でスライスしたもの）と SLD（Service Level Dependency: 依存サービスとのメトリクス）を追加し、これら 3 要素を結んだ SLX Graph をグラフ走査することで「時系列相関のある異常 SLO 依存チェーン」を自動絞り込む。Desai（SREcon19 EMEA）が「SLO は 4 ユースケースのうち Incident Response においてプロバイダとコンシューマで優先度が異なる」と指摘した問題の、実装側での対処と読める (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 宣言的管理で吸収する**: Ant Group（60+ K8s クラスタ、99.999% 目標）では「コンポーネント × ユーザージャーニー × SLO 種別 × 実行環境」の組み合わせ爆発により数百件の SLO を手動管理しきれなくなった。対策として SLO 定義 YAML → Git レビュー → ArgoCD → Kubernetes → Prometheus/Grafana という宣言的パイプラインを構築した。Sedlak+（SOSE 2024）の SLO 拡散方法論が「SLO をベイズネットで分解する」という垂直方向の問題を扱うのに対し、SLX の GitOps 管理は「膨大な SLO をどう一元管理するか」という水平方向の問題を扱い、両者は相補的である (Source: [[@2021__SREcon21__SLX - An Extended SLO Framework to Expedite Incident Recovery]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 - **SLO がカバーする範囲とユーザーが気にする範囲のズレは「カバー不足」と「カバー過剰」の 2 方向に起きる**: Gangatirkar は SLO カバレッジの問題を Venn 図で視覚化し、SLO がユーザーの気にする機能を網羅できていない「カバー不足」（users may notice problems your SLO doesn't cover）と、ユーザーが気にしない項目を SLO でカバーする「カバー過剰」（your SLO may cover things your users don't care about）の 2 方向のリスクを示した。Binette・Flaming（SREcon18 Americas）が「ケイパビリティを SLI 設計の起点」とすることで前者を防ごうとした手法は、Gangatirkar の「6 フレーバー」フレームワークと相補的——6 フレーバーは SLI 候補カテゴリを提供し、ケイパビリティ列挙はそのカテゴリをサービス固有に具体化する。(Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]]) - **可用性・レイテンシ SLO だけではデータ集約型サービスのステークホルダーが関心を持たない**: Booking.com では検索サービスに可用性・レイテンシ SLO を設定しても開発・ビジネスステークホルダーは無関心だった。彼らが気にするのはデータの一貫性・新鮮性・完全性・耐久性であり、これらを「データ品質 SLO」として計測・目標化するまでは SLO が意思決定に使われなかった。可用性・レイテンシは「サービスが動いているか」を示すが「正しいデータを返しているか」は示さない（[[データ品質SLO]]）。(Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]]) - **SLO が明確に定義されると自動緩和・自動修復の根拠が生まれる**: Booking.com では Freshness Probe が新鮮性 SLO 違反を検知した際にトラフィックを自動停止し（自動緩和）、Completeness Probe が欠損を検知した際に Hadoop スナップショットから再処理する（自動修復）ことで、SLO が単なる監視指標から自動化アクションのトリガーへ進化した。SLO 導入の最大の恩恵として「Awareness（可視化）」と「Confidence（行動根拠）」が挙げられた (Source: [[@2019__SREcon19EMEA__SLOs for Data-Intensive Services]])。 - **SLO の 4 ユースケースはプロバイダ・コンシューマで優先項目が異なり、単一の SLO では全てに対応できない**: Desai は Ongoing（日常の管理）/ Design（設計時の期待設定）/ Incident Response（インシデント時の影響評価）/ Bounding the Tail（テール事象の管理）という 4 ユースケース×プロバイダ/コンシューマのマトリクスを提示した。例えば Incident Response ではプロバイダは「問題の大きさを把握したい」、コンシューマは「依存先が問題を認識して修復してほしい」という互いに似て非なる優先順位を持つ。この差異を無視した単一汎用 SLO はいずれのニーズも中途半端にしか満たさない (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 に並置することで日常体験を保証できる**: Desai は Google 内部で「すべてのサービスが公開 SLO ちょうどの性能で動作したら全てが崩壊する」というジョークを紹介し、クラスタマネージャの新タスクスケジューリング SLO（分単位）が常時発生するとリアクティブシステムが機能不全になる例を挙げた。P99 SLO だけでは日常的なユーザー体験（中央値付近の挙動）を保証できないため、P50 に括弧付き SLO を追加する実践を推奨する。Gangatirkar (SREcon18 Asia) の S 字曲線「ユーザーが痛みを感じる閾値より下に 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 は単一パーセンタイル閾値より「予測可能な変動」を提供する**: Hartmann（2019）がパーセンタイルの平均化不能問題を指摘したのと同じ問題意識から、Coulter（2020）はインフラ SLO に多段パーセンタイル定義（90%/30s・99%/1min・99.9%/5min）を使うことを提案する。単一の「99% の応答が X 秒以内」では、X 秒を超える 1% の分布を制御できない。多段定義は「速い応答の大多数」と「遅い応答の尾部」を別々に制御し、SLA 超過が起きた際の性能劣化パターンがコンシューマ側に予測可能になる。Desai（2019）の「P50 括弧付き SLO を P99 SLO に並置」という提案と方向性が同じであり、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 は技術的エラーシグナルと独立してゲーミングを補足できる**: Coulter（2020）は CX 次元の SLI として「10 秒以上経ってから 5 分以内に再試行された患者検索」を定義した。この SLI はサーバーエラーが発生していなくても（HTTP 200 でも）ユーザー不満を検知でき、技術指標の SLO を満たすながら CX が悪化しているシナリオを露出する。Gangatirkar（2018）の「SLO 達成・ユーザー不満（共感ギャップ）」セルを検知する実装上の解の一つであり、Booking.com（2019）のデータ品質 SLO（可用性 SLO では見えない「正しいデータを返しているか」を計測）と同様に、単一次元 SLO のカバー不足を補完するアプローチである (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 時間窓が異なる**: Coulter（2020）の事例では Code は 28 日間・Infrastructure は 24 時間・Business & CX は 8 時間。この差は各次元のビジネスインパクト即時性を反映しており、CX が最も短い。Booking.com（2019）がデータ品質 SLO を可用性 SLO と別に設定した事例と同様に、次元ごとに SLO の性質（評価指標・時間窓・SLA アクション）が異なることを示す。SRE Workbook の SLO 文書化では時間窓を明示することが求められており（Implementing SLOs）、次元別に最適時間窓を選ぶというフレームがそこに加わる (Source: [[@2020__SREcon20Americas__Avoiding Goodhart's Law]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]])。 - **SLO は合意形成プロセス（交渉スキル）として設計する必要がある**: Coulter（2020）は「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」という反復的交渉フローを提案した。SLO を技術的に「正しい値を計算する」問題ではなく、リスク許容量・期待境界・戦略を事前に把握したうえでのステークホルダー交渉として扱う視点は、SRE Workbook の「ステークホルダー合意」をプロセス論として展開したものと読める。Smith（SREcon22 Americas）が「営業チームとの共感ギャップ」を指摘した問題への処方箋とも重なる。RECUR という反復要素が入っているのが重要で、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 年に明示された**: Desai（SREcon22 Americas）は「SLO requires recognized errors」と述べた上で、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータ（shallow data）」にとどまると主張する。これは Desai 自身の 2019 年発表（SLO の暗黙的仮定批判）と 2021 年発表（Goldilocks Reliability 批判）を踏まえ、「SLO そのものが計測ツールとして根本的に不完全」という結論へ進んだ最も強い批判形である。SLO を段階的改善の対象として論じる多くの先行ソースとは立場が異なる。(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）はいまだ未解決の重要課題である**: 複数のダウンストリームサービスを消費する上位サービスの SLO を、依存先の SLO から分析的に導出する体系的手法が存在しない。Desai が 2019 年に「現状の最良は桁でパッドするだけ」と指摘した問題は、Mogul+Wilkes (2017) の「素朴なサブシステム SLO 分解は相関を見落とす」という警告と同じ問題を別角度から指摘している。依存関係の直列/並列消費パターン・フェイルオープン/クローズド動作を考慮した代数的枠組みの確立は、SRE 分野の未解決課題として残っている (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 設計の根本的な失敗を示す**: Gangatirkar の 2×2 マトリクス（Failing/Meeting SLO × Sad/Happy user）では、「SLO 達成・ユーザー不満」セルを「Empathy gap」と命名し、SLO がユーザーの痛みのしきい値より高く設定されている（ユーザーが感じる閾値よりゆるい）場合に発生すると説明する。Jones・Murphy（SREcon16）が「SLO を公表しないと現状性能への無言の期待が生まれる」と指摘した問題とは別軸——こちらは SLO 目標値そのものがユーザー体験から乖離している問題である。(Source: [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]], [[@2016__SREcon16__Service Levels and Error Budgets]]) - **SLO の目標値は S 字曲線で特定した痛みのしきい値より下に設定する**: Gangatirkar は可用性（横軸）対ユーザー幸福度（縦軸）の S 字曲線を用いて、B2B ツール Tenfold の例で SLO 99.95% が "tolerable" ゾーンの上限にあることを示した。S 字の屈曲点（"We're paying how much?\!?\!" ゾーンの開始点）が痛みのしきい値であり、SLO はそれより下——つまりユーザーが不満を感じ始める前の水準——に設定すべきだとする。SRE Workbook の「ユーザーが気にする SLI を選ぶ」原則に「目標値を 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 手法の優劣構造を確立した**: 2 登壇者の比較で見ると、両者の主張は同社の共通知見を裏付けると同時に、「SLO をカウンタまたはヒストグラムで実装せよ」という結論が 1 社の実装経験を超えて 2 つの独立した発表として提示されていることの重みを増す。Wilkinson (SREcon17 Americas) がアラート設計でバケット比率を先に示し、Hartmann・Moyer (SREcon19 EMEA・Americas) がレイテンシ SLO 計算の 3 手法として体系化し、Prometheus native histograms (2022〜) などが後続したという系譜が確認できる。(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 を技術閾値から顧客観察結果」へ変換する最短経路**: Stanke（2020）の SLO Policy は "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale を一行添え、技術閾値が顧客行動指標と結びついた根拠を持つことを示した。Gangatirkar（2018）の S 字曲線は「ユーザーが痛みを感じる閾値を特定してから SLO を設定する」手法を示したが、Stanke はその結果を SLO Policy ドキュメントの Rationale フィールドとして記述する形式を具体化した。SLO の目標値を「技術的最良実践」ではなく「ユーザー行動観察に基づく設計判断」として文書化する最も直接的な実装例である (Source: [[@2020__SREcon20Americas__Squish Level Objectives]], [[@2018__SREcon18Asia__Quantifying Empathy Through Service Level Objectives]])。 - **集計 SLO は「少数の大規模障害」を検知するが「多数の少量顧客への障害」を隠蔽する**: [[Alex Palcuie]]（SREcon22 EMEA）は Rachel Kroll (2019) の "Your nines are not my nines" を引き、プロバイダの集計 SLO が 99.999% を保つ一方で個別顧客が完全な障害状態になりうることを GCE の実データで示した。Gangatirkar (2018) の「共感ギャップ（SLO 達成・ユーザー不満）」を回避する最も直接的な実装は、SLO 粒度を「プロバイダ全体」から「顧客（プロジェクト）単位」へ細分化することである。Moyer (SREcon20 Americas) のエラーバジェット民主化（1,000 名規模の組織展開）と同方向だが、分割軸が「チーム」ではなく「外部顧客」である点が異なる (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 エラーのルール」で動的化する必要がある**: Palcuie は顧客単位 SLO のターゲットをトラフィック量に応じて `target = 1 - 5 / total_requests` と動的設定する手法を示した。1 万リクエスト以上で 99.95% に収束するが、1,000 リクエストでは 99.5%、10 リクエストでは 50% となる。一律 99.95% を小規模顧客に適用すると 1,000 リクエストで 1 エラーが出ただけで逸脱とみなされるため、エラーバジェットの意義が失われる。この動的ターゲットは Moyer (SREcon20 Americas) の「機械解析可能な公式・明示性」原則の顧客単位への拡張であり、かつ Hauer+ (2020) の「ウィンドウ付きユーザーアップタイム」がユーザーごとの均等加重で集計する発想とも通底する (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 と同一計算基盤で管理可能にする**: Palcuie は、ターゲットレイテンシ以内のリクエストを「fast request」と定義し、SLO ターゲットをパーセンタイル値と同値（P90 なら目標 90%）とすることで、複数 API・複数レイテンシ閾値を混在させたままカウンタ基盤で評価できることを GCE の本番 SLO として示した。Hartmann・Moyer (SREcon19 EMEA・Americas) が「パーセンタイルは時間窓・ノードをまたいで集計できない」と問題提起し「ターゲット以内の良いイベント比率への変換」を提唱した手法の、大規模本番実装事例として位置づけられる (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 モデルは「信頼性の測定」ではなく特定の問いへの回答モデルであり、ステークホルダーごとに問いが異なる**: Davidovič (SREcon22 EMEA) は、オンコールエンジニア（1 分窓/1 SLI）〜 CEO（>1 年窓/1,000 SLI）という 5 つの問いを挙げ、それぞれが時間窓・対象 SLI 数で全く異なる空間を占めることをバブルチャートで示した。Richard Hamming の「コンピューティングの目的は数字ではなく洞察だ」という引用を持ち出し、単一の SLO 集計がどの問いにも等しく答えられるわけではないことを強調する。この「問い先行・モデル後続」の原則は、Palcuie (SREcon22 EMEA) の顧客単位 SLO や Gangatirkar (2018) のユーザー幸福定義と同じ方向を持つが、分解軸が「ステークホルダーの認識目的」である点で新しい切り口を加える (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]])。 - **実務者はすでに SLO ウィンドウと目標値を無視したアドホックモデルを構築している**: Davidovič は、インシデント対応中のオンコールエンジニアが「緩和後の SLI が SLO 以上かどうか」を見ると言いながら実際には 15 分という恣意的な短窓を使い、SLO ウィンドウも目標値も参照していないことを赤注釈付きスライドで示した。この観察は、SLO の「時間窓・目標・評価頻度の 3 自由パラメータ」（SLO Model Recap）が現場では全て無視される場面があることを意味し、「直感的アドホックモデルの形式化こそが次のステップ」という論旨の出発点となる。MTTx メトリクスが実際の意思決定に使われていないことを Davidovič が O'Reilly レポートで示した流れ（[[@2021__OReilly__Incident Metrics in SRE]]）の続編として読める (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]], [[@2021__OReilly__Incident Metrics in SRE]])。 - **SLO モデルは時間・空間で線形性を仮定しており、集約によって深刻な問題を隠蔽する**: Davidovič は「1,000×1 分停止 = 1×1,000 分停止」という SLO の時間線形性問題と、「一部ユーザーへの完全障害 = 全ユーザーへの軽微な障害」という空間線形性問題を示した。後者は Palcuie の "Your nines are not my nines" 問題（顧客単位 SLO の動機）と接続するが、Davidovič はさらに「ユーザーへの完全障害がグローバル集計では検知不能になる」ことを US-West/US-East→User ヒエラルキーの合成ヒストグラムで視覚的に示した点が新しい。複数ソースが「集計は深刻な問題を隠す」という共通の限界を記録しており、信頼性測定の根本的構造問題として浮上する (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 導入の失敗要因が「技術」より「組織・人・プロセス」であることは複数のソースで独立に確認されている**: Takamura（Road to SRE NEXT 2026 神戸）は「SLO 採用は社会技術的問題」と明示し、Durst（SREcon25 EMEA）は 4 度の失敗事例でオブザーバビリティ基盤が揃っていても所有権・標準プロセス・保護時間がなければ SLO は定着しないことを示した。Smith（SREcon22 Americas）が「営業チームへの暗順応期間」を指摘した文脈と合わせると、SLO 導入の障壁は測定技術ではなく組織横断の調整コストにあるという観察が SRE 実務コミュニティの共通認識になっていると読める。SRE Workbook の「ステークホルダー合意」をプロセス論として実装するのが Coulter（2020）の交渉フローであり、それに先んじる「前提条件診断」が Durst の 4 条件チェックリストとして体系化された (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 定着の到達点が小規模スタートアップでも到達可能であることを示す**: Palcuie（GCE）や Moyer（Zendesk）の大規模組織での SLO 成熟と同じゴール（信頼性が組織の意思決定に組み込まれた状態）を、Spring Health（200 名エンジニア・8 SRE）が達成した。Takamura の「定着 Lv5」は大組織の話として受け取られがちだが、ハイパーグロース・スタートアップでも 3 年間（Attempt #1: 2022 → 成功: 2025）で到達可能であることが実証された (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 年に実践者視点から整理された**: [[Alex Hidalgo]] は SREcon19 EMEA で、信頼性スタック（SLI→SLO→エラーバジェット）の導入前に「3 原則」を置いた——(1) 信頼性がサービスにとって最も重要な特性である、(2) ユーザーが「信頼できる」とはどういうことかを決める、(3) どんなものも常に動き続けるわけではないので目標にするな——。SRE Book が「99.9% の可用性」の計算から始めるのに対し、Hidalgo は「なぜ SLO を作るのか」という動機の合意を最初に求めた。Squarespace ELK の SLO（99% / 5 分以内）は 1 日後の障害でエラーバジェット枯渇が宣言できたことで、「組織的に信頼性対応を優先する許可証」として即座に機能した。単一コンポーネント障害の対応をやめ「ELK 全体の全力修復」に入れたのは、SLO + エラーバジェットという仕組みがあってはじめて組織内で正当化できた。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) - **SLI は「悪い挙動」ではなく「成功」を定義すべきである**: Furino は、エラーを定義する場合は既知の問題のみをカバーする（有限スコープ）が、成功を定義すれば「それ以外はすべて不確か」という包括的定義になると論じた。Availability SLI = Service Connect API への 2XX/3XX/4XX のリクエスト割合（ロードバランサ計測）という具体例も示す。SRE Workbook の「良いイベント数 / 全イベント数」型 SLI を「良い = 成功の定義から導く」という設計原則として再解釈したものと読める (Source: [[@2023__SREcon23EMEA__9 Things You Should Do When Starting to Use SLOs]])。 - **同一 SLI を異なる時間窓で評価することで 3 つのステークホルダーペルソナに対応できる**: Furino は SRE/Ops（24h/48h）・開発チーム（14D/2W）・アーキテクト/リーダーシップ（Monthly/Quarterly）という 3 ペルソナ別の時間窓を提案した。Davidovič（SREcon22 EMEA）がバブルチャートで示したステークホルダー別「問いの空間」を、実装可能な時間窓マッピングとして具体化した実践的解釈と読める。Davidovič の 5 ペルソナ（オンコール〜CEO）を実務的な 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）は均等加重ユーザーアップタイムの「重み付き変形」である**: Hauer+（NSDI 2020）の「ウィンドウ付きユーザーアップタイム」は全ユーザーを均等加重で集約するが、Riot Games の Player Minutes は CCU（同時接続ユーザー数）で各分を重み付けする。大規模インシデントほど大きく反映され、季節変動（ピーク時の CCU 増減）も自動的に吸収される。「有意義性（ユーザー体験を捉える）」と「比例性（変化に比例する）」の両要件を Hauer+ と同様に満たしつつ、重み付けロジックが「ユーザー均等」ではなく「CCU 比例」である点が異なる（Source: [[@2025__SREcon25Americas__Measuring Availability the Player Focused Way - How Riot Games Changed Its Availability Culture]], [[@2020__NSDI__Meaningful Availability]]）。 - **SLO 定着の最速経路として「CEO 強制の OKR 接続」が有効**: SLO 導入失敗の主要因が「組織・人・プロセス」であることは複数ソースで確認されている（Durst SREcon25 EMEA、Smith SREcon22 Americas、Takamura 2026 神戸）。Riot Games はこれを「CEO が会社レベル OKR を強制する」という最強の手段で突破した。同時に「CTO スポンサー」「グラスルーツ（テックリード層）」「スタジオリード向け幹部トレーニング」という三層も機能しており、トップダウン単独では組織定着が難しいことを示唆する（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（プロダクトオーナー）が使う主動機は「チームで判断を回す」こと**: 渡辺は SRE NEXT 2023 で、Mackerel の SLO 導入動機を「判断と改善をチームで回したい」と明示した。PO が信頼性に関わる技術的判断を個人で担う代わりに、SLO という数値基準でチームが自律的に判断できるようにする——判断が減ることが PO にとっての嬉しいポイントと述べた。SRE Book が SLO を「開発チームと SRE の共通インセンティブへの変換」として位置づけた方向の延長だが、PO という「ビジネス側の意思決定者」も受益者になるという視点を実践ベースで追加する。Jones・Murphy（SREcon16）の「SRE が No から Yes/if へ転換する」という帰結が、PO 視点では「PO の判断依頼が減る」という形で発現する (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2016__SREcon16__Service Levels and Error Budgets]])。 - **信頼性をユーザー主語で定義することが SLI 選択の出発点になる**: 渡辺は O'Reilly SLO 本を引用し「ユーザーの期待に沿っているか」を信頼性の定義として採用した。レイテンシ・エラー率という技術指標から出発するのでなく、ユーザーが感じる信頼性から逆算して指標を選ぶ動機付けとして機能する。Gangatirkar（SREcon18 Asia）の「S 字曲線でユーザーが痛みを感じる閾値を特定して SLO を設定する」と同方向であり、SRE Book（2016）の「ユーザーが気にする SLI を選ぶ」原則をチームが腹落ちする前提として機能する。Mackerel では外形監視で「サービスに到達できない状態が正しい挙動」になる場合もあるという特殊ケースが示すように、ユーザー主語の定義はサービス固有の難しさも露出させる (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 に従って行動する」は別の困難として分離して管理する必要がある**: 近藤（SRE NEXT 2022）は、2 プロダクト 15 チームへの SLI/SLO 導入（定義・観察）には成功したが、SLO 違反時のアーキテクチャ変更・インフラ分離といった根本対処まで至らなかった失敗を報告する。失敗の根本原因は「測定・観察の文化不足」ではなく「非機能要求への予算・権限が開発チームになかった」という組織的制約であり、技術戦略グループの発足と予算配分（新規:エンハンス:技術的負債 = 1:1:1）という制度的変更が解決をもたらした。Durst（SREcon25 EMEA）が 4 前提条件（所有権・標準プロセス・保護時間・SLO 計測基盤）を導入前に確認すべきと論じた観点に「非機能要求の予算配分権限」という第 5 の前提条件が加わる (Source: [[@2022__SRENext2022__Who owns the Service Level?]], [[@2025__SREcon25EMEA__Run Walk Crawl or How We Failed Our Way to SLO Readiness]])。 - **「仮値から始めてフィードバックで洗練する」アプローチが SLO 定着の共通パターンとして独立に確認される**: 渡辺は「SLI と仮値を決めて見直しフローを作り、まずとりあえず始めた」と述べ（SRE NEXT 2023）、Takamura（Road to SRE NEXT 2026 神戸）は「小さく始める」4 ステップを体系化し、Durst（SREcon25 EMEA）は 4 前提条件確認後の段階的導入を、Hidalgo（SREcon19 EMEA）は「翌日障害でエラーバジェット枯渇したが許可証として即座に機能した」と述べた。3 社 4 名の実践者が独立に「完璧な値を追い求めず動かしながら修正する」を成功の起点として選んでいる——これは SLO 導入の技術的困難（SLI 設計の難しさ・ステークホルダー合意）より「動かした実績が合意を作る」という組織的ダイナミクスを優先した判断と読める (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設計の起点になる**: Luup では電動キックボード・電動アシスト自転車という物理デバイスを対象に「マシンが期待通りに動作できる状態であるか」を測定する CMC という概念を Luup 内で作成した（CUJと区別するための用語）。計測対象は定期通信（MQTT/LwM2M）の応答や通信途絶、ハードウェアエラーなど。坪内の IOTS2025 発言（「現実世界に染み出してくるともっと面白い SLI が出てくる」）が指摘した方向を、実際の CMC 概念と IoT 自動サービスアウト実装として具体化した事例と読める。SRE Workbook の CUJ 定義（「あるユーザーの体験の中核部分となるタスクの並びで、サービスのきわめて重要な側面」）を物理デバイスに拡張した場合、計測対象がアプリリクエストからデバイス通信に切り替わる（Source: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]], [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]]）。 - **Enabling SLO の組織的アプローチとして「習熟度調査→勉強会→Lead 直接コミュニケーション」が有効**: Luup SRE チームは「開発者・PdM に SLO を伝導・導入する」ために、まず SLO 習熟度調査（14 問、エンジニア＋PdM 対象）で現在地を把握し、その結果をフィードバックして構成した SLO 勉強会（背景・SLI/SLO 基本・Luup SRE の運用状況の 3 部構成）を実施した。特定チームには Embedded SRE の代わりに Developer Lead との直接コミュニケーションで導入を進めた。Takamura（2026 神戸）の「小さく始める 4 ステップ」や SIE（SREcon23 EMEA）の「Reliability Meetup」と並び、SLO の組織横断定着を「知識普及→個別導入」の二段階で設計した実践事例として記録される（Source: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]）。 ## 未解決の問い - ウィンドウ付きユーザーアップタイムは Google G Suite（プロダクティビティスイート）で評価されたが、マイクロサービスベースのクラウドインフラ（IaaS/PaaS）に直接適用可能か。IaaS ではユーザーの「リクエスト」を定義すること自体が困難では。 - SLO 拡散のベイズネットワークモデルは静的なパイプライン構造を前提とするが、動的にスケーリングするマイクロサービス環境でのリアルタイム更新は実現可能か。 - SLE/CBE 枠組みは概念的提案にとどまり、実装・評価は未着手。実際のクラウドプロバイダでの採用事例は報告されていない。 - SRE Workbook の「良いイベント数 / 全イベント数」型 SLI はリクエスト駆動サービスに適用しやすいが、ユーザー行動が断続的な低トラフィックサービスや非同期パイプラインでは、どこまで同じ形に正規化できるか。 - 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 定義のために「上位サービス（顧客）へ聞く」プロセスは、コアインフラチームと開発チームの間にどう制度化されているか（レビュープロセス、頻度、担当者）。 - **複合 SLI（Latency AND Availability）は OR 結合により単一のエラーバジェットで両次元を管理できる**: Moyer（SREcon20 Americas）は、可用性 SLI「response code != 5xx」とレイテンシ SLI「served in < 100ms」を OR で結合し、一つの SLI として扱うことで単一 SLO・単一エラーバジェットで両方を管理する手法を示した。Hartmann（SREcon19 EMEA）の「レイテンシ SLO はしきい値内の good event 比率で実装する」という原則を、可用性との複合に拡張した事例として読める。(Source: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) - **Moyer (SREcon20 Americas) は 2 年連続の連作で「レイテンシ実装 → 複合 SLI・組織展開」の階層を進んだ**: SREcon19 でパーセンタイル集約の誤りとヒストグラム計装を示し（[[@2019__SREcon19 Americas__Latency SLOs Done Right]]）、SREcon20 でその実装を Zendesk 1,000 名規模に展開するための公式化・複合 SLI・マルチサービス EB 問題へ発展させた。「何を測るか → どう実装するか → どう組織に展開するか」という SLO 導入の 3 段階を一人の実践者が連続発表でカバーした稀有な事例。(Source: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]], [[@2019__SREcon19 Americas__Latency SLOs Done Right]]) - SLO Algebra の体系化に向けて、依存関係の共有障害（shared fate）・フェイルオープン/クローズド挙動・直列/並列消費を数学的にどうモデル化するか。Mogul+Wilkes の CBE（顧客挙動期待）の枠組みを SLO 合成に適用できるか。 - ユーザー幸福の 6 フレーバー（Availability/Responsiveness/Freshness/Completeness/Accuracy/Breadth）は exhaustive か。特に AI 生成コンテンツの品質評価（ハルシネーション率等）はどのフレーバーに分類されるか、または 7 番目のフレーバーが必要か。 - ~~非同期パイプラインでは 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]]）。 - S 字曲線のしきい値をデータから特定する具体的手法は何か（アンケート、離脱率分析、サポートチケット数等）。Gangatirkar の発表では「データでユーザーの痛みを探す」とだけ述べられており、手法は不明。 - 共感ギャップの発見と解消を組織として継続するプロセス（定期レビュー頻度、担当者、合意形成方法）はどう設計するか。 - SLX の SLF（Service Level Factor）と SLD（Service Level Dependency）を大規模サービスで全網羅的に定義・維持するコストは妥当か。高カーディナリティ爆発（コンテナ ID など）を避けながら調査に有用な粒度を維持する実践的な基準はあるか。 - SLX Graph を用いた「時系列相関のある異常 SLO 依存チェーン」の絞り込みは、相関 ≠ 因果の罠を引き起こさないか。検知（Detection）と根本原因分析（RCA）の責任境界をどう設けるか。 - CCU ベースのプレイヤー分計測はゲームサービスに特有のユーザー行動量計測だが、同様のアプローチをストリーミングサービス（視聴中ユーザー数 × 分）や EC（セッション中ユーザー数 × 分）へ拡張する場合、「アクティブセッション」の定義をどう標準化するか。 ## 関連 - ソース: [[@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]] - エンティティ: [[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]] - 概念: [[AIOps]] / [[agentic SRE]] / [[エージェント運用安全性]] / [[Transactional No-Regression]] / [[インシデント管理]] / [[エラーバジェット]] / [[SLI-SLO段階的導入]] / [[データ品質SLO]] / [[Player Journey]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@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 による定着手法)