如何設計有效的警報策略？如何避免警報疲勞？

警報疲勞的危害

過多或低品質的警報導致 on-call 工程師對警報麻木，真正的緊急問題反而被忽視。

好的警報原則

以症狀為導向，而非原因：

• 差：CPU 使用率 > 80%（原因指標，可能是正常高峰）
• 好：使用者可見的錯誤率 > 1%（症狀指標，直接影響使用者）

告警要可採取行動：每個警報都應有對應的 Runbook，說明收到警報後要做什麼。沒有明確處理方式的警報只是噪音。

設定合理閾值：避免過於敏感（每次 CPU 短暫尖峰都告警）。使用滾動窗口（如「過去 5 分鐘平均值 > 閾值」）減少誤報。

分層嚴重性：

• P1（Critical）：立即中斷服務，需立即響應（如：網站完全不可用）
• P2（Warning）：效能降級，需 1 小時內響應
• P3（Info）：需要關注但不緊急

降低噪音的策略

Alert Grouping：相同根因的多個警報合併為一個通知

Alert Suppression：維護窗口期間暫時靜音警報

依賴感知：資料庫停機後，避免上游服務同時發出大量衍生警報

警報品質評估

定期回顧告警記錄：

• 警報被靜音的比例有多高？→ 噪音太多
• 沒有觸發警報的事故有多少？→ 覆蓋不足
• 警報到響應的平均時間是多少？→ On-call 負擔指標