アラート理論:シグナル/ノイズとアラート疲労
鳴りすぎるアラートで疲弊するのを卒業。症状ベース設計と適合率/再現率のトレードオフを意思決定理論で捉え、SLOバーンレートでノイズを原理から削る考え方を解説。
- 1.良いアラートは原因ではなく症状(ユーザー影響)で鳴らす。適合率(鳴ったら本物か)と再現率(取りこぼさないか)はトレードオフ。
- 2.ページング閾値は誤報コストと見逃しコストの比から決める。期待損失最小化の決定理論問題として設計できる。
- 3.固定閾値はトラフィック変動で適合率が崩れる。SLOバーンレートはユーザー影響速度を直接測るため高い適合率を保ちやすい。
アラートは「分類器」である
アラートを発報する仕組みは、本質的に 二値分類器 です。各時刻で「今は人を呼ぶべき状態か(陽性)/そうでないか(陰性)」を判定し続けています。この視点を持つと、アラート設計は感覚論ではなく 統計的決定理論 の問題になります。
分類器の出力は2つの軸で評価します。適合率(precision) は「鳴ったアラートのうち本当に対応が必要だった割合」、再現率(recall) は「対応が必要だった事象のうち実際に鳴らせた割合」です。
適合率 = 真陽性 ÷ (真陽性 + 偽陽性) … 鳴ったら本物か(ノイズの少なさ)
再現率 = 真陽性 ÷ (真陽性 + 偽陰性) … 取りこぼさないか(見逃しの少なさ)
偽陽性(誤報)は シグナル/ノイズ比 を下げ、偽陰性(見逃し)は障害の検知失敗を意味します。アラート疲労の正体は、適合率が低い——つまりノイズが多い——状態です。
偽陽性が続くと、オンコール担当は学習的にアラートを軽視します(オオカミ少年効果)。すると適合率の低さが、実効的な再現率の低下まで引き起こす。鳴っているのに誰も見ない、という最悪の状態です。ノイズ削減は快適さの問題ではなく、検知能力そのものを守る施策です。
症状ベースで鳴らす:原因の組合せ爆発を避ける
何を観測して鳴らすかには2つの流派があります。原因ベース(cause-based) は「CPU使用率が高い」「ディスクが満杯に近い」「特定プロセスが落ちた」といった内部状態で鳴らします。症状ベース(symptom-based) は「ユーザーのリクエスト成功率が落ちた」「レイテンシが悪化した」といった ユーザーが体感する結果 で鳴らします。
原因ベースが破綻する理由は 組合せ爆発 です。ユーザー影響に至る経路は無数にあり、原因を1つずつ閾値化しても網羅できません。しかも多くの原因アラートは ユーザー影響を伴いません。CPUが高くてもレイテンシが許容内なら、それは対応不要——つまり偽陽性です。原因ベースは構造的に適合率が低くなります。
| 観点 | 原因ベース | 症状ベース |
|---|---|---|
| 鳴らす対象 | 内部状態(CPU・メモリ・プロセス) | ユーザー影響(成功率・レイテンシ) |
| 網羅性 | 経路ごとに個別設定。漏れやすい | 結果で捕捉。未知の原因も検知 |
| 適合率 | 影響を伴わない発報が多く低い | 影響と直結し高い |
| 原因究明 | そのまま原因に近い | 別途デバッグ情報が必要 |
原則は 「症状でページし、原因で診断する」 です。人を叩き起こす(ページングする)のは症状アラートに限り、原因系のメトリクスは発報ではなく オブザーバビリティ のダッシュボードやトレースとして、駆けつけた後の診断に使います。なお症状ベースでも「ディスクがあと数時間で満杯」のような 確度の高い先行指標 は例外的に原因系で鳴らす価値があります。これらは偽陽性が極めて少なく、放置すれば確実に症状化するからです。
適合率と再現率のトレードオフ
理想は「全部鳴らす(再現率1.0)かつ誤報ゼロ(適合率1.0)」ですが、現実の分類器では両立しません。閾値を下げれば(敏感にすれば)取りこぼしは減るが誤報が増え、上げれば逆になります。これは閾値を動かすと適合率と再現率が逆方向に動く、避けられない関係です。
閾値を下げる → 再現率↑・適合率↓(うるさいが見逃さない)
閾値を上げる → 適合率↑・再現率↓(静かだが見逃す)
ここで効くのが 基準率(base rate) です。重大障害は本来まれな事象で、発生率は非常に低い。基準率が低い領域では、個々の判定がそこそこ正確でも、鳴った中の偽陽性が相対的に多くなり適合率が伸びません(基準率の誤謬)。だからアラートでは、再現率を多少犠牲にしてでも 適合率を優先 する設計が支持されます。見逃しは別の遅い検知層(バックストップとなる遅延アラートや定期レビュー)で拾えますが、ノイズは検知体制そのものを腐らせるからです。
適合率と再現率のトレードオフは「全部を1つの通知レベルで扱う」から苦しくなります。即時対応が要る高適合率の事象は ページング(人を起こす)、緊急でないが対応が要る事象は チケット(営業時間に処理)へ分離する。重大度ごとに別の閾値・別の経路を持たせると、各層で最適点を選べます。
ページング閾値は「期待損失最小化」で決める
では閾値はどこに置くべきか。決定理論はこれに明確な答えを与えます。2種類の誤りのコスト比 から最適点が決まります。偽陽性のコストを C_fp(不要な叩き起こし・疲労・信頼低下)、偽陰性のコストを C_fn(障害見逃し・SLO違反・収益損失)とすると、合理的な方針は 期待損失を最小化 することです。
陽性と判定すべき条件:
P(本物 | 観測) C_fp
────────────── > ──────
P(誤報 | 観測) C_fn
直感的には、見逃しのコストが誤報のコストより大きいほど閾値を下げる(敏感にする)べきだ、という関係です。決済システムのように偽陰性が致命的なら閾値は低めに、社内ツールのように見逃しても致命的でないなら閾値を高めにして静けさを優先します。閾値はサービスごとに異なって当然で、唯一の正解値は存在しません。
この比は固定値ではなく 時間帯にも依存 します。深夜のページングは C_fp(睡眠を奪うコスト)が日中より高い。だから「夜間はページ、日中はチケット」ではなく「夜間こそ高適合率の事象だけページ」という設計が理にかないます。コストを定量化できないときも、「どちらの誤りがより痛いか」という順序だけ合意すれば閾値の向きは決められます。
SLOバーンレート:適合率を構造的に高める
固定閾値(例:エラー率が0.5%を超えたら鳴らす)の弱点は、トラフィック変動で適合率が崩れる ことです。深夜の低トラフィック時は数件の失敗で率が跳ね上がり偽陽性を生み、ピーク時は同じ率でも絶対的な影響が桁違いに大きい。固定閾値は「ユーザー影響の大きさ」を測れていないのです。
ここで SLO と バーンレート が効きます。バーンレートは「エラーバジェットを通常の何倍の速さで消費しているか」を表す量で、ユーザー影響の速度そのもの を一次情報にします。
バーンレート = 実測エラー率 ÷ 許容エラー率 (1 − SLO)
バーンレートで鳴らすと、低トラフィックで数件失敗してもバジェット消費速度が小さければ鳴らず、ピーク時の同率は大きな消費速度として正しく鳴る。鳴る条件が「ユーザーへの影響の深刻さ」と一致する ため、適合率が構造的に高くなります。さらに重大度の分離も自然にできます。
速いバーン(重大): burn_rate(1h) > 14.4 AND burn_rate(5m) > 14.4 → 即ページ
遅いバーン(緩慢): burn_rate(6h) > 6 AND burn_rate(30m) > 6 → チケット
長短2窓の AND は、決定理論的には 独立に近い2つの証拠を組み合わせて適合率を上げる 操作です。長窓で「有意に消費した」、短窓で「今もまだ燃えている」を同時に要求することで、一過性スパイク(長窓は満たさない)も収束後の惰性(短窓が満たさない)も棄却できます。閾値の導出と多窓設計の詳細は エラーバジェットの数理 を参照してください。
バーンレートは適合率を上げますが、万能ではありません。SLO の選び方が悪い(ユーザー体感とずれた SLI)と、症状ベースの利点ごと崩れます。また極端に低トラフィックなサービスでは1件の失敗が大きなバーンレートになり再び不安定化する。その場合は最小イベント数の条件を併用し、統計的に有意な母数でのみ発報します。
まとめ
- アラートは二値分類器。適合率(ノイズの少なさ) と 再現率(見逃しの少なさ) はトレードオフし、アラート疲労の正体は低い適合率。
- 症状ベースでページし、原因ベースは診断に回す。原因系は組合せ爆発し、影響を伴わない発報で適合率を下げる。
- 基準率が低い障害領域では適合率を優先し、見逃しは遅い検知層で拾う。ページとチケットを重大度で分離する。
- ページング閾値は 誤報コストと見逃しコストの比 から決まる決定理論問題。見逃しが痛いほど閾値を下げる。
- SLOバーンレートはユーザー影響速度を直接測るため、固定閾値より適合率が構造的に高い。多窓 AND でさらにノイズを棄却する。
DevOps/インフラ Article
アラート理論:シグナル/ノイズとアラート疲労を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
SRE
比較で見る軸
難易度: advanced / カテゴリ: DevOps/インフラ / タグ数: 5
導入後に効く点
ページング閾値は誤報コストと見逃しコストの比から決める。期待損失最小化の決定理論問題として設計できる。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- DevOps/インフラ
- タグ数
- 5
判断チェックリスト
- 自社の用途が「SRE / アラート」に近いか確認する。
- 強みである「良いアラートは原因ではなく症状(ユーザー影響)で鳴らす。適合率(鳴ったら本物か)と再現率(取りこぼさないか)はトレードオフ。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。