上周二凌晨两点半企业微信告警群像炸了锅一样刷屏订单中心 SLA 掉点、支付网关超时率飙升、消息队列堆积告警、容器平台健康检查失败……一晚上涌进来 800 多条告警。我们 SRE 团队 7 个人全靠人工一条条翻、一个个查等找到真正导致故障的那条根因告警业务已经受了十几分钟损失。这种场面干运维的兄弟应该都不陌生——告警越多定位越难值班越痛苦。博睿数据 Bonree ONE 平台里新上的 Sage AI「故障诊断助手」恰恰就是冲这个痛点来的。我拿到体验权限之后在公司测试环境加生产环境轮番实测了两周今天把这套从告警到根因只要一句话的完整过程连同我踩过的坑一次性讲清楚。1. 先搞懂 Sage AI 到底在解决什么问题1.1 传统告警处理方式为什么越来越难扛先别急着聊产品功能我们得先对齐一个共识现在的告警处理链路瓶颈早就不是告警能不能发出来而是告警发出来之后谁能看懂。我司的情况很有代表性——Prometheus、夜莺Nightingale、Bonree ONE 三套监控体系并存基础设施、应用性能、业务链路各看各的。告警事件每分钟成百上千条But 每一条都只是现象不是原因。过去定位根因我们靠的是人肉三板斧先看告警详情猜一个方向再逐个跳进 Grafana、链路追踪、日志平台反复翻最后凭借对业务的熟悉程度把碎片拼起来。运气好十分钟定位运气不好一晚上搭进去。更坑的是告警风暴一来重要告警被海量噪音淹没真正 P1 的那条反而没被注意。这套打法太依赖个人经验和临场状态团队没法规模化复制。所以当 Bonree ONE 平台灰度上线 Sage AI「故障诊断助手」的时候我最关心的不是它能聊几句而是它能不能把告警背后的上下文——指标、链路、日志、拓扑、历史变更——一次性串起来直接告诉我根因大概率是什么。简单说我要的是从告警降噪到告警研判的闭环而不是又一个花式聊天机器人。1.2 Sage AI 的核心设计思路把告警上下文搬进对话里用了一周之后我可以负责任地说Sage AI 和普通大模型助手的本质区别在于它不靠通用知识硬答而是长在 Bonree ONE 的可观测性数据底座上。只要你在平台上纳管了主机、中间件、应用、容器、网络、调用链、日志这些数据源Sage AI 在收到告警事件时会自动把告警附近的指标片段、关联的 Trace、相关日志聚合、CMDB 拓扑关系、近期发布变更记录一起拉出来作为推理上下文。我打个比方。传统做法是你自己进厨房翻遍冰箱找食材再开火做饭Sage AI 是厨师已经把食材洗好切好你只需要说来一道鱼香肉丝它直接告诉你肉在哪、下锅顺序是什么、火候哪里容易翻车。当然它也会失误偶尔把糖当盐所以后面的实测里我会专门讲它翻车的场景和规避办法。这个设计思路带来的直接价值是值班同学不用再花 90% 时间在到处找数据上而是把精力放在验证 AI 给的结论是否合理上。这一步转变才是告警处理效率提升的真正来源。2. 实测前准备Bonree ONE 平台与 Sage AI 接入的几件要事2.1 我司测试环境的数据源构成与纳管范围这次实测我选用了一套跟生产 1:1 的最小化环境20 个微服务节点跑着订单、支付、库存、会员四个核心业务域数据库用了 MySQL 主从和 Redis 集群消息中间件是 Kafka任务调度是 DolphinScheduler容器平台是 K8s。Bonree ONE 平台需要先完成基础纳管Sage AI 才有东西可分析。我在测试环境里把 Agent 装到了应用服务器、JVM、数据库主机、K8s 节点上同时在平台配置了调用链采集日志也接入了产品内置的日志分析模块。这一步很关键如果调用链没配好Sage AI 能看到的就只有指标层面的波动根因分析的深度会大打折扣。有一点要提醒Sage AI 的分析能力上限取决于你喂给它的数据质量。CMDB 里服务的归属、等级、关联关系如果没维护AI 连这个告警影响的是下单还是支付都判断不准。所以动手接入之前我先把测试环境 CMDB 的几十个服务关系重新梳理了一遍确保每个服务节点挂在了正确的业务域下面。2.2 Sage AI 的接入与权限配置要点在平台界面上Sage AI 的启用路径并不复杂管理中心找到 AI 能力模块一键开通后需要给智能体绑定数据源权限。这里有两个非常容易踩的坑。第一个坑是账号权限。Sage AI 是以平台内部账号身份去读取指标、检索调用链、拉取日志的。如果你给它绑定的是一个只读但权限范围过窄的账号它分析业务 A 的故障时会缺少业务 B 的关联数据反过来如果给了全量权限安全合规上又有风险。我的做法是单独建立一个 AI 专用账号授权范围为全部告警数据 调用链搜索 日志检索 CMDB 读权限不开放配置修改类权限。第二个坑是事件源标注。我司还有一部分告警是夜莺和 Prometheus 通知过来的通过 Webhook 接入到 Bonree ONE 告警中心。Sage AI 能消费这些第三方事件但前提是事件里尽量带上 service、ip、cluster 这些标签。如果接入时没做标签规范化AI 拿到一条裸告警文本没法关联拓扑只能靠猜天赋。2.3 一个容易被忽略的配置告警严重级别与业务属性的绑定真正开始实测之后我才发现Sage AI 的根因推荐会优先参考告警严重级别和业务影响范围。如果所有告警都设成同一级别AI 的排序逻辑会失去抓手。于是我把测试环境的告警规则统一梳理了一遍核心链路的错误率、时延、可用性阈值设为 P1/P2基础设施类资源水位设为 P2/P3纯噪音类直接关闭或收敛。这样做的原因很简单AI 在处理一条 P1 告警时会更激进地往下钻取调用链和日志处理 P3 告警时更多是基于拓扑做快速归类。给告警配好身份属性Sage AI 的响应策略才会精准。这块配置完成后我特意找了三个历史故障场景来验证后面逐个讲。3. 核心实测实录三种典型故障场景的根因定位全过程3.1 场景一促销活动期间下单接口失败率突增第一个场景是我人为注入的故障在测试环境对订单库的从库做了一次主从切换同时给下单服务的数据库连接池设置了一个偏小的 maxTotal。现象很快出现——Bonree ONE 应用性能监控里下单接口的错误率在 5 分钟内从 0.4% 飙到 23%触发 P1告警。我直接打开 Sage AI 对话框问了一句最近 5 分钟下单接口失败率突增帮我定位根因。 大概 8 秒左右它返回了四个层面的分析结果第一层是现象确认下单服务 ORDER-SVC 的 POST /api/order 接口错误率从 0.4% 突增到 23%环比前 1 小时上升约 57 倍。第二层是链路下钻响应时间中位数从 42ms 升到 1.9s调用链追踪显示 92% 的慢请求集中在下游数据库 DBAccess 组件的连接获取阶段。第三层是关联证据MySQL 从库节点的主从延迟从 0 秒升到 18 秒Threads_running 峰值到 89连接池活跃连接数逼近 maxTotal 上限。第四层是根因推论故障极大概率由数据库连接池容量不足叠加主从切换诱发的旧连接失效共同导致。它给的信息比我预想的还要细连连接池 maxTotal 从日志参数中识别出当前值为 50都标出来了。我后续用数据库客户端确认确实连接池被打满。这个案例让我比较满意AI 不是简单说一句数据库有问题而是把指标、链路、日志、拓扑串成了一条可验证的证据链。3.2 场景二DolphinScheduler 定时任务连续失败企微告警刷屏第二个场景来自真实工作流——我司大量离线数仓任务跑在 DolphinScheduler 上某个早上 ods_order_daily 任务连续失败了三次企微告警群直接被刷屏。以往的排查方式先从 DolphinScheduler 界面看日志再联系数仓同学确认上游表产出情况最后发现是上游数据源表结构变更导致的。这次我直接问 Sage AIDolphinScheduler 里 ods_order_daily 任务最近 3 次失败的原因是什么 因为测试环境接入了任务调度日志AI 很快给出一条链路任务 DAG 中 ods_order_daily 依赖的上游表 ods_order_fact 在凌晨 1 点 50 分产出的分区数据量为 0继续下钻发现上游任务在读取源库时因为一个连接超时退出触发重跑后仍然超时。最有意思的是AI 额外指出源库在 1 点 45 分出现过写入锁等待激增并把云数据库相关慢日志片段摘了出来。我从没在提示词里让它查锁等待它主动给到了。这背后其实是 Sage AI 把任务日志、数据库慢日志、告警事件做了时间轴对齐把看起来孤立的调度失败和数据库抖动挂上了钩。这种场景对值班同学价值非常大——调度任务失败在告警里很常见根因往往不在任务本身而在上游的数据产出和数据源状态。AI 能自动往上游多跳两三层省掉了大量跨系统联查的时间。3.3 场景三多条安全类事件告警AI 帮我做了研判和收敛第三个场景不是业务故障而是事件类告警的研判。测试环境接入了一个模拟的安全告警源产生了两类事件一类是主机 A 到主机 B 的异常内网连接另一类是主机 C 到多个主机的非常规端口访问。这种告警以前值班时最容易纠结——它确实是安全设备报的但到底是真实攻击还是误报我试探性地问 Sage AI评估这两条安全告警的威胁程度并给出处理建议。 它的处理方式惊艳到我了它先把两台主机放到 CMDB 拓扑里看角色主机 A 和主机 B 同属一个微服务集群连接协议和端口号与该集群的健康检查组件完全匹配且连接频率符合正常基线判定为疑似误报建议降噪关闭。而对主机 C 的事件它在分析窗口内关联到了多条登录审计日志和文件变更告警特征与业务常规行为明显偏离判定为高危建议立即隔离并排查。我特意确认过AI 没有把这个过程写成任何攻击手法介绍而是聚焦在告警研判本身——这一点对合规很重要。这条场景让我意识到Sage AI 对告警降噪的价值不只是少看几条告警而是把安全类事件从看到就紧张变成有依据地判断优先级。全网上下一致好评的告警研判功能在它这里不是概念是真能落地。4. 提示词设计、告警降噪与中间细节的那些坑4.1 一句话问在点子上提示词设计的五个经验虽说产品叫故障诊断助手但它毕竟不是人不会追问你没说清楚的信息。实测下来提示词质量直接决定分析质量。我总结了几个非常实用的写法。第一说清时间窗口。最近 5 分钟、从 14:00 到 14:30这种明确时间范围能明显减少 AI 误抓历史数据做基线。第二绑定具体对象。不要只问为什么有告警要问下单接口的错误率为什么突增对象越具体AI 越容易定向搜索调用链和日志。第三给一个参考基线比如平时失败率不到 0.5%AI 能更准地判断异常程度。第四一次只问一个问题。复合问题容易让 AI 拆解错误先问根因是什么再追问连接池为什么耗尽效果更好。第五可以用业务语言不用非写服务全名不可。我直接问下单接口AI 也能基于 CMDB 的别名映射找到对应服务。这也是很多同事实际用起来觉得AI 不如想象中聪明的最大原因——你把提示词写得太模糊自然得到模糊的答案。上面五个点逐一改完后Sage AI 的诊断准确率在我这边实测中提升非常明显。4.2 和告警降噪规则配合先收敛再诊断单独靠 AI 做根因分析如果上游告警不做收敛AI 也会眼花。Bonree ONE 告警中心本身支持按时长、按主机、按规则做聚合与抑制Sage AI 拿到的应该是收敛后的事件而不是原始风暴。我在测试环境把同一时间窗口中同一服务的相似告警配置成 5 分钟窗口聚合由多条变一条Sage AI 的分析响应速度和结果可读性都好了很多。个人体会先靠规则引擎做告警降噪把数量降下来再靠 Sage AI 做告警研判与根因把质量提上去。两者配合才算完整的智能告警闭环。如果一上来全靠 AI 硬扛海量原始事件效果会大打折扣。另外我们在接入夜莺和 Prometheus 告警时维护好告警标签这件事的优先级要排在功能接入之前。标签不干净AI 分析就发飘。建议把 service、env、cluster、pod、severity 五个标签作为从外部系统接入事件的最低要求。4.3 几个典型误判场景与排查思路Sage AI 不是百分之百准确我实测中也抓到了几个翻车现场这里如实分享。翻车一CMDB 拓扑错误导致关联错对象。有一次我把一个服务的父节点配错了AI 在根因分析时把当前服务异常归结为父节点数据库异常而实际上父节点只是一个配置中心。排查思路每次 AI 给出根因后留意它关联的拓扑路径如果路径显示的服务归属和实际不符先把 CMDB 修正再重新询问。翻车二日志检索范围太窄。当应用只输出少量日志时AI 从日志侧拿到的证据极少会更多依赖指标做猜测。排查思路接入日志的级别别只开 ERROR至少保留 WARN 及以上关键时刻 INFO 也有用在调用链采样率上对核心接口单独调高采样率。翻车三多指标同时异常时AI 会优先选了表象最剧烈的那条链路但真正的根因可能藏在另一个温吞吞的指标里。比如我之前那个场景里连接池耗尽的表象很吓人但根因其实是参数配置不合理AI 第一次给出的结论只到了连接池耗尽没到为什么耗尽。解决办法是连续追问我接着问连接池为什么耗尽它才进一步定位到 maxTotal 设置过小的参数项。这也是我把经验总结为AI 给方向人下钻验证的原因。完全迷信 AI 不验证和完全不相信 AI 自己死磕两个极端都不可取。5. 实测之外Sage AI 的边界与充分发挥价值的前提5.1 它不能做什么我眼中的能力边界两周实测下来Sage AI 定位成故障诊断助手是很准确的它确实不是自动驾驶运维。它不会替你变更配置不会自动回滚发布也不会在发现根因后直接执行任何变更动作——它给的最终交付物是分析结论 证据链 建议动作。另外对于涉及多人协作、需要跨部门沟通的故障比如数据链路坏了要催数仓、网络变更要联系网络组Sage AI 也只能帮你把证据整理得更充分沟通和决策还是要靠人来推进。所以我的判断是Sage AI 是运维专家判断力的放大器而不是替代者——它能让你更快想清楚发生了什么、下一步动哪里但动不动、怎么动这件事得人拍板。如果你所在团队觉得AI 诊断结果我们不敢直接信我的建议是从低风险场景开始慢慢建立信任。先在测试环境跑通 3 到 5 个高频故障样板让值班同学拿着 AI 结论和我们原有的人工排查结论做对比两边一致后再扩大使用范围这个过程走完大家自然就敢在生产环境依赖它了。5.2 三件让 Sage AI 越用越顺手的辅助工作第一持续维护 CMDB。AI 再聪明也架不住拓扑关系是错的。我司现在把 CMDB 维护纳入变更流程的必检项服务上线或者下线时同步更新平台里的依赖关系Sage AI 的关联分析才有准头。第二沉淀历史故障库。Sage AI 能结合历史告警和工单做相似案例匹配但如果你没有积累这个库它的经验就少了历史维度。我们开始有意识地把每次带根因结论的复盘记录入库后续 AI 的建议会明显更懂你家的业务。第三设计最小必要权限的专用账号。既保证 AI 能读取它需要的数据又不至于权限过窄导致分析断链这个度需要平台管理员仔细配一次。5.3 后续可以扩展的两个方向顺着这两周的实测我认为 Sage AI 还有两个非常大价值的扩展玩法。一个是把诊断结论自动回写到工单系统告警触发后AI 出分析摘要直接生成一张带证据链网络链接和根因建议的工单技术负责人点开就能决策省掉大量整理时间。另一个是值班日报的自动归纳每天早上让 AI 汇总前 24 小时的高优告警、根因类别、未闭环事项比手工写周报轻松太多。这两个方向目前我们正在和平台方沟通开放的 API 能力等真正落地了我再给大家出一篇后续分享。最后说点实在的感受。这套产品给我的最大冲击不是某个单点功能有多炫而是它把告警 → 定位 → 根因这条链路从一种靠经验的个人手艺转变成一种可复制、可交接、有证据支撑的标准化流程。新同学值班时不用再慌慌张张到处翻平台对着 AI 问两句话再顺着证据链核一遍就能给出判断。当然我也保留了足够的警惕心——每次 AI 给出结论我都会自己快速核验一遍关键指标毕竟生产环境的安全感最终还是得靠人兜底。
