自动化、智能运维与AIOps：三层能力进阶真相

随着系统规模持续增加，软件系统已经由单体程序逐步演化为由微服务、容器、消息队列、数据库、中间件以及云基础设施共同组成的复杂系统。系统复杂性的增加，并不仅仅意味着服务器数量增加，更意味着系统状态空间呈指数级增长。一次请求经过多个服务传播，一个资源瓶颈可能表现为日志、指标、链路、配置等多个维度的信息变化，因此运维工作的核心任务也逐渐由"执行操作"转向"理解系统状态"。

正是在这样的背景下，运维自动化、智能运维以及AIOps三个概念不断出现。然而，它们经常被混用，以至于许多人认为三者只是名称不同。事实上，这三个概念分别对应不同层次的问题，它们解决的问题类型、所依赖的信息以及系统具备的能力均不相同。如果将运维理解为一个信息处理系统，那么三者实际上对应着从执行、分析到决策三个逐步提高的信息处理层级。

运维自动化（Operation Automation）解决的问题最直接：如何让机器替换人工完成重复操作。

设系统状态为，运维动作表示为函数，则自动化的基本目标可以表示为

这里的已经预先确定，例如部署程序、扩容节点、重启服务、创建数据库备份、执行脚本等。系统并不会分析为什么需要执行这些动作，而只是按照既定流程完成操作。

因此，自动化强调的是"动作能够自动完成"，而不是"动作是否合理"。Ansible、SaltStack、Terraform以及CI/CD流水线都属于这一范畴，它们提高的是执行效率和一致性，而不是系统理解能力。

仅有自动执行并不足以管理复杂系统，因为真正困难的问题往往不是执行，而是判断。

例如CPU利用率升高，到底属于正常业务增长，还是数据库查询效率下降？日志数量增加，是版本更新导致，还是缓存命中率下降引起？这些问题不能依靠固定脚本完成，而需要分析大量运行数据。

智能运维（Intelligent Operations）正是在这一层展开工作。

它将日志（Logs）、指标（Metrics）、链路（Traces）、配置以及历史运行记录共同作为输入，通过统计分析、机器学习、知识图谱等方法建立系统状态模型，从而完成异常检测、根因分析、容量预测以及性能评估。

如果将系统观测数据记为

智能运维的目标可以写成

其中表示状态识别模型。这里输出的不再是执行动作，而是系统当前更接近于什么运行状态。

因此，智能运维回答的问题是："系统现在处于什么状态？"

AIOps（Artificial Intelligence for IT Operations）通常被认为是智能运维的发展方向，但更准确地说，它是在智能分析基础上进一步加入自动决策能力。

其输入仍然来自日志、指标、链路等多源数据，但输出已经不再局限于状态判断，而是进一步生成建议甚至直接完成处理。

整个过程可以表示为

其中最后两个阶段构成了AIOps区别于普通智能运维的重要特征。

例如，一个数据库连接数持续增加。

自动化只能按照预设规则执行扩容脚本。

智能运维能够判断这是连接池配置异常还是SQL效率下降。

AIOps则可能综合历史案例、知识库以及实时拓扑信息，自动推断最可能原因，选择最优处理方案，并调用自动化平台完成配置调整，同时持续观察处理结果是否达到预期。

因此，AIOps不仅分析系统，而且管理整个决策流程。

如果按照信息论观点观察，这三个概念实际上对应三个不同层次。

第一层是执行层。

输入已经明确，目标动作已经确定，系统只负责完成任务。

第二层是认知层。

输入是不完整的数据，需要通过算法重建系统运行状态，此时重点已经从执行转移到信息解释。

第三层是决策层。

系统不仅需要理解当前状态，还需要比较多个候选方案，并依据目标函数选择处理策略。例如可以将目标函数写成

其中表示处理策略，表示综合代价，包括重建时间、资源消耗以及业务影响等因素。

可以看到，这已经属于典型的决策优化问题，而不仅仅是异常检测问题。

原因通常来自能力边界没有发生变化。

很多平台增加了机器学习算法，却只是把固定阈值替换成动态阈值；增加了异常检测模型，却仍然依赖人工确认处理方案；增加了知识库，却没有形成反馈学习机制。

AIOps至少需要形成完整闭环：

因此，一个系统即使应用了机器学习算法，如果仍然依赖人工完成决策，那么更准确地说，它属于智能运维，而不是完整意义上的AIOps。

运维自动化、智能运维和AIOps是运维体系三个不断递进的能力层次。自动化解决执行效率问题，智能运维解决系统理解问题，AIOps进一步解决决策优化问题。三者之间是信息处理能力逐步提高后的自然延伸。

从理论计算角度来看，自动化处理的是确定映射问题，智能运维处理的是状态估计问题，而AIOps进一步处理策略优化问题。当系统规模继续扩大、数据