## 定義 エラーバジェットとは、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]] はアップタイムでなくリクエスト成功率で計測する——分散システムは部分的に稼働し続けるため、バイナリなアップ/ダウンは不適切 ## 横断的知見 - **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]]) ## バーンレートアラートの定量化（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]])。 ## 未解決の問い - エラーバジェットは人間の開発チームと 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]])。 ## 関連 - ソース: [[@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]] - エンティティ: [[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]] - 概念: [[サービスレベル目標]] / [[agentic SRE]] / [[インシデント管理]] / [[Warningアラート]] - 関連 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 普及はコミュニティ形成課題)