# SLI/SLO 教科書 > [!abstract] 概要 > 本文書は、SRE における SLI/SLO/SLA フレームワークを、基礎定義から組織的導入、応用領域まで網羅的にまとめた教科書である。SRE Book、SRE Workbook、SREcon 各年の発表、学術論文、国内実践事例など 49 件の文献を横断的に統合する。 --- ## 第 0 章　歴史的起源 SLI/SLO の概念はソフトウェアに固有のものではない。1984 年の米国高速道路管理では、(1) Asset Quality Index(路面のラフネスなど材料品質の絶対尺度)と (2) Customer Happiness Index(平均渋滞時間、平均車速、交通密度)という 2 種の指標が定義され、「Levels of Service」という用語で呼ばれていた。下水道管理でも同様に、パイプあたりのひび割れ数(資産品質)と水洗の稼働率(顧客満足)が区別されていた [1]。 2003 年、Ben Treynor Sloss（Google）が SRE チームを創設し、ソフトウェアエンジニアリングの手法を運用に適用するディシプリンを確立した。SLI/SLO/SLA フレームワークとエラーバジェットは、2014 年の SREcon14 基調講演で初めて公に体系化され [2]、2016 年の SRE Book で理論的基盤が確立された [3]。 --- ## 第 1 章　基礎概念 — SLI/SLO/SLA フレームワーク ### 1.1 SLI(サービスレベル指標) SLI はサービスの振る舞いを定量的に計測する指標である。リクエストレイテンシ、エラー率、スループット、可用性などが典型例にあたる。SLI はサービスの健全性を直接反映する**計測値**であり、目標値ではない [3]。 SRE Workbook は SLI を「良いイベント数 / 全イベント数」の比率として設計することを推奨する。0% は何も動かない状態、100% は何も壊れていない状態という直感的な尺度になり、SLO とエラーバジェットに接続しやすい [4]。 重要な設計原則として、SLI は**仕様**と**実装**に分けて考える。 - **SLI 仕様**: ユーザーにとって意味のある評価(例:「リクエストが 200ms 以内に正常応答を返す」) - **SLI 実装**: それをどこでどう測るか(例:「ロードバランサのアクセスログで HTTP 5xx 以外を成功、レスポンスタイム 200ms 以下を高速と数える」) ### 1.2 SLO(サービスレベル目標) SLO は SLI の目標値あるいは許容範囲である。「SLI ≤ target」の形をとる。例:「リクエストレイテンシの p99 が 200ms 以下」。SLO はサービスの信頼性に関する**内部的な目標**であり、外部への約束ではない [3]。 ### 1.3 SLA(サービスレベル合意) SLA は SLO に**違反時の罰則(consequences)**を付加した明示的な契約である。SLO + 帰結 = SLA と定式化される [5]。SLA は通常、外部顧客との間で締結される。 SLI → SLO → SLA は抽象度が上がる方向の階層をなす。SLI なしに SLO は定義できず、SLO なしに SLA は意味を持たない。 ### 1.4 なぜ 100% を目指さないのか SRE の核心原則の一つは、100% の可用性を追求しないことである。理由は 3 つある。 1. ユーザーは 99.99% と 99.999% の差を検知できない 2. 信頼性改善のコスト曲線は非線形であり、各増分が前回の 100 倍のコストを要する 3. 顧客側の依存関係(端末、ネットワーク)も含めると、100% の体験は物理的に不可能 [6] --- ## 第 2 章　SLI の設計 — 何を・どこで・どう測るか ### 2.1 サービス種別ごとの優先指標 | サービス種別 | 優先 SLI | |---|---| | ユーザー向けサービス | 可用性、レイテンシ、スループット | | ストレージシステム | 耐久性、可用性、レイテンシ | | ビッグデータパイプライン | スループット、エンドツーエンドレイテンシ | [3] SRE Workbook は、リクエスト駆動サービスには成功応答率・閾値以下レイテンシ・劣化なし応答の割合を、パイプラインにはデータ鮮度・正確性・カバレッジを、ストレージには書き込んだレコードが読み出せる割合を推奨する [4]。 ### 2.2 パーセンタイルの重視 レイテンシ指標を**平均値**で評価してはならない。平均はテールレイテンシの情報を潰す。推奨される計測はパーセンタイルであり、特に p50(典型的体験)、p99(テール)、p99.9(最悪体験)が重視される [3]。 ただしパーセンタイルには重大な実装上の制約がある。Hartmann（Circonus）は、時間ごとの p90 を平均すると全体分布から計算した p90 とずれることを示し、**パーセンタイルは複数時間窓・複数ノードをまたいで集約できない**ことを実務上の問題として定式化した。解決策は「しきい値以内のリクエスト数 / 全リクエスト数」という良いイベント比率に変換することである [7]。 ### 2.3 測定点の選択 Jones・Murphy（Google）は SREcon16 で、サーバー側レイテンシを測りがちな Google の実態を「間違い」と認め、クライアント側が実際のユーザー体験を正確に反映すると述べた。**制御しやすい場所で測る(locus of control)のと、ユーザーに意味のある場所で測る(locus of measurement)のは異なる** [8]。 SLI 実装の選択肢には、サーバーログ・ロードバランサ監視・ブラックボックス監視・クライアント側計装があり、それぞれ品質・カバレッジ・コストのトレードオフがある [4]。 ### 2.4 ケイパビリティ駆動の SLI 設計 New Relic の Binette・Flaming は、システム境界ごとに「公開するケイパビリティ」を列挙し、各ケイパビリティの「利用可能」を平易な言葉で定義してから技術的 SLI に落とす 7 ステップレシピを示した。SLI 設計で「何を測ればいいかわからない」という難点を、**「システム境界の機能一覧を作る」という操作可能な第一歩に変換**する [9]。 ### 2.5 「成功」を定義すべき理由 SLI は「悪い挙動」ではなく「成功」を定義すべきである。エラーを定義する場合は既知の問題のみをカバーする(有限スコープ)が、成功を定義すれば「それ以外はすべて不確か」という包括的定義になる [10]。 ### 2.6 ユーザー幸福の 6 フレーバー Gangatirkar（Indeed）は SLI 候補を 6 種に整理した: Availability / Responsiveness / Freshness / Completeness / Accuracy / Breadth。この枠組みとケイパビリティ列挙を組み合わせると、SLI 候補の見落としを防ぎつつサービス固有に具体化できる [11]。 ### 2.7 集約インターバルの問題 SREcon16 で Jones は、同じデータが 1 分インターバルでは平坦、30 秒では散発的スパイク、1 秒では「毎分先頭に全リクエストが集中」と見えることを示した。SLI 設計において「何を測るか」の前に「**どのウィンドウで見るか**」という問いがある [8]。 --- ## 第 3 章　SLO の設定 — 目標値の決め方 ### 3.1 初期 SLO は正解でなくてよい 初期 SLO は正しくなくてよい。安価に測れる指標から始め、ユーザー満足・既知障害・サポートチケット・エラーバジェット損失との相関で継続改善する [4]。 Evernote は月次 99.95% 稼働率という単純な初期 SLO で開始し、月次レビューと半年ごとの見直しで改善した [12]。 ### 3.2 S 字曲線で痛みのしきい値を特定する Gangatirkar は可用性(横軸)対ユーザー幸福度(縦軸)の S 字曲線を用い、SLO はユーザーが不満を感じ始める前の水準に設定すべきだとした。屈曲点が痛みのしきい値であり、SLO はそれより下に設定する [11]。 ### 3.3 共感ギャップ Gangatirkar の 2×2 マトリクスは重要な概念を定義する。 | | SLO 達成 | SLO 未達 | |---|---|---| | **ユーザー満足** | 正常 | 過剰達成の幻影 | | **ユーザー不満** | **共感ギャップ** | 正常 | 「SLO 達成・ユーザー不満」のセルが共感ギャップ(Empathy Gap)であり、SLO がユーザーの痛みのしきい値より緩く設定されている場合に発生する [11]。 ### 3.4 SLO の Rationale をユーザー行動データで根拠づける Stanke（Google）は SLO Policy に "Error rates greater than .05% correlate with significant increase in customer support tickets" という Rationale を添え、技術閾値が顧客行動指標と結びついた根拠を持つことを示した [13]。 ### 3.5 多段パーセンタイル定義 単一の「99% の応答が X 秒以内」では、X 秒を超える 1% の分布を制御できない。多段定義(90%/30s・99%/1min・99.9%/5min)は「速い応答の大多数」と「遅い応答の尾部」を別々に制御する。SLO を「しきい値の通過/未通過」から「分布の制御」として扱うアプローチである [14][15]。 ### 3.6 SLO 公表の重要性 Jones・Murphy は SREcon16 で、**SLO を公開しないサービスではユーザーが「今の性能が永遠に続く」と期待し始め、将来の設計変更・コスト最適化の選択肢が失われる**と警告した。対処として「意図的なダウンタイムを入れるシステムが Google に実在する」と明かした [8]。 ### 3.7 SLO 文書の構成 Appendix A の Example Game Service は、SLO 文書の構成要素を示す。 - サービス概要と対象カテゴリ - SLI 定義(何を、どこで測るか) - SLO 目標値と評価ウィンドウ(4 週間ローリング) - 根拠(履歴データと丸めルール) - エラーバジェット計算 - 但し書きと限界 SLO は可用性だけでなく、レイテンシ、鮮度、正確性、完全性など、ユーザー価値に対応する複数次元で定義できる [16]。 --- ## 第 4 章　エラーバジェット — SLO を組織的意思決定へ接続する ### 4.1 定義と原理 エラーバジェットとは、SLO で許容される障害量の上限を「予算」として扱い、開発チームと SRE が共有する信頼性管理の仕組みである。SLO が 99.9% ならば 0.1% のエラーバジェットを持つ。予算を消費しきった場合はリリースを凍結して信頼性改善に集中する [6]。 エラーバジェットの最も重要な組織効果は、SRE が「ノー」から「イエス、もし〜ならば」へ転換することである。プロダクト開発チームが SRE を迂回しようとしなくなるのは、迂回するとエラーバジェットを自ら消費するだけだからである [8]。 ### 4.2 起源 エラーバジェットの起源は「SLA を超えすぎることへの気づき」である。Alvidrez（Google）は SREcon15 で、AdSense が 2009 年に SLA を一貫して超えた状態を「機会の損失」と語った。超過分は「速く動く・少ないリソースで動く」ために使えた。この逆転の発想が概念の個人的な起源である [17]。 ### 4.3 エラーバジェットポリシー SRE Workbook Appendix B は具体的なポリシー例を示す。 - 直近 4 週間でエラーバジェットを超過 → P0・セキュリティ修正以外の変更停止 - 単一インシデントが 4 週間予算の 20% 超消費 → ポストモーテムと P0 アクションアイテム - 単一障害クラスが四半期予算の 20% 超消費 → 翌四半期計画に P0 項目 重要な解釈: この方針は罰ではない。変更停止は望ましい状態ではないが、信頼性データが「今は機能より信頼性を優先すべき」と示すとき、チームが信頼性に集中するための**制度的許可**として機能する [18]。 ### 4.4 バンバン制御からプロポーショナル制御へ Jones は SREcon16 で、エラーバジェットを二値切り替え(「リリース全開」→「リリース全停止」)ではなく、バーン率の連続的な監視に基づく速度制御として使うべきだと説明した。制御工学でいう「バンバン制御」から「プロポーショナル制御」への移行である [8]。 ### 4.5 時間スライス vs イベントベース集計 99.95 SLO + 95% 閾値による時間スライス方式では、ピーク時(1 分 1,000 リクエスト)と深夜(1 分 10 リクエスト)を同じ 1 票として扱う。結果、「軽微なエラーが多い時間帯の 1 分」が予算を大きく削る一方、深夜の大規模障害が反映されにくい逆転現象が生じる。イベントベース集計に切り替えると深刻度に比例した消費になり、エラーバジェットが「信じられるシグナル」として機能する [19]。 ### 4.6 エラーバジェットの拡張適用 Thomson・Laing（Pivotal）は SLI/SLO/ポリシーのモデルがドメイン非依存の汎用構造であることを示した。 - **脆弱性バジェット**: SLI = 依存パッチリリースからの経過日数、SLO = 最大許容日数 - **フィーチャーフレッシュネス**: SLI = フィーチャーリリースからの経過日数、SLO = ブリーディングエッジ度の範囲 Equifax 侵害(CVE-2017-5638)の事例で「30 日 SLO のパッチ適用ポリシーがあれば 67 日後の侵害は防げた」と実証した [20]。 --- ## 第 5 章　SLO ベースアラーティング ### 5.1 設計原則 SLO ベースアラートの目的は、エラーバジェットを大きく消費する重大イベントを、予算消費前に通知することである。アラートはエラー率の異常ではなく、エラーバジェットへの重大な脅威に対して出す [21]。 ### 5.2 評価軸 - **精度**: 検知されたイベントのうち重大イベントである割合 - **再現率**: 重大イベントのうちアラートされた割合 - **検知時間**: 通知までの時間 - **リセット時間**: 解決後にアラートが残る時間 ### 5.3 バーンレート バーンレートは SLO に対してどれだけ速くエラーバジェットを消費しているかを表す。 | バーンレート | エラー率 | 30 日・99.9% SLO での枯渇予測 | |---|---|---| | 1 | 0.1% | 30 日 | | 2 | 0.2% | 15 日 | | 10 | 1% | 3 日 | | 1000 | 100% | 43 分 | [22] ### 5.4 推奨構成: 複数ウィンドウ・複数バーンレート 推奨開始点: - **ページ用**: 1 時間 2% 予算消費 + 6 時間 5% 予算消費 - **チケット用**: 3 日 10% 予算消費 短窓を長窓の 1/12 程度に置き、長窓と短窓が同時に閾値を超えるときだけ通知すると、精度とリセット時間のバランスが改善する [21]。 Wilkinson（Google）は Prometheus で `delta(errors[1h]) > (expected_events * error_budget / burn_period)` を SLO Fast Burn アラート式として示した [23]。 ### 5.5 バーンレートグラフの読み方 EBR グラフ上で識別すべき 4 パターン: 1. **Slow burn**: 変更起因のじわじわ消費 2. **Fast burn**: 大規模インシデントによる急激消費 3. **Recovery**: バグ修正後の回復 4. **No Incident drain**: インシデントなしの緩慢消費(バグ起因の遅延劣化。バーンレートアラートだけでは捕捉困難) [19] ### 5.6 低トラフィック・極端な可用性目標 - **低トラフィック**: 10 リクエスト/時では 1 失敗が 10% エラー率。対策は人工トラフィック、関連サービスの上位集約、SLO 再交渉 - **99.999% 目標**: 100% 障害が 26 秒で予算枯渇。アラートでは守れないため、カナリアリリースなど設計で全停止確率を下げる [21] ### 5.7 SLO アラート発火後の設計 SLO アラートは「鳴らす条件」だけでなく「鳴った後に何を見ればよいか」を含めて設計されるべきである。池田将士（面白法人カヤック）は SRE NEXT 2023 で、Warning アラートに対し対象期間のリクエストパス別レスポンスタイムを自動集計する仕組みを示した [24]。 --- ## 第 6 章　可用性指標の限界と進化 ### 6.1 ナインだけでは不十分 Mogul+Wilkes（Google）は「ナインだけでは不十分」と論じ、3 つの限界を指摘した。 - 短時間断続障害と長時間大規模障害を区別できない - グレースフルデグラデーションを記述できない - ビジネス的重要日の重み付けができない [5] ### 6.2 良い可用性メトリクスの三要件 Hauer+（Google）は「良い可用性メトリクスは**有意義性**(ユーザー体験を捉える)・**比例性**(変化に比例する)・**実用性**(原因の洞察を与える)の三要件を同時に満たすべき」と定式化した [25]。 既存指標の限界: - **成功率**: 最活発ユーザーに最大 1,000 倍偏り、障害中のリクエスト断念を過少評価 - **インシデント比**: 任意の「インシデント」しきい値に依存し、大規模分散システムに不適切 - **合成プローブ**: ユーザーの実際のワークロードを代表しない ### 6.3 ウィンドウ付きユーザーアップタイム Hauer+ が Google G Suite で評価・本番展開した新指標: 1. 各ユーザーの細粒度リクエストログからアップ分・ダウン分を算出し、全ユーザーの均等加重平均で集約 2. 1 分から四半期まですべてのウィンドウサイズで最悪可用性を算出し、MCR(Maximum Contiguous Ratio)曲線として可視化。「膝」の位置で短時間断続障害と長時間大規模障害を区別 [25] ### 6.4 SLE/CBE — 法律家的思考から統計家的思考へ Mogul+Wilkes は SLO 定義の困難さを統計学的意思決定との同型性として捉え、転換を提唱した。 - **SLE(サービスレベル期待)**: プロバイダが通常条件下で顧客に期待させる挙動。結果保証ではなく期待管理 - **CBE(顧客挙動期待)**: プロバイダが SLE を満たすために前提とする顧客側の挙動 [5] ### 6.5 集計が隠す問題 SLO モデルは時間・空間で線形性を仮定しており、集約によって深刻な問題を隠蔽する。 - **時間線形性**: 1,000×1 分停止 = 1×1,000 分停止と扱われるが、ユーザー影響は全く異なる - **空間線形性**: 一部ユーザーへの完全障害 = 全ユーザーへの軽微な障害と扱われる [26] Palcuie（Google）は「プロバイダの集計 SLO が 99.999% を保つ一方で個別顧客が完全な障害状態になりうる」ことを GCE の実データで示し、顧客単位 SLO への移行を推進した [27]。 ### 6.6 「5 エラーのルール」による動的ターゲット 少トラフィック顧客への一律 SLO 適用は現実的でない。Palcuie は顧客単位 SLO のターゲットをトラフィック量に応じて `target = 1 - 5 / total_requests` と動的設定する手法を示した。1 万リクエスト以上で 99.95% に収束するが、10 リクエストでは 50% となる [27]。 --- ## 第 7 章　SLO の組織的導入 — 技術から文化へ ### 7.1 段階的導入が鍵 SLO 導入の失敗要因が「技術」より「組織・人・プロセス」であることは複数のソースで独立に確認されている [28][29]。 Takamura（Topotal）は SLO 違反ポリシーの段階的拡大を体系化した。 | レベル | アクション | |---|---| | Lv1 | なにもしない(計測と可視化のみ) | | Lv2 | 調査判断のトリガーとする | | Lv3 | チーム内でアクション実行 | | Lv4 | 他チームとの調整を含むアクション | | Lv5 | 開発スケジュールの意思決定に SLO を組み込む | [29] ### 7.2 「仮値から始めてフィードバックで洗練する」 4 名の独立した実践者が共通して「完璧な値を追い求めず動かしながら修正する」を成功の起点として選んでいる。 - 渡辺起(Mackerel, SRE NEXT 2023):「SLI と仮値を決めて見直しフローを作り、まずとりあえず始めた」 - Takamura(Topotal, 2026 神戸):「小さく始める」4 ステップの体系化 - Durst(Spring Health, SREcon25 EMEA): 4 前提条件確認後の段階的導入 - Hidalgo(Squarespace, SREcon19 EMEA):「翌日障害でエラーバジェット枯渇したが許可証として即座に機能した」 [30][28] ### 7.3 ステークホルダーの「暗順応期間」 Smith（Campspot）は SLO 導入事例で、営業チームを SLO ワークショップに招いたところ「Uptime 99.999% の話ではないのか」と混乱が生じたと報告した。「可用性 = 稼働率」から「良い体験の割合」への認知的転換には準備期間が必要であり、SLO 実装の前に非技術ステークホルダーとの「Adjust」フェーズを設けるべきだとする [31]。 ### 7.4 SLO は交渉プロセスである Coulter（AppDynamics）は SLO を技術的に「正しい値を計算する」問題ではなく、ステークホルダー交渉として扱う視点を示した。「Prepare to Engage → Warmup → Test Drive → Assess → Propose → [RECUR] → Agree」という反復的交渉フローを提案し、SLO は一度合意すれば終わりではなく継続的に再交渉されるものとして設計される [14]。 ### 7.5 組織的前提条件 近藤武士(Recruit, SRE NEXT 2022)は、SLI/SLO の定義・観察文化を 2 プロダクト 15 チームに導入した後も、Error Budget Policy が定着しなかった原因を「**非機能要求に対処する予算・権限が開発チームになかった**」と分析した。技術戦略グループの発足と「新規:エンハンス:技術的負債解消 = 1:1:1」という予算宣言が解決をもたらした [32]。 Durst(Spring Health, SREcon25 EMEA)は導入の 4 前提条件を示した: (1) 所有権、(2) 標準プロセス、(3) 保護時間、(4) SLO 計測基盤 [28]。 ### 7.6 実導入事例の比較 | 組織 | 規模 | アプローチ | 結果 | |---|---|---|---| | **Evernote** | 2.2 億ユーザー | 外形監視ベースの月次 99.95% から開始、Google CRE と協働 | リリース窓 5→2 回に削減 [12] | | **The Home Depot** | 2,200 超店舗 | VALET 枠組み + 自動収集基盤 + 管理職インセンティブ | 0→800 サービスを 1 年未満で展開 [12] | | **Atlassian** | 大企業 | Error Budgets 0.1(13 週中 7 週未達でアクション)から開始 | 段階的に基準引き締め [33] | | **Squarespace** | 中規模 | Ceph Object Storage に 6 ステップで SLO 実装 | プローバー計測で新規サービスの SLI 確立 [34] | | **Spring Health** | 200 名 / 8 SRE | 3 年間の試行錯誤後にエラーバジェット起点のコードフリーズ RFC 経営承認 | スタートアップでも Lv5 到達可能を実証 [28] | | **Riot Games** | ゲーム | Player Minutes(CCU 重み付き)+ CEO OKR 強制 | 文化変革を 3 層で推進 [35] | | **Ant Group** | 60+ K8s クラスタ | GitOps + K8s 宣言的管理で SLO 爆発問題を吸収 | 99.999% 目標を運用 [36] | --- ## 第 8 章　応用と拡張 ### 8.1 データ集約型サービスの SLO Booking.com では可用性・レイテンシ SLO だけではステークホルダーが関心を持たなかった。**データの一貫性・新鮮性・完全性・耐久性**を「データ品質 SLO」として計測・目標化するまでは SLO が意思決定に使われなかった。SLO が明確に定義されると、Freshness Probe がトラフィック自動停止(自動緩和)、Completeness Probe が Hadoop スナップショットからの再処理(自動修復)のトリガーとして機能した [37]。 ### 8.2 非同期パイプライン eBay は可用性 SLI(SUCCESS / ABANDONED 比率)とレイテンシ SLI(累積 end-to-end histogram)の 2 種類で、非同期パイプラインの Freshness・Quality・Throughput を代替できることを実装で示した。バーンレートアラートに加えて `absent(sum(sli_valid_events{...}))` でメトリクス欠損を検知するデータ損失アラートを併置する必要がある [38]。 ### 8.3 SLO 拡散(高レベル→低レベル分解) Sedlak+（TU Wien）はマイクロサービスパイプラインにおいて高レベル SLO を自動的に低レベル SLO へ分解する 3 ステップ方法論を提案した: (1) ベイジアンネットワーク学習(BNL)によるサービス変数間の条件付き依存グラフ構築、(2) 高レベル SLO 変数からグラフを遡り変数消去法で許容範囲を推定する拡散(HLD)、(3) 重複制約の矛盾検知と自律的解決(CIR)。評価では VehicleRouting・TrafficPrediction・LiveMonitoring の 3 パイプラインで高レベル SLO 達成率 83〜100% を達成した。 制約の厳しさを決める超パラメータ **λ** には重要なトレードオフが確認された。λ を大きくする(許容範囲を狭める)と高レベル SLO 達成率は向上するが、過度に大きくすると低レベル SLO 間でコンフリクトが発生し達成率が 0 へ急落する。コンフリクトは積集合が空でない**マイナーコンフリクト**(交差区間を採用して自動解決)と、互いに素な**メジャーコンフリクト**(解決不能として開発者へ通知)の 2 種に分類される。低レベル SLO 充足率は常に高レベル SLO 充足率より高く、高レベル充足は低レベル充足の帰結として得られることも確認された [39]。 ### 8.4 SLX — 調査のための拡張フレームワーク SLO は検知には強いが調査には向かない。Ding・Zhang（Ant Group）は補完概念として SLF(SLI を詳細ラベル次元でスライス)と SLD(依存サービスのメトリクス)を追加し、SLX Graph をグラフ走査することで異常 SLO 依存チェーンを自動絞り込む [36]。 ### 8.5 ハードシャードシステム 水平スケールでは 3 ノード中 1 ノード障害 = 全体 SLO 66%(比例反映)だが、ハードシャードでは SLO 0%/100%/100% が全体集計では 66% と誤って健全に見える。**ハードシャードでは論理インスタンスごとに独立した SLO が不可欠** [9]。 ### 8.6 HPC への適応 LANL の Lueninghoener は HPC 環境で「各クラスタ四半期 30 時間」をダウンタイム予算と定義し、バーンダウンチャートで可視化した。エラーバジェットの本質は「単位(リクエスト失敗)」ではなく「リソースを追跡して意思決定に使う」構造にある [40]。 ### 8.7 IoT・モビリティ Luup では電動キックボード・電動アシスト自転車を対象に、CUJ の代わりに CMC(Critical Machine Communication)を SLI 設計の起点とした。計測対象はデバイスの定期通信応答や通信途絶であり、SLI がリクエスト駆動から物理デバイス通信へ拡張された事例 [41]。 Luup は 2024 年、Enabling SLO の対象を iOS/Android クライアントへ拡張した。API のみの計測では BLE 通信(施錠・解錠・ライド開始終了)や Firestore への直接アクセスが SLI から漏れるため、PdM・SWE・SRE の三者協働でユーザージャーニーを再設定し、CUJ 単位のマトリクスに落とし込んだ。Latency SLI には Core Web Vitals の LCP Good Score が採用する **p75** を用い、Datadog の Time Slice SLO(2024-05-02 GA)によって Monitor 設定なしに SLO 作成中にしきい値を試行できるようにした。さらに 1 つの SLI に対して Upside(将来目指す理想値)・Downside(現実的に割りたくない現状監視水準)・Actual(既に一部割れている水準)の 3 段階を定義する **Multi-tiered SLOs** を採用し、開発フェーズが進むにつれて Actual → Downside のみを注視する状態へ収斂させる設計とした。技術的な計測基盤の整備以上に、SLI ダッシュボードの整備と Weekly レビューによる「文化醸成」が最重要と位置づけられている [42]。 ### 8.8 AI サービスの SLI/SLO 生成 AI サービスでは SLI の候補が「応答の品質」へ広がる。Yoshikawa（Topotal）は、出力品質スコア、ハルシネーション率、RAG 検索精度を SLI に加える例を示した。LLM 推論では TTFT(Time To First Token)・ITL(Inter Token Latency)・E2EL(End-to-End Latency)・Goodput(レイテンシ要件を満たすリクエスト数)に加え、Tokens/Dollar や Tokens/User/Dollar を費用対効果指標として位置づける [43][44]。 ### 8.9 カーボン認識 SLO CASCA(Carbon-Aware SLO and Control plAtform)はカーボンフットプリントを報酬関数に組み込み、SLO 充足とサステナビリティの両立を図るマイクロサービス原則ベースのプラットフォームである。インフラプロバイダーがサービスのセマンティクスを知ることなく SLO 充足のために動的再設定を行えるよう、SLO 宣言とパラメータ名を「ServiceSLO」「ServiceParam」へ匿名化する仕組みを持つ。匿名化しても意思決定システムの挙動はほぼ変化せず(SLO 充足率・カーボンフットプリントとも完全記述時と同様の序列)、プライバシー保護と SLO 充足を両立できることを実証した。 貪欲ヒューリスティック(GDS)・強化学習(RLDS)・ランダム基準(RDS)の 3 方式を 24 時間の実機評価で比較したところ、FPS SLO 充足率では GDS が最良(90.6%、RLDS: 85.2%)である一方、カーボンフットプリントの最小化では報酬関数にカーボン強度を組み込んだ RLDS が最良(72.4 vs GDS 74.9 mgCO₂/分)となり、**パフォーマンス最適化とサステナビリティ最適化はトレードオフの関係にある**ことを定量的に示した。宣言的な SLO・パラメータの追加変更は平均 2.8 秒で完了し、ソースコード修正・再ビルドを要する命令的アプローチ(平均 56.5 秒)と比べ約 54 秒短縮した [45]。 ### 8.10 セルフクラフト — SLO の未来像 坪内祐樹（さくらインターネット研究所）は、2040 年代の個別化アプリケーションでは信頼性・コスト・変更速度などの基本変量の均衡点を利用者と AI が対話的かつ体験的に決めると描いた。SLO を静的な契約値ではなく、探索プロセスとして扱う視点であり、SLO の主体が事業者から利用者+AI に移行する方向性が示唆される [46]。 ### 8.11 セキュリティ領域への応用 — Security Level Objectives John Benninghoff（Security Differently）は SREcon25 Americas で、SRE の SLO をセキュリティ領域に転用した **Security Level Objectives** を提唱した。着想は Safety-II の枠組み(悪い結果の非発生でなく良い結果の増加を目指す、分布の右シフト)に基づく。2019 年の DORA・Veracode・Sonatype という 3 つの独立データセットは、サイバーセキュリティのパフォーマンスとソフトウェアデリバリー・信頼性パフォーマンスが強く相関することを既に示しており、実証的に効果の高いセキュリティコントロールのトップ 2(攻撃面管理・パッチ頻度)は SRE の中核的な運用活動(インベントリ・構成管理、依存関係管理)と 1 対 1 で対応する [47]。 Security Level Objectives の候補指標には、エンドポイント当たりの脆弱性数、公開サービス当たりの開放ポート数、MFA 未使用エンドポイント率、孤立アカウント率、ログイン失敗率・成功率が挙げられる。通常の SLO との本質的な違いは損失分布の規模にある。アウテージ損失が $100–$10M(典型 $100K)であるのに対し、サイバーセキュリティ損失は $100–$10B(典型 $1M、95 パーセンタイル $52M)と桁違いに大きく、エラーバジェット的な「許容できる損失率」の設定が困難である。そのため Security Level Objectives は損失率そのものではなく、リスクと相関する先行指標に閾値を設定する設計に寄る [47]。この構造は第 4.6 節の脆弱性バジェット(Thomson・Laing)と同じ問題領域を扱うが、Benninghoff は「SRE の日常運用そのものがセキュリティパフォーマンスの土台である」という組織論的視点を加えている点で異なる。 ### 8.12 定常性モデル — 閾値ベース SLI/SLO を超える代替アプローチ Narayan Desai(Google Cloud SRE)は SREcon21 で、SLI に固定閾値を設定する従来アプローチを「Goldilocks Reliability」と呼び、これが暗黙に依存する 4 つの荷重仮定 ―― 「ちょうどいい」の有意性・答えの一意性・問いの既知性・答えの不変性 ―― を明示化した上で批判した。閾値通過判定は元の分布を 2 バケットヒストグラムへ圧縮する操作であり、Hartmann(2019、第 2.2 節)が指摘したパーセンタイル集約不能問題と同根の「点推定によるデータ圧縮」問題を抱える [48]。 代替として提示されたのが**定常性モデル(Stationarity-based Reliability Model)**である。信頼性を可用性・パフォーマンス・正確性の 3 次元に分解し、それぞれに定常性仮定(可用性=エラーの時空間的 i.i.d.、パフォーマンス=長時間窓での一定性、正確性=バグを除く同一入力からの同一出力)を付与し、その逸脱を信頼性劣化のシグナルとして検知する。キャリブレーション不要(閾値設定のための人間判断が不要)で、定常性違反を階層的に分解することで根本原因を識別できる(例: 「スロークエリ割合」全体の定常性違反 → 理由別に分解し IO Time が原因と特定)。この手法は 2022 年の SREcon22 Americas(Principled Performance Analytics)で正規分布 z スコアによる 2σ 手法として数理実装され、Google 本番環境で障害の 18 時間先行検知を実証した [48][49]。 定常性モデルは SLI/SLO の閾値設計問題そのものを解消するのではなく、SLO フレームワークと**直交**する「あるべき状態からの逸脱」を検知する層として位置づけられる。SLO が「どこを超えたらアウトか」を定義するのに対し、定常性モデルは「通常どうあるべきか」を定義する点が根本的に異なる。 --- ## 第 9 章　未解決の問いとフロンティア ### 9.1 SLO 代数 複数のダウンストリームサービスを消費する上位サービスの SLO を、依存先の SLO から分析的に導出する体系的手法が存在しない。依存関係の直列/並列消費パターン・フェイルオープン/クローズド動作を考慮した代数的枠組みの確立は未解決課題 [15]。 ### 9.2 SLO の根本批判 Desai は「SLO requires recognized errors」と述べた上で、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの構造的問題から「エラーは浅いデータにとどまる」と主張した。SLO を段階的改善の対象として論じる多くの先行ソースとは異なり、「SLO そのものが計測ツールとして根本的に不完全」という結論に進んだ最も強い批判形である [49]。 ### 9.3 エラーバジェットの不確実性 エラーバジェットを設定するためのインパクト推定が桁違いに不正確でありうる。Davidovič（Google）は 3 人の独立した担当者にインシデント影響を推定させてバリアンスを観察することを推奨した [26]。 ### 9.4 その他の未解決課題 - SLE/CBE 枠組みは概念的提案にとどまり、クラウドプロバイダでの採用事例は未報告 - AI サービスでハルシネーション率をどのユーザー幸福フレーバーに分類するか、または 7 番目のフレーバーが必要か - SLO アラート発火時に自動添付する情報の標準化範囲 - クライアント側測定とサーバー側測定の乖離を定量化する実践的手順 --- ## 付録 ### A. 文献年表 | 年 | 文献 | 主な貢献 | |---|---|---| | 1984 | 高速道路 Levels of Service | SLI/SLO の概念的起源 | | 2007 | Hamilton, LISA | SLA を設計段階の酸性試験と位置づけ | | 2014 | Treynor Sloss, SREcon14 | 13 のキーと「ローンチオンブラック」ルール初出 | | 2015 | Alvidrez, SREcon15 | エラーバジェットの起源体験 | | 2016 | SRE Book Ch3-4 | SLI/SLO/SLA フレームワーク体系化 | | 2016 | Jones+Murphy, SREcon16 | SLO 公表理由、集約インターバル問題、バンバン制御回避 | | 2017 | Mogul+, HotOS | 可用性定義の困難さを提起 | | 2017 | Wilkinson, SREcon17 | Prometheus でのバケット比率 SLI 実装 | | 2018 | SRE Workbook | SLO 実装・アラーティング・事例・文書例を体系化 | | 2018 | Wilkinson, SREcon18 Asia | SLO バーンレートアラートとシンプトムベースドアラーティング | | 2018 | Binette+Flaming, SREcon18 Americas | ケイパビリティ駆動 SLI 設計 | | 2018 | Gangatirkar, SREcon18 Asia | 共感ギャップ、S 字曲線、6 フレーバー | | 2018 | Vieiro, SREcon18 Asia | Atlassian Error Budgets 0.1 | | 2019 | Mogul+Wilkes, HotOS | SLE/CBE、SLOgician | | 2019 | Hartmann/Moyer, SREcon19 | レイテンシ SLO のパーセンタイル集約不能問題 | | 2019 | Desai, SREcon19 EMEA | SLO の 4 ユースケース、暗黙的仮定、SLO Algebra | | 2019 | Booking.com, SREcon19 EMEA | データ品質 SLO | | 2019 | Lawson, SREcon19 Americas | 新規サービスへの SLO 実装 6 ステップ | | 2020 | Hauer+, NSDI | ウィンドウ付きユーザーアップタイム | | 2020 | Coulter, SREcon20 Americas | SLO 交渉フロー、ユーザー行動ベース SLI | | 2020 | Moyer, SREcon20 Americas | エラーバジェット民主化の 3 鍵 | | 2021 | Ding+Zhang, SREcon21 | SLX フレームワーク | | 2021 | Desai, SREcon21 | Goldilocks Reliability 批判、定常性モデル | | 2022 | Palcuie, SREcon22 EMEA | 30→3000 万 SLO、顧客単位 SLO | | 2022 | Davidovič, SREcon22 EMEA | SLO モデルの線形性問題 | | 2022 | Desai, SREcon22 Americas | SLO 根本批判 | | 2022 | 近藤, SRE NEXT 2022 | 非機能要求予算の組織的前提 | | 2023 | Koss+Goins, SREcon23 Americas | 時間スライス vs イベントベース集計 | | 2023 | Furino, SREcon23 EMEA | 成功定義 SLI、3 ペルソナ時間窓 | | 2024 | Sedlak+, SOSE | SLO 拡散方法論 | | 2024 | Tsuda, SRE NEXT 2024 | クライアントサイド SLO、Multi-tiered SLOs | | 2025 | Durst, SREcon25 EMEA | SLO 導入の 4 前提条件 | | 2025 | Riot Games, SREcon25 Americas | Player Minutes と CEO OKR | | 2025 | eBay, SREcon25 Americas | 非同期パイプライン SLO | | 2025 | Benninghoff, SREcon25 Americas | Security Level Objectives | | 2026 | Takamura, Road to SRE NEXT 2026 | SLI/SLO 段階的導入の体系化 | | 2026 | Yoshikawa | AI サービス SLI/SLO | | 2026 | CASCA | カーボン認識 SLO | ### B. 参考文献 [1] Last9. "The Origin of Service Level Objectives." Last9 Blog. https://blog.last9.io/the-origin-of-service-level-objectives/ [2] Ben Treynor Sloss. "Keys to SRE." SREcon14, USENIX, 2014. https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre [3] Chris Jones, John Wilkes, Niall Murphy, Cody Smith. "Site Reliability Engineering - Chapter 4: Service Level Objectives." *Site Reliability Engineering*, O'Reilly, 2016. https://sre.google/sre-book/service-level-objectives/ [4] Steven Thurgood, David Ferguson, Alex Hidalgo, Betsy Beyer. "The Site Reliability Workbook - Chapter 2: Implementing SLOs." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/implementing-slos/ [5] Jeffrey C. Mogul ほか. "Nines are Not Enough: Meaningful Metrics for Clouds." HotOS '19, ACM, 2019. https://dl.acm.org/doi/10.1145/3317550.3321432 [6] Marc Alvidrez. "Site Reliability Engineering - Chapter 3: Embracing Risk." *Site Reliability Engineering*, O'Reilly, 2016. https://sre.google/sre-book/embracing-risk/ [7] Heinrich Hartmann. "Latency SLOs Done Right." SREcon19 EMEA, USENIX, 2019. https://www.usenix.org/conference/srecon19emea/presentation/hartmann-latency [8] Chris Jones, Niall Murphy. "Service Levels and Error Budgets." SREcon16, USENIX, 2016. https://www.usenix.org/conference/srecon16/program/presentation/jones [9] Elisa Binette, Matthew Flaming. "SLOs and SLIs in the Real World: A Deep Dive." SREcon18 Americas, USENIX, 2018. https://www.usenix.org/conference/srecon18americas/presentation/flaming [10] Sal Furino. "9 Things You Should Do When Starting to Use SLOs." SREcon23 EMEA, USENIX, 2023. https://www.usenix.org/conference/srecon23emea/presentation/furino [11] Ketan Gangatirkar. "Quantifying Empathy Through Service Level Objectives." SREcon18 Asia, USENIX, 2018. https://www.usenix.org/conference/srecon18asia/presentation/gangatirkar [12] Ben McCormack, William Bonnell, Garrett Plasky, Alex Hidalgo, Betsy Beyer, Dave Rensin. "SLO Engineering Case Studies." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/slo-engineering-case-studies/ [13] Dave Stanke. "Squish Level Objectives: How SRE can Help Align Technical Work to User Benefit." SREcon20 Americas, USENIX, 2020. https://www.usenix.org/conference/srecon20americas/presentation/stanke [14] Marco Coulter. "Avoiding Goodhart's Law: Use SLO's as Tools Not Cudgels." SREcon20 Americas, USENIX, 2020. https://www.usenix.org/conference/srecon20americas/presentation/coulter [15] Narayan Desai. "The Map Is Not the Territory: How SLOs Lead Us Astray, and What We Can Do about It." SREcon19 EMEA, USENIX, 2019. https://www.youtube.com/watch?v=NW4OOpQ3nz8 [16] Steven Thurgood. "Google SRE Workbook - Appendix A: Example SLO Document." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/slo-document/ [17] Marc Alvidrez. "Error Budgets and Risks." SREcon15, USENIX, 2015. https://www.usenix.org/conference/srecon15/program/presentation/alvidrez [18] Steven Thurgood. "Google SRE Workbook - Appendix B: Example Error Budget Policy." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/error-budget-policy/ [19] Troy Koss, Michael Goins. "Not All Minutes Are Equal: The Secret behind SLO Adoption Failure." SREcon23 Americas, USENIX, 2023. https://www.usenix.org/conference/srecon23americas/presentation/goins [20] Jim Thomson, David Laing. "Extending the Error Budget Model to Security and Feature Freshness." SREcon19 Americas, USENIX, 2019. https://www.usenix.org/conference/srecon19americas/presentation/thomson [21] Steven Thurgood, Jess Frame, Anthony Lenton, Carmela Quinito, Anton Tolchanov, Nejc Trdin. "Alerting on SLOs." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/alerting-on-slos/ [22] Alex Jones, Alois Reitbauer, Bartłomiej Płotka, Liz Fong-Jones, Michael Hausenblas ほか 35 名. "Observability Whitepaper." CNCF TAG Observability, 2023. https://github.com/cncf/tag-observability/blob/main/whitepaper.md [23] Jamie Wilkinson. "A Theory and Practice of Alerting with Service Level Objectives." SREcon18 Asia, USENIX, 2018. https://www.usenix.org/conference/srecon18asia/presentation/wilkinson [24] 池田将士. "Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵." SRE NEXT 2023, 2023. https://speakerdeck.com/mashiike/warningaratowofang-zhi-sinai-aratoqu-dong-deroguyametoritukuwozi-dong-shou-ji-surushi-zu-miniyoruen-hui [25] Tamás Hauer ほか. "Meaningful Availability." NSDI '20, USENIX, 2020. https://www.usenix.org/conference/nsdi20/presentation/hauer [26] Štěpán Davidovič. "Measuring Reliability: What Got Us Here Won't Get Us There." SREcon22 EMEA, USENIX, 2022. https://www.usenix.org/conference/srecon22emea/presentation/davidovic [27] Alex Palcuie. "Going from 30 to 30 Million SLOs." SREcon22 EMEA, USENIX, 2022. https://www.usenix.org/conference/srecon22emea/presentation/palcuie [28] Rob Durst. "Run, Walk, Crawl, or How We Failed Our Way to SLO Readiness." SREcon25 EMEA, USENIX, 2025. https://www.usenix.org/conference/srecon25emea/presentation/durst [29] Narimichi Takamura. "小さくはじめるSLI/SLO ~育てながら組織に定着させる実践知~." Road to SRE NEXT 2026 神戸, 2026. https://speakerdeck.com/nari_ex/slos-building-adoption-through-continuous-growth [30] 渡辺起. "プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜." SRE NEXT 2023, 2023. https://speakerdeck.com/tatsuru/sre-next-2023 [31] Kristin Smith. "Dark Sky Camping: Reducing Alert Pollution with Modern Observability Practices." SREcon22 Americas, USENIX, 2022. https://www.usenix.org/conference/srecon22americas/presentation/smith [32] 近藤武士. "Who owns the Service Level?" SRE NEXT 2022, 2022. https://speakerdeck.com/chaspy/who-owns-the-service-level [33] Gui Vieiro. "How Atlassian Is Tackling Error Budgets, Agile Style." SREcon18 Asia, USENIX, 2018. https://www.usenix.org/conference/srecon18asia/presentation/vieiro [34] Arnaud Lawson. "Case Study: Implementing SLOs for a New Service." SREcon19 Americas, USENIX, 2019. https://www.usenix.org/conference/srecon19americas/presentation/lawson [35] Maxfield Stewart. "Measuring Availability the Player Focused Way: How Riot Games Changed Its Availability Culture." SREcon25 Americas, USENIX, 2025. https://www.usenix.org/conference/srecon25americas/presentation/stewart [36] Qian Ding, Xuan Zhang. "SLX: An Extended SLO Framework to Expedite Incident Recovery." SREcon21, USENIX, 2021. https://www.usenix.org/conference/srecon21/presentation/ding [37] Yoann Fouquet. "SLOs for Data-Intensive Services." SREcon19 EMEA, USENIX, 2019. https://www.usenix.org/conference/srecon19emea/presentation/fouquet [38] Jash Mistry, Gabriela Medvetska. "Beyond Sequential: A Recipe for Async Pipeline Observability and Alerting." SREcon25 Americas, USENIX, 2025. https://www.usenix.org/conference/srecon25americas/presentation/mistry [39] Boris Sedlak ほか. "Diffusing High-level SLO in Microservice Pipelines." SOSE 2024, IEEE, 2024. https://ieeexplore.ieee.org/document/10685329 [40] Cory Lueninghoener. "HPC Downtime Budgets: Moving SRE Practice to the Rest of the World." SREcon16 Europe, USENIX, 2016. https://www.usenix.org/conference/srecon16europe/program/presentation/lueninghoener [41] Wataru Tsuda. "電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践." SRE NEXT 2023, 2023. https://speakerdeck.com/grimoh/dian-dong-maikuromobiriteinosieasabisu-luup-niokeruenabling-slonoshi-jian [42] Wataru Tsuda. "Enabling Client-side SLO." SRE NEXT 2024, 2024. https://speakerdeck.com/grimoh/enabling-client-side-slo [43] Ryota Yoshikawa. "Reliability in the Age of AI: Engineering for AI Velocity." SpeakerDeck, 2026. https://speakerdeck.com/rrreeeyyy/reliability-in-the-age-of-ai-engineering-for-ai-velocity [44] 道下幹也. "推論基盤のパフォーマンス検証と最適化戦略." SpeakerDeck, 2026. https://speakerdeck.com/aztecher/tui-lun-ji-pan-nopahuomansujian-zheng-tozui-shi-hua-zhan-lue [45] Juan Luis Herrera ほか. "A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management." arXiv, 2026. https://arxiv.org/abs/2602.12875 [46] Yuuki Tsubouchi, Hirofumi Tsuruta. "AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想." DICOMO 2022, 情報処理学会, 2022. https://speakerdeck.com/yuukit/dicomo2022-6a-1 [47] John Benninghoff. "Is the S in SRE for \"Security\"?" SREcon25 Americas, USENIX, 2025. https://www.usenix.org/conference/srecon25americas/presentation/benninghoff [48] Narayan Desai. "Beyond Goldilocks Reliability." SREcon21, USENIX, 2021. https://www.usenix.org/conference/srecon21/presentation/desai [49] Narayan Desai, Brent Bryan. "Principled Performance Analytics." SREcon22 Americas, USENIX, 2022. https://www.usenix.org/conference/srecon22americas/presentation/desai