AIOps系列 | 基础理论学习

没有故事的陈师傅

发布于 2025-07-02 18:14:18

22200

代码可运行

文章被收录于专栏：运维开发故事运维开发故事

运行总次数：0

代码可运行

大家好，我是乔克，一个爱折腾的运维工程，一个睡觉都被自己丑醒的云原生爱好者。

作者：乔克 公众号：运维开发故事博客：https://jokerbai.com

✍ 道路千万条，安全第一条。操作不规范，运维两行泪。
最近在学习《AIOps》相关的知识课程，为了让学习有一定的收获，所以将其进行了总结分享，如果你恰好也需要，很荣幸能帮到你。

在正式进入AIOps实践之前，先简单普及下相关的理论知识，我们会从以下几个方面进行介绍：

从精益、敏捷、DevOps到AIOps
什么是AIOps
大模型和AIOps
AIOps算法和应用案例

从精益、敏捷、DevOps到AIOps

不论是产品设计、开发甚至是运维，其都是围绕应用的生命周期做管理，那就存在设计、开发、测试、运维等阶段。在这些阶段中就会涉及到一些精益思想、敏捷开发、DevOps等相关指导思想，我们下面对其一一做简要介绍。

什么是精益

精益思想起源于制造行业，最早是由丰田公司实践并发展起来，旨在消除浪费、优化流程以最大化价值交付。在整个精益的发展历程中，戴明博士起到了非常重的作用，他提出的组织管理的14条基本原则在众多的精益实践中都有戴明博士的影子，比如在丰田公司，在打造丰田精益体系的时候，就是借鉴戴明博士关于质量控制、流程优化等多方面理念。

简单来说，精益管理是一种旨在提高效率和优化流程的管理方法，其主要要素可总结为以下几个方面：

价值（Value）： 将焦点放在满足顾客需求和提供对顾客有价值的产品或服务上。精益管理强调明确价值的定义，即顾客愿意为之付费的特定产品或服务特征。
价值流（Value Stream）： 价值流是指从原材料采购到最终交付给顾客所涉及的全部过程。精益管理要求组织全面了解价值流，识别其中的瓶颈和浪费，以便进行优化。
流程优化（Flow）： 通过消除浪费和改进流程，使产品或服务的生产与交付过程更加高效顺畅。其目标是实现无阻滞的价值流动，从而缩短生产周期、减少库存，提高交付速度。
拉动（Pull）： 拉动是指根据顾客需求来进行生产与供应，而非根据内部预测或批量生产。精益管理倡导「按需生产」，通过拉动机制确保只有在真正需要时才进行生产，以避免产生过剩库存和不必要的浪费。
消除浪费（Eliminate Waste）： 浪费是精益管理中的敌人。其中七大浪费包括：过度生产、库存、运输、过程中的等待、过度加工、不必要的动作和修正、未充分利用员工的潜力。通过消除这些浪费，组织能够更有效地利用资源。
人才与培训（Respect for People）： 精益管理强调尊重员工，认识到员工是组织最重要的资产之一，并鼓励员工参与流程优化和问题解决，提供培训和发展机会，以建设学习型组织。

什么是敏捷开发

瀑布开发

在敏捷开发大范围普及之前，瀑布开发在早期被广泛的采用，它要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段，它适用于需求明确的项目。

在瀑布开发模式下是存在一些局限性，主要有：

缺乏灵活性：按照固定的顺序线性开发，每个阶段都有明确的开始和结束时间，这种开发流程无法适应快速的需求变化和灵活性要求。
长时间的交付周期：要求进入下一个阶段之前完成上一阶段的所有工作，导致项目的交付周期长。如果需求发生变化或者出现问题，则可能需要回到前面的阶段。
高风险：测试和部署通常在开发的最后阶段执行，这意味着问题只能在开发结束后才会被发现，这导致修复问题的时间成本会很高，增加项目失败的风险。
缺乏协作和沟通：不同团队的成员在不同阶段工作，他们之前的沟通和协作较少，导致信息传递不常、问题未能及时发现和解决。
无法快速响应市场的需求：需要等整个项目完成才能交付产品，无法及时响应市场的需求变化，在快节奏的的市场环境中，容易出现无法满足需求的情况。

敏捷开发

