告警系统

告警系统的目标不是“有异常就发消息”，而是“在需要人处理时，把足够上下文发给正确的人”。一个糟糕的告警系统会在凌晨发出几百条无效通知，最后所有人都学会忽略它。

告警规则

告警规则通常由四部分组成：

数据源 + 判断条件 + 持续时间 + 通知策略

例如：

payment-callback P95 延迟 > 2s 持续 5 分钟，通知支付值班人

持续时间很关键。瞬时抖动不一定需要告警，持续异常才更可能需要人工介入。规则还要区分级别：

• P0：核心链路不可用，需要立即电话或短信。
• P1：核心指标明显异常，需要值班人处理。
• P2：非核心服务异常，可以工作时间处理。

聚合与抑制

同一个故障可能触发多个规则。数据库慢会导致 API 延迟升高、错误率上升、队列积压。如果每个规则都单独发通知，值班人会被信息淹没。

告警系统需要聚合：

• 按服务聚合：同一服务多个接口异常合并。
• 按根因聚合：下游依赖异常时，抑制上游派生告警。
• 按时间聚合：短时间内重复触发只更新一次状态。

还需要抑制：

• 发布窗口内降低非核心告警敏感度。
• 已知维护期间暂停相关规则。
• 同一告警未恢复前不重复轰炸。

通知与升级

通知渠道要和严重程度匹配：

告警超过一定时间无人确认，需要自动升级给备班或负责人。确认告警不代表解决问题，只代表有人接手；恢复通知也很重要，它能告诉团队故障是否已经结束。

告警内容

一条可用告警至少应该包含：

• 哪个服务、哪个接口或哪个业务指标异常。
• 当前值、阈值、持续时间。
• 影响范围，例如错误请求数或受影响租户。
• 最近变更链接，例如发布单、配置变更。
• 关联看板、日志查询和 trace 示例。

告警内容越接近排障入口，平均恢复时间越短。

告警质量治理

告警系统上线后要持续治理：

• 统计每条规则的触发次数、确认率、恢复率。
• 标记误报和漏报。
• 清理长期无人处理的规则。
• 对高噪音服务做专项优化。

告警不是配置完就结束，而是一个持续迭代的工程系统。下一章我们会补上链路追踪，让告警能更快指向请求经过的具体服务。