アラート疲れと誤検知を避けるために、アラートのしきい値をどのように選択しますか？

Question

IT Interview Practice · Accepted Answer

基本的なルール: **症状に基づいてアラートを出し、原因ではなく**、**対応可能で緊急な事項のみにページを限定する**。毎晩発動するノイジーなアラートはミュートされるか無視される — 本当のリスクは、アラートの欠落ではなく、実際の障害で寝過ごす無感覚なオンコールです。

## なぜ重要なのか

**ユーザー向けの SLO**（エラー率、レイテンシ、可用性）にアラートを出し、"CPU > 80%" などの内部的な原因にはアラートを出さないでください。CPU が高い可能性がありますが、重要なのはユーザーが影響を受けているかどうかです。

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

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

単一の静的なしきい値は、敏感すぎるか遅すぎるかのいずれかです。代わりに、**エラー予算**をどの程度の速さで消費しているかに基づいてアラートを出し、2 つのウィンドウを使用して、高速消費は即座にページを表示し、低速消費は持続する場合のみページを表示します。

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

短いウィンドウは既に自己解決した問題のページングを防ぎます。長いウィンドウは一時的なスパイクのページングを防ぎます。

## ページ vs チケット vs ダッシュボード

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

アラートが対応可能でない場合、ページングすべきではありません — チケットまたはダッシュボード パネルに変換してください。その後、**時間をかけて調整**します: すべてのページを確認し、誰も対応しなかったものを削除します。

アラート疲れは信頼性のリスクであり、単なる不便ではありません。人間はノイジーなチャネルを心理的にフィルタリングするため、送信する誤検知が多いほど、本物の障害が見逃される可能性が高くなります。症状に基づいてアラートを出し、バーンレート ウィンドウを使用して、対応可能な緊急事態のみにページを予約することで、すべてのページを意味のあるものに保ちます — これがオンコールの応答性を保つものです。

アラート疲れと誤検知を避けるために、アラートのしきい値をどのように選択しますか？

なぜ重要なのか

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

ページ vs チケット vs ダッシュボード

関連する質問

なぜ重要なのか

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

ページ vs チケット vs ダッシュボード

関連する質問

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