告警风暴治理：从 200 条告警到 1 条有效通知

告警为什么总会“狼来了”

半夜三点，数据库主从切换引发三十秒抖动。这三十秒里，订单服务超时、支付服务重试、网关 5xx、Redis 连接池告警接踵而至——一条根因，连锁触发两百多条告警。值班同学被电话叫醒后，先花十分钟从告警洪流里翻出第一条真正的报错，再花二十分钟逐一关闭无关告警。

问题不在“告警太多”，而在“告警没有组织”。可观测平台的告警模块，价值不只是“能发出来”，而是“发出来的每一条都值得看一眼”。

四道防线：聚合、抑制、静默、分级

炬鲸 OBSERVE 用四层机制把噪声挡在值班人员手机之外：

1. 聚合（Grouping）：同一维度的告警合并成一条，带出现次数和首次/最近时间，而不是一条条刷屏。比如同一服务的 500 错误，五分钟内无论触发多少次，只发一条。
2. 抑制（Inhibition）：配置“数据库不可用”这类根因告警后，自动抑制其下游“接口超时”“连接池耗尽”等派生告警。根因解决了，症状告警自然消失，没必要重复打扰。
3. 静默（Silence）：计划内变更（发版、迁移、压测）期间手动或定时静默，避免“已知问题”刷屏。静默必须带过期时间，防止忘记解除。
4. 分级（Severity）：P0 电话加短信，P1 企业微信，P2 只进面板不打扰。让通知渠道匹配事件严重度，而不是一刀切全推电话。

配置示例：把 200 条压成 1 条

告警规则用 YAML 声明式配置，下面这段把“订单服务错误率大于 5%”的告警按错误码聚合，并抑制下游支付服务的超时告警：

alert_rules:
  - name: order-service-error-rate
    expr: error_rate(service='order-service', window='5m') > 0.05
    severity: P1
    group_by: [service, error_code]
    group_wait: 30s
    inhibit: [pay-service-timeout]
    notify: [wecom-oncall]

再加一条根因告警：数据库连接池耗尽时，订单、支付、网关的告警全部被抑制，最终只推一条 “DB connection pool exhausted” 给值班同学。告警量从两百条降到一条，on-call 的起床成本也降到最低。

落地建议

• 先花半天梳理告警的依赖拓扑，把“根因”和“症状”分开，抑制规则才有意义；
• 聚合维度宁粗勿细：group_by 先按 service，稳定后再细化到 error_code；
• 每月复盘一次告警数据：哪些规则连续 30 天没触发、哪些被静默的次数最多，该删的删、该调的调；
• 静默一定带过期时间，避免“永久静默”埋雷。

告警的价值是“精准叫醒正确的人”，不是“证明系统在报警”。