在瀑布开发模式越来越满足不了快速的市场变化的情况下，在精益思想的指导下，敏捷开发模式应运而生。敏捷开发是一种小步快跑的开发模式，它是一种以用户需求进化为核心、倡导拥抱变化、循环迭代、循环渐进的开发方法。 首先把用户最关心的软件原型做出来并交付给用户，用户在实际场景中发现问题并给予反馈，研发人员快速修改弥补需求中的不足。上述过程不断迭代，直到用户满意。

敏捷追求“更早地交付价值，更灵活地应对变化”，适用于需求不明确、创新性或者需要抢占市场的项目，特别适合互联网项目。

相较瀑布开发模式，敏捷开发有以下不同：

敏捷开发模式是一个循环的过程，将交付周期拆分成多个小的迭代，以持续且连续的方式进行。
敏捷开发在每个周期完成后立即进行部署，随后可以快速响应用户的反馈，再进行分析评估以进入下一个阶段的设计、开发以及测试。
敏捷开发强调的是快速响应变化，持续交付可用的软件以及项目进程中不断获取应用和用户的反馈，以优化产品。

但是，随着敏捷的不断践行，在应用的整个生命周期中还是会有环节不堪重负，那就是运维环节，主要表现以下几点：

运维团队不堪重负：面对开发团队日益增长的发布次数需求，运维团队因人力和精力限制感到压力巨大。
工作时间盲目增加：为了满足开发团队的高频发布要求，运维团队开始在周末加班和通宵工作，过度依赖延长工作时间来提高发布频率。
稳定性下降：运维团队过度关注发布次数而非效率，导致线上稳定性受团队文化和工作环境影响而下降，质量问题和稳定性问题开始显现。
建立部门墙：为维护自身利益和保证发布质量，运维团队开始限制发布速度，比如一周仅限发布一次，试图通过建立部门墙来避免背锅和责任。

其中，建立部门墙是整个敏捷实行过程中最大的问题了。

敏捷模式的局限性导致开发团队和运维团队的目标与诉求不一致，开发团队追求变化，而运维团队追求稳定，尽量减少发布。
环境差异使得开发团队在本地测试正常的情况下，线上发布时出现问题，导致两个部门间的沟通障碍和部门墙加剧，协作效率降低。
开发团队在采用敏捷工具后变得敏捷，但运维团队仍依赖手工操作进行变更，这种不敏捷的状态导致故障处理时间延长。
运维团队对业务逻辑不熟悉，当生产环境出现故障时，查找问题和恢复时间较长，尤其是在更新依赖时可能引发业务问题。

所以，这就引入另一种文化：DevOps。

DevOps

DevOps代表的是将开发（Development）和运维（Operations）结合在一起的工作流程，目的是让两者共同负责产品质量。

DevOps是一种方法论，它希望将人、流程、技术结合起来，通过借助自动化工具来优化开发者服务，提升软件研发的效率和质量。

另外，精益、敏捷和DevOps三者之间是存在联系的：

敏捷和精益在文化层面提供指导，IT管理在工具层面提供解决方案，它们共同构成DevOps。
敏捷、精益和DevOps三者之间的主要联系在于它们都致力于提升效率与质量。
DevOps通过集成自动化工具和流程，实现了对敏捷和精益原则的扩展和深化，以适应现代IT管理的需求。

AIOps

DevOps 的出现是为了解决软件开发与运维之间的协作障碍，致力于实现从开发到运维全流程的自动化、高效化，强调通过持续集成、持续交付等实践让软件能够快速、稳定地交付和运行。而 AIOps 则是在 DevOps 基础上，随着企业数字化转型中数据量不断增长以及人工智能等技术逐渐成熟的背景下应运而生的。AIOps 继承了 DevOps 打破部门壁垒、追求高效运维的理念，并进一步借助人工智能和机器学习等技术手段，拓展了运维的深度和广度，提升了运维的智能化水平。

AIOps有以下优势：

持续观测监控数据流：AIOps对数据处理的吞吐量和敏感度远远超过人工。
解决运维团队孤岛问题：AIOps能够通过业务指标、日志、追踪数据关联性随时发现问题。
预测问题并提前解决：借助机器学习预测问题，而不是被动解决问题。
根因分析：借助机器学习技术快速处理大数据，并确定问题的根本原因。

要实现 AIOps ，需要将底层的数据抽象化，便于 AIOps 能够更高效的管理和自动化运维：

要将不同类型的应用以及日志进行收集存储
然后通过深度学习以及大模型的分析能力对数据进行建模分析
最后借助声明式将运维能力进行接口抽象化，便于维护管理

