字节跳动系统智能运维实践 | DataFun大会分享回顾
The following article is from 字节跳动SYS Tech Author STE团队&DataFun
本文整理自字节跳动智能运维架构师王峰在数据智能大会上的分享，主要包括智能运维的前沿理念、规划路径、大模型的应用以及 AIOps 平台的实践应用。在本次大会中，重点分享了大模型在智能问答和故障诊断场景中的应用实践，通过 AIOps 平台，字节跳动成功实现了算法的快速迭代与部署，进一步提升了智能运维算法在各运维场景中的效率与实际应用能力。
作者：字节跳动 STE 团队 & DataFun 社区志愿者程思琪
智能运维前沿洞察
智能运维作为一种典型的人工智能技术与运维服务的结合领域，近些年取得了显著的发展。在呈现的图表中，左上方描绘了 2021 年 ~ 2023 年人工智能技术成熟度曲线的演变，智能运维相关的三项关键技术有明显的进展：一是生成式 AI，已经从技术萌芽期进入到了期望膨胀期的顶点，并且成为了各大技术会议和产品创新的焦点。二是ModelOps，它目前处于期望膨胀期和泡沫破裂谷底期边界处。三是自治系统（Autonomous System），它在 2023 年进入了技术萌芽期。
按照左下角描绘的 Gartner 在 2021 年发布的 AIOps 应用场景定义，大部分的智能运维领域的发展都是按照这一路线进行。右上角是 2022 年 OpsRamp 发布的一份研究报告，其中列出了运维场景中优先应用的前五大智能运维（AIOps）场景，包括：智能告警、根源分析、异常检测、容量优化和故障自愈等。OpenAI 发布的 ChatGPT 引发了整个行业对大型模型的研究与应用，ITOM 供应商无疑也在其中。从右下角的图表我们可以看出，许多国内外厂商已经开始提供结合 AIOps 和大模型的产品和服务，我们暂且称它为“AIOps+”。
2007 年图灵奖得主 Joseph 教授在 2018 年的一篇论文中提出了“自主系统”概念，可以看这个图包含四部分：感知，经验知识，决策和行动。这是一个自治系统的核心组成部分，与我们看到的自动驾驶在理论上是一样的。教授在论文中主要描述的也是自动驾驶场景。现在智能运维有了大模型的加持后，也可以基于这个自治系统的理论，探索和实现软件系统的“自动驾驶”。软件系统在出现故障后可以根据经验知识进行决策处置后实现自愈。后面在谈到大模型的 AI Agent 在智能运维场景的方案设计时大家对这个理论会有更深刻的理解。
如上图所示，运维可以划分为五个级别：从基本的运维脚本开始，经过工具化运维，平台化运维，数字化运维，最终迈向完全自动化的智能运维。在这个发展过程中，每一阶段均构筑于其前序阶段之上：运维实践经验被提炼成实用的运维脚本，这些脚本进而汇聚成为高效的运维工具；随后，这些工具演化为具备自动化处理能力的运维平台，并逐步推广至多算法协同工作的应用场景，直至达到能够自主做出运维决策的高度。在 AIOps（人工智能运维）体系构建的过程中，标准化扮演着核心基石的角色，缺乏标准化，不论是采用何种工具、平台或是 AI 技术，都难以根治运维领域中的痛点。当前，大规模模型所带来的变革与机遇正被广泛认知，这无疑为加速实现我们终极目标-第五级 AIOps 的实践应用提供了强劲的动力。
系统智能运维规划
在深入探讨系统智能运维的规划前，有必要先理解系统智能运维与其他运维类型之间的区别。此处的"系统"主要指应用层下面的基础设施，包括与服务器相关的操作系统，内核，驱动等系统技术栈相关软件。系统运维的主要目标是实现在快速交付服务器的同时，确保其稳定性。
由于基础设施上层的业务形态多样，对服务器硬件的需求也各不相同，进而导致系统软件需要相应适配。同时，随着业务规模的急剧扩张，需要交付的新服务器数量大增，如何在保证部署效率的同时维护系统稳定性，对我们来说是一大挑战。
此外，规模达到百万级别的数据中心，存在着众多的服务器配置和多版本的系统软件，保证快速交付的同时对这些存量版本进行有效管理亦是一项挑战。
重要的是，基础设施是支撑所有上层业务的基础，如果对基层设施的潜在风险没有有效管理，可能会影响到大量上层的业务。因此，日常运维工作中必须对运维操作进行严格的管控。实现全栈的高可用性需要各技术栈的紧密配合与协调，鉴于各层都有其专业性，因此通过系统化和智能化的手段整合专家经验，推动知识流转，构建智能运维体系，是一项重要的工作。
我们对系统智能运维进行了全方位的规划，以质量保障，效率提升和成本优化为三大业务价值，应用于运维场景。这是一份系统智能运维的全景规划图，共包含四层。
首先，是数据层。这一层包括运维系统采集的各种监控指标，比如告警记录、事件工单记录、变更记录等。这其中，领域知识和运维经验库构成了训练智能体的基础。
其次，是平台能力层。我们通过智能运维平台，一方面积累基础和通用的算法能力，另一方面则是通过平台提供的算法场景落地通用能力，来提升实施落地的效率。
第三层是算法场景。在这一层，我们针对基础设施运维场景，规划并实施了许多算法场景。例如，针对操作系统，我们能够通过智能 panic 原因分类来应对由 panic 引发的系统宕机。针对服务器硬件，我们可以通过预测磁盘、内存、光模块等硬件的故障以提前规避对业务的影响。针对数据中心的温度和电力，我们可通过算法对冷通道的温度上升进行预警，以及对水冷系统的水质进行智能检测以确保冷却效率。此外，还有面向系统和基础设施的常规异常检测和变更风险截断。这一部分场景除了已规划和实施的场景外，我们还在持续进行探索和完善。
让我们先来谈论一个传统的智能运维场景——预测内存故障。内存中的无法纠正的错误（Uncorrectable Error，简称 UE）可能导致服务器宕机，进一步影响运行中的应用。如果云上虚拟用户没有针对应用层做出高可用设计，业务就可能受到因内存 UE 导致的宕机的影响。因此，我们的策略主要集中在预防和修复方面。过多的可恢复错误（Corrected Error，简称 CE）在某些情况下可能会转变为无法恢复的 UE。因此，我们需要基于 CE 进行 UE 的预测，并通过软修复的方法修复这部分风险内存，以减少由于硬件更换而导致的关机。
在预测过程中，我们根据内存架构的分层特性进行分类处理，比如按照行（row）、列（column）、存储区（bank）等进行分类处理。对于与行相关的潜在问题，我们采用在线修复技术如页面脱机（page-offline）的方法，这样无需停机即可进行修复。而对于列或存储区的问题，我们提出维修请求服务工单，在完成服务迁移后进行硬件修复或采取软修复，以避免更换物理内存条。尤其在面向企业（ToB）的场景中，我们会为大客户进行虚拟机迁移，即使在弹性计算环境下，都能进行热迁移，以确保服务的连续性。如果无法进行软修复，将清空服务器，然后使用封装后修复（PPR）进行修复，再将其投入使用。数据显示，这种策略大大提高了服务器修复的效率，使集群内存故障的频率显著降低了约 60%，这验证了预测与修复策略的有效性。此类方法也可以应用于数据中心的磁盘和光模块的维护。
大模型Agent实践
目前，大家都在探索将大模型技术应用于智能运维场景。我们也进行了相关的尝试，并设计了一套面向智能运维场景的大模型智能运维解决方案，该解决方案在 MLOps、LLMOps 以及 OpsPlatform 等平台上通过 AIAgent（智能体）进行构建。其中，MLOps 为算法落地提供加速，OpsPlatform 提供运维工具，LLMOps 则为大模型提供基础能力。在此基础上，我们将运维平台上的能力封装为大模型插件，这些插件可以在 MLOps 平台上进行开发、部署和调试，并可以在单智能体或多智能体的场景下使用。
在智能运维场景下，运用智能体过程中存在三大挑战：角色定义、多智能体协同以及计划制定。首先，智能体的角色定义需要明确，我们的目标是构建在某一特定领域接近专家水平的智能体，它能够专注于特定领域的知识，避免泛化，并与知识库和任务紧密关联。其次，如何实现多智能体的协同互动是一个大难点，不同的智能体需要达成共识，并能互补。最后，智能体在执行运维活动时，需要制定有效的计划，这个计划必须符合标准流程，并能解决实际问题。智能值班、故障诊断、脚本生成与评审、变更管理、性能优化等场景都是大模型可以落地的高价值场景。
LLM Agent 的应用场景分为单一智能体和多智能体两大类，每一类又有一些特定的方向。
在单一智能体中，我们有知识咨询和工具使用两个主要的运用方向。知识咨询，也就是知识问答场景，在这里传统的文档查询依赖关键词匹配，这在一定程度上限制了查询范围。当缺乏全面的专业知识时，仅通过现象描述难以找到深层次的相关知识。然而，大模型的应用改变了这一局限，使我们能够通过现象关联到理论知识层面。工具使用是指在运维和工具开发过程中，由于往往由不同的角色或团队承担，彼此之间可能存在一定的沟通障碍，而大模型的介入则能有效简化这两者间的接口，使运维人员能够通过自然语言与工具进行沟通，同时促进了工具开发者对运维需求的快速响应。
在多智能体模式中，主要运用在故障诊断和运维活动增强两个场景。故障诊断通常涉及到多个专家的协作，而由于专家资源的稀缺性和招聘成本的高昂，低成本复制 AI 智能体的方式具有很大的优势。在这个模式中，决策者扮演着至关重要的角色，以确保各专家的意见能得到有效整合。而在运维活动增强的场景中，我们更看重运维活动编排的改进，即基于AI驱动，通过推荐实用工具和有效流程，简化场景编排，同时设立审查环节，以保证运维活动执行的准确性，从而进一步提升工作效率。
首先，我想详细说明智能问答这个运用场景。它在运维领域具有重要性，其主要特点是对特定领域知识的深入理解和对技术文档的高度依赖。举字节跳动为例，公司的知识文档平台飞书承载了全部的工作相关资料，这使得员工可以随时随地通过手机访问这些信息，无需携带电脑，大幅提高了工作的便捷性。为适应这个变化，我们整合了飞书文档和其他各种知识库，并将它们映射到网络运维和系统运维等不同的专业知识领域，这为实时智能问答提供了强大的支撑。
智能问答的流程可以分为六个步骤。首步是用户提出问题，接着我们利用大模型的能力对问题进行改写并利用多个插件进行处理。然后，在分析问题的基础上生成提示词，并尝试从向量库中找到可能的答案。由于流程涉及到多插件处理，因此需要对各处理结果进行筛选、整合或排序，最终为大模型提供合适的提示词。这个过程可能会反复进行，直到找到满意的答案提供给用户。此外，我们发现运维人员提出问题的方式并不只是文字，他们可能会使用截图等多种形式，因此我们引入了 OCR 技术，并尝试使用文本转 SQL 的方法来解决数据库查询问题。在准备知识库的建立时，我们依照“从小到大，以语义为指导”进行知识的总结、分解与组织，以提升其实用性。目前，智能问答已经在智能 oncall 和数据中心的运维工作中得到应用，使用形式包括飞书机器人、运维产品页面和嵌入式浮窗等。
我们当前正在进行优化过程的另一个应用实例是故障诊断。这个流程包括信息提取、规划和执行等关键阶段。在规划阶段，我们通常以经验知识库为指南，使用工具插件收集诸如服务拓扑和配置等运维信息。基于这些初步信息，我们开始排查可能的故障，这个过程类似于日常运维人员的工作活动，比如从指标、日志、事件和历史故障知识库中寻求可能的解决方案。故障诊断阶段可以采用单个 Agent 或多个 Agent 处理，初期可以以单个 Agent 为起点进行尝试。在该过程中，我们需要大量使用已有的工具系统，并且添加了 RAG 方法来回顾历史故障记录，从而吸取其中的经验。在运维场景中，token 的数量并非“越大益智”，事实上，使用“精确的” tokens 更优，也就是说，我们需要对 token 使用进行优化以避免信息冗余。
此方案选择使用了多 Agent 方式进行实施。在多 Agent 模式下，主 Agent 负责控制整个诊断过程，包括制定诊断计划，并将任务分配给其他 Agent 执行，如异常分析、故障诊断和工具系统故障处理等，最终，由总结 Agent 收集并整理所有数据。其中，多 Agent 协作是一个主要的挑战。我们也在考虑引入知识图谱来加强 Agent 的知识处理能力。
目前的实践如上图所示，通过实例引导生成计划，利用 ReAct（Reinforcement Learning for Autoencoding and Translation）调用排查工具并总结的能力已初步建立，后续将持续迭代优化。
AIOps平台助力提效
AIOps 平台可用于多个算法场景的实际运用，且在应用流程中有大量共性； 业务用户希望看到快速上线并能实时查看线上效果的场景； 落地应用的效果需要可视化，并且需要持续运营； 受算法工程师数量限制，实施多个场景时面临 ROI 挑战； 算法场景通常无法单独为用户服务，需要与已有的运维系统结合使用。
虽然 Gartner 并未提供具体的平台建设解决方案，但通过观察像上图右侧 Dynatrace 公司的产品架构，我们可以看到有一些类似于 AIOps 平台，它们提供了算法场景服务。这进一步凸显了构建此类平台的必要性。
AIOps 平台的设计目标用户主要有三类：算法工程师、SRE（站点可靠性工程师）和其他运维平台。整个架构大致分为三层：数据层、算法服务能力层和平台功能层。
本平台提供的核心功能强大，涵盖了数据管理、运维场景固化、原子算法服务、大模型插件管理、Agent 设计调试、以及算法服务监控等六大类别。
从数据管理的角度，用户可以方便地接入和使用数据进行推理。为满足运维的各种需求，我们在场景市场中固化了一些常见的运维场景，并支持用户自行创建新的场景，以便能够进行快速的复用。平台还提供了一套原子级别的算法服务，用户可以直接调用这些原子算法或者进行组合编排。对应于大模型的应用需求，我们提供了插件管理能力，帮助大模型开发者的工作。在 Agent 设计环节，用户可以使用我们的平台进行 Agent 的调用和调试。此外，我们还提供了算法服务的监控功能，帮助用户维护和管理他们的实际运用场景。
为提升 AI Agent 的开发效率，AIOps 平台针对 AI Agent 的开发提供了全方位的支持。通过平台的编排能力，可以实现工具和算法的组合，编排后的工具可以作为 Agent 调用的插件。我们的平台允许用户快速定义 Agent 并方便地进行调试。通过 Agent 市场，我们还能分享 Agent 智能体。此外，平台还提供了多个 Agent 的编队能力，允许智能体专家组成专家团队来处理不同的场景问题。
在一般情况下，算法场景的用户和业务方更关心的是算法是否能真实地解决问题，使他们能从中获取实际的商业价值，而不是具体采用哪种算法。通过使用 AIOps 平台，新上线的算法模型的落地速度有了显著的提升，由原先需要一个月的周期缩短为每周就可以发版，甚至能够即日完成用户的需求。部分算法甚至实现了配置即部署的便捷性。
此外，我们的平台目标还包括建立跨部门的算法共享机制。通过使用 AIOps 平台，多个部门可以共建和共享算法市场，实现资源整合的增值效应。这样，无论是算法团队还是用户，都能直观地体验到智能算法平台在线应用的实效，并增强对平台的信任。