100%の稼働率を超えて：エラーバジェット実践ガイド

Table of Contents

DevとOpsの間の平和条約

開発者はコードをデリバリーするために生き、運用チームは安定性のために生きています。これらの目標は通常衝突し、デプロイのたびに絶え間ない綱引きが発生します。Googleはこの緊張をエラーバジェット（Error Budget）の導入によって解決しました。100%ের稼働率という、コストがかかりすぎる神話を追うのではなく、許容できる失敗の量を正確に定義するのです。

私が現場で学んだのは、エラーバジェットは単なるメトリクス以上のものだということです。それは「社会契約」です。いつスピードを上げてもいいのか、いつ立ち止まってプラットフォームを修正すべきかを決定します。「デプロイしてもいいか？」という議論を、データに基づいた意思決定へと変えてくれるのです。

5分でわかる計算術：ナインを時間に変換する

ダッシュボードに触れる前に、基本的な算術をマスターする必要があります。エラーバジェットは、サービスレベル目標（SLO）から残された余裕にすぎません。

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

30日間のウィンドウで99.9%の可用性SLOを見てみましょう。失敗に対する予算は0.1%です。実際の時間に換算すると、次のようになります。

月間の総時間: 43,200分
許容されるダウンタイム: 43.2分

デプロイの失敗による切り戻しに15分かかった場合、月間予算の35%を消費したことになります。もし20日目に予算がゼロになったら、条約が発動します。すべての新機能のリリースを停止し、予算がリセットされるまで、エンジニアリングのリソースを100%信頼性の向上に充てるのです。

本当に重要なメトリクスを選ぶ

サービスレベル指標（SLI）がなければ、バジェットを組むことはできません。多くのチームが「サーバーの稼働率」を追跡していますが、これはしばしば虚栄の指標（バニティ・メトリクス）になりがちです。APIがすべてのユーザーに500エラーを返していても、サーバー自体は「稼働中」である可能性があるからです。代わりにリクエスト成功率やレイテンシに注目しましょう。

1. 可用性SLI

これは、有効な全リクエストに対する成功したリクエストの割合を測定します。Prometheusでは、次のクエリを使用して過去30日間の成功率を計算できます。

sum(rate(http_requests_total{status=~"2..|3.."}[30d])) 
/
sum(rate(http_requests_total[30d]))

2. レイテンシSLI

「遅い」は「ダウン」と同じです。チェックアウトページが読み込まれるのに10秒かかれば、ユーザーは離脱します。一般的なSLOは「リクエストの90%が500ミリ秒以内に完了すること」のようになります。501ミリ秒かかったリクエストは、バジェットをわずかに削ります。

sum(rate(http_request_duration_seconds_bucket{le="0.5"}[30d])) 
/
sum(rate(http_request_duration_seconds_count[30d]))

バーンレートの監視：早期警戒システム

バジェットが0%になるまで待つのは、破滅への道です。バーンレート（Burn Rate）、つまり予算を消費するスピードを追跡する必要があります。バーンレートが1であれば、ちょうど月末に予算を使い切ることを意味します。バーンレートが14.4であれば危機的状況です。わずか1時間で月間予算の2%を失うことを意味します。

私は階層化されたアラート戦略をお勧めします。軽微な変動にはSlackを使用し、高いバーンレートにはPagerDutyを予約しておきましょう。1時間のバーンレートが14を超えた場合は、誰かがすぐに起きてログを確認する必要があります。

アラートロジックの例 (Prometheus)

groups:
- name: ErrorBudgetAlerts
  rules:
  - alert: HighErrorBudgetBurn
    expr: |
      (sum(rate(http_requests_total{status="500"}[1h])) / sum(rate(http_requests_total[1h]))) 
      > (1 - 0.999) * 14.4
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "致命的な予算消費：1時間あたり月間予算の2%を消費しています。"

ポリシー：ゼロになったらどうするか？

バジェットを追跡するのは簡単ですが、行動を変えるのは困難です。機能的なSRE文化には、CEOからジュニアデベロッパーまで、全員が尊重する承認済みのポリシーが必要です。このポリシーには通常、次の3つの柱が含まれます。

機能開発の凍結（Feature Freeze）: 予算がなくなると、デプロイは停止します。セキュリティパッチと信頼性の修正のみが本番環境に適用されます。
非難なきポストモーテム（Blameless Post-Mortems）: バジェットの10%以上（99.9%のSLOで約4分）を消費したインシデントは、徹底的な調査の対象となります。
信頼性の負債の返済: チームは、サーキットブレーカーの追加や自動テストのカバレッジ向上など、信頼性に関するバックログの解消に焦点を移します。

現場で得た教訓

「ナイン」を増やすことの高コスト

マネージャーが99.99%（フォーナイン）を要求する場面を何度も見てきましたが、それが月間わずか4.3分のダウンタイムしか許容されないことを理解していない場合が多いです。ユーザーが不安定な4G回線を使っているなら、99.9%と99.99%の違いに気づくことはありません。しかし、その目標を達成するためにインフラコストは3倍になる可能性があります。バジェットを使って、計算されたリスクを取りましょう。

メンテナンスは免罪符ではない

GoogleのSRE基準によれば、計画メンテナンスもバジェットを消費すべきです。これは厳しく聞こえるかもしれませんが、効果的です。チームは、ローリングアップデートやダウンタイムなしの移行をサポートするシステムを構築せざるを得なくなります。ユーザーに影響を与えるなら、それはバジェットに響くべきなのです。

賭けられているものを可視化する

これらの数値をスプレッドシートに隠さないでください。Grafanaを使用して、オフィスの大きなスクリーンに「残りのバジェット」ゲージを表示しましょう。真っ赤な「残り0.05%」という表示を見ることは、言葉を発さずにチームの焦点を一致させる強力な方法です。それは信頼性を、感情的な議論から共有されたミッションへと変貌させます。