分布式系统告警应该如何设计，如何避免告警风暴？
简化版
告警设计要围绕用户影响和服务目标，而不是所有指标一异常就报警。优先对错误率、P99 延迟、可用性、核心业务成功率、资源饱和度设置告警，并区分严重级别、持续时间和影响范围。
避免告警风暴要做聚合、抑制、去重、分级、依赖关联和恢复通知。根因服务已经告警时，下游大量连带错误不应该把所有人都吵醒。
详细版
好的告警应该具备可行动性。收到告警后，值班人员应该知道哪个服务、哪个接口、什么指标、影响范围、从什么时候开始、可能关联什么变更。如果告警只是“CPU 高了一下”但不需要行动，长期会让团队对告警麻木。
告警阈值要结合业务和 SLO。比如核心下单接口错误率超过 1% 持续 5 分钟，比某台机器 CPU 瞬间 90% 更值得报警。资源告警也要关注饱和度和持续时间，而不是瞬时波动。
告警风暴通常发生在依赖故障或大面积网络问题时。要通过告警聚合、根因抑制、同类合并、静默窗口、升级策略和告警路由降低噪音，让值班人员优先处理真正的根因。
完整版教学
一、告警的目标是驱动行动
告警不是为了证明系统有很多指标，而是为了让人在需要介入时及时介入。一个好告警应该回答：发生了什么、影响多大、谁负责、应该怎么查。
如果一个告警经常没人处理，或者处理动作永远是“观察一下”，它可能就不是好告警。
二、优先围绕用户影响设计
最重要的告警通常来自用户可感知指标：可用性、错误率、延迟、核心业务成功率。比如登录失败率、下单成功率、支付回调延迟，这些比单个容器 CPU 抖动更直接。
资源告警也重要，但它通常是原因或风险信号。CPU 高不一定影响用户，错误率升高才说明用户已经受影响。告警优先级要体现这一点。
三、SLO 和错误预算
SLO 是服务目标，比如 99.9% 可用性、P99 延迟小于 300ms。基于 SLO 告警比拍脑袋阈值更科学。
错误预算表示在目标范围内允许的失败量。如果错误预算消耗很快，就应该告警，因为它说明当前失败速度可能破坏服务目标。
这种方式能减少无意义告警，把注意力集中在真正影响服务承诺的问题上。
四、告警要有持续时间和窗口
瞬时波动不一定需要报警。比如 CPU 一秒钟冲高、接口偶发一个 500，都可能是正常噪音。告警通常要设置持续时间或滑动窗口。
例如“5 分钟内错误率超过 2% 且请求量大于一定阈值”比“出现一个错误就告警”更合理。请求量门槛也重要，否则低流量接口一个请求失败就变成 100% 错误率，会产生误报。
五、告警风暴的来源
分布式系统有依赖关系。一个数据库故障，可能导致几十个服务报错；一个注册中心异常，可能导致大量服务发现失败。如果每个服务都独立报警，值班人员会被淹没。
告警风暴会带来两个问题：真正根因被噪音掩盖，团队对告警疲劳。解决它需要关联和抑制。
六、如何抑制和聚合
常见手段包括：
- 去重：同一服务同一指标短时间只报一次。
- 聚合：同一根因或同一集群问题合并成一条告警。
- 抑制：上游依赖已告警时，下游连带告警降低优先级。
- 分级：P0、P1、P2 对应不同通知方式。
- 静默：发布窗口或已知维护期间设置静默。
- 升级：长时间无人确认再升级通知。
这些机制让告警系统更像调度系统，而不是喇叭。
七、面试回答建议
回答时可以说：告警要围绕用户影响和 SLO，指标要有持续窗口和请求量门槛，告警要可行动。避免风暴靠去重、聚合、抑制、分级和依赖关联。
再补充告警内容要包含服务、接口、指标、当前值、阈值、影响范围、排查链接和 Runbook，这会很加分。
八、常见追问和落地边界
常见追问是告警应该通知谁。告警路由要按服务 owner、严重级别和值班表分发。平台问题通知基础设施团队，业务成功率问题通知业务 owner，跨团队故障需要升级到统一值班协调。
另一个落地边界是每条高优先级告警都应该有 Runbook。Runbook 至少包含指标含义、常见原因、排查入口、应急动作和回滚方式。没有 Runbook 的告警，值班人员容易临场猜，恢复时间会变长。
告警还要区分症状告警和原因告警。症状告警直接反映用户影响，比如错误率、延迟、成功率；原因告警反映可能原因，比如 CPU、连接池、磁盘、GC。值班体系里通常优先响应症状告警，再用原因指标定位。只靠原因告警容易误报，只靠症状告警又可能定位慢，两者需要配合。
恢复通知也很重要。告警恢复后要通知相关人员，并记录持续时间。否则团队只知道问题发生，不知道是否恢复，也无法统计 MTTR、告警准确率和故障影响时间。告警系统本身也需要持续治理，定期清理低价值告警。
九、常见误区与追问
这道题要紧扣「告警设计」本身回答，不能把它混成泛泛的可观测性套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖日志、指标、追踪、上下文传播、采样、告警和排障闭环。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 告警设计要围绕用户影响、SLO、错误预算和可行动性，而不是把所有指标阈值都发给人 | 不要停在名词解释 |
| 流程机制 | 定义 SLO 和核心指标 -> 设置多窗口阈值 -> 聚合相同故障 -> 通知负责人 -> 执行处置预案 -> 复盘优化规则 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 接口错误率连续 5 分钟超过 1% 比 CPU 瞬时 80% 更接近用户影响，也更适合叫醒值班同学 | 可观测性不能替代稳定性设计，它用额外采集、存储和分析成本换更快定位问题 |
告警设计 面试拆解：
1. 定义 SLO 和核心指标
2. 设置多窗口阈值
3. 聚合相同故障
4. 通知负责人
5. 执行处置预案
6. 复盘优化规则记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「告警设计」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：告警越多越安全。 告警过多会造成疲劳，真正事故反而被淹没。
- 误区：CPU 高就一定要告警。 资源指标要结合错误率、延迟和饱和度判断用户影响。
- 误区：告警只要发出来就完成了。 告警必须可定位、可归属、可处置。
- 追问：什么是可行动告警？ 收到后能明确判断影响、负责人和下一步动作。
- 追问：如何减少告警噪声？ 聚合、抑制、分级、多窗口燃尽率和依赖根因关联。
- 追问：告警和监控区别？ 监控记录状态，告警是在状态偏离目标且需要动作时通知人或系统。
十、加强记忆
告警像消防警报，不是烟雾传感器一抖就全城拉响。真正好的告警是少而准，能把人叫醒去处理对用户有影响的问题。
告警设计的核心是可行动、可分级、可抑制、可追踪。