# Error Budgets and Risks 副題: *Striving for Imperfection: Using an error budget to move fast without compromising high reliability* [[Marc Alvidrez]]（Google Senior Staff SRE）、SREcon15、2015-03-16、Santa Clara, CA。26 スライド + 音声文字起こし。 ## 概要 エラーバジェットは SLA を「最低限ではなく最低限かつ上限」として再定義し、信頼性の余裕を定量化してリリース速度や運用改善に「使える予算」として扱うフレームワークである。Google の AdSense チームが 2006-2009 年の試行錯誤から発見し、あらゆる種類のシステム（インフラ・低レイテンシサービング・バッチパイプライン）に汎用できることが示された。本講演は参加者にエラーバジェットを自分たちの環境でどう適用できるかを考える場として設計されており、前半 15 分の解説後にグループディスカッションと全体共有が行われた。 ## 主要メッセージ - **SLA はミニマムかつマクシマムである**: SRE の目標は 100% 信頼性でなく「必要な分だけの信頼性」。SLA を超えて余剰信頼性を持つことは機会損失であり、より速い開発・より少ないリソース・エンジニアのQoL改善に使えた（p.9-10）。 - **エラーバジェットの定義式**: `error budget = availability − SLA target`（p.12）。可用性を `successful requests / total requests` で計測することでエラーバジェットが定義・計測しやすくなる（p.6）。 - **最低要件は 3 つ**: (1) SLA しきい値を知る、(2) 可用性パフォーマンスを計測できる、(3) パフォーマンスが SLA しきい値を一貫して超える（p.14）。 - **具体的な始め方**: HTTP ウェブアプリなら、外部 SLA 99.9% / 内部 99.95%、エラーは HTTP 500、計測はウェブサーバーログの日次集計スクリプトで十分（p.15）。 - **エラーバジェットは権利でなく獲得するもの**: バジェットを使い切って SLA を割った翌四半期は、まず実績を回復させてからリスクを再開する（transcript Q&A）。 ## 視覚的に重要な図表 **p.6 可用性 2 種の計算式とエラーバジェットへの誘導** ![[_attachments/2015__SREcon15__Error-Budgets-and-Risks/page-006.png]] 上段がシステム稼働率ベース（`availability = uptime / (uptime + downtime)`）、下段がリクエスト成功率ベース（`availability = successful requests / total requests`）。分散環境では部分稼働が続くためバイナリなアップ/ダウンは不適切で、後者の定義がエラーバジェットの定量化を可能にする。 **p.12 エラーバジェットの定義式** ![[_attachments/2015__SREcon15__Error-Budgets-and-Risks/page-012.png]] `availability = successful requests / total requests`、`error budget = availability − SLA target` の 2 段構成。エンジニアリングアプローチとして measure → analyze → improve のサイクルを可能にする量化フレームとして提示。 **p.26 エラーバジェットの使い道と思慮ある有界リスクテイク** ![[_attachments/2015__SREcon15__Error-Budgets-and-Risks/page-026.png]] 「買えるもの」として高速移動（変更頻度増・新機能・speed to market）・タイトな運用（余剰キャパシティ削減）・QoL 改善の 3 種を提示。鍵となる考慮点は「リスクを有界にする・可逆なリスクを選ぶ・計測しやすいリスクを選ぶ」。目標: *Thoughtful, bounded risk taking*。 ## 口頭説明・補足（transcript より） - **AdSense 2006 の実体験**: Alvidrez 自身がアドサーブチームへ異動し、検索インフラを使ったシステム再実装に携わった。「ページ通知が数十件ではなく数百件」という状態が続き、SLA 達成に苦しんだ。 - **「これは大きな気づきだった」**: SLA をミニマムかつマクシマムとして捉える転換が、Alvidrez 自身の発見として語られる。単なるフレームワーク紹介ではなく実体験からの発見。 - **1% クラスターの境界計算**: 「平均ページ応答時間・フェイルオーバー時間が 15 分とすると、1% トラフィックのピーク時でも失敗するリクエスト数を計算でき、SLA への影響が境界内に収まることを事前に確認できた」。 - **Q&A: 1% の定義問題**: AdSense は「クッキー」で識別するため 1% は undifferentiated な分割が可能。しかし Google Photos のようなサービスで 1% のユーザーを選ぶと「不運な 1%」が発生し不適切。システムによって適用できる分割次元が異なる。 - **Q&A: SLA の計測対象（自己申告 vs. 外部）**: 「まず計測しやすいものから始め（サーバーサイド）、時間をかけてクライアントサイドの視点も取り込んで洗練させる」。Google では ISP 別・IPv4 vs. IPv6 別のエラー率をバックグラウンドレートとして計測し、SLA から分離する。 - **Q&A: バジェット消費の帰属**: リリースとエラーバジェット消費を相関させると「この実験は予算の 50% を消費した、続けるか？ロールバックか？」という判断が可能になる。あるいは変更頻度全体を上げて小さな失敗を分散させる（"peanut butter across the quarter"）2 通りのアプローチがある。 - **Q&A: 開発チームと SRE の共同オーナーシップ**: 「本当によく運営されているサービスでは、開発チームと SRE チームがサービスの共同オーナーであり、それぞれの強みを持ち寄って一緒に届ける。コミュニケーションが鍵」。 - **Q&A: 内部メトリクス（例外・アラート）への適用**: エンドユーザー/顧客可視の影響に集中することを推奨。内部例外は「チェックエンジンランプ」——いずれ本番問題につながる兆候として扱う。 - **フォールトインジェクションへの言及**: 「SLA の範囲内で意図的に障害を注入し、ユーザーが本当に 99.9% を基準に設計しているかを検証し始めている。非常に興味深い探求の方向」——初期のカオスエンジニアリング的思想の萌芽。 ## 概念・実体への接続 - 概念: [[エラーバジェット]] / [[サービスレベル目標]] / [[SRE]] / [[カオスエンジニアリング]] - エンティティ: [[Marc Alvidrez]] / [[Google]] - 関連ソース: [[SRE Book]]（Chapter 3 Embracing Risk がエラーバジェットを体系化） ## 限界・不確実点 - transcript は Whisper による自動文字起こしのため、固有名詞・数値の一部に不確実性がある（文脈から補正した箇所あり） - グループディスカッション（20 分）の内容は transcript に含まれるが参加者の音声が不明瞭な箇所がある - Alvidrez の所属が「Senior Staff SRE」は公式ページ記載のものだが、2015 年当時の正確なチームは不明