LLMs如何重塑智能运维AIOps领域

最新推荐文章于 2025-07-23 22:52:57 发布

frostmelody

最新推荐文章于 2025-07-23 22:52:57 发布

阅读量510

点赞数 16

CC 4.0 BY-SA版权

分类专栏： LLM/RAG/MLLM/Agent知识点文章标签：运维

本文链接：https://blog.youkuaiyun.com/Listennnn/article/details/149569905

LLM/RAG/MLLM/Agent知识点专栏收录该内容

119 篇文章

订阅专栏

A Survey of AIOps in the Era of Large Language Models

摘要

这篇综述通过分析2020年1月至2024年12月间的183篇研究论文，系统地探讨了大型语言模型（LLMs）在智能运维（AIOps）领域的应用、影响和未来方向。作者们提出了四个核心研究问题（RQs），分别关注数据源的演变、AIOps任务的革新、基于LLM的方法论以及评估体系的适配。研究发现，LLMs不仅优化了传统AIOps任务，还催生了新的任务和方法，显著提升了运维的自动化和智能化水平。

第一部分：研究背景与动机

AIOps（Artificial Intelligence for IT Operations）由Gartner在2016年首次提出，旨在利用机器学习（ML）和深度学习（DL）技术处理海量运维数据，以实现系统问题的实时检测、诊断和修复。传统的AIOps方法在面对现代日益复杂的软件系统时，存在以下挑战：

复杂的特征工程：需要大量数据预处理工作，且难以处理日志等非结构化数据。
缺乏通用性：模型通常为特定系统定制，系统一旦变更，性能便会大幅下降。
任务灵活性差：一个模型只能执行一个特定任务，无法应对多样的运维需求。
模型适应性有限：系统更新后，模型需要频繁重新训练。
自动化水平受限：仍需大量人工干预，尤其在自动修复方面进展缓慢。

大型语言模型（LLMs）的出现为解决这些挑战提供了新的思路：

强大的自然语言处理能力：能有效处理非结构化数据，减少了特征工程的需求。
卓越的通用性和推理能力：基于海量数据预训练，具备跨平台的通用知识。
高度的灵活性：通过自然语言输出，能够同时执行多个AIOps任务。
强大的适应能力：利用检索增强生成（RAG）等技术，无需重新训练即可整合新知识。
更高的自动化潜力：具备强大的脚本生成和工具调用能力。

鉴于LLM在AIOps领域的应用迅速增长，进行一次全面的综述是非常必要的。

第二部分：四大核心研究问题 (RQs) 解析

这篇综述围绕以下四个研究问题展开，形成了一个从数据到任务，再到方法和评估的完整逻辑链条。

RQ1: LLM时代AIOps的数据源发生了哪些变革？

数据是AIOps的基础。LLMs的出现不仅改变了处理传统数据的方式，还引入了新类型的数据源。

1. 传统数据源的预处理技术革新

系统生成数据 (System-generated Data)：主要包括三类：
- 指标 (Metrics)：如CPU使用率、内存利用率等量化数据。LLM被用于指标数据的插补（补全缺失值），例如GatGPT、CRILM等模型。
- 日志 (Logs)：记录系统事件的详细文本，信息密度高但非结构化。日志解析 (Log Parsing) 是研究最活跃的领域。LLM通过强大的语言理解能力，将原始日志转化为结构化的事件模板，但存在准确性、一致性和成本问题。解决方法包括：
  - 基于提示的方法 (Prompt-based Approach)：如LILAC、LLMParser、Lemur等，通过上下文学习（ICL）或思维链（CoT）引导LLM进行解析。
  - 微调方法 (Fine-tuning Approach)：如OWL、LogLM，通过在特定日志数据集上微调LLM来提升其解析能力。
- 链路 (Traces)：记录请求在分布式系统中的完整路径。LLM在该领域的应用还较少，但已有研究开始尝试使用LLM生成仿真链路数据。

2. 新兴数据源的引入

