大语言模型加持，是智能运维架构的未来吗？

在 QCon 北京 2024 大会上，字节跳动技术专家王宁，根据自己在字节的实践经历，发表了题为《SRE－Copliot：基于大语言模型的智能运维架构》的演讲。

本文由 InfoQ 整理，经王宁老师授权发布。以下为演讲实录。

随着大语言模型的广泛应用和能力的提升，许多团队都在尝试利用大语言模型来改进他们所在行业的应用，我们团队在字节跳动内部也在探索如何将大语言模型与 AIOps 实践相结合。

去年，我们带着 SRE-Copilot 框架参加了 AIOps 2023 挑战赛，并荣幸地获得了冠军。在比赛中，我们设计了一套更为开放和富有想象力的框架，进行了初步的探索。

比赛的题目是开放性的，旨在鼓励大家尽可能地探索大语言模型在智能运维领域的应用潜力。选手面临的挑战是帮助企业运维团队应对日益庞大的系统规模、复杂的系统结构以及日益增多的数据量。

比赛所用的数据来自中国建设银行“建行生活”APP 中的真实模拟数据。比赛的架构设计模拟了从入口负载均衡集群到中间的基础集群，如抢券集群和订单集群，这些集群之间相互依赖。此外，还包括了出口负载均衡集群，并且依赖许多复杂中间件如 Redis、MySQL、Kafka 等的各个集群。

我们在比赛中获得的数据包括调用链数据、业务黄金指标，例如订单成功率、抢券成功率，系统交易的每个订单的延迟时间，以及集群的性能指标，不仅涵盖了基础集群，还有中间件集群的监控数据，如 CPU 负载、常见的出入网流量，系统日志数据等。

随着系统日益复杂和数据量的增加，即使是专业的运维团队也难以全面掌握所有技术细节。在大型企业中，每个组件，如计算、存储、数据库，都可能需要专门的运维团队。当出现大规模故障时，通常需要所有团队协作来定位问题根源。而 SRE-Copilot 框架可以通过大语言模型的能力，学习和模拟不同团队的运维知识，以解决整个链路上的技术问题。

传统的 AIOps 在异常检测和根因分析上严重依赖于标注数据，这限制了算法的泛化能力，因为它们需要在有监督的环境下进行训练。而大语言模型能够学习更多的通用知识，减少对标注数据的依赖，从而降低训练成本。

运维团队积累的专家经验很难编码到算法模型中。通常，这些经验会被简化为阈值或复杂的规则，不仅难以维护，也难以传承。SRE-Copilot 框架通过大语言模型，将专家经验转化为模型可以理解和推理的形式，从而提升了故障处理的能力。

传统 AIOps 的接入和维护成本较高，需要业务和算法团队深入理解业务逻辑和算法模型。此外，私域数据的处理和定制化开发也增加了成本。SRE-Copilot 框架采用集成学习的概念，通过模块化设计，使得系统能够像搭积木一样动态编排。

在传统 AIOps 中，未遇到过的故障很难被解决，因为它们超出了模型的训练范围。大语言模型展现出了强大的推理能力，能够基于通用知识和训练中学到的关键字，推断出未知故障的性质，即使没有相似的训练数据。

传统的 AIOps 解决方案需要用户理解模型并精确地传递参数，而 SRE-Copilot 框架支持自然语言交互，使得非技术用户也能轻松地与系统交互，提高了用户体验，并有潜力开放给更广泛的用户群体。

SRE-Copilot 框架，采用了基于 function call（函数调用）的方法来实现多功能的智能运维。

我们首先将 SRE 在日常运维中可能遇到的多种场景进行了统一收敛，通过大语言模型来理解用户的意图。无论是进行运维可视化还是故障分类，我们的目标是编排不同的工具，以实现一个多场景的智能运维解决方案。

在比赛上，我集成了一些简单的场景，虽然每个场景本身并不复杂，但我们尽可能探索了许多新的场景，以测试和展示 SRE-Copilot 的多功能性。比如我们实现了故障分类功能，并让框架能够生成故障自愈的代码，以自动化处理常见的问题。

