エラーバジェットとバーンレートアラート：正しい理由で呼び出す

ユーザーの体験から始める

うるさいアラートの多くは、ユーザーが感じることではなく、CPU、メモリ、再起動したPodといった原因に対してアラートを出していることから生まれます。サービスレベル指標（SLI）は前者を直接測ります：有効なリクエストのうち、良好だったものの割合です。良好とは、サーバーエラーのない応答、しきい値より速い応答、またはその両方を指します。

サービスレベル目標（SLO）は、その割合に対してある期間での目標を定めます。たとえば30日間でリクエストの99.9%が成功、といった具合です。100%との差がエラーバジェットで、この例ではリクエストの0.1%、つまり月あたり約43分の完全停止に相当します。

固定しきい値のアラートが失敗する理由

「エラー率が5分間1%を超える」といったアラートは、敏感すぎると同時に遅すぎます。バジェットをほんのわずかしか消費しない短いスパイクで呼び出す一方、1週間で静かにバジェットを使い切る0.5%のエラー率では決して発火しません。

これを解決するのがバーンレートです。SLOに対してバジェットが消費される速さのことで、バーンレート1は期間中にちょうどバジェットを使い切り、バーンレート14.4は30日分のバジェットを2日余りで使い切ります。

マルチウィンドウ・マルチバーンレートアラート

GoogleのSRE Workbookで説明されている方法では、各バーンレートのしきい値を、問題が重大であることを示す長いウィンドウと、問題がまだ続いていることを示す短いウィンドウと組み合わせます。30日間で99.9%のSLOなら、よく使われる出発点は次のとおりです：

• 呼び出し：1時間と5分の両方でバーンレートが14.4超——1時間でバジェットの2%を消費。
• 呼び出し：6時間と30分の両方でバーンレートが6超——バジェットの5%を消費。
• チケット：3日と6時間の両方でバーンレートが1超——バジェットの10%を消費。

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

短いウィンドウは長いウィンドウと同じくらい重要です。修正が入ると5分間の割合が下がり、残りの1時間鳴り続けることなくアラートが解消されます。

うまくいくかを左右する細部

• レコーディングルール：各ウィンドウのエラー率を事前に計算し、アラート式を軽く読みやすく保ちます。
• トラフィックが少ない場合：1分あたり数リクエストでは、1回の失敗が大きな割合になります。最小リクエスト数を条件にするか、合成監視で測定します。
• レイテンシのSLO：しきい値より遅いリクエストを不良イベントとして数え、しきい値を含むヒストグラムのバケットを使います。
• 除外：クライアントエラーやヘルスチェックを含めるかを事前に決め、SLOの横に書いておきます。

バジェットは何のためにあるか

バジェットはポケベルであるだけでなく、意思決定の道具です。余裕があるうちは、チームはより速くリリースし、よりリスクのある変更に取り組めます。使い切ったら、傾向が回復するまで信頼性の作業を機能開発より優先します。この方針は、最初の違反が起きる前にプロダクト責任者と合意しておきましょう。違反の最中ではなく。