エラーバジェット

エラーバジェットとは

エラーバジェット（Error Budget）は、SREにおける最も重要な概念の一つであり、開発チーム（機能開発の速度）とSREチーム（システムの信頼性）の間の対立を解消するための客観的な指標です。

Google SRE bookの「Embracing Risk（リスクの受容）」の章では、信頼性を100%にすることは不可能であり、また望ましくもないとされています。ユーザーが気づかないレベルの過剰な信頼性を追求することは、機能開発の機会損失（Opportunity Cost）につながるからです。

エラーバジェットは、100%から信頼性目標（SLO: Service Level Objective）を引いたものとして定義されます。

エラーバジェット = 100% - SLO

例えば、四半期のSLOが 99.9% の場合、エラーバジェットは 0.1% となります。これは、その四半期において 0.1% までは失敗（ダウンタイムやエラー）が許容される ということを意味します。

エラーバジェットの主な目的は、リリースの速度と信頼性のバランスをデータに基づいて決定することです。

バジェットが残っている場合:
- 開発チームは積極的に新機能をリリースできる。
- 実験的な試みや、リスクのある変更を行うことができる。
- テストを簡略化してスピードを優先することも許容される。
バジェットが枯渇した場合:
- 機能リリースを一時停止する。
- エンジニアリングリソースを「信頼性の向上」（テストの強化、バグ修正、インフラ改善など）に集中させる。
- バジェットが回復する（または次の期になる）まで、リスクのある操作を控える。

これにより、「リリースしたい開発」と「安定させたい運用」の間の政治的な交渉や感情的な対立を排除し、「バジェットが残っているか？」 という客観的な事実に基づいて意思決定を行うことができます。

SLOを「リクエスト成功率」で定義した場合の計算例です。

この場合のエラーバジェット（許容される失敗数）は以下のようになります。

1,000,000,000 × (1 - 0.9999) = 1,000,000,000 × 0.0001 = 100,000 回

つまり、この四半期で10万回のエラーまでは「許容範囲内」として扱われます。

Google SRE bookでは、サービスの性質に応じて適切な可用性ターゲット（SLO）を設定することの重要性が説かれています。その好例として YouTube の事例が紹介されています。

2006年にGoogleがYouTubeを買収した際、GoogleはYouTubeに対してどのような可用性ターゲットを設定すべきかを検討しました。

Googleは、GmailやGoogle Calendarなどのエンタープライズ向け製品（Google Apps for Work）と比較して、YouTubeの可用性ターゲットを低く設定しました。

ビジネスフェーズの違い: 当時のYouTubeは急速に成長している消費者向けサービスであり、機能開発のスピードが何よりも重要でした。
ユーザー層の違い: エンタープライズユーザー（企業）にとってのダウンタイムは業務停止に直結しますが、消費者向け動画サービスのユーザーはそこまでの厳密な可用性を求めていませんでした。
イノベーションの優先: 過剰に高い信頼性を目標にすると、変更の速度が遅くなり、YouTubeの成長を阻害する恐れがありました。

この事例は、「信頼性は高ければ高いほど良いわけではない」 ということを示しています。サービスのフェーズやユーザーの期待値に合わせて適切なSLOを設定し、余剰分の信頼性（エラーバジェット）を機能開発の速度（イノベーション） に投資することが、ビジネス全体の成功につながります。