大模型和AIOps

随着 GPT 这类大模型的不断发展，使得数据分析和建模变得更加容易，降低了技术门槛，促进了AI技术在运维领域的普及和应用，它能够轻松编写如时序预测、分类等AI算法，简化了数据建模的过程，加速了AIOps的落地实践。

就拿根因分析来说，在传统的方式中，需要根据时间轴去查看所有的指标数据、日志内容，然后通过不断下钻的方式去分析原因，这种方式需要大量的专家经验，并且准确率还不是很高。

在大模型的加持下，我们可以借助大模型的agent技术对指标、日志、链路等多模态运维数据进行混合分析，然后输出分析结果。再结合运维专家的内部知识库，还可以找到对应的解决办法，提升问题解决的效率和准确性。

随着大模型和AIOps的结合，诞生了一种新的交互方式——以自然语言为核心的人机交互。这种交互方式避免了传统上的UI界面、鼠标操作、命令行或者API方式的局限。在这种模式下，用户只需要用自然语言描述需求，大模型将对应的语义转换为函数调用的参数，比如用户希望查询app=grafana的CPU使用情况指标数据，大模型可以将其转化为getMetrics({ app: "grafana", metric: "cpu_usage" })。

在大模型中，Agent可以理解为某种能自主理解、规划决策、执行复杂任务的智能体，它能够感知其环境，通过自己的决策和行动来改变环境，并通过学习和适应来提高其性能。

要利用好大模型，就需要打牢五层基石：

第一层就是模型，我们常见的就是各种大模型，然后通过API去调用，发出一个指令，然后大模型根据你的指令返回一些结果。
第二层是 prompt模板，我们在prompt中可以引入一些变量，动态地为大模型提供额外上线文或参考知识。
第三层就是链式调用。我们通过chain 把多次大模型调用串联起来。使用的主要场景是将上一次的模型输出作为下一个模型的输入。这样就能很好对大模型的一些缺陷进行一个弥补，或者是能完成更加复杂的一些工作。
第四层就是Agent，能自主执行链式调用，通过工具对外部环境产生作用。既能告诉你怎么做，还能帮你做。
第五层就是多Agent 协助，问题拆机，自动分工协作，帮人类完成更复杂的任务。

其中使用到的核心技术主要有：

Prompt Enginnering：提示词的质量决定输出的质量
JSON Model：大模型稳定的输出格式，以便于与程序之间的连接和编码操作。
Function Calling：函数调用，它通过将方法封装成函数调用来实现链式调用和前置意图识别等功能。
RAG：检索增强生成，通过构建个人知识库或运维专家智库，解决大模型的业务理解和幻觉问题。
Fine-tuning：微调

当然，当前情况下要将大模型应用到 AIOps 还存在不小的挑战，主要表现如下：

运维场景是非常严肃的场景，绝大多数情况下错误零容忍的，但是当前大模型幻觉问题还无法完全解决
运维数据有非常高的私密、安全性。大多数的场景是不允许使用外部公开的模型，避免数据泄露，所以需要企业独立部署大模型，不论是模型维护还是成本支出都有不小的挑战。
多数企业都缺少高标准的企业数据、知识库，这会降低大模型的训练质量。
现在的大模型由于上下文Token以及成本原因导致很难处理大量的实时数据。

AIOps 算法和应用案例

AIOps 常用的算法主要有：

统计分析算法：ANOVA、标准差、t检验、皮尔逊相关系数、箱型图
时序分析和预测算法：SARIMA、LSTM、Prophet
机器学习分类和回归算法：决策树、SVM、K近邻、梯度提升
异常检测和变更点检测算法：孤立森林、K均值聚类、DBSCAN

通过对这些算法的综合利用，可以实现对复杂系统的全面监控和智能分析，提升运维效率。比如在故障预警方面，通过采用LSTM算法可以学习历史数据预测潜在的风险，提前进行预警通知，减少故障发生。

再比如利用日志聚类算法对日志进行自动分类，通过机器学习识别相同模式的日志，可以快速掌握系统状态并实现对海量日志的分类与分析。

基于 RAG 的根因分析

基于 RAG（Retrieval-Augmented Generation，检索增强生成） 的 根因分析（Root Cause Analysis, RCA） 是当前 AIOps（智能运维）、故障诊断、日志分析等领域的前沿应用方向。它结合了信息检索和大语言模型的推理能力，可以在复杂系统中快速定位问题的根本原因。

