这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
告警系统
告警系统的目标不是“有异常就发消息”，而是“在需要人处理时，把足够上下文发给正确的人”。一个糟糕的告警系统会在凌晨发出几百条无效通知，最后所有人都学会忽略它。
告警规则
告警规则通常由四部分组成：
数据源 + 判断条件 + 持续时间 + 通知策略例如：
payment-callback P95 延迟 > 2s 持续 5 分钟，通知支付值班人持续时间很关键。瞬时抖动不一定需要告警，持续异常才更可能需要人工介入。规则还要区分级别：
- P0：核心链路不可用，需要立即电话或短信。
- P1：核心指标明显异常，需要值班人处理。
- P2：非核心服务异常，可以工作时间处理。
聚合与抑制
同一个故障可能触发多个规则。数据库慢会导致 API 延迟升高、错误率上升、队列积压。如果每个规则都单独发通知，值班人会被信息淹没。
告警系统需要聚合：
- 按服务聚合：同一服务多个接口异常合并。
- 按根因聚合：下游依赖异常时，抑制上游派生告警。
- 按时间聚合：短时间内重复触发只更新一次状态。
还需要抑制：
- 发布窗口内降低非核心告警敏感度。
- 已知维护期间暂停相关规则。
- 同一告警未恢复前不重复轰炸。
通知与升级
通知渠道要和严重程度匹配：
| 级别 | 渠道 |
|---|---|
| P0 | 电话、短信、IM 强提醒 |
| P1 | IM 群、值班机器人 |
| P2 | 工单、邮件、日报 |
告警超过一定时间无人确认，需要自动升级给备班或负责人。确认告警不代表解决问题，只代表有人接手；恢复通知也很重要，它能告诉团队故障是否已经结束。
告警内容
一条可用告警至少应该包含：
- 哪个服务、哪个接口或哪个业务指标异常。
- 当前值、阈值、持续时间。
- 影响范围，例如错误请求数或受影响租户。
- 最近变更链接，例如发布单、配置变更。
- 关联看板、日志查询和 trace 示例。
告警内容越接近排障入口，平均恢复时间越短。
告警质量治理
告警系统上线后要持续治理：
- 统计每条规则的触发次数、确认率、恢复率。
- 标记误报和漏报。
- 清理长期无人处理的规则。
- 对高噪音服务做专项优化。
告警不是配置完就结束，而是一个持续迭代的工程系统。下一章我们会补上链路追踪，让告警能更快指向请求经过的具体服务。