# Google SRE Workbook - Appendix B Example Error Budget Policy Navigation: [[エラーバジェット]] | [[サービスレベル目標]] | [[ソフトウェア変更管理]] ## 概要 付録 B は、Example Game Service のエラーバジェット方針例である。対象はバックエンドの日次リリースとクライアントの週次リリースの両方であり、目的は顧客を反復的な SLO 未達から守り、信頼性と機能開発のバランスを取るインセンティブを与えることである。(Source: [[.raw/articles/sre-workbook-error-budget-policy-2026-06-07.md]]) この方針は SLO 未達への罰ではない。変更停止は望ましい状態ではないが、信頼性データが「今は機能より信頼性を優先すべき」と示すとき、チームが信頼性に集中するための制度的許可として機能する。 ## 方針の要点 - サービスが SLO 以上で動作している場合、通常のリリース方針に従ってリリースとデータ変更を進める。 - 直近 4 週間でエラーバジェットを超過した場合、P0 課題またはセキュリティ修正以外の変更とリリースを停止し、SLO 内へ戻るまで待つ。 - コードバグ、手続きミス、ポストモーテムで明らかになった硬い依存関係、誤分類により本来消費すべき予算が消費されなかった場合、チームは信頼性作業に取り組まなければならない。 - 全社ネットワーク障害、他チーム管理サービスの障害、SLO スコープ外ユーザー、ユーザー影響のない誤分類などの場合、非信頼性機能の作業を継続してよい。 - 単一インシデントが 4 週間のエラーバジェットの 20% 超を消費した場合、ポストモーテムと根本原因対策の P0 アクションアイテムが必要である。 - 単一障害クラスが四半期のエラーバジェットの 20% 超を消費した場合、翌四半期計画に P0 項目を置く必要がある。 - エラーバジェット計算や方針上の行動に関する不一致は CTO へエスカレーションする。 ## 重要な概念候補 - [[エラーバジェット方針]]: エラーバジェット消費に応じて変更停止、信頼性作業、ポストモーテム、計画項目を発動する制度。 - [[変更停止]]: SLO 未達時に P0・セキュリティ修正以外の変更を止める信頼性制御。 - [[信頼性作業への制度的許可]]: 罰ではなく、データに基づいて機能開発から信頼性へリソースを振り替える組織設計。 - [[P0アクションアイテム]]: 根本原因に対処する最高優先度の作業項目。 ## 重要な実体候補 - [[Steven Thurgood]] - [[David Ferguson]] - [[Betsy Beyer]] - [[Example Game Service]] - [[CTO]] ## 既存 SRE Book との関係 SRE Book 第 3 章「Embracing Risk」はエラーバジェットの概念を説明する。本付録は、その概念を変更管理、ポストモーテム、四半期計画、エスカレーションに接続する具体方針として示す。SRE Workbook の SLO 実装章と付録 A の SLO 文書例とも一体で扱う必要がある。 ## 統合時に更新すべき既存ページ候補 - [[エラーバジェット]]: 4 週間窓、20% 閾値、変更停止、P0 アクションアイテム、罰ではなく優先順位変更という解釈を追記。 - [[ソフトウェア変更管理]]: エラーバジェットを変更速度制御のメカニズムとして接続。 - [[サービスレベル目標]]: SLO 文書とエラーバジェット方針の連動を追記。 - [[インシデント管理]]: 20% 予算消費時のポストモーテム発動条件を追記。 ## 出典 - [[.raw/articles/sre-workbook-error-budget-policy-2026-06-07.md]]