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

《文吉-基于大模型的根因分析实战.pdf》由会员分享，可在线阅读，更多相关《文吉-基于大模型的根因分析实战.pdf（46页珍藏版）》请在三个皮匠报告上搜索。

1、基于大模型的根因分析实战文吉 畅捷通信息技术股份有限公司演讲嘉宾文吉十年以上SRE实战经验，特别是对ToB场景有丰富实战经验用友集团 P9高级专家多次对外分享，融合大模型能力升级智能运维荣获了信通院颁发的“稳定性优秀案例”目 录CONTENTS1.背景2.问题/痛点3.解决思路/整体方案4.具体实现/技术实践5.总结与展望背景PART 01畅捷通是做什么的？畅捷通信息技术股份有限公司是用友旗下成员企业，成立于2010年3月，于2014年在港交所上市，是中国领先的小微企业财税及业务云服务提供商。业务架构复杂C端用户量+B端客户体量要保障每个用户的体验业务迭代速度快畅捷通运维转型之路目标0-2-5

2、-10业务从自建机房逐步转向全面采用公有云容器化架构，为业务发展提供了更强大的基础，但同时也带来了运维复杂性的指数级增长。自建机房云计算虚拟化容器化手工操作资源利用率低部署和扩展速度慢不易实现弹性伸缩提高资源利用率简化部署和管理仍需手动配置和管理迁移到公有云或私有云平台实现弹性、灵活性和成本效益可根据需求快速调整资源实现更快速的部署弹性伸缩和持续交付提高开发和部署效率问题/痛点PART 02从一次飞机撞鸟说起2023年11月1日，旭日8409飞机起飞离地时，发动机遭遇鸟击。情况万分危急，关系到机上183人的生命安全。收集现象执行检查单做出正确决策总耗时7秒畅捷通运维面临什么样的压力？上给我退货

3、！发生故障时难以定位定位一个问题，需要：打开3-5个看板执行2-4次分析脚本90%的问题此时就能找到原因，耗时10分钟。但另10%的问题，才会产生大的故障，且往往难以定位原因无法快速判断爆炸半径怎么判断报警严重性？报警爆炸半径多大？是否正在处理？谁在处理？恢复了吗？畅捷通运维面临什么样的压力？客户不能等线上法复现迹可寻压解决思路/整体方案PART 03关键要素：检查单1.吸收了所有故障排查经验2.紧急时刻不需要思考3.谁都可以执行，无门槛4.资料集中，查阅方便运维领域现状-传统AIOps的缺陷运维团队积累的专家经验很难编码到算法模型中。通常，这些经验会被简化为阈值或复杂的规则，不仅难以维护，也

4、难以传承。接入和维护成本高，需要业务和算法团队深入理解业务逻辑和算法模型。未遇到过的故障很难被解决，因为它们超出了模型的训练范围。方案需要用户理解模型并精确地传递参数如何打造运维检查单？可落地的协同处理流程建立故障处理流程；高效协同多个组织；可落地的协同处理流程建立业务高峰期预防应急机制。应急止损方法论应急止损建立应急止损操作流程和工具。应急止损方法论排障树建立故障排查的专家经验排障树。基于大语言模型的根因诊断（RCA）Agent 框架我们定义了一些工具和插件，这些工具和插件是用于出现故障时进行检测。除了工具和插件，我们还设计了工作流编排，可以自动化的故障处理流程。此外我们构建了一个知识库，它

5、包含了历史故障数据、专家经验和故障处理策略，这些都是进行有效根因分析的关键资源。基础工具的构建将传统的针对多模态运维数据的异常检测方法变成工具（Agent），用户仅需维护指标项即可。比如我们定义变更查询工具，该工具可以用于确定问题是否由线上变更导致。这样的工具有很多，一般都是基于运维专家日常的排障经验，可以是一个简单的脚本，也可以是一个API，或者是一个命令，这些工具可以完成故障排查过程中某一个环节的任务。服务器资源瓶颈分析域名错误量upstream分布分析工作流的构建构建工作流，我们在prompt和文档中预先设置了不同报警的分析流程，即应该先后检查哪些数据，从而得出结论。这个工作流类似飞机检

