接手蜂控那套系统时，值班群每天涌进来上百条告警。我观察了几天，发现一个规律，告警越多，响应质量越差。前面几条大家还会看一眼，到后面几十条上百条刷屏，就没人认真对待了，顶多扫一眼标题感觉不紧急就算了。这就是告警疲劳，值班的人被噪音淹没，对真正重要的信号也麻木了。等某天真的出了大事，那条本该第一时间响应的告警淹没在几百条噪音里，没人看见，故障就这么从小拖到大。
告警治理的核心目标就一个词，提炼信号。让每一条到达值班人的告警都值得响应，把噪音在到达人之前就过滤掉。这事做不到，监控系统再强大也没用，因为输出的告警没人信。下面把告警治理里几个真正能减噪的杠杆讲清楚。
告警的两个极端都不对
告警这件事容易滑向两个极端，都不对。
图：告警太少靠客诉发现故障，告警太多触发疲劳，目标是少而准的中间状态
一个极端是告警太少。系统裸奔，没人盯着，出事了靠用户客诉才知道。等用户来反馈，故障已经扩散了半小时一小时，影响面早就不可控。这种团队通常是把监控当摆设，指标采了不看，告警规则没配或者配了不灵。
另一个极端更常见，就是告警太多。怕漏报，于是什么都加告警，CPU 到 70% 告一下，磁盘到 80% 告一下，某次 GC 偶尔多花了几十毫秒也告一下。每一条单独看都合理，加在一起就是灾难。值班的人一天被轰炸几百条，很快进入告警疲劳，重要的和不重要的混在一起，全部沦为背景噪音。
健康的状态在中间，少而准。每条告警都值得响应，收到就知道该干什么。这个目标听起来简单，做起来要持续投入，因为告警噪音是会反弹的，业务变了、流量模式变了、系统迭代了，新的噪音告警又会冒出来，治理是一个持续的工程。
先把监控的骨架搭对
告警是建立在监控指标之上的，监控指标没选对，告警治理无从谈起。Google SRE 那本实践里提的四大黄金信号是个好起点，延迟、流量、错误、饱和度，这四个维度覆盖了任何服务最核心的健康状况。
延迟看的是请求处理快不快，但要区分正常请求和慢请求的延迟分布，一个平均延迟正常但尾部 P99 飙高的服务，说明有少量请求卡死了，平均数会把这种问题藏起来。流量看的是系统承受的负载规模。错误看的是请求失败的比例。饱和度看的是资源使用到什么程度，CPU、内存、连接池、队列深度，饱和度高意味着系统快到极限了。
光有技术指标还不够，必须补上业务监控。技术指标只能告诉你系统在技术层面是否正常，但有时候系统没报错，业务已经出问题了。下单量突然掉了一半，技术指标全绿，可能是前端某个页面的 bug 导致用户根本下不了单，也可能是风控误杀把正常用户拦了。这类问题技术监控发现不了，只有业务监控，订单量、支付成功率、关键转化漏斗，才能第一时间捕捉到。
技术监控和业务监控是两个互补的视角，缺了任何一个都会出现盲区。最经典的事故模式就是技术指标一切正常，值班很安心，但业务已经塌了，等业务方找上门才知道出事了。
分级决定告警怎么送达
告警必须分级，不分级的告警必然走向疲劳。原因很简单，磁盘用了 80% 和 支付服务完全不可用 这两件事的紧急程度完全不在一个量级，如果用同样的方式通知值班人，后者就被前者淹没了。
图：P0-P3 四级告警匹配不同通知通道，紧急程度与打扰程度严格对应
分级的标准是影响和紧急程度。P0 是核心功能不可用，支付挂了、登录挂了、核心链路全断，这种必须电话叫醒值班人，立即处理，分秒必争。P1 是功能降级或性能显著劣化，某个非核心服务报错率高了、整体 RT 涨了，这种走 IM 通知加值班跟进，重要但不至于半夜叫醒。P2 是非核心异常，某个边缘接口偶尔报错、某台机器重启了，这种汇总后定时通知，值班有空再看。P3 是趋势观察，CPU 这周比上周高了五个百分点，这种不通知，放在报表里定期看趋势。
分级的关键不只是定义，而是配套的通知机制要严格执行。P0 必须是电话这种能叫醒人的通道，P3 绝对不能进 IM 群打扰。一旦分级和通知通道脱节，比如 P3 的告警也往值班群发，告警疲劳立刻抬头。
阈值要加持续时间过滤抖动
告警规则的阈值设计是降噪的第一道关卡。最常见的新手错误是只看瞬时值，指标一超阈值就告警。
瞬时超阈值里藏着大量噪音。一次 GC 停顿让延迟飙升一秒，一次流量尖峰让 CPU 瞬间打满，这些抖动几秒钟就过去了，系统本身没问题，告警发出来就是误报。值班的人收到一看，哦是抖动，不用管。几次之后他就会对这类告警免疫，哪天真的持续异常他也会先假设是抖动。
解法是给告警加上持续时间条件。指标超过阈值，并且持续 N 分钟没有回落，才真正触发告警。这个持续时间窗口过滤掉绝大多数瞬时抖动。窗口取多长要看指标特性，错误率这种需要快速响应的，设 1 分钟。磁盘使用率这种变化慢的，设 30 分钟甚至更长。
收敛和合并，把同源噪音压成一条
即使加了持续时间，告警还是会因为同一个底层问题而批量爆发。一个数据库慢了，依赖它的十几个服务都会报错超时，每个服务的告警规则都会触发，值班群瞬间涌进十几条告警。这十几条指向同一个根因，但值班人看到的是十几条噪音，要花时间才能理清它们是同一个问题。
图：抑制规则让父告警（DB 宕机）触发时压住下游现象告警，值班人只收到一条根因
告警收敛的目的就是把这种同源噪音压成一条。几个策略配合用。同源合并，识别出这些告警来自同一个底层故障，合并成一条通知。时间窗口，同类告警在 N 分钟内只通知一次，避免反复轰炸。抑制规则，父告警触发时自动抑制它引发的子告警，数据库连接打满是父因，依赖数据库的服务报错是子象，父告警触发后子告警静默，值班人只看到根因那一条。
抑制规则是这里面价值最高也最考验对系统依赖关系理解的。要把系统的依赖拓扑梳理清楚，配置好父子关系，某个根因告警一旦触发，它下游所有的现象告警全部静默。这套规则维护得好，一次大故障值班人看到的可能就一两条根因告警，而不是几十条噪音。
一个 DB 宕机，会导致依赖它的几十个服务集体报错。这几十条都是现象告警，根因只有 DB 宕机这一条。如果告警系统没有抑制能力，值班人面对几十条报错，要花精力去判断它们的共同根因是什么，这几分钟就是故障扩大的时间。抑制规则让根因告警触发时压住它导致的现象告警，值班人直接看到根因，处置效率天差地别。
不可执行的告警是负担不是帮手
告警治理还有一个维度容易被忽略，可执行性。一条告警发出来，值班人收到之后能不能立刻知道该干什么。
内存使用率 85%，看到这条告警，然后呢？是该立刻扩容，是该去查有没有内存泄漏，还是这个数字正常不用管？如果一条告警不能回答这些问题，它带来的就是焦虑而非行动指引。值班人收到之后要么去翻文档，要么去问别人，要么直接忽略。忽略几次之后，这条告警就彻底失效了。
可执行的告警要做到，每条告警关联上足够的信息。指标的含义是什么，超阈值可能的原因有哪些，标准的处置预案是什么，相关的文档和仪表盘链接在哪。值班人收到告警，照着预案一步步执行就行，不需要从零开始分析。
关联处置预案这件事投入不小，但回报很高。它把值班人的响应从依赖个人经验变成了依赖标准化预案，新人也能快速上手处理，不会卡在 收到告警不知道咋办 这种地方。
定期清理，让告警集持续收敛
告警治理不是一次性的，是持续工程。最容易出现的问题是告警只加不减，业务上遇到一次故障就加一条告警，加了之后从来不删，最后告警规则膨胀到几百条，大半是过时的噪音。
要建立定期复盘的机制，比如每月过一遍所有告警规则。看几个维度。从未触发过的告警，要么是这个故障再没发生过，要么是阈值定得太松，这种可以删掉或者降级成观察报表，占着告警名额却不干活。触发但没有处置预案的，补上预案或者删掉，留着只会增加疲劳。误报率高的，调阈值或者调规则逻辑。触发后处置过度的，说明告警级别定高了，降级处理。
目标是让告警集持续收敛到每一条都精准、都值得响应。这个状态不会自然达到，要靠一轮轮的复盘清理去逼近。把告警当资产一样管理，定期审计淘汰，才能让它始终保持信号而不是退化为噪音。