人工生成数据 (Human-generated Data)：LLM使利用富含语义的人类知识成为可能。
- 软件信息 (Software Information)：包括软件架构、配置文件和文档，为AIOps提供了系统设计层面的背景知识。
- 源代码 (Source Code)：提供了系统行为最底层的逻辑，LLM可用于代码理解、缺陷检测和修复建议生成，例如RCAgent就结合了日志和源代码进行诊断。
- 问答数据 (Question & Answer)：运维相关的问答对可以作为知识库，辅助运维人员决策。
- 故障报告 (Incident Reports)：由用户或工程师编写的自然语言描述。LLM可以直接分析这些报告，实现故障的自动诊断和缓解方案推荐。

RQ2: AIOps的任务随着LLMs的出现如何演进？

AIOps任务流主要分为三个阶段：故障感知、根因分析和辅助修复。LLM不仅革新了传统子任务，还催生了许多新任务。

1. 故障感知 (Failure Perception)
此阶段的目标是在故障发生前或初期检测到异常。

故障预防 (Failure Prevention)：传统方法是缺陷预测等，但基于LLM的研究很少。
故障预测 (Failure Prediction)：预测未来可能发生的故障，但因许多故障缺乏明确前兆，LLM在此领域的应用受限。
异常检测 (Anomaly Detection)：是故障感知中最主要的研究方向。LLM时代的异常检测主要关注：提升模型通用性、利用大模型增强小模型性能，以及完全绕过模型训练直接使用提示进行预测。

2. 根因分析 (Root Cause Analysis, RCA)
在检测到异常后，定位问题并确定其性质。LLM的出现使RCA的起点从机器数据转向了人类编写的故障报告，并引入了文档、代码等作为辅助知识。

故障定位 (Failure Localization)：确定故障发生的具体组件或机器。
故障类别分类 (Failure Category Classification)：判断异常的具体类型（如CPU资源不足）。
根因分析报告生成 (Root Cause Report Generation)：这是一个由LLM催生的新任务。它超越了简单的定位和分类，能够生成包含详细推理过程的、易于理解的综合性报告，极大地帮助了运维人员。

3. 辅助修复 (Assisted Remediation)
根据根因分析的结果，辅助或自动执行修复操作。LLMs极大地提升了此阶段的自动化水平。该综述按自动化程度从低到高将修复任务分为五类，其中四项是LLM时代的新任务：

辅助问答 (Assisted Questioning) (新)：运维人员可直接向LLM提问，快速获取解答。
缓解方案生成 (Mitigation Solution Generation) (演进)：LLM根据历史故障报告和解决方案，生成针对当前问题的可行性建议。
命令推荐 (Command Recommendation) (新)：在运维人员输入命令时，LLM推荐下一步可能的操作或现有脚本。
脚本生成 (Script Generation) (新)：LLM直接生成用于解决特定异常的定制化修复脚本。
自动执行 (Automatic Execution) (新)：自动化程度最高的级别，LLM不仅生成脚本，还能自动执行，实现端到端的无人干预修复。

RQ3: 在AIOps中使用了哪些基于LLM的方法？

文章将应用于AIOps的LLM方法分为五大类：

基础模型 (Foundation Model)：直接使用预训练好的大模型。根据其结构分为：
- 编码器-仅模型 (Encoder-Only)：如BERT系列，适合需要对输入进行精细分析的任务。
- 解码器-仅模型 (Decoder-Only)：如GPT系列，适合生成式任务。Lag-Llama和TimesFM是其在时间序列预测领域的应用范例。
- 编码器-解码器模型 (Encoder-Decoder)：如T5、BART，适合需要复杂输入-输出映射的任务。
微调方法 (Fine-tuning Approach)：在领域特定数据上调整模型参数。
- 全参数微调 (Full Fine-Tuning)：更新模型所有参数，计算成本高。
- 参数高效微调 (Parameter-Efficient Fine-Tuning, PEFT)：只更新一小部分参数，如Adapter Tuning、LoRA等，成本更低，更灵活。LogLM使用指令微调（Instruction Tuning）来处理多种日志分析任务。
基于嵌入的方法 (Embedding-based Approach)：利用LLM生成的向量表示来捕捉语义信息。
- 预训练嵌入 (Pre-Trained Embedding)：直接使用GPT等模型的嵌入向量来表示日志等数据。
- 提示嵌入 (Prompt Embedding)：为特定任务设计提示，让LLM生成更具针对性的嵌入向量，常用于将指标数据转换为LLM能理解的格式。
基于提示的方法 (Prompt-based Approach)：通过设计提示词直接与LLM交互。
- 上下文学习 (In-Context Learning, ICL)：在提示中提供少量示例，引导模型按需输出，在日志解析任务中广泛应用。
- 思维链 (Chain of Thoughts, CoT)：引导模型进行多步推理，适用于复杂的因果发现和根因分析任务。
- 任务指令提示 (Task Instruction Prompting)：给出明确指令，适用于零样本或简单任务。
基于知识的方法 (Knowledge-based Approach)：整合外部知识以增强模型能力。
- 检索增强生成 (Retrieval-Augmented Generation, RAG)：从知识库（如历史故障报告、技术文档）中检索相关信息，并将其提供给LLM作为上下文，以生成更准确的回答。
- 工具增强生成 (Tool-Augmented Generation, TAG)：赋予LLM调用外部工具（如诊断脚本、API）的能力，使其能够执行实际操作或获取实时数据。RCAgent和AIOpsLab是这类方法的典型代表。

