告警的成功标准不是发现，是处置

一句话总结

告警规则运行 inactive → pending → firing 状态机，Alertmanager 按 Wait → Dedup → Retry → Inhibit → Silence → Notify 的顺序处理收到的告警。知道告警在两条流水线的哪个位置消失，就能在 3 分钟内缩小“为什么没收到告警”的排查范围。

为什么需要它

值班体系崩溃的典型路径如下：每发生一次事故，复盘都会得出“本该提前发现”的结论，然后新增一条告警。两年后规则达到 300 条，Slack 频道每天堆积 400 条消息，值班人员夜里醒来三次，却三次都无需处理又继续睡觉。

每天 400 条中只有 4 条需要实际行动，精度就是 1%。此时人学到的最优策略是“先忽略，以后再看”，而正因为这是合理策略，情况才更危险。培训和意志力无法逆转它。

因此，实务目标要用数字定义：每 12 小时轮班最多 2 次页面呼叫，页面呼叫转化为行动的比例至少 70%。 超过这两个界限时，不应增加告警，而应删除告警。

工作原理

告警状态机

inactive --(표현식 매칭)--> pending --(for 경과)--> firing --(매칭 해제)--> resolved
                              |
                              +--(중간에 거짓)--> inactive  (타이머 0 으로 초기화)

for 的核心是连续。中途只要一次为假，计时器就归零。这正是防止抖动的原理。常见的错误建议是：“误报很多，把 for 增加到 30 分钟吧。”这样虽然有效，却会让检测晚 30 分钟；如果事故 25 分钟就结束，告警甚至完全不会触发。真正的问题仍然存在——表达式本身正在观察噪声。

正确顺序是：先用长窗口 rate 平滑噪声，再用短窗口 AND 确认问题仍在持续，最后只设置 2～5 分钟的 for 来吸收一两次抓取缺失。如果已经使用长窗口，for 仍超过 15 分钟，说明窗口设计有误。

处于 firing 的告警会在每个求值周期重新发送给 Alertmanager。此时 endsAt 设置为当前时间 + 4 × evaluation_interval，防止下一次发送前告警过期。Prometheus 宕机后告警会自动变成 resolved，正是因为这种过期设计。

Alertmanager 流水线

阶段	作用	容易忽略的点
Wait	新组出现时收集 group_wait 时长	默认 30 秒
Dedup	通过 notification log 判断是否已经发送	HA 通过 gossip 共享此日志
Retry	失败时以指数退避重试
Inhibit	source 为 firing 时阻止 target	equal 标签必须相同
Silence	与人工创建的静默匹配	永不过期的静默意味着该告警应被删除
Notify	实际发送

三种计时器的区别是考试常客。group_wait 是新组首次发送前的等待时间（默认 30 秒）；group_interval 是现有组新增告警后的发送间隔（默认 5 分钟）；repeat_interval 是无变化的组再次提醒的间隔（默认 4 小时）。

group_by 中包含什么，决定告警数量。按实例分组会收到与 Pod 数量相同的告警；按服务或 SLO 分组，数量才适合人类阅读。

抑制与静默经常混淆。抑制是配置文件中的规则驱动自动阻断；静默是人在 UI 或 API 中创建的临时阻断。两者都阻止通知，但在 UI 中仍然可见。

多窗口燃烧率是 SRE 工作簿的标准组合。

预算消耗	长窗口	短窗口	燃烧率阈值	响应
2%	1 小时	5 分钟	14.4	立即呼叫
5%	6 小时	30 分钟	6	立即呼叫
10%	1 天	2 小时	3	工单
10%	3 天	6 小时	1	工单

惯例是短窗口取长窗口的十二分之一。短窗口的作用不是灵敏度，而是恢复速度。没有短窗口，事故结束后，长窗口还会让告警维持整个窗口长度。

现场会遇到的情况

曾因一条规则漏写 for:，一天涌入 50 多条告警。结果和预期一样：人们开始忽略该告警；忽略成为习惯后，同一频道中的真实信号也一起被淹没。损坏的不是单条告警的准确度，而是整个值班体系的响应速度。

低流量时段也是反复出现的陷阱。凌晨 5 分钟只有 3 个请求，其中 1 个失败，错误率就是 33%，会一次越过所有燃烧率阈值。必须用 AND 加上最低流量条件，才能消除幽灵告警。如果流量完全为 0，比率会变成 NaN，告警悄然消失；这种情况应由独立的吞吐量骤降告警捕获。

页面呼叫还要强制附带运行手册。凌晨 3 点醒来的人并不处于发挥创造力的状态，他需要的是写明三项检查和两项操作的文档。通过 CI 门禁查找 severity=page 却没有 runbook_url 的规则并让构建失败，就能让纪律不再依赖人的记忆。

下一实验要做什么

在 /root/pca-alerting/ 下编写 Alertmanager 路由树和抑制规则，并创建快速消耗与慢速消耗两条燃烧率告警。最后亲自编写捕获运行手册缺失的 CI 门禁脚本，确认正常文件能通过、缺少运行手册的文件会被阻止。