告警风暴是值班运维最头疼的事。这篇拆解炬鲸 OBSERVE 告警引擎的设计：聚合窗口与持续时长、同根因归并、静默窗口、四级分级与自动升级、标签路由与值班轮转，把告警收敛成真正该处理的事。
告警系统的难点从来不是"能不能发出来"，而是"发出来的到底该不该处理"。一个日均百万请求的业务，如果每次抖动都告警，值班的人两天就麻木了，真故障反而被淹没。我们重构告警引擎时定的目标就一条：让值班的人每天要处理的告警，从几百条降到几十条，同时不漏掉真故障。这篇拆解这套降噪和分级是怎么做的。
降噪的第一层发生在规则之前：先聚合再告警。原始指标一秒钟一个点，直接比阈值会产生大量抖动。我们把告警规则的评估对象从"单点"改成"聚合窗口"：比如"5 分钟内错误率持续超过 1% 才告警"，写成 rate(错误数[5m]) / rate(请求数[5m]) > 0.01 for 5m 这样的表达式，短促抖动根本进不了告警路径。规则里暴露两个参数——持续时长和最小触发次数，用户按业务敏感度自己调。
第二层是去重和收敛。同一条规则触发后，只要状态没变，就只发一次通知，之后进入持续状态，不再重复轰炸。多个告警如果共享同一个根因——比如一台机器宕机导致它上面十个服务的探活全失败——会被归并成一条父告警，下面挂十个子项，而不是发十条独立通知。
第三层是静默窗口。计划内的发版、压测、机房割接，提前建好静默窗口，时间窗内不发告警。静默窗口支持按规则、按数据源、按标签过滤，还支持一次性静默和周期静默（比如每周日凌晨的备份任务）。
告警本身要分等级，否则一条"磁盘使用率 75%"的提醒和一条"核心接口 502"的告警，在手机上看起来一样紧急。我们分四级：P0 业务不可用、P1 业务降级、P2 性能劣化、P3 提示信息。等级不是写死在规则里的，而是由影响面自动推断——涉及对外核心接口、影响用户数超过阈值、持续时间过长的，自动升级到 P0/P1。
分级直接决定通知渠道：P0/P1 走电话加企微加短信，P2 走企微加邮件，P3 只进待办不打扰。值班的人一眼就知道先看谁。
分级之后是路由。告警按标签路由到对应团队，比如 service=order 路由到订单组，env=prod 只发给当班的人。值班轮转表按周配置主备值班人，告警自动发给当期值班人的企微和手机；主值班人 15 分钟没确认，自动升级给备值班人，再超时升级给团队负责人。
确认和升级要形成闭环。每条告警支持确认、认领、转派、关闭，全程留痕。每周告警周报统计误报率、平均响应时长、升级次数，用数据倒逼规则收敛——某条规则连续两周误报率超过 30%，就该重新定阈值了。
告警系统的好坏，最终看值班的人晚上能不能睡好觉。降噪和分级做得越扎实，真故障被漏掉的概率越低。