6、查单（SOP），不同的现象对应不同的检查项，类似一个树状结构，最终一定会递归找到一个叶子节点然后返回。比如当某个域名出现5xx状态码报警，我们需要先判断这些状态码是否来源于同一个用户的请求，再判断这些请求是否都打到了同一个upstream节点，后端承载流量的微服务、容器和node是否存在问题，最后再检查是否是第三方依赖存在问题等。这是一种妥协方案，我们可以选择对通用大语言模型进行训练，十七能够根据用户的SOP文档直接生成工作流，但是大模型训练的成本是非常高的，一方面是资源成本，另一方面是对大模型人才需求的成本。具体实现/技术实践PART 04数据治理CMDB建设将资产标签化，将标签目录化，得到

7、完整的产品六级目录，既有业务信息，又有资产实例的关联关系，每种资源都拥有自己的身份证号：六级目录。这是AIOps落地的基石。数据治理监控统一来源于不同监控工具的报警必须满足最小字段集合，这样以来所有的报警都能标准的关联到具体的业务、产品，从而关联出所有的资源、中间件等信息。同时我们也完成了CMDB的自动化维护，形成了包含业务、基础资源、人员、代码仓库、配置等关联关系的大型数据字典，本身也为webUI提供了许多API，这些API都将作为Agent被注册。数据治理监控统一SOP定义专家经验的沉淀针对每种现象，我们都梳理了运维专家的排障脑图，将故障排查过程固化下来。根节点表示现象（报警），分支节点代

8、表一个分析操作，每个分支节点会再分化出是和否两个分支，直到最外围的叶子节点，无法再进行下一步分析为止。外围节点会有两种状态：根因和非根因工具构建之查询类Agent查询类Agent融合了CMDB（产品、应用、资源的关联关系）、IT资产清单、CICD配置、config数据的查询。查询类Agent的还包含了历史故障单的查询，让AI具备寻找历史相似事件的能力。工具构建之动作类Agent动作类的Agent就是前文提到的，对于排障脑图中某个具体节点的对象的分析过程，我们可以非常原子化的进行这些Agent的定义，比如下面是我们定义的一些Agent服务器资源瓶颈检查异常访问来源检查异常访问upstream检查

9、流程编排流程编排效果升级降低编码的复杂性和成本输出实际运用我们目前已经实现了所有线上报警的自动分析，目前根因的召回率已经超过了50%，随着Agent和流程编排的完善，召回率还会逐渐提升。对于成功召回根因的报警，机器人会自动关闭报警工单，同时支持钉群交互，形成闭环。RCA效果展示我们更进一步的尝试总结与展望PART 05方案总结望、闻、问、切本方案通过构建根因排查逻辑树、建立统一的报警字段集规范，建立多模态Agent集合，充分调度AI大模型文本推理的能力，对报警通知、报警事件单和根因分析过程进行了整合，实现了报警的自动化分析，整体耗时在1分钟以内，对于90%常见的报警都能分析出根因所在，即便是1

10、0%的不常见报警，也能完成分析过程，运维人员无需重复分析，为应急止损和故障定位争取了更多时间，保证了业务稳定性。中台服务A某服务访问变慢中台服务B应用服务C应用服务F应用服务G应用服务D应用服务E大模型时代，做AI的主人大模型技术诞生之后，已经颠覆了IT从业者的工作和思维习惯，大家的技术水平差距已经被大模型抹平了，而善于思考，能把问题想明白变这个事情，变得更加重要了。其实用大模型技术完成推理+检索实现RCA应用的过程，其实就是在prompt或者知识库中定义了各种if else的逻辑，理论上只要能说得清的逻辑，就可以通过传统编码的方式实现，我们为什么要承担AI大模型偶尔“一本正经胡说八道”的风险？把问题想明白说清楚 专业技术强大我们接下来会做的事情更多工作流：让AI串联更多工作流程，比如监控、巡检、故障止损、智能容量预防、智能风险识别等工作流插件化：让这些工作流变成插件，从而可以在大模型应用中进行调用大总管的模式：面向对话框工作，所有的交互不再需要设计webUI，也不再需要设计问题，简化开发的过程，充分释放AI的能力我们接下来会做的事情未来的发展趋势XXX现在有问题吗？queryXXX当前有少量500状态码，都来自同一个用户的请求，结合历史判断目前正常关键词：全文检索、逻辑推理、低代码目标：1、基于大模型的，减少知识获取难度2、利用大模型擅于汇总、总结的能力THANKS