我利用大语言模型生成了一个排查故障的工作流，并以自然语言的形式呈现。

根据提前设定的 Agent，模型会匹配并确定哪些 Agent 能够在排障工作流程中发挥作用，然后将这些 Agent 编排成一个可执行的工作流。我可以通过自然语言向模型提问，比如询问特定时间段内的问题。模型会提取相关参数，并动态地将任务分配给相应的子 Agent。每个子 Agent 会检查自己的数据，寻找故障迹象。

例如，调用链 Agent 会检查调用链是否存在问题。如果检测到 CMDB（配置管理数据库）中的信息，模型可以进行下钻操作，比如定位到具体的集群，然后触发下一轮更深入的检测。如果没有更多的信息，模型会开始进行根因诊断，检索历史故障和专家经验，以此来判断当前的故障类型，比如磁盘写满。

在诊断过程中，我会将相关指标进行可视化展示，帮助理解故障的性质。根据诊断结果，我会生成清理磁盘的简单代码。如果是线上执行，模型会匹配预设的自愈方案。每次故障诊断完成后，会自动生成告警总结和复盘报告。诊断的故障信息会自动积累下来。如果用户对诊断结果进行确认，那么这个故障案例就会被记录到历史故障库中，供模型未来诊断时参考。

在比赛的复现过程中，我们在建行云的 8 核和 16G 内存的堡垒机上进行了演示，并使用了一张 V100 显卡。实际上，我们仅使用了开源的 ChatGLM 6B 的小模型，就实现了上述效果。

在 SRE-Copilot 架构中，Tool calling 是指将大语言模型与外部工具有效结合或交互的能力。这种机制允许模型解决它自身无法直接回答的问题，因为它可以调用外部工具来获取所需的信息。

以询问天气为例，大语言模型本身无法提供实时天气信息，因为它缺乏对外部环境的感知。为了解决这个问题，需要设计一个封装用户问题的方法，并提供一个能够获取当前天气的接口工具，再通过一些描述指导模型使用接口。

例如，接口可以根据给定的地点查询天气，它是一个 function，需要两个参数：地点（location）和温度单位（如摄氏度或华氏度）。成熟的大语言模型，如 ChatGPT 或文心一言，通常都是通过相似的训练方法来实现这一机制。模型会调用适当的函数，并且能够从用户的问题中提取出必要的参数。假设用户询问的是伦敦的天气，模型会自动将“伦敦”作为 location 参数补全，并指导调用天气查询接口，从而提供准确的天气信息。

SRE-Copilot 架构中的另一个重要概念是检索增强生成（Retrieval-Augmented Generation，简称 RAG）。RAG 结合了搜索技术和大语言模型，旨在解决几个关键问题。

首先，它可以帮助处理私域知识，例如公司内部服务器的状态或特定订单的详情，这些信息是大语言模型无法直接感知的。

RAG 能够解决新知识的问题。以电影为例，如果模型的知识截止日期是 4 月，那么它不会知道 5 月上映电影的主演是谁。同样，对于当天发生的新故障或新闻，模型也无法感知。

RAG 也适用于长尾问题，即那些在模型训练时不常见或非常具体的问题。例如，如果用户需要编写某个小众语言的代码，或者询问关于特定数据库连接的问题，尤其是当这个数据库是公司内部改造过的，传统的大语言模型可能无法提供答案。为了解决这些问题，可以利用传统的检索方法，比如搜索公司内部文档，查找是否有关于特定语言连接数据库的 QA 文档。一旦检索到相关文档，我会将文档中的相关内容与用户的问题一起输入给大语言模型，以便模型能够提供一个更准确的答案。

ReAct 概念针对的是那些无法仅通过一步查询或大语言模型自身直接解决的任务。这些任务通常需要多步骤的执行，并且每一步都需要模型提供其思考过程，以减少模型产生幻觉现象的风险。

