我的 AIOps 最佳实践：告警从"刷屏"到"一次一个事件"，我们用 CloudQ 做降噪与根因定位

原创

一、场景背景：不是"没有告警"，是"告警多到没人信"

几年前把单体拆成微服务之后，监控这块很快就失控了。每个服务、每个中间件、每种资源都有自己的告警规则——Zabbix 一套、腾讯云可观测平台一套、日志平台还各算各的，攒下来光告警规则就有几百条。一开始想法很朴素——"监控越全越安全"，后来发现根本不是这么回事。

最典型的一个凌晨：两点多手机响了，是一个下游服务的接口超时告警。等我爬起来、连上 VPN、把日志翻出来，发现是内存抖了一下，几分钟就自己恢复了，用户那边毫无感知。那一晚我被这样叫醒了三次。

白天也不好过。一个核心服务出问题，它的上游、下游，以及依赖的 Redis、MySQL、Kafka、Nginx 网关会在几分钟里一起告警，几十条消息瞬间把群刷满。真正有价值的那条，早被淹没了。值班的同学慢慢出现了"告警疲劳"——看到告警的第一反应不是紧张，而是"大概又是误报吧"。

说白了，问题不是"没有告警"，而是"告警太多，多到没人信"。我们要治的就是这个。

二、方案总览：为什么把这件事交给 CloudQ

一开始我们想自己搭：上几个开源组件做收敛，再写点脚本做关联。搭到一半就发现不对劲——规则越写越多、维护成本越来越高，而且每次排查还是要人在监控、日志、链路几个系统之间来回跳。

后来我们把这件事交给了 CloudQ。吸引我们的其实是三点：一是它以自然语言为入口（ChatOps），值班同学可以直接问"过去一小时这个业务域发生了什么"，而不用学一套复杂的查询语法；二是它的 AIOps 能力偏向主动——主动巡检、主动诊断，能帮我们把关联和根因推断做起来，不用从零去搭；三是它本身就是装在 WorkBuddy 里的一个技能，装完即用，业务特有的规则我们再补自研 Skill。对我们来说，这意味着把"重复造轮子"的时间省下来，专注在自己的业务规则上。

还有一个很实际的原因：它的入口就在我们每天已经在用的 AI 工作台 WorkBuddy 里——不用再单独开一个运维控制台，装上技能，在对话框里说句话就能用，值班同学几乎零学习成本。更省事的是，WorkBuddy 能直接对接企业微信、QQ 这类日常 IM，也就是说值班同学不用切系统，在自己平时盯的群里就能把它喊出来问一句，故障一发生顺手就能查。

三、接入流程：从"看到告警"到"看懂故障"

具体接入我们没有一步到位，是分几段推进的。

第一段是把数据地基打好。 把云账号下的资源、指标监控、日志、调用链这些"原材料"纳管进来。这一步最不起眼，但最要命——如果资源标签、服务命名是乱的，后面关联一定不准。我们是先把服务名、环境、机房、业务域这几类标签统一规范了，才往下走。

第二段是装配能力。 我们在 WorkBuddy 里通过 SkillHub 把 CloudQ 技能装上（它在 WorkBuddy 里叫"CloudQ 多云管理专家"），云资源纳管、主动巡检、根因诊断这些能力就随技能一起可用；业务特有的规则，我们再补自研 Skill。这一步的好处是能力可插拔，哪个环节不好用就换，不用动整体。

第三段是编排工作流。 以前写规则文件，现在改成用自然语言描述任务，比如"把过去一小时同一业务域内的告警聚成事件，并给出可疑根因和服务影响面"。编排好之后，一次任务下来，值班同学拿到的不是几十条告警，而是一条结论。

第四段是人工复核。 这一点我们特意保留了：高危结论和自动处置动作，都要人确认后才执行，不盲目全自动。吃过亏之后，我们更愿意让机器"给建议"、让人"拍板"。

四、关键决策与踩过的坑

先做降噪，再做根因。 一开始贪大，想直接做全自动根因，折腾挺久发现数据地基根本没打好，做不动。后来收缩范围，先把告警量压下来、把关联做准，根因反而水到渠成。
抑制规则要保守。 有次抑制写太狠，线上真出问题，结果被自己的规则吃掉，报了句"已知事件"就没再提醒。从那以后原则改成：宁可多报一点，也别漏真故障。
先治理标签，再谈关联。 服务名一会儿带环境后缀、一会儿不带，关联肯定做不准。这是脏活，但绕不过去。
静态阈值换动态基线。 业务有峰谷，手拍阈值不是太松就是太紧，永远调不完。我们把核心指标换成了按历史分位数算的动态基线，误报一下降了不少。