文吉-基于大模型的根因分析实战

基于大模型的根因分析实战 文吉畅捷通信息技术股份有限公司 演讲嘉宾 文吉 十年以上SRE实战经验，特别是对ToB场景有丰富实战经验用友集团P9高级专家多次对外分享，融合大模型能力升级智能运维荣获了信通院颁发的“稳定性优秀案例” 1.背景2.问题/痛点3.解决思路/整体方案4.具体实现/技术实践5.总结与展望 目录 背景PART 01 畅捷通是做什么的？ 畅捷通信息技术股份有限公司是用友旗下成员企业，成立于2010年3月，于2014年在港交所上市，是中国领先的小微企业财税及业务云服务提供商。 C端用户量+ B端客户体量 要保障每个用户的体验 畅捷通运维转型之路——目标0-2-5-10 业务从自建机房逐步转向全面采用公有云容器化架构，为业务发展提供了更强大的基础，但同时也带来了运维复杂性的指数级增长。 问题/痛点PART 02 从一次飞机撞鸟说起 2023年11月1日，旭日8409飞机起飞离地时，发动机遭遇鸟击。 情况万分危急，关系到机上183人的生命安全。 畅捷通运维面临什么样的压力？ 发生故障时难以定位 定位一个问题，需要： •打开3-5个看板•执行2-4次分析脚本 90%的问题此时就能找到原因，耗时10分钟。 但另10%的问题，才会产生大的故障，且往往难以定位原因 无法快速判断爆炸半径 •怎么判断报警严重性？•报警爆炸半径多大？•是否正在处理？谁在处理？•恢复了吗？ 畅捷通运维面临什么样的压力？ 解决思路/整体方案PART 03 关键要素：检查单 1.吸收了所有故障排查经验2.紧急时刻不需要思考3.谁都可以执行，无门槛4.资料集中，查阅方便 运维领域现状-传统AIOps的缺陷 •运维团队积累的专家经验很难编码到算法模型中。通常，这些经验会被简化为阈值或复杂的规则，不仅难以维护，也难以传承。 如何打造运维检查单？ •接入和维护成本高，需要业务和算法团队深入理解业务逻辑和算法模型。•未遇到过的故障很难被解决，因为它们超出了模型的训练范围。•方案需要用户理解模型并精确地传递参数 可落地的协同处理流程 建立故障处理流程；高效协同多个组织； 可落地的协同处理流程 建立业务高峰期预防应急机制。 应急止损方法论——应急止损 应急止损方法论——排障树 基于大语言模型的根因诊断（RCA）Agent框架 我们定义了一些工具和插件，这些工具和插件是用于出现故障时进行检测。除了工具和插件，我们还设计了工作流编排，可以自动化的故障处理流程。此外我们构建了一个知识库，它包含了历史故障数据、专家经验和故障处理策略，这些都是进行有效根因分析的关键资源。 基础工具的构建 将传统的针对多模态运维数据的异常检测方法变成工具（Agent），用户仅需维护指标项即可。 比如我们定义变更查询工具，该工具可以用于确定问题是否由线上变更导致。这样的工具有很多，一般都是基于运维专家日常的排障经验，可以是一个简单的脚本，也可以是一个API，或者是一个命令，这些工具可以完成故障排查过程中某一个环节的任务。 工作流的构建 构建工作流，我们在prompt和文档中预先设置了不同报警的分析流程，即应该先后检查哪些数据，从而得出结论。 这个工作流类似飞机检查单（SOP），不同的现象对应不同的检查项，类似一个树状结构，最终一定会递归找到一个叶子节点然后返回。比如当某个域名出现5xx状态码报警，我们需要先判断这些状态码是否来源于同一个用户的请求，再判断这些请求是否都打到了同一个upstream节点，后端承载流量的微服务、容器和node是否存在问题，最后再检查是否是第三方依赖存在问题等。 这是一种妥协方案，我们可以选择对通用大语言模型进行训练，十七能够根据用户的SOP文档直接生成工作流，但是大模型训练的成本是非常高的，一方面是资源成本，另一方面是对大模型人才需求的成本。 具体实现/技术实践PART 04 数据治理——CMDB建设 将资产标签化，将标签目录化，得到完整的产品六级目录，既有业务信息，又有资产实例的关联关系，每种资源都拥有自己的身份证号：六级目录。这是AIOps落地的基石。 数据治理——监控统一 来源于不同监控工具的报警必须满足最小字段集合，这样以来所有的报警都能标准的关联到具体的业务、产品，从而关联出所有的资源、中间件等信息。同时我们也完成了CMDB的自动化维护，形成了包含业务、基础资源、人员、代码仓库、配置等关联关系的大型数据字典，本身也为webUI提供了许多API，这些API都将作为Agent被注册。 数据治理——监控统一 SOP定义——专家经验的沉淀 针对每种现象，我们都梳理了运维专家的排障脑图，将故障排查过程固化下来。 根节点表示现象（报警），分支节点代表一个分析操作，每个分支节点会再分化出是和否两个分支，直到最外围的叶子节点，无法再进行下一步分析为止。外围节点会有两种状态：根因和非根因 工具构建之查询类Agent 查询类Agent融合了CMDB（产品、应用、资源的关联关系）、IT资产清单、CICD配置、config数据的查询。查询类Agent的还包含了历史故障单的查询，让AI具备寻找历史相似事件的能力。 工具构建之动作类Agent 动作类的Agent就是前文提到的，对于排障脑图中某个具体节点的对象的分析过程，我们可以非常原子化的进行这些Agent的定义，比如下面是我们定义的一些Agent 流程编排 流程编排 效果升级 降低编码的复杂性和成本输出 实际运用 我们目前已经实现了所有线上报警的自动分析，目前根因的召回率已经超过了50%，随着Agent和流程编排的完善，召回率还会逐渐提升。 对于成功召回根因的报警，机器人会自动关闭报警工单，同时支持钉群交互，形成闭环。 RCA效果展示 我们更进一步的尝试 总结与展望PART 05 方案总结——望、闻、问、切 本方案通过构建根因排查逻辑树、建立统一的报警字段集规范，建立多模态Agent集合，充分调度AI大模型文本推理的能力，对报警通知、报警事件单和根因分析过程进行了整合，实现了报警的自动化分析，整体耗时在1分钟以内，对于90%常见的报警都能分析出根因所在，即便是10%的不常见报警，也能完成分析过程，运维人员无需重复分析，为应急止损和故障定位争取了更多时间，保证了业务稳定性。 大模型时代，做AI的主人 大模型技术诞生之后，已经颠覆了IT从业者的工作和思维习惯，大家的技术水平差距已经被大模型抹平了，而善于思考，能把问题想明白变这个事情，变得更加重要了。 其实用大模型技术完成推理+检索实现RCA应用的过程，其实就是在prompt或者知识库中定义了各种if else的逻辑，理论上只要能说得清的逻辑，就可以通过传统编码的方式实现，我们为什么要承担AI大模型偶尔“一本正经胡说八道”的风险？ 把问题想明白说清楚>专业技术强大 我们接下来会做的事情 •更多工作流：让AI串联更多工作流程，比如监控、巡检、故障止损、智能容量预防、智能风险识别等 •工作流插件化：让这些工作流变成插件，从而可以在大模型应用中进行调用•大总管的模式：面向对话框工作，所有的交互不再需要设计webUI，也不再需要设计问题，简化开发的过程，充分释放AI的能力 未来的发展趋势 关键词：全文检索、逻辑推理、低代码 目标： 1、基于大模型的，减少知识获取难度2、利用大模型擅于汇总、总结的能力 THANKS