告警治理与值班体系建设

监控采集得越多，不代表系统越可靠。真正有效的告警必须在正确的时间通知正确的人，描述真实影响，并且接收者能够采取明确动作。大量无效告警会让值班人员形成条件反射式忽略，最终使真正严重的问题淹没在噪声中。

本文从告警设计、分级、路由、值班、度量和持续治理六个方面，给出一套可逐步落地的方法。示例使用 Prometheus/Alertmanager 的概念，但同样适用于 Zabbix、云监控和其他平台。

一、先区分记录、通知和呼叫

并非所有异常都需要叫醒一个人。

如果一个告警触发后没有任何可执行动作，它不应成为呼叫。可以把它保留为仪表盘信息、工单或用于关联分析的事件。

二、什么值得告警

1. 优先告警用户可感知的症状

在线服务优先关注成功率、延迟、可用性和数据新鲜度；批任务关注最近成功时间、积压和完成期限；基础设施关注即将导致业务中断的容量与冗余丢失。

CPU 高并不一定影响用户，CPU 正常也不代表服务健康。原因类指标主要用于定位，症状类指标更适合决定是否呼叫。

2. 一个合格告警的四个条件

• 真实：信号能代表实际问题，数据源本身可信；
• 重要：不处理会造成明确影响；
• 紧急：不能等到正常工作时间；
• 可操作：接收者有权限、有步骤、有办法验证结果。

缺少其中任一条件，都应重新评估通知级别。

3. 监控系统也需要被监控

应从外部验证采集、规则计算、Alertmanager、通知通道和接收终端的完整链路。仅监控每个组件进程存活，不能证明告警真的能送达。

三、告警分级

分级必须绑定动作和响应时间，不能只用颜色区分。告警描述中应写明升级条件，例如“错误率持续 15 分钟或影响超过两个区域时升级 P1”。

四、阈值、持续时间与缺失数据

1. 不要只用瞬时阈值

瞬时尖峰可能是正常抖动。告警规则通常需要持续窗口，例如连续 5 分钟满足条件。持续时间应根据业务容忍度、采集周期和故障发展速度确定，不能机械地全部设成同一个值。

2. 避免平均值掩盖问题

平均延迟可能正常，但少量用户已经非常慢。延迟应结合分位数、错误率和请求量；集群指标应能下钻到区域、实例或租户，同时控制标签基数。

3. 处理“没有数据”

指标消失可能表示目标宕机、服务发现失败、采集异常或业务真的没有流量。规则需要区分零值与缺失值，并为采集链路建立独立告警。

4. 使用多窗口避免误报和漏报

对于 SLO，可同时观察短窗口快速燃烧和长窗口持续消耗。短窗口用于发现剧烈故障，长窗口用于发现较慢但持续的质量下降。

五、SLO燃尽率告警

假设月度可用性目标为 99.9%，允许错误预算约为 0.1%。燃尽率表示错误预算消耗速度：

燃尽率 = 观察窗口内的错误比例 ÷ SLO允许的错误比例

燃尽率为 1 表示按计划消耗；明显高于 1 表示预算会提前耗尽。实务中通常组合两个窗口，要求短窗口和长窗口同时超过阈值才触发呼叫，从而兼顾速度和稳定性。

SLO告警不是替代所有基础设施告警。磁盘即将耗尽、证书即将过期、备份连续失败等虽然还未产生用户错误，仍然需要提前处理，但多数情况下可以进入工单而非夜间呼叫。

六、Alertmanager治理思路

分组

同一集群、服务和告警名称的实例应聚合成一条通知，避免网络分区时发送几百条消息。分组标签要稳定，不能包含 Pod UID 等高变化字段。

抑制

当“整个集群不可达”触发时，可以抑制该集群下大量实例不可达告警。抑制只减少重复通知，根告警必须可靠且路由正确。

静默

静默必须有创建人、原因、关联变更、开始和结束时间。禁止创建无期限静默。变更结束后应检查是否有被静默掩盖的真实故障。

路由

建议按照服务、环境、等级和团队路由。任何生产服务都应有默认兜底接收组，避免标签错误导致告警无人接收。

七、一条告警应包含什么

推荐字段：

• 告警名称和等级；
• 服务、环境、区域和受影响对象；
• 当前值、阈值和持续时间；
• 可能的用户影响，而不是武断根因；
• 仪表盘、日志查询和链路入口；
• Runbook；
• 服务负责人和值班组；
• 最近变更；
• 告警指纹或事故编号；
• 确认、静默和升级入口。

不推荐只发送“CPU告警：95%”。值班人员还需要知道哪台主机、持续多久、服务是否受影响、能否扩容、谁负责以及如何验证。

