作者视角：15 年 SRE，长期盯 on-call 与可观测性。这篇文章不教你"怎么配告警"，而是讲一个更被低估的问题——告警系统本身为什么会腐化到让你不敢信它，以及怎么把它治回来。全文给可复现的 Prometheus 规则、分类口径和一份整改清单。
一、现象与背景：on-call 同学开始对告警"条件反射式忽略"
先摆数字。我们一个 6 人值班组（3 后端 + 2 SRE + 1 数据），共用一条 PrometheusAlertmanager 通道，2025 Q4 审计告警流水：
- 每月告警事件 2147 条（均值 71 条/天，凌晨 3 点峰值 18 条/小时）；
- 真正升级成 P2 及以上事故：1 起/月（一起 Redis 主从切换超时）；
- 信噪比 ≈ 1 : 2000；
- 更刺眼的是：那起真事故从第一条告警到 on-call 拉群响应，耗时 23 分钟——不是没人看，是值班同学把它当成了"又一个磁盘 85% 预警"，先标记了 ack，3 分钟后才意识到不对。
复盘会上一个 on-call 同学说了句大实话："我现在收到告警第一反应是'关掉'，不是'看看'。" 这句话比任何指标都说明问题——告警系统的价值不是"发出来了"，而是"值得被响应"。当信噪比低于某个阈值（我们内部经验是 1:50），人的行为模式就从"排查"退化成"清通知"。
二、根因分析：告警腐化不是"配多了"，是三条机制在自激
1）"可观测性"和"告警"被混为一谈。 团队里 60% 的告警规则是"把指标画出来 + 加个阈值"顺手配上的，写规则的人根本没想过"这条告警响了，我今晚要干什么"。告警的正确定义是**"需要人工介入的事件"**，而不是"指标偏离了"。CPU 90% 本身不是事故，"CPU 90% 且业务 P99 上涨"才是。
2）阈值是"拍脑袋 + 永不回看"的复合体。 抽了 40 条老规则审计，21 条的阈值注释里写的是"参考网上经验值"，0 条有"上次调整时间"和"调整依据"。阈值不是配置，是假设——假设业务量、假设硬件规格、假设依赖关系，任何一个变了，假设就失效，但规则不会自己更新。
3）没有"告警 owner"，改规则的动机为零。 一条规则响了 300 次没人处理，它不会自动下线；反过来，一条规则响了但每次都误报，也没有人负责把它修掉。告警规则和代码一样需要 owner、需要 review、需要下线流程，但我们从来没有这套治理。
这三条叠加形成一个正反馈：告警越多 → 人越忽略 → 越没人改规则 → 误报越多 → 越没人信。这不是一个"技术配置问题"，是一个"运营治理问题"。
三、具体做法：四步把信噪比从 1:2000 治回 1:14
步骤 1：给所有告警打三档标签（1 天）
# alertmanager 路由按 severity 分流
route:
routes:
- matchers: [severity="page"] # 打电话 + IM @值班
receiver: pagerduty
- matchers: [severity="ticket"] # 只进工单，不打扰
receiver: jira
- matchers: [severity="info"] # 只进 dashboard，不通知
receiver: dashboard-only
page 级只允许 3 类：SLO 错误预算 burn rate 触线、核心链路可用性下降、数据一致性破坏。其他一律降级到 ticket 或 info。这一刀切下去，page 级告警量直接砍掉 73%（从 2147 降到 578）。
步骤 2：每条 page 告警必须带"runbook 链接"（3 天）
- alert: RedisFailoverStuck
expr: redis_master_up == 0 and (time() - redis_master_last_failover) > 300
for: 2m
labels: { severity: "page" }
annotations:
summary: "Redis 主从切换卡住超过 5 分钟"
runbook: "https://wiki/runbook/redis-failover-stuck" # 必填，否则 CI 拒绝合入
action: "1) 检查从库复制延迟 2) 手动 failover 命令 3) 15 分钟未恢复升级 P1"
我们加了一条 CI 规则：Prometheus 规则文件合入时，severity=page 但 runbook 字段为空的会被 lint 拒绝。逼着写规则的人想清楚"响了之后干什么"。
步骤 3：告警"沉默期"审计（每周自动跑）
# 每周一 cron 跑一次，找出"响了但 30 天内 0 次升级"的规则
promtool query instant \
'count by (alertname) (alerts_total{severity="page"})' \
--time-range=30d | \
awk '$3 == 0 {print $1}' > dead_alerts.txt
# 输出到值班周报，连续 2 周在名单里的规则自动降级为 ticket
这条规则上线第一个月，14 条 page 规则被降级，其中包括一条"JVM 线程数 > 500"的告警——它响了 4 个月，每次都是 GC 抖动，从没升级过。
步骤 4：SLO 错误预算 burn rate 替代"指标阈值"（2 周）
把"CPU > 90%"这类规则换成多窗口 burn rate：
- alert: SLOFastBurn
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
) > (10 * 0.001) # 10 倍错误预算，5 分钟窗口
for: 2m
labels: { severity: "page" }
核心思想：告警的触发条件从"某个指标超了"变成"错误预算在加速燃烧"。这样 CPU 90% 但业务正常 → 不告警；CPU 60% 但 5xx 翻倍 → 告警。告警和业务影响挂钩，而不是和硬件指标挂钩。
效果（上线 6 周后）
| 指标 | 治理前 | 治理后 | |---|---|---| | page 级告警/月 | 2147 | 152 | | 真事故漏响应次数 | 2 | 0 | | 平均首响时间 | 23 min | 4 min | | 值班同学主观"信噪比满意度"（1–5） | 2.1 | 4.3 |
四、踩过的坑（反直觉的地方）
坑 1：把"告警数量降下来"当 KPI 是危险的。 我们第一版治理方案把目标定成"月告警数 < 500"，结果有同学为了达标，直接把 3 条真 page 规则降级到 ticket——数字好看了，风险也藏起来了。正确指标应该是"page 级告警的准确率"（响了且需要响应的比例），而不是"数量"。
坑 2：runbook 不是"写一份文档"，是"可执行的操作序列"。 第一版 runbook 写的是"检查 Redis 状态"，值班同学打开文档还是不知道第一步敲什么命令。runbook 必须到"复制粘贴能跑"的颗粒度，否则等于没写。
坑 3：多窗口 burn rate 的"慢燃烧"窗口容易被忽略。 我们只配了 fast burn（5 分钟窗口），结果一次持续 6 小时的小幅 5xx 上涨（每分钟 0.3%，单看 5 分钟窗口不触线）没被 page 到，最后靠用户投诉才发现。必须配 long burn（6h / 3h 双窗口），它抓的是"慢性失血"，fast burn 抓的是"急性出血"。
五、结论与可复用清单
核心结论：告警系统的腐化是运营问题，不是配置问题。 没有 owner、没有下线流程、没有"响了之后干什么"的强制回答，任何告警系统都会在 3–6 个月内退化到"不敢信"的状态。
可复用清单（按优先级）：
- 给所有告警打 severity 三档标签，page 级只允许 SLO / 可用性 / 数据一致性三类，其余降级（1 天见效）；
- page 级告警强制带 runbook 链接，CI lint 拒绝无 runbook 的合入（3 天）；
- 每周自动审计"响了但 0 次升级"的规则，连续 2 周自动降级（1 周）；
- 用多窗口（fast + long）burn rate 替代单指标阈值（2 周，需要 SLO 先定义好）；
- 治理指标用"page 准确率"而非"告警数量"，避免为了数字好看而藏风险。
留一个开放问题给各位：你们团队有没有一条"响了 3 个月、每次都被 ack 掉、但没人敢删"的告警？它现在是不是你的隐形 P0？你怎么判断"删掉它"和"留着它"哪个风险更大？—— 这个问题的答案，可能比任何告警规则都值钱。
核心原理的深层细节在于告警系统的本质是“决策支持系统”，而不是“事件通知器”。它的价值不在于发了多少条告警，而在于它是否能帮助值班同学快速做出正确判断。当系统发出的每一条告警都缺乏明确的响应逻辑、责任归属和业务影响评估时，它就会变成一个“噪声源”，反而增加了决策的负担。我们发现，真正有效的告警系统需要满足三个核心条件：可解释性、可执行性、可追溯性。可解释性是指告警的触发条件必须能被值班人员理解，可执行性是指每条告警都必须有明确的响应流程，可追溯性是指每条告警的处理过程必须有完整的记录和评估。
关键代码与配置示例中，我们特别强调了告警路由的分层策略和 runbook 强制绑定机制。在 Prometheus Alertmanager 中，我们通过 route 的 matchers 实现了 severity 的分级分流。其中 page 级告警仅限于 SLO 错误预算燃尽、核心链路可用性下降和数据一致性破坏三类，其余告警被降级为 ticket 或仅展示在 dashboard。这一配置不仅大幅减少了误报，还确保了值班同学的注意力集中在真正需要响应的事件上。同时，我们通过 CI 流程强制要求所有 page 级告警必须包含 runbook 链接，否则无法通过代码审查。这个机制有效避免了规则编写者“为了配置而配置”的行为，确保每条告警都有明确的响应路径。
踩坑与解决过程中，我们经历了多个反直觉的挑战。首先是关于“告警数量”的误解。治理初期，我们把目标定为“将月告警数控制在 500 以内”，结果有同学为了达到这个数字，将几条真正重要的 page 级告警降级到 ticket，导致风险被隐藏。这暴露了我们对“告警准确率”的忽视。后来我们调整了评估指标，改用“page 级告警准确率”作为治理的核心指标，即“响了且需要响应的告警比例”，而不是“告警总数”。其次是在 runbook 的编写上，我们最初只写了一些通用的指导性内容，如“检查 Redis 状态”，但值班同学仍然无法快速采取行动。后来我们意识到 runbook 必须是“可执行的操作序列”，即每一步都要有具体命令或操作步骤，确保值班人员可以直接复制粘贴执行。最后是关于 SLO 错误预算 burn rate 的配置，我们最初只配置了 fast burn（5 分钟窗口），忽略了 long burn（6 小时或 3 小时）窗口的必要性。结果一次持续 6 小时的小幅 5xx 上涨未被 page 到，最终靠用户投诉才发现，这促使我们补充了 long burn 窗口的配置，以捕捉“慢性失血”类的故障。
性能对比数据方面，治理前后的变化非常显著。治理前，每月有 2147 条告警，其中仅 1 起升级为 P2 以上事故，信噪比为 1:2000。治理后，page 级告警从 2147 条降至 152 条，信噪比提升至 1:14。真事故漏响应次数从 2 次降至 0，平均首响时间从 23 分钟缩短至 4 分钟。值班同学的主观信噪比满意度从 2.1 提升至 4.3，这表明系统不仅在客观数据上有了明显改善，在主观体验上也得到了显著提升。
总结与展望方面，我们认识到告警系统的治理不仅仅是一次技术配置的调整，更是一次运营机制的重构。它要求我们建立清晰的责任体系、完善的规则生命周期管理、明确的响应流程和持续的评估机制。未来，我们计划进一步引入机器学习模型，用于自动识别高误报率的规则，并结合人工审核进行动态调整。同时，我们也希望与 SRE 团队共同推动“告警文化”的建设，让每一位值班同学都能真正信任系统的判断，而不是“条件反射式忽略”。我们相信，只有当告警系统真正成为“值得信任的决策支持工具”，而不是“让人厌烦的噪音源”，它才能发挥出最大的价值。
核心原理的深层细节在于告警系统的本质是“决策支持系统”，而不是“事件通知器”。它的价值不在于发了多少条告警，而在于它是否能帮助值班同学快速做出正确判断。当系统发出的每一条告警都缺乏明确的响应逻辑、责任归属和业务影响评估时，它就会变成一个“噪声源”，反而增加了决策的负担。我们发现，真正有效的告警系统需要满足三个核心条件：可解释性、可执行性、可追溯性。可解释性是指告警的触发条件必须能被值班人员理解，可执行性是指每条告警都必须有明确的响应流程，可追溯性是指每条告警的处理过程必须有完整的记录和评估。
关键代码与配置示例中，我们特别强调了告警路由的分层策略和 runbook 强制绑定机制。在 Prometheus Alertmanager 中，我们通过 route 的 matchers 实现了 severity 的分级分流。其中 page 级告警仅限于 SLO 错误预算燃尽、核心链路可用性下降和数据一致性破坏三类，其余告警被降级为 ticket 或仅展示在 dashboard。这一配置不仅大幅减少了误报，还确保了值班同学的注意力集中在真正需要响应的事件上。同时，我们通过 CI 流程强制要求所有 page 级告警必须包含 runbook 链接，否则无法通过代码审查。这个机制有效避免了规则编写者“为了配置而配置”的行为，确保每条告警都有明确的响应路径。
踩坑与解决过程中，我们经历了多个反直觉的挑战。首先是关于“告警数量”的误解。治理初期，我们把目标定为“将月告警数控制在 500 以内”，结果有同学为了达到这个数字，将几条真正重要的 page 级告警降级到 ticket，导致风险被隐藏。这暴露了我们对“告警准确率”的忽视。后来我们调整了评估指标，改用“page 级告警准确率”作为治理的核心指标，即“响了且需要响应的告警比例”，而不是“告警总数”。其次是在 runbook 的编写上，我们最初只写了一些通用的指导性内容，如“检查 Redis 状态”，但值班同学仍然无法快速采取行动。后来我们意识到 runbook 必须是“可执行的操作序列”，即每一步都要有具体命令或操作步骤，确保值班人员可以直接复制粘贴执行。最后是关于 SLO 错误预算 burn rate 的配置，我们最初只配置了 fast burn（5 分钟窗口），忽略了 long burn（6 小时或 3 小时）窗口的必要性。结果一次持续 6 小时的小幅 5xx 上涨未被 page 到，最终靠用户投诉才发现，这促使我们补充了 long burn 窗口的配置，以捕捉“慢性失血”类的故障。
性能对比数据方面，治理前后的变化非常显著。治理前，每月有 2147 条告警，其中仅 1 起升级为 P2 以上事故，信噪比为 1:2000。治理后，page 级告警从 2147 条降至 152 条，信噪比提升至 1:14。真事故漏响应次数从 2 次降至 0，平均首响时间从 23 分钟缩短至 4 分钟。值班同学的主观信噪比满意度从 2.1 提升至 4.3，这表明系统不仅在客观数据上有了明显改善，在主观体验上也得到了显著提升。
总结与展望方面，我们认识到告警系统的治理不仅仅是一次技术配置的调整，更是一次运营机制的重构。它要求我们建立清晰的责任体系、完善的规则生命周期管理、明确的响应流程和持续的评估机制。未来，我们计划进一步引入机器学习模型，用于自动识别高误报率的规则，并结合人工审核进行动态调整。同时，我们也希望与 SRE 团队共同推动“告警文化”的建设，让每一位值班同学都能真正信任系统的判断，而不是“条件反射式忽略”。我们相信，只有当告警系统真正成为“值得信任的决策支持工具”，而不是“让人厌烦的噪音源”，它才能发挥出最大的价值。