【AIOps实践】我的 AIOps 最佳实践：告警从“刷屏”到“一次一个事件”

几年前把单体拆成微服务之后，监控很快就失控了。每个服务、每个中间件、每种资源都有自己的告警规则——Zabbix 一套、腾讯云可观测平台一套、日志平台还各算各的，攒下来光告警规则就有几百条。一开始想法很朴素——“监控越全越安全”，后来发现根本不是这么回事。最典型的一个凌晨：两点多手机响了，是一个下游服务的接口超时告警，等我爬起来、连上 VPN、把日志翻出来，发现是内存抖了一下，几分钟就自己恢复了，用户那边毫无感知。那一晚我被这样叫醒了三次。白天也不好过。一个核心服务出问题，它的上游、下游，以及依赖的 Redis、MySQL、Kafka、Nginx 网关会在几分钟里一起告警，几十条消息瞬间把群刷满，真正有价值的那条早被淹没了。值班的同学慢慢出现了“告警疲劳”——看到告警的第一反应不是紧张，而是“大概又是误报吧”。说白了，问题不是“没有告警”，而是“告警太多，多到没人信”。我们要治的就是这个。后来我们把这件事交给了 CloudQ，吸引我们的是三点：一是它以自然语言为入口（ChatOps），值班同学可以直接问“过去一小时这个业务域发生了什么”，而不用学一套复杂的查询语法；二是它的 AIOps 能力偏向主动——主动巡检、主动诊断，能帮我们把关联和根因推断做起来，不用从零去搭；三是它本身就是装在 WorkBuddy 里的一个技能，装完即用，业务特有的规则我们再补自研 Skill。具体接入我们分四段推进。第一段是把数据地基打好，把云账号下的资源、指标监控、日志、调用链这些“原材料”纳管进来，这一步最不起眼但最要命——如果资源标签、服务命名是乱的，后面关联一定不准，我们是先把服务名、环境、机房、业务域这几类标签统一规范了才往下走。第二段是装配能力，在 WorkBuddy 里通过 SkillHub 把 CloudQ 技能装上，云资源纳管、主动巡检、根因诊断这些能力随技能一起可用。第三段是编排工作流，以前写规则文件，现在改成用自然语言描述任务，比如“把过去一小时同一业务域内的告警聚成事件，并给出可疑根因和服务影响面”，编排好之后一次任务下来，值班同学拿到的不是几十条告警，而是一条结论。第四段是人工复核，这一点我们特意保留了：高危结论和自动处置动作都要人确认后才执行，不盲目全自动。关键决策与踩过的坑：先做降噪再做根因，一开始贪大想直接做全自动根因，折腾挺久发现数据地基根本没打好，后来收缩范围先把告警量压下来、把关联做准，根因反而水到渠成；抑制规则要保守，有次抑制写太狠，线上真出问题结果被自己的规则吃掉，从那以后原则改成宁可多报一点也别漏真故障；先治理标签再谈关联；把核心指标的静态阈值换成按历史分位数算的动态基线，误报一下降了不少。收益方面：约七成的误报、抖动被收敛掉，告警形态从“一次故障几十条”变成“一次故障一个事件”，MTTR 从原来的 1 小时左右压到 10 分钟级，半夜被误报叫醒的次数明显减少。回头看最有用的一条经验是：别迷信“智能”，先把地基打好。

来源：腾讯云开发者社区

以上资讯由金支点整理发布
关注金支点公众号获取每日行业报告