通过 ReAct，我们可以将任务的每一步规划和执行可视化。例如，如果任务是让大语言模型去厨房做菜，模型可能会首先思考需要哪些调料，并预测它们可能存放的位置。比如，模型可能会推断出胡椒可能在 1 到 6 号柜子里，或者 1 到 3 号台面上。模型首先会选择检查第一个柜子，如果没有找到胡椒，它会根据这一步骤的结果，决定下一步检查其他柜子。

再比如，当用户询问 GitHub 上某位开发者获得的点赞数并想要得到该数值除以 2 的结果时，模型的第一步是通过 GitHub 的 Open API 获取点赞数，然后使用计算器工具进行除法运算，通过这两步操作来得到最终结果。

ReAct 概念旨在通过分步骤地规划，并在每一步中进行合理的推理和决策，来执行越来越复杂的任务。

智能体主要由三个部分组成：

1. 大脑：最核心的部分是大语言模型，它扮演着智能体的大脑角色，负责处理和生成语言输出，同时整合和利用知识库中的信息。

2. 感知：智能体的第二部分是它的感知能力，这涉及到使用外部工具来感知图片、声音等信息。通过这些工具，智能体能够与外部世界进行交互，获取必要的数据。

3. 行动：智能体还可以通过计算 API、查询 API 等工具进行实际的交互操作，执行真实世界中的行动。这使得智能体能够处理更为复杂的任务，如根据图片内容推断位置并查询当地天气。

我们期望实现的是多个智能体之间的复杂交互，让智能体不仅能够独立工作，还能够相互协作，共同解决更加复杂的问题。

在 SRE-Copilot 框架的具体实现上，我根据比赛时提供的数据，在最底层为每个数据源设计了相应的 Agent。这些数据源包括日志、调用链、交易类型数据、主机监控数据以及 CMDB 数据等多元数据类型。对于每种类型的数据都设计了一个 Agent，使其能够进行异常检测、数据可视化，以及查询历史故障和返回故障描述等操作。

在底层 Agent 之上，我定义了功能型 Agent，它包括知识库问答、工作流规划、故障报告编写和代码生成等能力。这些功能型 Agent 能够基于 ReAct 框架，调用底层的子 Agent，并动态地编排它们的执行顺序和结果。

在框架的最顶层，我设计了一个名为 Copilot 的智能体，它作为与人类用户交互的核心。Copilot 负责识别用户的意图，判断用户是想要获取答案还是进行故障诊断，并从用户的问题中提取出相关参数。

例如，用户可能询问某个具体时间段的情况，Copilot 可以将这个时间段作为参数传递给后续的处理流程。随着大语言模型的智能化，它甚至能够理解并处理如“过去 15 分钟”这样模糊的时间段，并将其转换为具体的参数。顶层 Copilot 还能够进行任务分配和 Agent 之间的协调工作，确保整个框架能够高效地响应用户的需求。

在设计 SRE-Copilot 框架时，我借鉴了 GPT 背后的集成学习思想。我们的目标并不是开发一个庞大而全面的模型来解决所有问题，而是通过集成多个专精于特定领域的子 Agent 来实现。每个子 Agent 都在其专业领域内表现出色，我们采用混合专家系统（Moe, Mixture of Experts）的形式，使整个系统的效果更加完善和高效。

首先介绍一个异常检测场景，以下是我们在这个场景中定义的角色：

1. Copilot 主持人：作为核心，Copilot 负责解析用户需求，制定运维计划，并安排不同 Agent 执行具体任务。

2. 多数据源 Agent：针对不同的数据源，如日志、调用链、交易类型数据、主机监控数据以及 CMDB 数据，我们设计了专门的 Agent。这些 Agent 利用合适的算法对各自模态的数据进行异常检测和检索。

3. RCA Agent：该 Agent 负责收集其他 Agent 的检测结果，并执行最终的根因分析推理。

以 Copilot 为起点，例如，当收到用户关于 9 月 18 日下午 4 点大量交易失败的请求时，Copilot 会识别这是一个根因诊断问题，并将任务交给 RCA Agent。

