告警分级落地：日报降噪、夜间静默与同类去重

先说那个被淹掉的夜晚

凌晨 2:47，订单服务 5xx 从 0.3% 跳到 27%。值班同学手机在 90 秒内震了 41 次：30 条是上游服务超时，8 条是数据库连接池告警，2 条是容器重启，最后 1 条才是根因——主库磁盘写满。他花了 11 分钟往上翻，找到那条 P0 时，故障已经持续了 13 分钟。

这不是推送通道的问题，是分级的问题。告警系统的失败通常不是“没发出来”，而是“发得太多，等于没发”。

日报为什么必然被忽略

很多团队每天早上 9:00 推一条运行日报，内容涵盖接口耗时、任务成功率、库存同步条数。前 21 天数据都正常，第 22 天日报里有一行“库存同步失败 1842 条”，没人点开——因为前 21 天已经把这套肌肉记忆训练好了：这条消息不需要动作。

一条通知的价值大致可以写成 P(需要人行动) × 后果严重度 ÷ 打断成本。日报的问题在于第一项长期接近 0。更糟的是，它破坏了“收到消息”和“系统异常”之间的对应关系——当通道里永远有消息，你就无法再用“有没有消息”判断系统状态。

正确的做法不是把日报做漂亮，而是把它拆开：趋势类指标进面板，不进推送；只有越过阈值、且有人能处理的项，才允许变成一条通知。

timeSensitive 与 active 的取舍

iOS 的通知中断级别有 passive、active、timeSensitive、critical 四档，timeSensitive 能穿透专注模式，critical 需要单独申请权限且审核很严。Android 各厂商通道也有类似的强弱分级。分级滥用的代价是真实的：用户可以在系统设置里单独关掉你的 timeSensitive 权限，一旦关掉，之后所有 P0 都只能当普通横幅。

判断标准只有一条：这条消息发出去，对方是否需要在 5 分钟内做决策？

• 服务不可用、资金或库存越界 → timeSensitive，必要时叠加电话；
• 可用性下降但可自愈、容量水位接近阈值 → active；
• 日报、趋势、周报 → 不推送，进面板。

很多团队把“严重”和“紧急”混为一谈。磁盘跑到 85% 很严重，但不需要凌晨 3 点处理；接口 5xx 到 27% 才是紧急。分级表应该按“要求响应时间”排，而不是按“看起来多吓人”排。

同一天同类告警只推一次：state 去重

同一个磁盘写满的告警，五分钟一次推了 40 遍，本质上是一条信息重复了 40 次。用 fingerprint 做状态去重，成本极低：

fp = sha1(f"{rule_id}:{resource_id}:{level}")

写入 Redis，当天首次出现才推送：

SET alert:sent:20261029:{fp} 1 NX EXAT 1793378700

用 EXAT 指定到次日 00:05 的绝对时间戳，不要用固定 EX 86400，否则任务重启会跨天漂移，出现“今天下午的告警被昨天的 key 挡掉”。NX 返回成功才发消息，失败直接返回。

两个必须保留的例外：级别升高要重推（fingerprint 里带了 level，天然会重推），恢复通知要发。去重只压重复，不压升级和恢复，否则值班同学永远不知道事情结束了没有。

推送本身走华为云 SMN 的发布消息接口即可，一个 topic 订阅多个终端：

POST /v2/{project_id}/notifications/topics/{topic_urn}/publish

请求头带 X-Auth-Token（由 IAM 的 POST /v3/auth/tokens 换取，取响应头 X-Subject-Token），请求体里 subject 控制在 100 字符内，time_to_live 给 3600，避免设备离线后半夜突然补推一堆过期告警。

夜间静默：只放两类过去

23:30 到 07:30 之间，白名单只留两类：

• 可用性：探针连续 3 次失败、核心接口 5xx 超 5%、主库不可连；
• 库存与资金：库存跌破安全线、支付对账差额超阈值。

其余告警不要丢弃，而是入队，07:30 合并成一条早报，按 rule_id 分组计数：“夜间折叠 12 类共 208 条，其中超时类 176 条，最长持续 42 分钟”。丢掉和折叠是两件事：丢掉会让团队彻底失去“昨晚出过事”的感知，折叠只是延后了打扰时间。

压住风暴：聚合、抑制与令牌桶

三层防线，缺一层都会漏：

• 同源聚合：同一 service 加同一 rule 在 300 秒窗口内只发首条，正文附“同类 37 条”。
• 依赖抑制：主库不可用期间，抑制依赖它的 30 个服务的“接口超时”，只保留根因那条。规则写在拓扑里，不要写在人脑里。
• 通道令牌桶：单通道每分钟上限 5 条，超出后只发一条汇总并附详情链接。SMN 侧本身对流控有限制，超频会被限流返回 429，客户端如果不做退避，重试反而会加重堵塞。

风暴抑制最容易被忽略的一点是抑制本身要可见。每抑制一次就要留一条计数，否则下次排查时你会怀疑是告警没配对，而不是被拦了。

分级的终点是一句话

每加一条规则，先问：这条消息发出去，收到的人第一个动作是什么？如果答案是“看一眼然后关掉”，那它就不该是告警，应该是面板上的一个数字。分级不是一张配置表，是深夜里有人被叫醒之后要执行的动作序列。