RQ4: AIOps的评估方法如何适应LLM的集成？

LLM的引入催生了新的评估指标和数据集。

1. 新兴的评估指标
除了传统的分类任务指标（如精确率、召回率、F1值、MAE、MSE等），还出现了三类新指标：

生成任务指标 (Generation Task Metrics) (新)：用于评估根因报告、解决方案生成等任务。
- 词法指标 (Lexical Metrics)：如BLEU、ROUGE，衡量生成文本与参考文本的表面重合度。
- 语义指标 (Semantic Metrics)：如BERTScore，评估文本的语义相似度。
执行任务指标 (Execution Task Metrics) (新)：用于评估脚本生成和自动执行等任务。
- 任务级指标 (Task-Level Metrics)：如功能正确性（FC）、平均正确性（AC），评估生成脚本中每个子任务的质量。
- 执行成功指标 (Execution Success Metrics)：如执行成功率，评估整个脚本能否成功运行并达到预期效果。
人工评估 (Manual Evaluation) (新)：由于LLM输出的复杂性和开放性，人工评估变得至关重要。
- 定性评估 (Qualitative Assessments)：由专家根据预定义标准（如精确、不精确、幻觉、推理错误）对结果进行分级。
- 人类偏好 (Human Preferences)：评估者根据主观判断评估结果的实用性和相关性，常见于案例研究。

2. 新型数据集的开发
为评估LLM在AIOps中的能力，研究人员开发了专门的数据集，尤其集中在辅助修复任务上。例如，OpsEval是针对运维问答任务的基准，而KubePlaybook则提供了用于生成Kubernetes修复脚本的提示数据集。微软开发的AIOpsLab提供了一个完整的框架，用于评估AI代理在故障注入、定位和解决方面的端到端能力。

第三部分：挑战与未来方向

尽管LLM为AIOps带来了巨大进步，但仍面临诸多挑战：

时间效率和成本效益：LLM的训练和推理成本高昂，尤其对于需要实时响应的故障感知任务，其高延迟和高成本是巨大障碍。未来的研究需要探索如何将小模型、大模型和运维专家（OCEs）有机结合，以实现成本和性能的平衡。
数据源的深度利用：目前对链路（Traces）数据的利用几乎为空白，而链路数据对理解分布式系统至关重要。此外，许多基于日志的工作仍在使用较小的模型，未能充分发挥LLM的优势。
泛化性和适应性：尽管LLM理论上应具备良好的泛化能力，但在软件系统不断演进的真实场景下，其性能是否能保持稳定仍缺乏充分的实证研究。
与现有工具链的集成：目前的研究大多致力于构建全新的方法，而忽略了将LLM与现有成熟的AIOps工具（如小型监控模型、自动化框架）集成。未来的方向应是构建模块化的、可互操作的框架，实现优势互补。

大型语言模型正在从根本上重塑AIOps领域，不仅提升了传统任务的效率，还开辟了全新的自动化路径。从数据处理、任务定义到方法论和评估体系，LLM都带来了深刻的变革。尽管存在成本、数据利用、泛化性等挑战，但通过解决这些问题，LLM驱动的AIOps方法论有望在未来实现更广泛和更具影响力的实际应用，为构建稳定、可靠的现代软件生态系统提供坚实的基础。