## 概要 [[Chris Jones]]（[[Google]] App Engine SRE）と[[Niall Murphy]]（Google Ads SRE Dublin）による SREcon16 の 23 分トーク（2016 年 4 月、Santa Clara）。[[SRE Book]] 第 4 章「Service Level Objectives」の共著者 2 名が、SLI/SLO/SLA の区別とエラーバジェットの考え方を口頭で直接解説した。Auto-caption に基づくトランスクリプトあり（[[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] も参照）。 ## 主要メッセージ - **SLI/SLO/SLA の三概念は業界で混同されており、分離が重要**: SLI = 計測値、SLO = 目標値（`SLI ≤ target`）、SLA = 帰結付き契約。SLA は弁護士・経営層の話であり、SRE が直接管理するのは SLO である（transcript [00:00:43]〜[00:03:09]）。 - **SRE の仕事は可用性の最大化ではない**: 「信頼性最大化を目標にすると、変更を拒否して休暇に出ればいい」と述べ、SRE の本来の役割を「所定の信頼性レベルの範囲内でプロダクトベロシティを最大化しコストを最小化すること」と定義する（transcript [00:17:02]〜[00:18:33]）。 - **最適な信頼性は 100% ではない**: 「哲学者ジャガーが言うように、あなたはいつも欲しいものを得られるとは限らない」（transcript [00:18:55]〜[00:19:00]）。 - **エラーバジェットは制御ループ**: SLO 達成中 → フィーチャーリリースを最速で進める。バジェット枯渇 → リリース停止、安定性改善へ。連続的にバーン率を監視するとバンバン制御（二値切り替え）を避けられる（transcript [00:20:06]〜[00:21:54]）。 - **SRE は「ノー」を言わなくなる**: エラーバジェットが共通言語となることで、SRE は「もし〜ならイエス」を言えるようになり、プロダクト開発チームとの関係が健全化する（transcript [00:21:56]〜[00:22:41]）。 ## 口頭説明・補足 ### SLI 選定の考え方 ユーザーが気にする指標: レイテンシ・エラー率・スループット・可用性・正確性（transcript [00:04:54]〜[00:06:30]）。 - **正確性は特殊**: 高速で整形された「間違いリスト」は価値がない。SRE はインフラ側を担当し、データ品質は主にプロダクト開発チームが扱うが、例えば「4 分前と比べて 50% のデータしか本番に届いていない」場合のアラーティングなど、信頼性角度での関与はある。 - **測定点の選択**: Google はサーバー側で測定しがちだが、ユーザー体験を正確に反映するのはクライアント側。「ロカス・オブ・コントロールとロカス・オブ・メジャーメントを混同してはいけない」（transcript [00:07:31]〜[00:08:02]）。 - **集約インターバルが解釈を支配する**: 1 分インターバルでは平坦に見えたリクエストが、30 秒インターバルでスパイクを持ち、1 秒インターバルで毎分の先頭に全リクエストが集中することが分かる。これはクライアント同期の問題であり、キャパシティプランニングとピーク性能の問題でもある（transcript [00:08:03]〜[00:10:13]）。 - **平均値は誤解を招く**: 「平均的な人間は 1.9 本の足を持つ」。p50/p80/p90/p95 での評価が必要（transcript [00:10:17]〜[00:11:13]）。 - **ファンアウトシステムでの p95 問題**: 複数バックエンドに問い合わせるリクエストでは、1 つのバックエンドの高レイテンシがリソースを長時間占有し、カスケード障害率を高める。"The Tail at Scale"（Jeff Dean & Luiz André Barroso）を参照（transcript [00:11:44]〜[00:13:10]）。 ### SLO の設定原則 （transcript [00:15:02]〜[00:17:01]） 1. **SLO を公表することで期待値を管理する**: 公表しないと、ユーザーは「今の性能が永遠に続く」と期待し始め、将来の選択肢を狭める。 2. **現在の性能をそのまま SLO にしない**: 将来の変更や設計変更を見越した値を選ぶ。 3. **100% を約束しない**: 100% は不可能であり、SRE の改善余地を奪う。 4. **安全マージンを持つ**: 意図しない違反への緩衝として、内部 SLO を公表 SLO より少し厳しく保つ。 5. **過達成しない（over-achieve しない）**: 公表値より良い性能が続くとユーザーはそれを期待するようになる。Google では「ランダムなタイミングで意図的にダウンタイムを入れる」システムが存在する——「頼りすぎないよう思い出させるために」。 6. **内部 SLO と公表 SLO の間にバッファを**: 慢性的な低レベル障害への対応空間と、将来の設計変更余地を確保する。Jeff Dean の格言「10 倍の成長を計画せよ、100 倍では完全な再設計が必要になる」（transcript [00:16:52]〜[00:17:01]）。 ### エラーバジェットと組織 （transcript [00:20:06]〜[00:22:56]） - SLO が 99.9% なら 0.1% のエラーバジェット（月換算で約 43.8 分）。この予算の範囲でソフトウェアリリースや変更を行う。 - バジェット枯渇 = 停止信号。リリースを止めて安定性改善へ集中する。 - **SRE がリリースを止める権限**が必要: プロダクト管理・経営陣の強い支持が前提となる。 - **組織的な帰結**: SRE は「ノー」の役割から解放される。「イエス、もし〜ならば」という条件付き合意へ移行。プロダクト開発チームは SRE を迂回しようとしなくなる（迂回するとバジェットを自ら削るだけのため）。信頼性がプロダクトの一等機能として認識される。 ## Q&A transcript に Q&A の記録は得られなかった（auto-caption の品質限界）。 ## 概念・実体への接続 - [[サービスレベル目標]]（SLI/SLO/SLA 三概念の原典解説） - [[エラーバジェット]]（制御ループとしての運用、組織的帰結） - [[Chris Jones]] / [[Niall Murphy]]（登壇者） - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]]（このトークの書籍版） - [[SRE Book]]（出版物本体） - [[Google]]（所属組織、App Engine・Ads SRE） ## 限界・不確実点 - 映像フレームなし（yt-dlp で映像取得できず）。スライド上の図・グラフ・数値は未確認。 - auto-caption のため固有名詞・数値の誤変換の可能性あり（"Nam urfi" は "Niall Murphy" の誤認識等）。 - Q&A 部分のトランスクリプトが不完全（[00:22:56] で終了しており、完全な Q&A は未取得）。 - 音声取得なし（mp3 は rackcdn にあるが本スキルの方針でダウンロード省略）。 ---