基本的なルール: 症状に基づいてアラートを出し、原因ではなく、対応可能で緊急な事項のみにページを限定する。毎晩発動するノイジーなアラートはミュートされるか無視される — 本当のリスクは、アラートの欠落ではなく、実際の障害で寝過ごす無感覚なオンコールです。
ユーザー向けの SLO（エラー率、レイテンシ、可用性）にアラートを出し、"CPU > 80%" などの内部的な原因にはアラートを出さないでください。CPU が高い可能性がありますが、重要なのはユーザーが影響を受けているかどうかです。
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 つのウィンドウを使用して、高速消費は即座にページを表示し、低速消費は持続する場合のみページを表示します。
# 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 }
短いウィンドウは既に自己解決した問題のページングを防ぎます。長いウィンドウは一時的なスパイクのページングを防ぎます。
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)
アラートが対応可能でない場合、ページングすべきではありません — チケットまたはダッシュボード パネルに変換してください。その後、時間をかけて調整します: すべてのページを確認し、誰も対応しなかったものを削除します。
アラート疲れは信頼性のリスクであり、単なる不便ではありません。人間はノイジーなチャネルを心理的にフィルタリングするため、送信する誤検知が多いほど、本物の障害が見逃される可能性が高くなります。症状に基づいてアラートを出し、バーンレート ウィンドウを使用して、対応可能な緊急事態のみにページを予約することで、すべてのページを意味のあるものに保ちます — これがオンコールの応答性を保つものです。