## 定義 エラーバジェットとは、SLO で許容される障害量の上限を「予算」として扱い、開発チームと SRE が共有する信頼性管理の仕組みである。SLO が 99.9% ならば 0.1% のエラーバジェットを持ち、この予算の範囲内で新機能のリリースや変更を許容する。予算を消費しきった場合はリリースを凍結して信頼性改善に集中する。Ben Treynor Sloss が Google SRE で体系化した (Source: [[@2016__OReilly__SRE Book - Chapter 1 Introduction]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]])。 主要な原則: - 100% の可用性を追求しない——ユーザーは 99.99% と 99.999% の差を検知できない - 信頼性改善のコスト曲線は非線形であり、各増分が前回の 100 倍のコストを要する - 開発速度と信頼性の対立を共通インセンティブに変換する仕組みとして機能する - 四半期ベースで SLO に基づき設定する - [[Google]] はアップタイムでなくリクエスト成功率で計測する——分散システムは部分的に稼働し続けるため、バイナリなアップ/ダウンは不適切 ## 子概念 - [[agentic SRE]] - [[コンテキスト対コントロール]] ## 横断的知見 - **SLI/SLO/SLA 体系とエラーバジェットは相補的である**: [[サービスレベル目標]] の SLI/SLO/SLA 体系が「何を約束するか」を定義し、エラーバジェットが「約束をどう運用するか」を担う。SLO 単体では目標が形骸化しうるが、エラーバジェットが予算消費という可視的な制約を導入することで、信頼性の維持が開発チームの自己利益に組み込まれる (Source: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]])。 - **Hamilton (2007) の「SLA を設計段階の酸性試験とする」原則とエラーバジェットは同方向を指す**: Hamilton は SLA を可用性メトリクスの議論以前に、サービス設計の酸性試験（任意のサーバをいつでもワークロードのドレインなしに停止でき、かつ SLA を満たせるか）として定義した。SLA/SLO を設計判断の制約として組み込み、信頼性を事後の測定でなく事前の設計に内在化させる点で、エラーバジェットの「予算の範囲で変更を許容する」運用設計と同じ思想を共有する (Source: [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2007__LISA__On Designing and Deploying Internet-Scale Services]])。 - **SRE Workbook はエラーバジェットをアラート・変更停止・計画の発火条件へ具体化する**: Implementing SLOs は、エラーバジェット消費を信頼性プロジェクトの優先順位比較に使い、Appendix B は直近 4 週間の予算超過時に P0・セキュリティ修正以外の変更を停止する方針例を示す。単一インシデントまたは同一障害クラスが予算の一定割合を消費した場合にポストモーテムや P0 アクションアイテムを要求する点で、エラーバジェットは「罰」ではなく、信頼性作業へ集中する制度的許可として機能する (Source: [[@2018__Google SRE Workbook__Chapter 2 Implementing SLOs]], [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]])。 - **バーン率はエラーバジェットを時間微分したオンコール向け指標である**: Alerting on SLOs は、アラート条件をエラー率そのものではなく予算消費速度で定義する。長い窓で重大性を確認し、短い窓で現在も燃焼中かを確認する複数ウィンドウ複数バーン率方式は、精度・再現率・検知時間・リセット時間を同時に制御する実践的な出発点である (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 - **Wilkinson（2018）はバーン率アラートをシンプトムベースドアラーティングの具体実装として提示した**: 「symptom = SLO で計測できるもの、symptom-based alert = SLO が危険になったときのアラート」と定義し、Prometheus で `delta(errors[1h]) > (expected_events * error_budget / burn_period)` を SLO Fast Burn アラート式として示す。QPS 1000・SLO 99%・1 週間の例では `delta(errors[1h]) > 70` となる。口頭説明では「エラーバジェットの消費速度を Google 内では SLO burn rate と呼んでいる」と明示している。SRE Workbook の Alerting on SLOs と同時期（2018）の発表であり、バーン率概念の二重確証となっている (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 - **Wilkinson の実践報告: 最悪オンコールから脱却**: Google 全チームで 100 パーセンタイル最悪オンコールシフトを 2 期連続記録したチームが、SLO ベースアラーティングへ転換後に「シフトあたり 2 ページ未満 × 4 週間継続」を達成した。エラーバジェットの活用が持続的な運用改善に直結した実証事例 (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 - **AI 補助の承認ポリシーはエラーバジェットで制御できる**: Yoshikawa は、バジェットが残っている間は AI 補助による自動承認を許容し、消費されれば人間承認へ戻す例を示す。これはエラーバジェットを「リリース停止/許可」だけでなく「AI に任せる権限レベル」の制御信号として使う拡張であり、[[SRE AI Autonomy Levels]] の段階的権限付与と接続する。(Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[SRE AI Autonomy Levels]]) - **SLO 違反ポリシーは段階的に拡大し、最初は SRE チームのみが動く形から始めるのが有効**: Takamura は、SLO 違反時のアクションを「なにもしない（Level1）」から「開発スケジュールの意思決定に SLO を組み込む（Level5）」まで 5 段階で徐々に拡大することを提案する。「開発を止める」のような極端なアクションを最初からトリガーする必要はなく、SLO の認知と価値が組織に伝わるにつれてアクションする範囲を広げる。これは SRE Book のエラーバジェットが「開発 vs 運用」の対立ではなく「共通インセンティブへの変換」であることと同じ方向を持つ (Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]])。 - **エラーバジェット導入の組織的帰結は「SRE が No と言わなくなること」であると原著者が明言した**: Jones・Murphy は SREcon16 で、エラーバジェットの最も重要な組織効果は SRE が「ノー」から「イエス、もし〜ならば」へ転換することだと口頭で強調した。プロダクト開発チームが SRE を迂回しようとしなくなるのは、迂回するとエラーバジェットを自ら消費するだけだからであり、信頼性がプロダクトの一等機能として扱われるようになる。Takamura の段階的拡大論と組み合わせると、「No 文化から Yes/if 文化への移行」はエラーバジェットが組織に定着したときの到達点として整合する (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **エラーバジェットの起源は「SLA を超えすぎることへの気づき」である**: Alvidrez は SREcon15 で、AdSense が 2009 年に SLA を一貫して超えた状態を「機会の損失」と語った。SLA はミニマムでもあるが、超過分は「速く動く・少ないリソースで動く・エンジニアのQoLを改善する」ために使えた。この逆転の発想がエラーバジェット概念の個人的な起源である (Source: [[@2015__SREcon15__Error Budgets and Risks]])。 - **エラーバジェット適用の「1% 問題」——ユーザー中心サービスは分割次元を選ぶ必要がある**: Alvidrez の AdSense 1% クラスターは undifferentiated なトラフィック（クッキーレベル）を対象としたため実現が容易だった。しかし Google Photos のようなユーザー中心サービスで「1% のユーザー」を選ぶと不運な 1% になる。リスクを境界化する分割単位はサービスのアーキテクチャによって異なる (Source: [[@2015__SREcon15__Error Budgets and Risks]])。 - **エラーバジェットは権利でなく「獲得」するもの**: SLA を割った翌四半期は、まず実績を回復させてからリスクを再開する。「バジェットを消費し尽くして SLA を下回ったなら、存在しない予算を使おうとするのではなく、まず SLA を上回る実績に戻す」——開発凍結ではなく、以前の慎重なリスクプロファイルへ戻るという処方 (Source: [[@2015__SREcon15__Error Budgets and Risks]])。 - **バンバン制御（bangbang control）の回避がエラーバジェット連続運用の意義**: SREcon16 で Jones は、エラーバジェットを二値切り替え（「リリース全開」→「リリース全停止」）ではなく、バーン率の連続的な監視に基づく速度制御として使うべきだと説明した。「バンバン制御」から「プロポーショナル制御」への移行という制御工学の語彙を実質的に使っており、これは SRE Workbook の複数ウィンドウ複数バーン率アラートへ直結する発想の原型と読める (Source: [[@2016__SREcon16__Service Levels and Error Budgets]], [[@2018__Google SRE Workbook__Alerting on SLOs]])。 - **エラーバジェットは SLO 設定と同時に計算・文書化することで初めて運用指針になる**: Lawson は COS への SLO 実装 6 ステップで Step5「初期 SLO からエラーバジェットを導出」を Step4「SLO 設定」の直後に置き、数値をそのまま引き算（99.9% → 0.1% 失敗許容、p90 < 300ms → 10% が 300ms 以上許容）として文書化した。SRE Book・Workbook はエラーバジェットを概念として定義するが、Lawson は「SLO 値からエラーバジェットを計算するステップを実装プロセスに明示的に組み込む」ことで、SLO 設定とエラーバジェット運用が一体であることを実践的に示した。(Source: [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]]) - **エラーバジェットの「アジャイル導入」では開発停止を最初のトリガーとしない**: Atlassian の Vieiro は、Google SRE Book の定義どおりの完全な Error Budget（開発凍結トリガー付き）を最初から適用せず、「13 週中 7 週未達でアクション・翌四半期は 5 週以下を目標」という緩い仕組み（Error Budgets 0.1）から始めた。Dev チームが SLO を自分ごととして受け入れるまで段階的に基準を引き締めることで、「重すぎる仕組みへの拒否反応」を回避した。Takamura の SLO 違反ポリシー 5 段階拡大と同じ方向性を実際の企業事例として裏付ける (Source: [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]])。 - **可視化とブログ公開がエラーバジェット受容の起点となった**: Atlassian は週次 SLO 達成率を Confluence ページ・ブログとして組織内に公開する「Make It Visible」戦略をとった。「Dev チームが SLO 未達に気づいていなかった」から「気づいていたが投資を承認できていなかった」へと問題が変化するのは、可視化が透明性を生み出したためである。Alvidrez の SREcon15 「SLA を超えすぎることへの気づき」が可視化から始まったことと対応する (Source: [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]], [[@2015__SREcon15__Error Budgets and Risks]])。 - **「Not So Good Result」もエラーバジェットプロセスの成果である**: Atlassian では「このサービスは移行予定なので信頼性投資しない」という応答がエラーバジェットプロセスを通じて明示的に「承認」された。SRE が「No と言わなくなる」だけでなく、「改善しない選択も組織として明示的に認知・承認する」ことで透明性が確保される。Jones・Murphy の「SRE が No から Yes/if へ転換する」という組織的帰結と、「明示的 No はプロセスを通じて正当化される」という実践知が補完関係にある (Source: [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]], [[@2016__SREcon16__Service Levels and Error Budgets]])。 - **SLI/SLO/ポリシーのモデルは可用性以外のドメイン——セキュリティとフィーチャーフレッシュネス——にも同じ構造で適用できる**: Thomson・Laing (Pivotal, SREcon19 Americas) は、エラーバジェットモデルを (1)[[脆弱性バジェット]](Vulnerability Budget: SLI=依存パッチリリースからの経過日数・SLO=最大許容日数・ポリシー=閾値接近時にパッチ適用) と (2)[[フィーチャーフレッシュネス]](Legacy Budget: SLI=フィーチャーリリースからの経過日数・SLO=ブリーディングエッジ度の範囲・ポリシー=90 日毎にアップグレード)に拡張した。Equifax 侵害(CVE-2017-5638)の事例で「30 日 SLO のパッチ適用ポリシーがあれば 67 日後のハックは防げた」と実証し、Pivotal の Nov 2018-Mar 2019 の実測グラフで有効性を示した。SRE Book のエラーバジェットが可用性に限定しているのに対して、SLI/SLO/ポリシーの三要素がドメイン非依存の汎用構造であることを最初に明示した (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 - **テール管理への SLO 適用は「サンドバッギング」を引き起こし、日常的な劣化を見えなくする**: Desai (SREcon19 EMEA) は、テール行動（低確率の大事象）を SLO で管理しようとすると 2 つの罠に陥ると論じた。①「小惑星エラーバジェット」——来るかもしれない大事象に備えて SLO を大幅に緩め、エラーバジェットに余裕を積む結果、日常的な劣化が SLO 範囲内に収まり気づかれなくなる。② エラーバジェットを「消費すべき」という通常の運用論が破綻する——小惑星に備えたバジェットを毎週消費するのは無責任だが、使わないままでは本来の Reliability 管理が形骸化する。Alvidrez (SREcon15) の「SLA を超えすぎることの機会損失」と逆方向の問題であり、SLO が現実から乖離するリスクとして対をなす (Source: [[@2019__SREcon19EMEA__The Map Is Not the Territory - How SLOs Lead Us Astray, and What We Can Do about It]], [[@2015__SREcon15__Error Budgets and Risks]])。 - **低重要度アラートでもエラーバジェット消費を起こすため、調査準備が必要になる**: 池田の SRE NEXT 2023 発表では、他システム向けの FCKeditor 脆弱性攻撃が Perl5 アプリケーションで有効な攻撃にはならない一方、HTTP リクエストボディを解釈できず 500 を返し、SLO 違反としてエラーバジェットを削る事例が示された。これは「Critical ではないから無視する」ではなく、低重要度の [[Warningアラート]] でも予算消費を観測し、WAF でアプリケーション到達前に遮断するなど、予算保護の観点で処理すべきことを示す。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]]) - **エラーバジェット枯渇は「もう予算がない」という制約ではなく、信頼性優先の組織的許可証として機能する**: Hidalgo は SREcon19 EMEA で、Squarespace ELK の SLO（99% / 5 分以内）を定義した翌日に発生した障害でエラーバジェットが枯渇し、「With no remaining error budget, we gave ourselves permission to go all-in」と述べた。エラーバジェットが残っているうちは「Surplus → Do what you want!」、枯渇すれば「Out of Budget → Focus on reliability.」という 2 択の意思決定モデルを視覚化した。この「許可証」としての機能は、Jones・Murphy の「SRE が No から Yes/if へ転換する」という組織的帰結と同方向だが、より現場に近い解釈——「状況が悪いときに全力を出す許可が与えられる」——として補完する。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) - **「ローンチオンブラック」ルールは 2014 年の SREcon14 で最初に公開されたエラーバジェットの運用実施形態である**: [[Ben Treynor Sloss]] は 2014 年に「SLA 遵守中ならローンチを自由に許可し、違反中はコンプライアンス回復まで全ローンチを凍結する」という明示的ルールを提示した。このルールの重要な特性は「SRE と開発チームの間に主観的判断を介在させない」点にある。SRE Book (2016) の「エラーバジェットによる開発速度制御」は、この 2014 年のシンプルな二値ルールをより精緻化した連続制御として発展させているが、Alvidrez の「バンバン制御から比例制御へ」という移行論（SREcon16）は逆に、2014 年の単純ルールから SRE Book/Workbook のバーン率制御への発展を組み立て制御の視点で整理していたことになる。また開発チームが「他チームの不品質なローンチが自チームのエラーバジェットを食い荒らす」ことに対抗して自浄的に動く仕組みは、2014 年講演で「開発チームが相互に牽制する」と口頭で明言されていたが、SRE Book ではより概念的な説明に留まる。(Source: [[@2014__SREcon14__Keys to SRE]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2016__SREcon16__Service Levels and Error Budgets]]) - **Hidalgo の入門的な「イベントベースと時間ベースは等価な表現」という説明は、Koss・Goins の実務知見が示す乖離の前で単純化として読み直す必要がある**: 『SLO サービスレベル目標』1 章は、良い/悪いイベント数で数えるイベントベースと、不良時間(不良分)で数える時間ベースを「同じ原理の異なる表現にすぎない」と導入する(例: 30 日・SLO 99.9% → 0.1% ≒ 43 分)。しかし Koss・Goins(SREcon23 Americas)は、時間スライス集計(時間ベースに近い)がピーク時と深夜のリクエスト数を同じ 1 票として扱うためインシデント深刻度と乖離し、イベントベース集計に切り替えると深刻度に比例した消費になることを実測で示した。両者は矛盾しない——Hidalgo の説明はトラフィックが一定である単純化された導入例であり、Koss・Goins はトラフィックが変動する現実の運用でこの単純化が破れる境界条件を明示する (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 - **段階的なエラーバジェットポリシーには「時間軸」「頻度」「人員配分」という 3 つの異なる次元の実装例がある**: Takamura(Road to SRE NEXT 2026 神戸)の Level1〜Level5 は組織の SLO 文化成熟度という時間軸に沿った段階化、Atlassian(Vieiro, SREcon18 Asia)の「13 週中 7 週未達」は評価期間内の未達頻度という頻度軸の段階化であるのに対し、Hidalgo(『SLO サービスレベル目標』5 章)は「バジェット消費 33%/66%/100% で信頼性作業に割り当てるチームメンバーの割合を 2/6→4/6→6/6 人と増やす」という人員配分軸の段階化を示す。3 者はいずれも「二値の開発凍結/非凍結を避け、連続的に対応の強度を上げる」という同じ設計思想(既出のバンバン制御回避と同方向)を共有しながら、段階化の軸として時間・頻度・人員のいずれを選ぶかが独立に異なる (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.2.3.2, [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]])。 - **カレンダーに紐付いたエラーバジェットウィンドウは、Atlassian・Mackerel が実務で採用する週次/四半期区切りの利点(報告のしやすさ)と表裏一体の失敗パターンを Hidalgo が明示する**: 既出の Atlassian「13 週中 7 週未達」・Mackerel「調査するか判断する」の実践知見はいずれもカレンダー区切り(週次・スプリント)でのポリシー運用を前提とするが、Hidalgo(『SLO サービスレベル目標』5 章)はカレンダーに紐付いたウィンドウの欠点として、月内にバジェットを使い果たしてリリースを凍結すると、月初にリリースが一斉に解放されて再度バジェットを急速消費する「自己永続的サイクル」を指摘する。カレンダー区切りの運用を推奨する実務側の知見(報告容易性・請求サイクルとの整合)と、それが生む構造的なリバウンドリスクを指摘する理論側の知見を並べると、カレンダー区切りの採否は「報告のしやすさ」対「リリース集中による再超過」のトレードオフとして捉え直せる (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.2.1.3, [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]])。 - **多段依存の合成計算は、単純な掛け算では下層ほど厳しい目標を要求することを具体例で示す**: 『SLO サービスレベル目標』12 章は、決済ベンダーの SLA(99.99%)と内部マイクロサービスの SLO(99.99%/99.9%/99%)を掛け合わせ、結果として得られる合成信頼性(99.98%/99.89%/98.99%)と月間許容ダウンタイム(8 分 45 秒/48 分 12 秒/7 時間 22 分 40 秒)を表で提示した。これは Moyer の Zendesk 依存ツリー(既出)が示した「上位層は下位層のエラー率を加算的に観測する」現象を、ベンダー契約という外部制約から逆算して自社の内部目標値を決める向きで具体化したものであり、SLO Algebra が未解決のまま、実務では掛け算による見積もりが広く行われていることを示す (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 12 適切に機能した例]] §12.2.2.1, [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]])。 - **「48 時間」をファストバーン/スローバーンの境界とする経験則は、CNCF Whitepaper・SRE Workbook のバーンレート表を具体的なウィンドウ幅の目安に翻訳する**: Murphy(『SLO サービスレベル目標』8 章)は、画像サーバーの例(SLO 99.9%・30 日間、許容ダウンタイム 2,592 秒)でファストバーンを 1 時間 1% 消費、スローバーンを 1 週間 10% 消費に設定し、SRE Workbook の目安(ページ用 1 時間 2%・チケット用 3 日 10%)より厳格な値を採用した。「48 時間未満をファストバーン、48 時間以上をスローバーン」という境界の明示は、CNCF Whitepaper のバーンレート表(バーンレート 1=30 日枯渇、1000=43 分枯渇)や SRE Workbook の Alerting on SLOs には見られない、この章オリジナルの追加である。ただし本文には 2,592 秒の 10% を「259.2 秒」と算出した直後に「1 週間ウィンドウでは 295.2 秒継続」と記す数値の食い違いがあり(2,592×0.1=259.2 が計算上正しいと考えられる)、原文の誤記の可能性がある点は該当 source ページに contradiction callout として明示した (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 8 SLOの監視とアラート]] §8.2.4–§8.2.5, [[@2018__Google SRE Workbook__Alerting on SLOs]], [[@2023__CNCF TAG Observability__Observability Whitepaper]])。 - **低頻度イベント SLO の達成可能上限 `(N-1)/N` は、低トラフィックサービスの極端なバーン率問題に部分的な計算式を与える**: Murphy(8 章 §8.2.7)は、SLO 評価期間あたりのイベント数が N 個しかない独立不可分な系では少なくとも 1 つのエラーを許容する必要があり、達成可能な SLO の上限は `(N-1)/N`(例: 10 イベント/期間なら 90% が上限)になると定式化した。対処として「イベント数そのものを再構成する」(月次アップロード回数でなく基礎データの整合性で SLO を定義する等)ことを提案するが、「すべてのシステムでこの再構成が可能なわけではない」と限界も明示する。これは本ページ既出の未解決の問い「低トラフィックサービスでは少数の失敗が極端なバーン率に見え、人工トラフィックや上位集約が必要になる」に具体的な計算式と部分的な対処法を与えるが、完全な解決策ではないため当該の問いは引き続き未解決として残る (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 8 SLOの監視とアラート]] §8.2.7)。 ## バーンレートアラートの定量化（CNCF Whitepaper） CNCF TAG Observability は SRE Workbook のバーンレート概念を Prometheus 計算式つきで体系化した（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）: | バーンレート | エラー率 | 30 日・99.9% SLO での枯渇予測 | |---|---|---| | 1 | 0.1% | 30 日 | | 2 | 0.2% | 15 日 | | 10 | 1% | 3 日 | | 1000 | 100% | 43 分 | 「30 日予算の 5% を 1 時間で消費するにはバーンレート ~36 が必要」という定量例を提示し、単純エラー率アラート（偽陽性が多い）の代替として位置づける。 - **エラーバジェットそのものに誤差マージンがあり、インパクト推定は桁違いに外れうる**: Davidovič (SREcon22 EMEA) は、「エラーバジェットを設定するためのインパクト推定が桁違いに不正確でありえる」ことを示し、3 人の独立した担当者にインシデント影響を推定させてバリアンスを観察することを推奨した。例: 1M USD/年・10K USD バジェット → 99% SLO と設定しても、インパクト推定が 97.4%〜99.7% の不確実バンドを持てばビジネス誤差バジェットを超過するかどうかの判断自体が信頼できない。これは Alvidrez (SREcon15) の「SLA を超えすぎることへの気づきが起点」という成功体験と表裏一体であり、エラーバジェットの信頼性はインパクト推定精度に依存するという見過ごされやすい前提条件として位置づけられる (Source: [[@2022__SREcon22EMEA__Measuring Reliability - What Got Us Here Won't Get Us There]], [[@2015__SREcon15__Error Budgets and Risks]])。 - **バーンアラートの3方式(閾値越え・相対・予測的)は、Wilkinson/CNCFのバーン率アラート式を実装選択肢として展開したものと読める**: Observability Engineering 2nd Edition 第12章は、非ゼロ閾値でのみ発火する「閾値越えアラート」、ベースラインウィンドウ内の失敗数と予算許容数の比を見る「相対バーンアラート」、将来のバジェット枯渇時点を予測する「予測的バーンアラート」の3方式を比較する。CNCF Whitepaper のバーンレート表(バーンレート1=30日枯渇、バーンレート1000=43分枯渇)や Wilkinson の Fast Burn 式 `delta(errors[1h]) > (expected_events * error_budget / burn_period)` は、このうち「相対バーンアラート」の一実装と位置づけられる。閾値越えアラートが最も単純だが「実質的にゴールポストを動かすだけ」という限界を持つのに対し、相対・予測的の2方式はトラフィック総量や将来傾向を織り込む点で優れるという評価軸が、3ソースを並べることで明確になる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]], [[@2023__CNCF TAG Observability__Observability Whitepaper]], [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 - **予測的バーンアラートの「ベースラインは lookahead の最大4分の1」という経験則は、SRE Workbook の複数ウィンドウ複数バーン率アラートの設計原理を定量化したものである**: SRE Workbook の Alerting on SLOs は「長い窓で重大性を、短い窓で燃焼継続を確認する複数ウィンドウ方式」を定性的に説明するが、Observability Engineering 2nd Edition 第12章は「24時間アラームは直近6時間、4時間アラームは直近1時間」という factor of four の具体的な倍率を提示する。さらに「短期(ahistorical)バーンアラート」と「コンテキスト対応(historical)バーンアラート」を区別し、後者は SLO ウィンドウ全体の履歴を保持するため計算コストが高くなる(Honeycomb で1日5,000ドル超の AWS Lambda コスト超過事例)という運用上のトレードオフを明示する点で、SRE Workbook の定性的原則を実装レベルまで具体化している (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]], [[@2018__Google SRE Workbook__Alerting on SLOs]])。 - **比例外挿(proportional extrapolation)は、時間スライス方式が抱える「トラフィック量を無視した票の等価扱い」問題への予測側の対応である**: [[イベントベースSLO]] の議論(Koss・Goins, SREcon23 Americas)は、集計時点でのイベントベース化によってピーク/深夜の重み差を解消するのに対し、Observability Engineering 2nd Edition 第12章の比例外挿は、予測(バーンアラート)の段階で同じ問題——低トラフィック時間帯の少数失敗を単純な件数の線形外挿だと過小評価する——に対処する。集計方式(イベントベースSLO)と予測方式(比例外挿)は独立した工夫だが、どちらも「トラフィック量に対する比率で見る」という同じ発想を異なる計算段階に適用している (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 - **エラーバジェットの消費量は、アラート起点の運用指標であると同時に、人員配置・予算の妥当性を判断する経営指標としても使われる**: 『SREをはじめよう』第13章で Ben Lutch・Dave Rensin は、Google のプロダクションエクセレンス(ProdEx)四半期審査でエラーバジェットの消費量を主要指標として扱うと述べる。予算のぎりぎりを定常的に消費していれば「良い仕事をしている」、大幅に上回れば「難しい話」、大幅に下回れば「人員過剰ではないか」という3方向の判断に使う。これまでの横断的知見(バーン率アラート・EB Policy・組織展開)がいずれも「いつ・誰が・何をアクションするか」という運用トリガーの設計を論じてきたのに対し、第13章は同じ消費量の数値を「このチームの人数は今のままでよいか」という人事・予算の意思決定に転用する点で、エラーバジェットの用途をアラート・リリース制御から組織設計の定量根拠へ拡張する独立した視点を示す (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]])。 - **経営層への説明では「エラーバジェット」という語彙そのものを使わず、事業指標に翻訳することが定着の前提になる**: Dave Rensin は、SLO やエラーバジェットという言葉は経営層には響かないとし、「不満を持つ顧客との対話に月に何分費やしてよいか」という経営層が直感的に測定できる言い換えを使う。近藤武士(SRE NEXT 2022)が「SLO 違反したらリリースストップ」という Error Budget Policy 原型を組織的に成立しない幻想だと論じたのと同じ問題意識——エラーバジェットの技術的定義だけでは組織に定着しない——を、Rensin は「翻訳前の語彙選択」という、より手前の段階の課題として指摘している (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]], [[@2022__SRENext2022__Who owns the Service Level?]])。 - **「不完全なSLIでも価値を得られる」という現場実務者の証言は、Error Budget Policy を最も緩いアクションから段階的に始めるべきだという複数事例と同方向を指す**: 付録A「若きSREへの手紙」で David Caudill は、SLIを完璧にすることが成功に不可欠だと思い込みやすいが、非常に不完全なSLIを持つチームと定期的に仕事をしていても「それでもSLIから多くの価値を得ている」と述べ、「最初に何をするにしても、それは間違っていると思え」と加える。これは、本ページ既出の「Error Budget Policy を最初は最も緩いアクションから始める実践が複数の独立事例で確認される」(Mackerelチーム・Atlassian・Takamura の3事例)という知見に対して、SLI自体の完成度についても同じプラグマティズムが実務者の個人的信条として支持されることを示す一次資料であり、「精緻なSLI/SLOを整えてから始める」という完璧主義への戒めを、制度設計の外側から補強する (Source: [[@2024__OReillyJapan__SREをはじめよう - Appendix A 若きSREへの手紙]] A.16, [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]])。 - **初めてのエラーバジェットポリシーには「凍結の例外処理」という設計要素が独立に必要であり、既出の段階的緩和とは異なる次元の柔軟性を担う**: 本ページ既出の「Error Budget Policy を最初は最も緩いアクションから始める」実践知(Mackerel・Atlassian・Takamura)は、ポリシーの**厳格度**をどう段階的に引き上げるかを扱う。一方 Rensin(『SLO サービスレベル目標』6章)は、最初のポリシーとして「新規機能なし(機能凍結)」という比較的厳格な方針を推奨したうえで、例外的に凍結を破る必要が生じた場合の処理として、無条件だが回数制限のある「銀の弾丸」(年3回程度・フィードバックループなし)と、凍結延長というコストを課す「解凍税」(解凍1日につき凍結1.5日延長)の2方式を提示する。これは「ポリシーの厳格さをどう段階化するか」ではなく「厳格なポリシーに対する例外をどう設計するか」という別の軸であり、Rensin は前者より後者(解凍税)を、リーダーに慎重な判断を促す点で好むと明言する。段階的緩和と例外設計は独立した2つのポリシー設計変数として区別できる。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] §6.3.3.1, [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]]) - **「銀の弾丸」という同一の訳語が、2冊の独立した O'Reilly 書籍で回数制限つき計画変更の例外処理という同じ設計を指しており、この語彙が SRE コミュニティで一定の共有度を持つことを示す**: Rensin(『SLO サービスレベル目標』6章)は、エラーバジェットの機能凍結ポリシーへの例外処理として、無条件だが年3回程度に制限される「銀の弾丸」を提示した。『SREエンタープライズロードマップ』第4章もまた、「エラーバジェットの枯渇に直面して機能リリースを中止する計画」を安易に破らせないための対策として、リーダーに3つの「銀の弾丸」を付与し、想定した計画を変更する必要が生じたときに弾丸の回数だけ上書きできるようにするプラクティスを紹介する。両者は独立した著者・独立した書籍でありながら、「人為的な希少性を導入することで、明確なトレードオフを要求する」という同一のメカニズムに同一の訳語を用いており、単なる偶然の一致というより、Google SRE コミュニティ内で既に流通していた比喩である可能性が高い。ただし第4章の銀の弾丸はエラーバジェット固有のポリシーに限定されず、「オデュッセウスの盟約」(計画への固執)全般への対策として、より広い「計画変更」一般に適用される点で射程が異なる。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] §6.3.3.1) - **「初めてのポリシー発動」を組織が完全に遵守できるかどうかが、エラーバジェットが名目的な仕組みで終わるか実効性を持つ制度になるかを分ける分水嶺として明示された**: Rensin は、SLO 採用における真の転換点は全員が賛成した時点でも最初の目標値を決めた時点でもなく、初めてエラーバジェットを使い果たしてポリシーの適用が必要になった瞬間であり、ここで「今回だけは例外にしよう」という誘惑に屈すると、それ以降 SLO が組織に本気で採用されることはないと述べる。近藤武士(SRENext2022)の「『SLO 違反したらリリースストップ』は組織的に成立しない幻想である」という指摘は、まさにこの最初の発動が骨抜きにされる事例を裏付けており、Rensin の警告が実務でも再現される失敗パターンであることを示す。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] §6.3.3.2, [[@2022__SRENext2022__Who owns the Service Level?]]) - **信頼性のバーンダウングラフは、バーン率アラート(機械向け)とは異なる「人間向けレポート」という独立の用途を持ち、HPC のダウンタイム予算バーンダウンチャートと同じ可視化発想をドメイン非依存で共有する**: Hidalgo(『SLO サービスレベル目標』17章)は、エラーバジェットと同じ計算式を任意の時間ウィンドウに適用した「信頼性のバーンダウン」を、常時監視するアラートではなく日次・週次ミーティングで人間が確認するレポート用ダッシュボードとして位置づけた(図17-1)。これは既出の Lueninghoener(SREcon16 Europe)の HPC ダウンタイム予算バーンダウンチャート(Y軸=残り時間、X軸=日付)と、対象ドメイン(Web SLO と HPC クラスタ)が異なるにもかかわらず同一の可視化発想——バーン率アラートによる自動検知と、バーンダウングラフによる人間のパターン認識を補助する装置を分離する——を独立に採用している点で符合する。SRE Workbook のバーン率アラート(Alerting on SLOs)が「いつ機械が発火するか」を設計するのに対し、両者は「いつ人間が気づくか」を設計する対の関係にある (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] §17.2.1, [[@2016__SREcon16Europe__HPC Downtime Budgets]])。 - **エラーバジェットの残量は「真偽値(SLOの状態)」と「絶対量(残り時間)」という異なる粒度でレポートすることで、異なる読み手のニーズに応える**: Hidalgo(17章)は、「SLOを満たしているか」という真偽値の指標と、「エラーバジェットが17分残っています」という絶対量の言明を区別し、前者は依存先サービスの状態確認、後者は即座に理解・行動できる意思疎通の手段として使い分けられると述べた。既出の Moyer(SREcon20 Americas)の「エラーバジェット民主化の3鍵」(実例・機械解析可能な公式・明示性)は主にエンジニア組織内での標準化を扱うのに対し、17章の真偽値/絶対量の使い分けは、経営層・依存先チームなど技術的詳細を必要としない読み手への「翻訳」の粒度設計として補完的である (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] §17.2.1–§17.2.2, [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]])。 - **意図的な余剰バジェット消費への処方箋は「実験的リスクテイク」という具体的なカテゴリで与えられる**: 本ページの未解決の問い(Wilkinson の「バジェットを意図的に消費しないとチームが変更を恐れる」問題、HPC の余剰時間活用ポリシーの必要性)に対し、Treen(『SLO サービスレベル目標』13章)は具体的な処方箋を示す——大規模マイグレーション・カオステスト(意図的なランダムエラー導入)・新アルゴリズムの実験・ロールバックインフラの整備・制御された障害からの回復練習という 5 種類の使途を挙げ、「失敗が許可されるのは珍しいことだ」と余剰バジェットの心理的な価値そのものを強調する。HPC のダウンタイム予算(Lueninghoener)が「技術的負債解消・専用ユーザー時間」を活用先の候補として挙げるにとどまっていたのに対し、13 章はより具体的にカオスエンジニアリングという既存プラクティスへ接続する点で一歩進んだ処方を与える。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] §13.3.6.3, [[@2016__SREcon16Europe__HPC Downtime Budgets]]) - **エラーバジェットの縮小は自動化投資の優先度を上げる駆動力として位置づけられる**: 『SREエンタープライズロードマップ』第3章は、自動化(SRE本第7章)が最も重要になるのは信頼性目標が99.99%以上の場合であり、この水準では人間の介入がほぼ必ずSLO違反を招くためだと述べる。エラーバジェットが縮小するにつれて、介入のバランスはグレースフルフェイル・リトライなどのアプローチによるプロアクティブなメンテナンスへ移行するという。これは、本ページ既出の「エラーバジェットは意思決定の連続制御シグナルである」(バンバン制御からプロポーショナル制御へ)という知見に、「バジェットの絶対的な小ささそのものが自動化投資の優先順位を規定する」という別の因果方向を加える——バーン率がリリース速度を制御するだけでなく、SLO水準自体が「どこまで自動化に投資すべきか」を規定するという読み方が可能になる (Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]], [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]])。 - **エラーバジェットは「コントロールの例」にも「コンテキストに近い自己統制の例」にもなりうる、視点依存の仕組みである**: 『SREの探求』1章で Coburn Watson(当時 Netflix)は、Google のエラーバジェットモデルを、組織規模が拡大した際に「より多くのプロセスに依存せざるをえない」コントロールベース寄りのモデルの一例として位置づける。一方、本ページ既出の SRE Book 第3章および SREcon16 での Jones の説明は、エラーバジェットを開発チームと SRE の対立を「共通インセンティブ」に変換する仕組みとして描き、その理想的な運用を二値の「バンバン制御」ではなくバーン率という連続シグナルに基づく「プロポーショナル制御」だとする。両者は矛盾しないが強調点が異なる——Coburn はエラーバジェットを「数値化されたルールによる制約」というコントロール的側面から見るのに対し、SRE Book/Jones はバーン率という連続的な情報提供を通じた自己統制という、コントロールとコンテキストの中間的な運用として描く。エラーバジェットという同一の仕組みが語られる文脈によって性格づけが変わる点は、[[コンテキスト対コントロール]] の中心的な論点でもある (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]] ch.1 p.4, [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]], [[@2016__SREcon16__Service Levels and Error Budgets]])。 ## 未解決の問い - 13 章の余剰バジェット活用リスト(マイグレーション・カオステスト・アルゴリズム実験・ロールバックインフラ整備・障害回復練習)は使途の例示にとどまり、どの程度の余剰(バーン率・絶対量)から着手してよいかの定量的な閾値は示さない。HPC の技術的負債解消ポリシーや実務のガバナンスプロセスとの比較検証が必要(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] §13.3.6.3)。 - Rensin の「銀の弾丸」「解凍税」という例外処理方式は、本ページ既出の Level1〜Level5 段階的ポリシー拡大や「13週中7週未達」トリガーとどう組み合わせられるか。段階が進んだ組織でも例外処理の必要性は残るか、それとも成熟とともに不要になるか。 - エラーバジェットの消費量を人員配置・予算判断(ProdEx のような四半期審査)に使う場合、インシデント影響推定の不確実性(Davidovič, SREcon22 EMEA)がそのまま人事判断の誤差になる。技術的なバーン率アラートより高い精度基準が必要ではないか。 - エラーバジェットは人間の開発チームと SRE の協調を前提とする。[[agentic SRE]] でエージェントが自律的に緩和する場合、エラーバジェットの消費判断と凍結判断は誰が/何が行うか。 - エラーバジェットの粒度（四半期・月次・週次）は機能リリース頻度に依存するが、CI/CD の高速化でリリース頻度が桁違いに上がった現在、四半期バジェットは適切か。 - Wilkinson は「SLO は現状のまま（status quo）」と述べ、現実の性能が公表値より良い場合はユーザーがその水準を期待し始めると警告する。設定したバジェットを意図的に消費しないとチームが変更を恐れるようになるが、これを防ぐ制度的な仕組みは何か。 - 低トラフィックサービスでは少数の失敗が極端なバーン率に見え、人工トラフィックや上位集約が必要になる。これらの補助信号は実ユーザー影響を隠す副作用をどこまで持つか。 - 外部からの無効な攻撃や探索的リクエストが 5xx を誘発してエラーバジェットを消費する場合、それをユーザー影響として扱うべきか、WAF・ロードバランサ・アプリケーションのどの層で予算対象外にすべきか。 - SLO 違反時のポリシーを Level1（なにもしない）から段階的に Level5（意思決定に組み込む）へ育てる場合、各レベルへの移行タイミングの判断基準はどう設計するか（Source: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]]）。 - エラーバジェットの「1% 問題」: ユーザー中心サービスでトラフィックを undifferentiated に扱えない場合、リスクを境界化する適切な分割単位（機能フラグ・データセンター・テナント・ユーザー属性）の選定基準はどうなるか（Source: [[@2015__SREcon15__Error Budgets and Risks]]）。 - SLA を割った後「以前のリスクプロファイルに戻る」という処方は実務上どの指標で判断するか。何四半期継続して SLA を超えれば「回復した」と見なせるか（Source: [[@2015__SREcon15__Error Budgets and Risks]]）。 - 「SRE がリリースを止める権限を持つ」ことが前提とされているが、経営・プロダクト管理が支持しない組織でエラーバジェットを有効に機能させる代替アプローチはあるか。 - バンバン制御（二値）からプロポーショナル制御（連続）への移行は、リリース速度をどの関数でバーン率に依存させるべきか。実務上の推奨式は確立されているか。 - **時間スライス集計はすべての分を等価に扱うためエラーバジェット消費がインシデント深刻度と乖離する**: Koss・Goins（SREcon23 Americas）は、99.95 SLO + 95% 閾値による時間スライス方式で "Badder Incident 0%↓"・"Baddest Incident 400%↓" という逆転現象が生じた実例を示した。ピーク時（1 分 1,000 リクエスト）と深夜（1 分 10 リクエスト）を同じ 1 票として扱う結果、「不運にもトラフィックが少ない時間帯に起きた大規模障害」がバジェットに反映されにくい一方、「軽微なエラーが多い時間帯の 1 分」がバジェットを大きく削る。イベントベース集計に切り替えると "Badder 18.1%↓"・"Baddest 36.6%↓" と深刻度に比例した消費になり、エラーバジェットが「ビリーバブルなシグナル」として機能した。(Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) - **エラーバジェットシグナルには「緩慢消費・急速消費・回復」のパターンがあり、読み取り訓練が定着に不可欠**: Koss・Goins は EBR グラフ上で "Slow burn"（変更起因のじわじわ消費）・"Fast burn"（大規模インシデントによる急激な消費）・"Recovery"（バグ修正後の回復）・"Change, Incident, Fast burn"（変更とインシデントの複合）という 4 パターンを識別するフレームを示した。特に「No Incident 49.5%↓」という「インシデントなしの緩慢消費」がインシデント起因消費より大きくなる事例は、バーン率アラートだけでは捕捉できないバグ起因の遅延劣化を示す。チームが EBR グラフを自分で読める状態になることが、エラーバジェットポリシーの実効性の前提条件になる。(Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) - **エラーバジェットポリシーは Leadership・Dev・Product・SRE の 4 者が顧客中心で共有所有することで初めて実効性を持つ**: Koss・Goins は EB Policy を「誰が・何を・いつするか」の責任分担と説明責任として定義し、4 者が顧客を中心とした輪（共有所有）で連携する構造を示した（p.32）。アカウンタビリティの明文化と SLI/SLO の継続的なアップデート（SLI 変更・Objective 変更）が含まれる。SRE Book の「開発チームと SRE の共通インセンティブ」論を現場の組織設計として実装した形式と読める。(Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) - **エラーバジェット民主化の 3 鍵は「実例・機械解析可能な公式・明示性」である**: Moyer（SREcon20 Americas）は、1,000 名規模のエンジニア組織にエラーバジェットを展開するためには、(1) 参照しやすい実世界の例、(2) 人間とコードの両方が解析できる公式、(3) 小さな詳細を明示すること、が不可欠だと述べた。SLI を `[Metric Identifier] [Operator] [Metric Value]`、SLO を `[Success Objective] [SLI] [Period]`、EB を `[Error Budget] [SLI] [Period]` の形式に固定することで、チームをまたいだ自動ツール化と口頭説明の両立が可能になる。Alex Hidalgo の *Implementing Service Level Objectives* が「詳細は読者への宿題」と評されたのに対して、Moyer は実装の細部を明示的に提供した。(Source: [[@2020__SREcon20Americas__Latency-and-Availability-Error-Budgets-Done-Right-at-Scale]]) - **エラーバジェットの HPC 適応——単位を「リクエスト失敗率」から「計画外停止時間」に変換することで移植可能**: Lueninghoener（SREcon16 Europe）は HPC 環境（LANL）で「0.01% of 1,000 ジョブ = 1/10 ジョブ」では意味をなさないと指摘し、代わりに「各クラスタ四半期 30 時間（DST 3 回 × 10 時間 = 利用可能時間の約 1.4%）」をダウンタイム予算と定義した。Y 軸を残り時間（0–30h）、X 軸を日付とするバーンダウンチャートで各クラスタを可視化する。Wolf クラスタが高速ネットワーク障害で一晩停止し四半期予算を使い果たした事例が、可視化なしでは判断が困難だったことを示す。エラーバジェットの本質は「単位（リクエスト失敗）」ではなく「リソースを追跡して意思決定に使う」構造にある (Source: [[@2016__SREcon16Europe__HPC Downtime Budgets]])。 - **マルチサービス構成では依存先のエラー率が上位層の観測誤差率に加算され、自身の EB を超えて見える**: Moyer が示した依存ツリー（Edge → Mid → [Third party (1.0% ER) | Backend (0.1% ER)]）では、Mid tier が 1% EB を設定していても、自身の実コード起因エラーは 0.1% に過ぎないのに、Third party + Backend 起源の 1.1% を加えた合計 1.2% 以上を観測する。Edge tier も同様に自身 0.1% + Mid tier 起源 1.2% = 1.2% を観測する。「誰の EB が消えているのか」を依存関係で追跡しないと責任の所在が不明になる。Desai（SREcon19 EMEA）の「SLO Algebra は未解決」という問題を Zendesk の実運用例として具体化した。(Source: [[@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]]) - **非同期パイプラインのバーンレートアラートは「データ損失アラート」を必ず併置する**: eBay（SREcon25 Americas）の実装では、バーンレートアラート（SLO 違反アラート）に加えて `absent(sum(sli_valid_events{...}))` と `absent(sum(sli_good_events{...}))` でメトリクス欠損を検知するデータ損失アラートを設けた。バーンレートはメトリクスが存在しなければ偽陰性（アラートが沈黙）になるため、メトリクスのノー・データを独立して監視する必要がある。これはエラーバジェット消費の観測可能性そのものを保証する補完的な仕組みであり、SRE Workbook の Alerting on SLOs では明示的に言及されていない実装上の注意点として追記された実践知である。(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]], [[@2018__Google SRE Workbook__Alerting on SLOs]]) - **Error Budget Policy の行動定着には「非機能要求への予算配分」という組織的前提が必要**: [[近藤武士]]（SRE NEXT 2022）は、スタディサプリで SLI/SLO の定義・観察文化を 2 プロダクト 15 チームに導入した後も、Error Budget Policy に従った「行動する」ステップが定着しなかった原因を「非機能要求に対処する予算・権限が開発チームになかった」と分析する。SLO 違反時にアーキテクチャ変更やインフラ分離を実施したくても、機能開発の優先度が常に高くリソースが割けなかった。解決は 2021 年の技術戦略グループ発足により「新規:エンハンス:技術的負債解消 = 1:1:1」という予算宣言が組織として承認されたことで実現した。Atlassian（Vieiro）の「13 週中 7 週未達」という緩いトリガーからの段階的拡大、Takamura の Level1〜Level5 段階体系と比較すると、近藤の事例は「ポリシーのトリガー設定」ではなく「アクションを実行するための組織的予算枠の存在」が前提条件であることを示す点で補完的な失敗事例として重要 (Source: [[@2022__SRENext2022__Who owns the Service Level?]])。 - **「SLO 違反したらリリースストップ」は組織的に成立しない幻想である**: 近藤はこれが「現実的ではない」とし、理由として ① 事業責任者の合意が必要、② 「完璧な SLI/SLO」が前提だが存在しない、③ 現場判断で都度実施するのは組織横断のコミュニケーションコストが高すぎる、を挙げる。SRE Book の Error Budget Policy（開発凍結）は組織的権限委譲と事業責任者の事前合意が整った状態を前提としており、それなしに現場 SRE が単独でリリースを止めようとしてもポリシーが有名無実化する。エラーバジェットを「開発速度の共通インセンティブ」に変える（Jones・Murphy）ためには、その前段として技術的課題解決の予算枠という制度的基盤が必要 (Source: [[@2022__SRENext2022__Who owns the Service Level?]], [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]])。 - **Error Budget Policy を「最初は最も緩いアクションから始める」という実践が複数の独立した事例で確認される**: Mackerel チームは「調査をするか判断する」という最低限のアクションを Error Budget Policy の出発点とした（渡辺、SRE NEXT 2023）。Atlassian（Vieiro、SREcon18 Asia）は「13 週中 7 週未達」という緩いトリガーから開始し、Takamura（Road to SRE NEXT 2026 神戸）は Level1「なにもしない」から Level5「意思決定に組み込む」への 5 段階体系化を提案した。3 社が独立に「厳格な Policy からスタートすると組織に拒否反応が起きる」という障害を回避するために同じ方向性を選んでいる。SRE Book・Workbook が示す完全なエラーバジェットポリシー（開発凍結トリガー付き）を「目指す終点」として位置づけつつ、起点は「調査判断」「アクション確認」「可視化」など組織が受け入れられる最小単位から始めることが、定着の共通条件と言える (Source: [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]], [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]], [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]], [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]])。 - テール管理の「サンドバッギング」を防ぐには SLO をどう調整すべきか。Desai は「テールに SLO を使わない」と提案したが、ではテールが発生した際に SLO 違反扱いしないための実装的な除外機構はどうあるべきか。 - Atlassian は「13 週中 7 週未達」という緩いトリガーから始め翌四半期に「5 週以下」へ引き締める反復戦略を採用した。この「トリガー閾値の段階的引き締め」はどのペースが組織的に持続可能か (Source: [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]])。 - HPC ダウンタイム予算では「四半期末に余剰時間が生じたクラスタ（Pinto: 約 3 時間しか使わず）」と「超過したクラスタ（Wolf: −12h）」が並列する。余剰時間をどう活用するか（技術的負債解消・専用ユーザー時間など）のポリシーが必要であり、Web SRE の「バジェットを意図的に消費しないとチームが変更を恐れる」問題と同型の問いが HPC でも生じる (Source: [[@2016__SREcon16Europe__HPC Downtime Budgets]])。 - コンテキスト対応バーンアラートの計算コストとキャッシュ鮮度はトレードオフになる(Honeycomb の1日5,000ドル超のコスト超過事例)。キャッシュを導入した場合、キャッシュの更新間隔がバーンアラートの検知遅延にどの程度影響するか、実務上の目安は確立されているか(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 - 「不完全なSLIでも価値を得られる」(David Caudill)という現場の実感は、どの程度の不完全さまでなら許容されるか。SLIの不完全さ(欠測・粒度の粗さ・代理指標としての限界など)を定量的に分類し、Error Budget Policy の段階的導入(Level1〜Level5)とどう対応づけられるかは未検討である(Source: [[@2024__OReillyJapan__SREをはじめよう - Appendix A 若きSREへの手紙]])。 - Hidalgo が指摘するカレンダーに紐付いたウィンドウの「月初リリース集中による再超過」の自己永続的サイクルを、実際に緩和した組織事例はあるか。ローリングウィンドウへの切り替え以外に、月をまたぐリリースの計画的分散やフィーチャーフラグによる段階的公開など、カレンダー区切りを維持したままの緩和策は確立されているか(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.2.1.3)。 - エラーバジェットの残量を[[カオスエンジニアリング]]実験(負荷テスト・ブラックホール演習等)の実施可否の判断材料に使う場合、「バジェットが十分残っている」を定量的にどう定義するか(閾値 %、バーン率の余裕など)。既存のカオスエンジニアリング事例(Bradesco 等)ではこの判断基準がガバナンスプロセスの一部として明示されていない(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.1.4–§5.1.6)。 - 『SREエンタープライズロードマップ』第4章の「銀の弾丸」がエラーバジェット固有でなく計画変更一般に適用される広い射程を持つのに対し、Rensin(SLO本6章)の「銀の弾丸」はエラーバジェットの機能凍結ポリシーへの例外処理に限定される。同一の訳語がこの2つの異なる射程の間でどこまで意図的に対応しているのか(同一の Google 系譜の比喩が広義/狭義に分化したのか、独立発生か)は、両ソースの記述だけでは確認できない。 ## 関連 - ソース: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 8 SLOの監視とアラート]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 12 適切に機能した例]] / [[@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]] / [[@2019__SREcon19Americas__Case Study - Implementing SLOs for a New Service]] / [[@2015__SREcon15__Error Budgets and Risks]] / [[@2016__SREcon16__Service Levels and Error Budgets]] / [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]] / [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] / [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] / [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] / [[@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__Alerting on SLOs]] / [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]] / [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] / [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]] / [[@2016__SREcon16Europe__HPC Downtime Budgets]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]] / [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]] / [[@2024__OReillyJapan__SREをはじめよう - Appendix A 若きSREへの手紙]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]] / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]] / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]] - エンティティ: [[Marc Alvidrez]] / [[SRE Book]] / [[Google]] / [[Ben Treynor Sloss]] / [[Jamie Wilkinson]] / [[Chris Jones]] / [[Niall Murphy]] / [[Gui Vieiro]] / [[Atlassian]] / [[Arnaud Lawson]] / [[Squarespace]] / [[Narayan Desai]] / [[Cory Lueninghoener]] / [[Los Alamos National Laboratory]] / [[Alex Hidalgo]] / [[Honeycomb.io]] / [[Ben Lutch]] / [[Dave Rensin]] - 概念: [[サービスレベル目標]] / [[信頼性スタック]] / [[agentic SRE]] / [[インシデント管理]] / [[Warningアラート]] / [[イベントベースSLO]] / [[SREエンゲージメントモデル]] / [[カオスエンジニアリング]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@2015__SREcon15__Error Budgets and Risks]]（エラーバジェットの実体験的起源、1% クラスター、可用性計算式、エラーバジェット = 権利でなく獲得するもの、SLA 計測の段階的洗練） - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]](SRE の定義、50% ルール、エラーバジェットの導入) - [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]](エラーバジェットの体系的定義、100% 可用性の非追求、非線形コスト曲線、リクエスト成功率での計測) - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]](SLI/SLO/SLA の実践的定義とエラーバジェットの運用) - [[@2016__SREcon16__Service Levels and Error Budgets]](エラーバジェットの制御ループ、組織的帰結、バンバン制御回避、SRE が No と言わなくなる変化) - [[@2018__Google SRE Workbook__Alerting on SLOs]](バーン率、複数ウィンドウ複数バーン率アラート、低トラフィックサービスの制約) - [[@2018__Google SRE Workbook__Appendix B Example Error Budget Policy]](変更停止、P0 アクションアイテム、信頼性作業への制度的許可) - [[@2018__SREcon18Asia__How Atlassian Is Tackling Error Budgets, Agile Style]](Error Budgets 0.1 アジャイル導入・13週中7週トリガー・可視化とブログ・Not So Good Result の透明化・SLO 達成率回復トレンド) - [[@2016__SREcon16Europe__HPC Downtime Budgets]](HPC への適応・ダウンタイム時間単位・バーンダウンチャート・Wolf クラスタ超過事例・SRE 普及はコミュニティ形成課題) - [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]](閾値越え/相対/予測的バーンアラートの3方式比較、factor of four ヒューリスティック、短期/コンテキスト対応バーンアラート、比例外挿、Honeycomb のキャッシュコスト事例) - [[@2024__OReillyJapan__SREをはじめよう - Chapter 13 ビジネス視点からのSRE]](プロダクションエクセレンス(ProdEx)によるエラーバジェット消費量の四半期審査、人員配置・予算判断への転用、経営層向け語彙翻訳の必要性) - [[@2024__OReillyJapan__SREをはじめよう - Appendix A 若きSREへの手紙]](A.16 David Caudill: 不完全なSLIでも価値を得られるという実務者の証言) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 1 信頼性スタック]](エラーバジェットのイベントベース/時間ベース算出、意思決定ツールとしての基本的な使い方) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]](エラーバジェットの実践的な使い道、イベントベース/時間ベース計算の詳細手順、ローリング/カレンダーウィンドウの比較、エラーバジェットポリシーの4要素) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 8 SLOの監視とアラート]](バーンレートの定義、ファストバーン/スローバーンの48時間境界、画像サーバーの具体例、低頻度イベントSLOの達成可能上限) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 12 適切に機能した例]](ベンダー SLA と内部マイクロサービス SLO の掛け算による合成信頼性の具体例) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 6 同意の獲得]](初めてのエラーバジェットポリシー設計、機能凍結の例外処理としての銀の弾丸・解凍税、初めてのポリシー発動が持つ組織的重要性) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]](信頼性のバーンダウンダッシュボード、SLOの状態とエラーバジェットの状態の使い分け、DDoS攻撃の物語によるエラーバジェット消費の実演) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 13 SLO文化の構築]](余剰エラーバジェットの意図的な使途——マイグレーション・カオステスト・アルゴリズム実験・ロールバックインフラ整備・障害回復練習、Harold Treen 執筆) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]](James Brookbank, Steve McGhee, 2022, 第4章)— 計画変更全般への例外処理としての「銀の弾丸」、オデュッセウスの盟約 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]](James Brookbank, Steve McGhee, 2022, 第3章)— エラーバジェットの縮小が自動化投資の優先度を上げる駆動力になるという関係づけ