RCA Agent 会关注用户请求中的关键信息，如交易类数据，并将其传递给交易类型 Agent 进行初步检查。该 Agent 将返回关于交易量同比下降的结果，但不提供额外信息。

根据初步检查结果，系统会动态调度其他 Agent 检查各自负责的组件是否存在问题。例如，当轮到第五个 Agent，即调用链 Agent 时，它发现了调用链上的异常情况。调用链 Agent 的反馈将引导 CMDB Agent 在 CMDB 中查询接口的调用记录，上游下游关系，以及接口的具体问题。

通过这种方式，我们模拟了真实线上云平台中多个组件之间的协同定位过程。整个异常检测过程完全自动化，没有一个固定的流程，而是根据每个 Agent 的检测结果动态地调度其他 Agent，共同完成异常检测任务。

有了上一步的异常检测结果，接下来需要对这个异常检测的结果做根因定位，或者说故障的分类。

首先，获取异常检测组件的结果，并对其进行了一些调整，使其返回的不仅是传统的 true/false 或 JSON 结构体，而是大语言模型和人类都容易理解的自然语言描述。例如，异常检测结构体可能会返回：“本次故障持续了 10 分钟，CPU 指标飙升，内存也被打满，某某接口出现了大量失败”。

然后，这个故障工单会转换成向量，并在提前构建的向量数据库中检索。向量数据库包含两部分内容：一部分是提前配置的专家经验，另一部分是历史上遇到的相似故障记录。例如，如果历史上遇到过内存打满的问题，通过重启服务解决了问题，这样的专家经验会被记录在系统中。

在当前故障检测时，系统会同时检索出相关的专家经验和历史故障信息。通过 RAG，将当前故障描述、专家经验和历史故障信息一起输入给大语言模型，进行根因推断。大模型会根据提供的信息推理，例如，这是否是内存打满的问题，是否需要通过重启服务来解决。

RAG 方法可以帮助大语言模型不断地更新其知识库，适应新的故障情况，同时减少模型的幻觉现象。通过引入历史故障数据和反思机制，模型的准确率得到提升，幻觉现象得到降低。即使在没有提前配置专家经验或历史故障数据的情况下，使用的 6B 大小的模型（如 ChatGLM 3）仍能够对某些类型的故障做出准确的推理，如磁盘写满或 Java GC 问题。

字节跳动内部的目标是先将基于大语言模型的根因诊断（RCA）Agent 框架落地应用，因为根因诊断是 SRE 团队面临的一个主要挑战，它占用了大量的时间和精力，日常的 On Call 问题定位也给团队成员带来了沉重的负担。我们希望专注于解决这些实际问题，真正缓解 SRE 同事的痛点。

我们定义了一些工具和插件，是在出现故障时用来进行检测的工具。除了工具和插件，我们还设计了工作流编排，以自动化和优化故障处理流程。我们构建了一个知识库，它包含了历史故障数据、专家经验和故障处理策略，这些都是进行有效根因分析的关键资源。

构建知识库方面所做的工作主要包括以下几个部分，并且我们计划未来会引入更多用户原始文档、历史 On Call 记录等不同类型的数据。

排障专家经验： 这部分是根据根因诊断的场景特别设计的，目的是让业务团队的成员能够管理和记录他们的知识和经验。我们定义的每一个经验都是一组根因故障，包括故障发生时的描述和一些止损措施的组合。这些信息将被用来训练大语言模型推理。

例如，流量突增导致的故障，其根因可能是用户 QPS 的突增。故障的表现可能是流量首先突增，随后内存和 CPU 使用率也跟着上升，最终导致服务不可用。这种描述将帮助模型理解故障模式。对于上述故障，可能的止损措施包括重启服务或进行扩容操作。

故障场景 SOP 文档：我们希望用户输入的是一些 SOP 文档。这种方式给组件团队提供一种灵活管理知识的方法。我们选择这种半规范化文档的形式，是因为当前大语言模型的能力还有局限，需要通过文档梳理来帮助模型更好地理解。

历史故障信息：我们还维护了一个历史故障信息库，记录每一次通过大语言模型检测到的故障，这些记录会用来对组件团队进行训练和打标。