主要的应用场景有：

场景	输入描述	根因分析输出
微服务异常	“order-service 响应延迟超过 5s”	检索到历史相似问题：Redis 缓存击穿，建议增加缓存预热机制
数据库慢查询	“MySQL 查询响应时间上升”	检索到执行计划变更，索引失效，建议重建索引
容器崩溃	“Pod 被 OOMKilled”	检索到内存泄漏案例，建议升级 JVM 参数配置
网络抖动	“跨区域访问延迟升高”	检索到 CDN 节点异常，建议切换接入点

RAG是什么

RAG 是一种结合“检索”和“生成”的技术架构：

检索（Retrieval） ：从知识库中查找相关上下文信息。
生成（Generation） ：使用大语言模型（LLM）基于检索结果进行推理并输出结论。

RAG的实现流程

RAG整体流程可以分为两个阶段：

数据准备阶段
数据查询阶段

1、数据准备阶段

a. 收集故障数据（知识库构建）

历史故障记录
日志样本
告警信息
操作手册
维护记录
SRE 或 DevOps 团队的经验文档

b. 对数据进行处理

清洗、标准化
分段成 chunk（如每条日志为一个 chunk）
使用 Embedding 模型将文本向量化（如 BERT、Sentence-BERT、SimCSE）

c. 存入向量数据库

FAISS
Milvus
Weaviate
Elasticsearch (dense vector)

2、数据查询阶段

a. 用户输入

"服务 user-service 出现 503 错误，QPS 下降 80%，日志显示 connection timeout"

b. 检索模块

将用户输入嵌入为向量
查询向量数据库，找到最相似的历史案例

示例返回：

【案例】user-service 出现连接超时，原因为数据库主节点宕机，导致连接池耗尽。
【解决方案】切换数据库到备节点，并重启服务。

c. 生成模块（LLM）

输入：用户原始问题 + 检索到的上下文
输出：结构化根因分析报告，例如：

{
  "root_causes": [
    {
      "reason": "数据库主节点宕机",
      "evidence": ["connection timeout", "db ping failed", "replica lag"],
      "probability": 0.92
    }
  ],
  "suggested_actions": [
    "检查数据库主节点状态",
    "切换数据库到备节点",
    "重启 user-service"
  ]
}

这其中涉及的关键技术组件有：

模块	技术选型建议
向量化模型	BERT、RoBERTa、Sentence-BERT、SimCSE
向量数据库	FAISS、Milvus、Weaviate、Elasticsearch
大语言模型	Qwen、ChatGLM、Llama3、Baichuan、通义千问
整合框架	LangChain、Haystack、FastRAG

总结

全文围绕《AIOps》相关知识展开介绍，通过对理论知识的整理，可以初步建立一个 AIOPS 的概念：

从精益、敏捷、DevOps 到 AIOps：
- 精益：源于制造行业，由丰田公司实践发展，旨在消除浪费、优化流程等，其要素涵盖价值、价值流、流程优化等多方面，是一种提高效率和优化流程的管理方法。
- 敏捷开发：在瀑布开发难以满足市场变化时，在精益思想指导下产生，以用户需求进化为核心、倡导拥抱变化等，对比瀑布开发有诸多不同，但在应用生命周期中运维环节存在一些问题，进而引出 DevOps。
- DevOps：将开发和运维结合的工作流程，是一种方法论，借助自动化工具优化开发者服务，提升软件研发效率和质量，与精益、敏捷存在紧密联系。
AIOps：在 DevOps 基础上，随着企业数字化转型及人工智能技术成熟应运而生，继承 DevOps 理念并借助相关技术提升运维智能化水平，具有持续观测监控数据流等优势，实现它需对底层数据进行相应处理。
大模型和 AIOps：大模型发展促进了 AIOps 的落地实践，二者结合诞生新交互方式，利用大模型需打牢五层基石，涉及多种核心技术，不过当前将大模型应用到 AIOps 还面临如大模型幻觉、数据安全等挑战。
AIOps 算法和应用案例：介绍了 AIOps 常用的几类算法，如统计分析算法、时序分析和预测算法等，通过综合利用这些算法可提升运维效率，并以故障预警、日志聚类算法为例说明应用情况。还着重阐述了基于 RAG 的根因分析，包括其应用场景、RAG 是什么、实现流程以及涉及的关键技术组件等内容。

下面再分享一个常见的 AIOps 实现流程：