华为云CES告警体系落地实践：从被动救火到主动巡检

一、背景：告警不是越多越好

业务上华为云的头半年，我们一直处在被动救火的状态：凌晨被电话叫醒，打开控制台发现是某台 ECS 的 CPU 打满，排查半小时才定位到是一次批量任务把磁盘 IO 顶住了。问题不在资源本身，而在告警体系——我们开了上百条规则，却没有一条告诉值班同学这条告警意味着什么、该看哪里。后来用华为云 CES（云监控服务）重新梳理，噪声降了约七成，漏报也基本消除。下面记录几个比较有效的动作。

二、先把指标分层，再谈阈值

很多团队上手的第一个动作就是给所有指标配 80% 阈值，结果必然是一堆无意义告警。我们的做法是按黄金指标分层：第一层是可用性指标，例如 ELB 后端健康检查失败数、RDS 连接数是否打满，越界就意味着业务受损，必须打电话；第二层是容量指标，例如磁盘和内存使用率，越界后还有数小时到数天的缓冲，走邮件或企业微信即可；第三层是趋势指标，例如 QPS 环比、P99 时延周同比，只用于周会复盘，不进告警通道。分层之后，告警通道和能力边界就对上了，值班同学不会被磁盘 80% 这种可以明天处理的事情打扰。

三、阈值分级：用持续时长压掉抖动

CES 的告警规则支持设置连续触发次数或持续周期，这是抑制抖动最有效的开关。我们统一约定：CPU 使用率连续 5 个周期超过 85% 才告警，而不是瞬时超一次就响；对 Redis、MySQL 这类对突发流量敏感的实例，阈值再放宽 5 个百分点。同时给每条规则补齐告警级别，紧急、重要、提示三档，级别直接决定通知方式和响应时限。这一步看起来只是填表，实际上是把谁在多久内必须处理这件事固化了下来。

四、告警收敛：一次故障只发一条

同一次可用区网络抖动，往往会同时触发十几台 ECS 的告警。我们在 CES 里用告警模板批量下发规则，再配合告警分组，把同一应用、同一资源组的告警聚合成一条通知；同时在消息通知侧按五分钟内同规则只发一次做去重。改造后，一次故障从几十条消息变成一条带资源清单的汇总消息，值班同学的判断成本大幅下降。

五、闭环：让每条告警都有归属

告警发出去只是开始，真正决定体系能不能活下去的是闭环。我们做了三件事：每条规则必须绑责任人，没有责任人的规则直接下线；告警处理结果回填工单，月度统计告警数、有效告警数、平均恢复时长；每月做一次告警巡检，清理连续三个月零触发的规则，重调误报率高的阈值。三个月后告警总量下降约 70%，故障平均发现时间从 20 分钟缩短到 3 分钟以内。

六、一个踩过的坑

第一，不要用一条规则覆盖所有规格的实例。小规格实例的基线波动远大于大规格实例，统一阈值容易误报。第二，通知渠道要分级但不要发散，我们曾把告警同时推到邮件、短信、企业微信和钉钉，结果没人认真看任何一个渠道。

写在最后：告警体系的本质不是技术配置，而是把运维经验写成可执行的规则。CES 提供了足够的表达能力，真正花时间的是梳理哪些指标对业务有意义。