八、Runbook模板

每个可呼叫告警至少关联以下内容：

1. 告警含义：指标如何计算，什么情况下会触发；
2. 用户影响：可能影响哪些业务；
3. 快速验证：两个独立信号确认真伪；
4. 常见原因：按概率和风险排序；
5. 安全止损：可以执行的低风险动作；
6. 禁止动作：例如不能直接清库、重建集群或删除数据；
7. 升级条件：何时联系数据库、网络、安全或管理人员；
8. 恢复验证：业务路径、指标和积压如何确认；
9. 回退方式：临时操作如何撤销；
10. 维护信息：负责人、最后演练日期和适用版本。

Runbook应由非作者值班人员实际演练。作者觉得清楚，不代表夜间第一次接触的人能够执行。

九、值班体系

1. 主值、备值和专家升级

主值负责首响，备值在主值未确认或需要协助时加入。数据库、网络、安全和供应商专家可以作为二线，不应把所有告警同时发给所有人。

2. 交接班

交接至少包含：当前事故、静默、变更窗口、容量风险、临时措施、未关闭工单和需要特别关注的客户。口头交接之后应有可查询记录。

3. 权限准备

值班人员应在上岗前完成权限验证。事故发生时再申请堡垒机、云账号或数据库只读权限，会显著延长恢复时间。紧急权限应短期、审批、审计并在事后回收。

4. 人员健康

持续夜间噪声会降低判断质量。需要统计每人每班呼叫次数、夜间唤醒次数和处理时长，为频繁事故安排补休，并优先治理产生最多噪声的系统。

十、告警质量指标

每月选择噪声最高的前十条告警治理，比一次性重写所有规则更可持续。

十一、告警评审流程

新增呼叫规则前应回答：

1. 对应什么用户或业务影响？
2. 为什么必须立即人工处理？
3. 接收团队是谁，标签是否能正确路由？
4. 是否有持续窗口、恢复条件和缺失数据处理？
5. 是否会被上游根告警抑制？
6. 是否具备仪表盘、Runbook和升级路径？
7. 在测试环境如何触发和恢复？
8. 规则成本和标签基数是否可控？

发布后观察一段时间，再根据真实触发情况调整，不能把规则写完就永久不管。

十二、常见误区

• 每台服务器每个指标都建立呼叫；
• 告警阈值完全沿用厂商默认值；
• 所有通知都发到一个大群；
• 用静默长期掩盖无法解决的问题；
• 只监控组件，不监控用户关键路径；
• 用告警数量衡量监控建设成果；
• 没有监控“监控系统”和通知通道；
• 事故结束后不清理临时规则和静默；
• 把夜间告警过多归因于值班人员能力不足。

十三、落地检查清单

• [ ] 区分记录、工单、通知和呼叫；
• [ ] 每个生产服务有负责人和值班路由；
• [ ] 可呼叫告警映射到用户影响或迫近风险；
• [ ] 配置分组、抑制、静默期限和兜底路由；
• [ ] 每条呼叫都有关联 Runbook；
• [ ] 建立黑盒监控与通知链路自检；
• [ ] 定期统计误报、重复和无动作告警；
• [ ] 每月治理噪声最高的规则；
• [ ] 定期演练告警触发、升级和恢复通知。

十四、示例：从CPU告警改造成可行动告警

原规则是“任意实例CPU超过80%持续一分钟就电话通知”。上线后批处理每天都会触发几十次，但服务延迟正常，值班人员只能逐条确认后忽略。真正发生线程池耗尽时CPU只有35%，规则反而没有报警。

治理时保留CPU为诊断指标，把呼叫条件改为“登录接口错误率和延迟同时导致SLO快速燃烧”；CPU持续高但无用户影响时自动创建容量工单。对实例故障增加集群可用副本判断：单实例退出且冗余充足只通知，多个实例退出或整体容量不足才呼叫。通知按服务和区域分组，并在集群不可达时抑制实例级告警。

新告警附带错误率、流量、最近发布、仪表盘和Runbook。团队在测试环境制造依赖超时，验证规则触发、路由、升级、静默和恢复通知。治理后告警数量下降并不代表监控变少，而是呼叫更接近真实用户影响，诊断指标仍保留在仪表盘中。

十五、参考资料

• Prometheus：Alerting practices
• Prometheus：Alertmanager
• Google SRE Workbook：Alerting on SLOs
• Google SRE Workbook：On-Call

告警体系的成熟标志不是“什么都能报警”，而是值班人员收到一条消息后，能够迅速判断影响、找到证据、采取安全动作，并相信真正严重的问题不会被噪声淹没。