一
背景
在日常运维工作中，我们常常会遇到各种线上故障。如何快速识别这些故障的原因，对于我们来说非常重要，因为这直接决定了我们应采取何种止损措施。特别是对于我们来说，每当故障持续一分钟，就会对用户的实际体验造成影响。因此，快速的故障定位对我们至关重要。
随着人工智能的迅速发展，大模型已成为最具影响力的AI技术之一，它也逐渐呈现出百家争鸣的盛景，各行各业都在使用大模型来重塑它们的行业，提升他们的工作效率，那么有没有可能利用大模型技术来帮助我们提升故障定位的效率呢？
二
现状
故障定位是保障系统稳定运行的关键环节。在日常运维中，及时准确地发现并解决故障，可以有效降低系统停机时间和业务损失。当发生线上故障的时候，导致的原因有很多，例如线上变更、节点过载或节点故障、依赖方出错、代码程序报错等。如果所有线上故障都依靠人力来定位，会存在很多问题，很难做到短时间内快速定位。
告警信息多而杂
目前智能学习配置了很多监控告警，当发生线上故障的时候，SRE运维监控告警群通常会收到大量告警信息，这些告警信息可能零散地分布在不同的群组内，给故障定位带来了挑战。
重复性的工作
当发生SLA可用性告警的时候，SRE运维伙伴的动作经常是重复性的，第一步检查最近是否发生变更，第二步检查线上关联的应用Pod的状态如何等等，这个过程既繁琐又低效。
信息不对称
告警处理过程中，当收到相同告警信息的时候，由于值班伙伴先前经验的不同，所以处理时间可能会延长。
三
智能学习在故障定位中的实践
3.1
大模型相较于人的优势
3.1.1 海量数据处理与分析
大模型：可以高效处理和分析海量的运维数据，包括日志、监控数据、告警信息等，从中提取有价值的信息和模式，并针对信息实现快速整合
人力排查：虽然有经验的运维人员也能分析数据，但面对海量数据时，效率和准确性远不及大模型。
3.1.2 标准规范化
大模型：使用的是统一的逻辑处理流程，确保在处理相似问题时，操作和响应是一致的。无论数据来源、数据量还是复杂程度如何，大模型都能按照设定的标准流程进行处理和分析。
人力排查：不同运维人员的经验和技能水平差异，会导致问题分析处理上的不一致。
3.1.3 处理速度
大模型：通过自动化的方式执行复杂的运维操作，减少了手动干预和操作步骤，全面覆盖全天候无间断工作，大幅提升了问题的响应和处理的速度。
人力排查：需要手动执行各类操作和数据分析，流程繁琐且耗时较长，效率执行速度比较慢。
综上所述，大模型在排查速度上具有显著的优势，通过智能化、自动化、实时化和高效化的排查流程，大幅提升了运维管理的效率和故障解决速度，而依赖人力的传统方法在排查速度方面存在明显的局限性。
3.2
建立在大模型之上的Agent
大模型Agent是一种构建于大语言模型之上的智能体，它具备环境感知能力、自主理解、决策制定及执行行动的能力。它能够模拟独立思考过程，灵活调用各类工具，逐步达成预设目标。在技术架构上，Agent从面向过程的架构转变为面向目标的架构，旨在通过感知、思考与行动的紧密结合，完成复杂任务。
3.2.1 基于Function Call 的数据源获取
在运维场景中，使用大语言模型调用工具具备很大的应用潜力。通过理解和拆分用户意图，模型能够编排并调用不同的工具，实现各个运维场景的统一集成。例如，在运维场景中，我们可以定义一系列工具用于辅助我们快速获取线上的数据，及时了解近期数据变化情况。
如下图，以智能学习为例，我们定义了多个工具来辅助我们进行日常运维工作，例如：查询近期线上应用变更行为、查询近期Ingress变更行为、查询近期网关节点状态、查询近期网络告警以及查询第三方依赖的组件告警等工具。
当我们向大模型提出问题：帮我检查最近线上节点状态如何？这个问题就会传递到大模型中，大模型通过分析我们提前定义好的多个工具的描述信息，找到更符合我们问题的工具函数searchNodeStatus，通过执行该工具并获得返回结果。最后将工具的返回结果交给大模型整合分析之后回答我们刚开始提出的问题。
3.2.2 CoT思维链
什么是思维链？
真正让大模型逼近“语言智能”，在于大模型展现出的强大的概念推理能力。推理，一般指根据几个已知的前提推导得出新的结论的过程，区别于理解，推理一般是一个“多步骤”的过程，推理的过程可以形成非常必要的“中间概念”，这些中间概念将辅助复杂问题的求解。通过让大模型逐步参与将一个复杂问题分解为一步一步的子问题并依次进行求解的过程可以显著提升大模型的性能。而这一系列推理的中间步骤就被称为思维链。
对比传统提示词的直接推理
以解数学题为例：
可以看出来，模型的回答结果是错误的，这个过程是比较黑盒的。但如果说，我们给模型一些关于解题的思路，就像我们在数学考试中，都会把解题过程写出来再最终得出答案，不然无法得分，让我们再看看模型的能力。
可以明显看到模型给出的结果不仅正确，而且还给出了推理步骤。
提示词CoT+Agent
上面提到我们创建了一个Agent，并且为Agent定义了一系列的工具，如果直接将告警信息交给Agent，那么它就能进行工作吗？答案是否定的。
我们尝试过直接将告警信息交给Agent，但是发现Agent确实会调用工具，但是如果遇到某一个工具执行出错之后，他会认为这个工具调用失败，就会重新调用这个工具，从而导致死循环，直到token超出限制而退出程序。
其次，对于有调用顺序的工具，Agent也不能很好的理解这些工具的调用顺序，以智能学习SLA告警分析为例，我们首先获取到SLA的告警信息之后，需要提取出告警信息中的域名和url然后将域名和url作为参数传入查询应用详情的工具中来查这个域名与url对应的是哪个应用，第二步拿到第一步查到的应用名作为参数去调用查询pod状态的工具检查这个pod最近是否发生pod漂移以及pod重启。这个过程中就需要先调用查寻应用详情的工具，然后再将第一步查询到的应用信息作为入参传入查询pod状态的工具中，如果顺序颠倒势必会导致程序执行过程报错，给程序带来太多的不稳定因素。
面对上述遇到的问题，我们想到了通过提示词CoT来保障Agent执行过程的顺序性，以及执行过程的稳定性。实现方式比较简单，就是在Agent执行之前我们嵌入提示词告诉它如何利用工具来分析告警信息和工具的执行步骤，以及故障定位根因的判断方式。如下图就是智能学习在故障定位过程中我们给出的分析步骤以及分析思路。
下图则是大模型给出的分析思路：
3.3
基于RAG技术的过去标注查询
RAG是指检索增强生成。检索指的是检索外部知识库，增强生成指的是将检索到的知识作为提示词送给大模型以此来优化大模型的生成结果，使得大模型在生成更精确、更贴合上下文答案的同时，也能有效减少产生误导性信息的可能。RAG工作流程包括三个关键步骤：首先，将长文本文档划分为离散块，然后使用编码器模型构建向量索引。其次，RAG根据查询内容转化后的向量和索引块的向量相似性来识别和检索块。最后，将检索出来的块通过大模型来合成一个响应。RAG的关键优势在于它不需要为特定任务重新训练LLM，开发人员可以添加外部知识库，丰富输入并从而改进模型输出精度。
过去，我们的SRE团队在处理故障时经常遇到重复性问题，导致故障定位和解决过程非常耗时且低效。为了解决这一问题，我们引入了故障标注系统。该系统记录每次告警的信息以及人工标注的故障原因。当类似告警再次发生时，它能基于历史数据给出可能的告警原因，从而提高处理效率，并帮助我们优化整体系统的稳定性和可靠性。
如上图：其中包含date、sla、root_cause_analysis、人工标注。date表示告警发生时间、sla表示告警信息、root_cause_analysis表示大模型故障定位分析的结果、人工标注表示导致告警产生的实际原因，需要我们运维值班伙伴进行手动标注。当告警发生之后，大模型会将告警信息作为输入去标注库中进行RAG检索，从而查找过去发生此类告警的人工标注原因。这将提示运维伙伴进行故障定位的方向。
3.4
基于RAG+CoT的架构
当前架构主要采用单Agent+多工具调用的方式来获取故障发生前的线上的一些状态，通过大模型强大的数据分析能力给出故障告警原因，同时通过搭配故障标注系统去检索分析过去面临相同告警的原因，辅助运维伙伴快速定位。
3.5
架构流程解读
以智能学习SLA告警故障定位分析场景为例，我们针对它提供的提示词为：
第一步从告警信息中提取域名与url，查找该域名与url对应的应用信息。
第二步从第一步中拿到应用的名称作为输入检测该应用在最近一段时间里是否pod状态如何。
第三步检查最近一段时间是否发生了线上变更，如果与告警时间相近，很大概率是变更导致的。
第四步检查网关/ingress节点是否出现节点异常或节点过载的行为。
第五步检测线上最近是否发生了网络告警。
第六步检测线上是否发生了三方依赖的组件告警。
第七步从标注系统中检测过去该告警信息的人工标注的原因。
整合各个步骤的结果，综合分析导致本次告警的原因是什么。
（1）系统通过定时任务检测SLA告警源，如果查询到最近存在告警信息，则将告警信息抓取下来，并与我们提前定义好的CoT提示词一起交给Agent处理。这一步确保系统能够实时响应并捕捉到最新的告警信息。
（2）Agent在接收到告警信息和上述CoT提示词后，大模型首先基于提示词做出整体规划，按照规划的步骤依次调用工具来获取线上数据。
（3）大模型先从告警信息中提取出告警的域名和url，然后调用查询应用详情的工具，利用未来云的线上接口查询到该域名与url对应应用的详细信息。
（4）接着大模型调用检测pod状态的工具，利用未来云线上接口，将刚刚查询到的应用名称，作为检测pod状态工具的入参，来查询该应用所有pod最近状态如何，是否出现异常。
（5）然后大模型调用变更检测工具，利用服务树变更事件的接口，查询最近一段时间内的线上变更情况。并且对比变更时间和告警时间，如果时间点相近，则变更的可能性较大。
（6）然后大模型调用检测最近是否存在网络告警的工具，利用哮天犬提供的接口通过taskid查询到最近一段时间是否发生了网络告警。同理查询三方依赖组件告警的工具也是依赖哮天犬taskid来获取最近告警信息的。
（7）大模型通过调用检索过去的标注信息的工具，从标注系统中利用RAG技术检索过去的标注信息来了解到过去面对相同告警信息的时候可能的告警原因是什么。
（8）整合这些告警结果，综合分析导致此次告警的原因是什么，然后将最终模型分析结果一方面通过机器人webhook与secret的方式推送到群聊内，另一方面通过插入故障标注系统进一步落库存储，等待后续人工标注，以此来不断优化第七步RAG的检索效果。
如下图：是智能学习在故障定位过程中，大模型依据线上数据分析的结果。
四
架构升级
4.1
当前架构存在的缺陷
1、单Agent在工具调用的过程中存在token的限制，当Agent在调用过程中使用的工具越来越多，消耗的token就会越来越大，执行过程中很有可能因为token消耗过大导致程序执行出错。
2、单Agent后期管理的工具越来越多，如果每个工具的功能描述存在语义类似，势必会导致调用工具的过程中调用非预期的工具。
3、当前架构定时通过哮天犬获取告警信息，由于定时就导致存在一定的延时性，增大故障定位的执行时间。
4、通过标注系统进行RAG检索，然后将检索结果交给大模型来处理这个过程比较黑盒，缺乏一定算法的支撑。
4.2
升级后的架构
这里面可以将Supervisor理解为一个大脑控制中心，主要负责接受告警信息与用户定义的CoT提示词步骤。这里面的Team表示团队，它是由同类任务的代理所构成，比如检查变更的任务：可以由检查网关变更的Agent、检查ingress变更的Agent、检查应用变更的Agent等组合成一个团队。在故障定位过程中通过各个Team之间彼此相互配合共同完成故障定位分析的过程。
五
未来展望
随着大语言模型的发展，传统运维故障定位中的许多痛点将得到显著解决。LLM具备强大的数据整合与分析能力，能够从多种数据源中提取有价值的信息并进行智能化处理，从而大幅缩短故障定位时间。此外，通过设计多Agent系统，LLM还能模拟资深运维专家的诊断过程，提供实时、精准的建议和解决方案，弥补团队经验不足的缺陷。
可以预见，在不久的将来，LLM在运维故障定位中的应用将不仅显著提升问题解决的效率，还会推动运维领域向智能化和自动化的发展方向迈进。这将实现从被动响应问题到主动预防问题的转变，最终构建更加可靠和高效的IT运维体系。