在构建 SRE-Copilot 框架的基础工具方面，我们参考了 OpenAI GPTs 将工具集成到平台时所遵循的规范。我们将运维场景中的一些关键指标和基础工具进行了统一管理，把传统的异常检测方法统一成一个工具，用户只需要维护他们需要进行异常检测的指标即可。

用户可以自定义检测项，包括指标名称、指标的标签或指标描述，以及定义何为异常表现。因为是用户自定义的工具，所以可以根据具体需求设置检测标准。

我们实现了一个变更事件查询工具，当出现故障时，用户可以通过调用这个接口来确定是否由线上变更导致。我们在平台上部署的组件配置了一些工具，例如异常检测、变更和事件查询等，还包括了自然语言的意图理解和大语言模型的根因推理功能。

关键的根因推理功能基于大语言模型。在实践中，我采用了一种新的方法，不再将故障数据压缩成向量空间进行聚类分析，而是利用大语言模型将故障映射到自然语言空间中，从而简化了故障分类过程。

例如，流量突增、内存升高和接口不可用等信息可以自然地描述为 QPS 问题。对于新出现的具有相同描述的故障，可以直接使用大语言模型进行分类，而无需计算向量空间中的相似度。

分类过程中会使用用户配置的专家经验和当前故障的检测结果。此外，工具还利用预定义的模板生成描述，并让大语言模型进行推断，而用户可以根据需要调整这些模板、专家经验和检测结果。

为了提高根因推断的准确性，确保检测项插件的描述足够具体，比如详细描述指标曲线的形态变化，以及变更检测组件提供的详细信息，如变更的范围和性质。这样的方法不仅提高了故障分类的效率，还能让大语言模型的推理过程更加精确。

下一步是构建工作流，目前这一过程仍然需要用户自行配置，这主要是由于大语言模型当前能力的限制所做出的妥协。

不过，我们正在探索一种新的方法，即允许用户在其 SOP 文档中预先设定工作流，例如，文档中可以指明首先需要检查哪些指标，以及根据这些指标的结果接下来应该检查哪些指标。

我们希望能够训练大语言模型，使其能够直接根据用户的 SOP 文档生成工作流。最终，SRE 团队能够向大语言模型提供一个简单的文档，甚至是未经格式化的文本，而模型能够根据文档中的指标或检测项动态地编排诊断步骤，并根据每一步的检测结果，智能地调度后续的执行流程。

我们在一些组件上进行了 RCA 的试点工作，实现了一些改变传统交互方式的效果。现在，用户可以通过提出模糊的问题来与系统交互，例如询问某个集群存在哪些故障，系统会自动识别并调用相应的集群诊断工作流。

完成诊断后，系统不仅能够将结果进行美化或封装，还能以卡片或自然语言的形式向用户直观展示。此外，在面对大规模故障时，系统能够自动解析故障群中的告警卡片信息或历史消息，判断需要诊断的参数，如特定集群和时间段，自动提取所需参数，并触发相应的诊断流程。

针对我们遇到的瓶颈，我认为未来需要继续在下面几个方向增强。

第一，我期望有越来越大、能力越来越强的通用大语言模型，因为随着这些模型能力的不断提升，在动态根因推理和每一步的动态决策上，它们的准确率和效果都将得到显著提升。

第二，我期待能够开发出更强大、更专业的模型，例如时序大模型或日志大模型，并将这些专业模型作为工具，供核心 Agent 调用。

第三，我正在探索是否能有更灵活的 Agent 框架，以支持多轮和更灵活的对话，比如让用户在排障过程中随时打断并提供关键信息，以此缩短故障排查的平均时间。实现多人或多 Agent 之间的真正协作。

第四，我期望 Agent 能在更丰富的场景 中应用，目前它们可以像实习生一样帮助进行简单的监控数据处理，未来随着模型和工具能力的增强，我希望它们能够发展到像初级员工或应届生那样进行一些简单的决策，甚至最终成为一个资深专家，能够自动诊断问题并执行高级决策。