深色模式
告警复盘与调优
摘要：告警规则不是一次写好就完事。本文给出“每周小复盘 + 每月大复盘”的节奏，用数据驱动删/改/留，让告警库长期保持健康。
适用环境
- 已能度量告警有效性（见上文告警有效性度量）
- 告警规则版本化管理（Git）
操作步骤
1. 建复盘看板
promql
# 本周 Top 噪音
topk(10, sum by (alertname) (count_over_time(ALERTS[7d])))
# 长期 firing 未恢复（可能卡死）
count by (alertname) (ALERTS)1
2
3
4
2
3
4
2. 每周 15 分钟小复盘
- 过 Top 10 噪音，每条标“删/降/修”
- 看是否有持续 firing 的“僵尸告警”
- 新上线规则错误率是否偏高
3. 每月结合故障大复盘
- 本月故障中，告警是否及时、准确？
- 有没有“该响没响”（漏报）？补规则
- 有没有“响了但没人动”？重新分级
4. 规则变更走 PR
bash
# 修改 rules/*.yml 后提交 MR，评审通过再合并并 reload
curl -X POST http://localhost:9093/-/reload1
2
2
DANGER
复盘结论必须落地为规则变更，否则“每次复盘都说要改”但永远没改，等于没复盘。
验证
bash
# 复盘后对比告警总量与误报率是否下降
sum(count_over_time(ALERTS[7d]))1
2
2
常见坑
WARNING
- 复盘只看“量”不看“质”，可能把真阳性也砍了；必须结合准确率和故障回顾。
- 没有 owner 的规则最容易腐烂，每条规则都要有负责人标签。