> [!abstract] 概要 > Marc Alvidrez による章。100% の信頼性を目標とすることの不合理性を論じ、リスクの受容とエラーバジェットの概念を通じて信頼性とイノベーション速度のバランスを取る Google の方法論を提示する。 ## 書誌情報 - 書名: Site Reliability Engineering: How Google Runs Production Systems - 章: Chapter 3 — Embracing Risk - 著者: Marc Alvidrez - 出版: O'Reilly Media, 2016 年 4 月 ## 100% 信頼性への反論 100% の信頼性を追求すべきではない理由は 2 つある。 ### ユーザー知覚の限界 ユーザーは可用性 99.99% と 99.999% の差を実質的に知覚できない。ユーザーとサービスの間にはネットワーク、端末、ISP など多数のコンポーネントが介在し、それら自体が 100% でないため、サービス単体の可用性を極限まで高めても体験上の改善は微小である。 ### 非線形コスト曲線 信頼性の漸増的改善はコスト曲線が**非線形**に上昇する。可用性の各「ナイン」を 1 つ追加するごとに、要するコストは約 **100 倍**に増大する。このコストは冗長なインフラだけでなく、機会費用——機能開発やイノベーションに投入できたはずのエンジニアリング資源——をも含む。 ## リクエスト成功率による計測 [[Google]] は従来の「アップタイム」（時間ベース）ではなく、**リクエスト成功率**で可用性を計測する。 $\text{availability} = \frac{\text{successful requests}}{\text{total requests}}$ この指標は計画保守や部分的劣化といった複雑なシナリオをより正確に反映する。時間ベースの計測では、トラフィックの少ない深夜の障害と、ピーク時の障害が等価に扱われてしまう問題を回避できる。 ## エラーバジェット [[エラーバジェット]]は本章の核心的概念である。プロダクトチームと SRE が共同で四半期ごとの [[サービスレベル目標]]（SLO）を定め、SLO を達成するために許容されるエラーの総量をバジェットとして設定する。 ### メカニズム 1. プロダクトマネージャが SLO を定義する（例: 四半期の可用性 99.9%） 2. 実際のアップタイムを計測する 3. SLO と実測の差分がエラーバジェットとなる（99.9% の場合、四半期で 0.1% のダウンタイムが許容される） 4. バジェットが残っている限り、新機能リリースやリスクのある変更を実行できる ### 共通インセンティブの創出 エラーバジェットの最大の効果は、プロダクトチームと SRE の間に**共通のインセンティブ**を生み出すことである。 - **プロダクトチーム**: バジェットを使い切らないようにテストや段階的リリースに投資する動機を持つ - **SRE**: バジェットが残っている限りリリースを阻止しない。過度な保守主義に陥る理由がなくなる この構造は、従来の開発対運用の対立——「速度 vs 安定性」——を解消し、**速度と安定性を同じ目的関数の下に統合する**。