前言

最近刷B站，把乾颐堂教主那套《2025教主AIOps合集》从头到尾啃了一遍。说实话，最开始我是抱着"又来一个炒概念的"心态点进去的，毕竟AIOps这个词喊了也不是一年两年了，从18、19年就开始有人吹，结果吹了这么多年，很多公司还停留在"用个算法做异常检测"的阶段。

但看完教主这套视频，加上我自己这半年关注的行业动态，突然意识到：2025到2026这一年多的时间，AIOps好像真的不一样了。不是那种"换个包装继续卖"的不一样，而是从底层逻辑到落地形态都发生了质变。

这篇文章不想做视频内容的搬运工，而是结合教主讲的那些核心知识点，再加上截止到2026年7月的行业最新进展，聊聊我对AIOps现状和未来的一些看法。尽量说人话，少整那些虚头巴脑的概念。

一、先吐槽一下传统运维的痛点

在聊AIOps之前，得先说说我们运维人每天面对的是什么。不然说AIOps好都是空口说白话。

1.1 告警风暴：每天都在狼来了

这个绝对是所有运维人的共同噩梦。一套稍微上点规模的系统，一天告警几千条都是家常便饭。交换机宕个机，上下游能给你报出几十条告警，什么端口down、链路不可达、服务超时、CPU飙高……看着一大片红色，你根本分不清哪个是因哪个是果。

结果就是：告警多了，人就麻木了。真出大事的时候，反而被淹没在一堆无效告警里，等反应过来已经晚了。这就是典型的"狼来了"效应。

教主视频里提到一个数据我印象很深：传统运维模式下，90%以上的告警都是无效的或者重复的。真正需要人介入处理的，可能连10%都不到。但问题是，你不知道哪10%是真的，所以只能全都看一遍——这就是纯纯的人力浪费。

1.2 排错靠经验：新人来了就是地狱难度

网络故障排查这个事儿，传统模式下极度依赖个人经验。同样一个网络不通的问题，老工程师可能ping两下、traceroute走一遍就大概知道问题出在哪了，新人可能折腾一下午还在那摸不着头脑。

而且现在的系统越来越复杂，从底层物理网络到虚拟化，再到容器、微服务、服务网格……链路一拉长，排查难度指数级上升。一个请求从用户端到数据库，中间可能经过十几二十个节点，任何一个环节出问题都会表现为"业务异常"，但根因藏在哪？

教主在视频里说的"网络神级排错"，本质上就是想解决这个问题——把老工程师的经验沉淀成系统能力，让排错不再靠"老中医把脉"。

1.3 被动救火：永远慢半拍

传统运维还有个大问题：永远是事后响应。系统崩了，告警来了，我们才开始动手处理。能不能提前发现问题？能不能在故障还没发生的时候就预警？

理论上可以，靠阈值告警嘛。但阈值这个东西有多难用，用过的都知道。设高了漏报，设低了误报。而且业务是动态变化的，双十一大促和平常日子的流量能一样吗？固定阈值根本跟不上。

这些痛点，其实就是AIOps诞生的背景。不是为了搞概念而搞概念，是真的被逼的——系统复杂到一定程度，纯靠人已经hold不住了。

二、AIOps到底是什么？别被概念忽悠了

很多人一听到AIOps，第一反应是"人工智能+运维"，然后就开始脑补什么机器人替代运维工程师，什么全自动无人值守……打住，那都是科幻片。

说点实在的，AIOps的核心其实就是一件事：用AI的能力，帮运维人做那些重复性高、数据量大、靠人力效率低的事情。

教主的视频里把AIOps拆解成了几个核心模块，我觉得挺实在的，没有吹得天花乱坠：

• 智能告警分析：把海量告警降噪、聚合、关联，告诉你真正该关注的是什么

• 根因定位：出了问题自动帮你找根因，不用一层层人肉排查

• 智能运维助手：用自然语言就能查状态、问问题、甚至执行操作

• 预测性运维：提前发现潜在问题，从被动救火变主动预防

• 自动化修复：常见问题自动处理，不用半夜爬起来重启服务

注意，这里的核心是"辅助"，不是"替代"。至少现阶段是这样。AI更像是给你配了个超级能干的实习生，数据处理、信息整理这些活儿它全包了，最终决策和高风险操作还是得人来拍板。

2.1 三代AIOps的演进

结合教主讲的和我看到的行业趋势，AIOps其实已经经历了三代演进：

第一代：规则驱动。其实就是传统的自动化运维，写好规则和脚本，满足条件就触发。优点是精确可控，缺点是覆盖不了长尾场景，规则多了维护起来也是噩梦。

第二代：传统机器学习驱动。开始用各种算法——孤立森林做异常检测、聚类做告警聚合、时序预测做容量规划……比规则灵活了，但有个大问题：传统ML对非结构化数据处理能力弱，而且缺乏推理能力。它能告诉你"这里异常了"，但说不清楚"为什么异常"。

第三代：大模型+多智能体驱动。也就是2025年以来爆发的方向。LLM的自然语言理解和推理能力，加上多智能体的协同能力，一下子把AIOps的天花板拉高了一大截。这也是教主视频里重点讲的内容。

为什么第三代这么猛？因为运维这个场景，本质上是一个"信息综合+推理判断"的过程。日志、指标、链路、告警、拓扑、知识库……信息散落在各个地方，需要把它们串起来分析。传统AI做不了这个，但大模型+知识图谱+多智能体的组合可以。

三、核心技术拆解：智能告警与提示词工程

教主的合集里有专门一块讲"智能告警分析与文本生成提示词"，我觉得这块是最接地气、最容易上手落地的。很多公司做AIOps都是从告警治理切入的，因为见效最快。

3.1 告警降噪：从一千条到一条

先说说告警降噪是怎么回事。传统的告警聚合无非就是按时间窗口、按服务、按优先级归归类，但效果很有限。

现在的智能告警分析不一样了，它会从几个维度去做关联：

• 时间相关性：同一时间段内爆发的告警，大概率是同一个故障引起的

• 拓扑相关性：同一个节点、同一个机房、同一个网络分区的告警，可能有因果关系

• 因果相关性：上游服务挂了导致下游超时，这种依赖关系能识别出来

• 语义相关性：告警内容描述的是不是同一个问题——这就是大模型的强项了

教主视频里提到的效果是：90%的告警压缩率。什么概念？原来一千条告警，压缩完只剩一百条，而且这一百条都是去重后的有效故障事件。

2026年的最新数据更夸张，行业头部企业做得好的能做到99%的压缩率。原来每天被告警轰炸的运维团队，现在一天可能就收几条真正需要关注的告警汇总。这个体验提升是质变级别的。

3.2 提示词工程：让大模型好好干活的关键

说到智能告警分析，就绕不开提示词工程。很多人以为把告警扔给大模型，它就能给你分析得明明白白——太天真了。直接喂原始数据，输出的结果要么是废话，要么是幻觉，根本没法用。

教主在视频里强调了提示词的重要性，这点我非常认同。运维场景的Prompt和普通聊天不一样，它有几个硬性要求：

第一，角色要明确。你不能说"帮我分析一下这个告警"，得说"你是一个有10年经验的资深SRE工程师，精通网络、数据库和分布式系统故障排查"。角色设定越具体，输出的内容越专业。

第二，输出格式要结构化。不能让大模型自由发挥，必须规定好输出什么字段。比如：现象摘要、最可能根因（Top1-3）、置信度、证据来源、下一步排查建议。结构化的好处是后续可以自动化处理，不用人再去读大段文字。

第三，约束要给足。比如"不允许臆测，所有结论必须基于提供的数据"、"如果信息不足，明确指出还需要什么信息"。这是防止大模型胡说八道的关键。

我看到过一个比较经典的告警分析Prompt模板，大概长这样：

别小看这么一个Prompt，调好了和调不好，输出质量天差地别。教主视频里说"提示词是AIOps的核心生产力之一"，我觉得一点都不夸张。很多公司做AIOps效果不好，不是模型不行，是Prompt写得太烂了。

3.3 从告警聚合到根因定位

光把告警聚合并不够，最终目的是要找到根因。这也是教主视频里"智能告警分析"的进阶部分。

传统的根因分析靠什么？靠规则、靠拓扑、靠算法算关联度。这些方法都有用，但有个共同的问题：只能处理已知模式。遇到新的故障场景，就抓瞎了。

大模型进来之后，根因分析的玩法变了。现在的模式是：算法做初筛 + 大模型做推理 + 知识图谱做验证。

先用传统算法把可能的根因候选列出来，然后大模型结合告警内容、日志片段、拓扑关系、历史案例进行综合推理，给出最可能的根因和推理过程，最后再用知识图谱去验证因果链路对不对。

教主视频里提到的"90%根因5分钟内精准定位"，就是这套组合拳打出来的效果。放在以前，一个复杂故障排查几十分钟甚至几小时都是常事。

四、网络排错的终极形态：多智能体+知识图谱

教主合集里我觉得最硬核的一块，就是"网络神级排错"——多智能体链路溯源加知识图谱推理。这块也是2025到2026年AIOps领域进展最快的方向之一。

4.1 为什么网络排错这么难？

网络故障排查之所以难，难在几个地方：

第一，链路长、节点多。一个跨区域的访问，中间可能经过十几个网络设备，还有防火墙、负载均衡、CDN……任何一个节点出问题都会影响业务。

第二，信息分散。设备日志在一个地方，流量数据在一个地方，配置在一个地方，告警又在另一个地方。排查的时候要来回切换好几个系统。

第三，依赖关系复杂。网络是分层的，物理层、数据链路层、网络层、传输层、应用层……每一层的问题表现可能一样，但根因完全不同。一个"ping不通"，可能是网线断了，可能是路由错了，可能是防火墙拦了，也可能是对端服务没起来。

第四，经验依赖性极强。同样的现象，不同水平的工程师排查效率差十倍都不夸张。

4.2 知识图谱：网络的"结构化大脑"

教主在视频里重点讲了知识图谱在网络排错中的作用。这个东西说穿了，就是把网络里的所有实体和关系都存成一张图。

什么实体？设备、接口、IP、VLAN、路由、BGP会话、服务、机房……

什么关系？连接关系、依赖关系、包含关系、因果关系……

比如"交换机A的端口1连接着交换机B的端口2"、"路由器R1和R2建立了BGP邻居"、"服务X依赖数据库Y，数据库Y运行在服务器S上，服务器S挂在交换机A下面"。

这些关系都存在图数据库里，出问题的时候就能沿着关系链追溯。比如一个服务告警了，沿着依赖关系往上找，能快速定位到是哪个网络节点出了问题。

2026年的最新进展是，知识图谱已经从静态变成动态的了。以前的网络拓扑是定时采集更新的，现在结合Telemetry和实时配置变更检测，图谱能做到准实时更新。网络发生变化，图谱马上就跟着变，排查的时候不会因为信息过时而走弯路。

4.3 多智能体协同：一个团队替你干活

如果说知识图谱是"大脑的记忆"，那多智能体就是"大脑的分工协作"。

什么是多智能体？简单说就是不是一个AI在干活，而是好几个不同分工的AI一起配合。教主视频里提到的"多智能体链路溯源"，大概是这么个分工：

• 感知智能体：负责收集数据，从各个设备、监控系统里把日志、指标、抓包结果捞回来

• 分析智能体：专门负责分析数据，比如解读日志、识别异常模式

• 推理智能体：负责逻辑推理，结合知识图谱判断因果关系、追溯故障源头

• 验证智能体：负责验证假设，比如"假设是路由问题，那我去查一下路由表对不对"

• 协调智能体：相当于项目经理，统筹其他几个智能体的工作，汇总输出最终结论

是不是很像一个真实的运维团队？有人收集信息，有人分析数据，有人做判断，有人做验证，最后有人汇总汇报。

这就是2026年AIOps最明显的趋势之一：从"单个大模型什么都干"变成"多个专业智能体协同干"。单个模型再强，精力也是有限的，分工协作才能处理复杂问题。

Cisco去年底发的一篇技术博客里也提到了类似的架构——Deep Research AI Agents for Network Troubleshooting，核心思路就是多智能体+知识图谱+验证闭环。看来行业里的头部玩家都在往这个方向走。

4.4 效果到底怎么样？

说几个我了解到的数据吧：

教主视频里说的是"90%的根因能在5分钟内精准定位"。这个数是不是吹牛？结合行业情况看，应该是真的，但有前提——网络规模适中、知识图谱建得比较完善、故障类型是常见场景。

运营商那边的数据更夸张一些。中兴通讯2026年的技术白皮书中提到，他们的"大模型+知识图谱"方案，根因定位准确率突破90%，北京昌平区的场景达到了91.7%。而且输出结果带推理路径，不是黑盒，运维人员能看到AI是怎么一步步推出来的，方便人工复核。

还有个很重要的点：可解释性。早期的AI运维工具最大的问题就是黑盒——它告诉你这里有问题，但说不出为什么。运维人员不敢信啊，万一是误报呢？万一把方向带偏了呢？

现在多智能体+知识图谱的模式，天然就带可解释性。因为推理过程就是沿着图谱的关系链走的，每一步都有依据，都能追溯。这也是为什么现在企业敢把它用到生产环境里。

五、智能运维助手：从ChatOps到"运维同事"

教主合集里还有一块是"AIOps智能运维助手"，这块也是这两年变化最大的。从最早的ChatOps到现在的运维Copilot，再到现在开始出现的"AI运维同事"，进化速度快得惊人。

5.1 ChatOps的前世今生

最早的ChatOps是什么？就是在聊天工具里敲命令，比如在钉钉或企业微信群里发个"/restart servicexxx"，机器人就去帮你重启服务。本质上就是把命令行搬到了IM里，省得你登录服务器。

后来有了大模型，ChatOps就升级了。不用记命令了，直接说人话就行。比如"帮我看看订单服务现在的QPS是多少"、"查一下最近一小时有没有异常告警"，大模型理解你的意图，自动去调用对应的接口查数据，然后用自然语言回复你。

这个阶段叫"运维问答助手"或者"运维Copilot"，核心能力是意图理解+信息查询。你问它答，帮你省掉查文档、翻监控、写脚本的时间。

5.2 2026年的新形态：意图驱动运维

2025年底到2026年，又升级了。现在叫"意图驱动运维"（Intent-Driven Operations）。

什么意思？就是你不用告诉它怎么做，只要告诉它你想要什么结果。

举个例子，以前你要扩容服务，得一步步来：先看当前实例数，再看资源使用率，然后算要扩几个，再改配置，最后执行发布。

现在你直接说："把订单服务的实例数扩到10个，确保高峰期能扛住。"AI自己去判断当前负载、计算需要多少资源、检查配额是否足够、走变更流程、执行扩容、最后验证结果告诉你搞定了。

这中间的所有步骤，AI自己规划自己执行。人只需要提需求和做审批。

教主视频里虽然没明确提"意图驱动"这个词，但他讲的"智能运维助手的终极形态"其实就是这个意思——用自然语言描述运维需求，AI自动拆解并执行。

5.3 从"工具"到"助手"再到"同事"

我觉得智能运维助手的发展可以分成三个阶段：

工具阶段：AI提供仪表盘和告警，人做决策。AI就是个高级监控工具。

助手阶段：Copilot模式。AI帮你分析数据、给建议、写脚本、执行简单操作。你是司机，它是副驾驶。

同事阶段：AI能独立承担一部分运维工作。比如日常巡检、常见故障处理、容量优化、变更审核……你只需要管复杂的和高风险的。它就像团队里的初级运维工程师。

2026年的现在，行业头部公司已经开始摸到"同事阶段"的门槛了。当然，离完全替代人还差得远，但处理80%的日常重复工作，已经不是问题了。

阿里云的STAROps、腾讯云的智能运维平台、还有各种创业公司的产品，都在往这个方向卷。再过两年，运维团队里没有个AI助手，可能就像现在没有监控系统一样不可思议。

六、2026年最新进展：AIOps 2.0时代真的来了

前面讲的都是教主视频里覆盖到的内容，接下来聊聊视频之外，2025年底到2026年这大半年里，AIOps领域又出现了哪些新东西。

6.1 从1.0到2.0：范式级的转变

行业里现在普遍认为，AIOps已经从1.0进入2.0时代了。这个转变不是简单的功能叠加，而是底层范式的变化。

AIOps 1.0的核心是"数据驱动"。收集各种监控数据，用算法去分析、找异常、做预测。本质上是在传统运维的基础上加了一层AI分析能力。

AIOps 2.0的核心是"智能驱动"。不只是分析数据，而是能理解、推理、决策、执行。大模型带来的语义理解能力和推理能力，加上Agent带来的规划和执行能力，让AI从"旁观者"变成了"参与者"。

具体来说，有这么几个标志性的变化：

• 从"规则+算法"变成"大模型+知识+工具"

• 从"单点能力"变成"多智能体协同"

• 从"辅助决策"变成"自主执行"

• 从"被动响应"变成"主动预测+自动优化"

DeepSRE 3.0这个概念最近提得比较多，融合了时序Transformer和因果推理，据说能把MTTR（平均故障恢复时间）从42.8分钟压缩到7.6分钟。这个数据如果属实，那确实是数量级的提升。

6.2 自治运维：终极目标越来越近了

AIOps的终极目标是什么？是自治运维（Autonomous Operations），也有人叫"自动驾驶式运维"。

就像自动驾驶分L1到L5一样，自治运维也可以分级：

• L1 辅助运维：提供监控告警，人做所有决策和操作

• L2 部分自治：常见场景自动处理，复杂情况通知人介入

• L3 条件自治：大部分日常运维工作AI自主完成，只在遇到未知场景或高风险操作时找人确认

• L4 高度自治：特定领域完全无人值守，AI能处理几乎所有故障和变更

• L5 完全自治：整个IT系统完全自我管理，人只需要定目标

现在行业大概在什么水平？我觉得头部互联网公司的核心系统，大概在L2到L3之间。简单故障能自愈，日常巡检能自动做，但复杂故障还是得人来。

2026年的进展是，很多公司开始在非核心系统上尝试L3了。比如测试环境、内部工具系统，基本做到了出问题AI自己排查自己修，实在修不好再叫人。

教主视频里说的"AI自动化运维终极形态"，应该就是L4、L5的水平。说实话，那个还比较远，至少五到十年内不太可能实现。但方向是明确的，而且进展比大多数人想象的要快。

6.3 时序大模型：监控数据的新玩法

还有一个技术趋势值得关注，就是时序大模型（Time Series Foundation Model）。

以前做指标异常检测、容量预测，用的都是传统的时序算法——ARIMA、Prophet、LSTM之类的。每个指标都得单独训模型，调参麻烦，泛化能力差。

现在有了时序大模型，一个预训练模型就能处理各种类型的时序数据。不管是CPU使用率、QPS、网络流量还是磁盘IO，都能用同一个模型做分析，而且效果比单独训的还好。

2025年下半年到2026年，TimesNet、Chronos这些时序基础模型陆续出来，给AIOps的异常检测和预测模块带来了一次升级。以后做监控告警，可能不用再一个个调阈值了，AI自动学习每个指标的正常模式，异常了就报。

6.4 eBPF+AI：可观测性的新维度

最后提一个技术组合：eBPF+AI。

eBPF这几年在运维圈火得不行，不用改代码就能在内核层面采集各种数据——系统调用、网络流量、文件IO……数据粒度细得吓人。

但eBPF有个问题：数据量太大了。细粒度的数据采集，带来的是海量的数据，人根本看不过来。这时候AI就派上用场了——用AI去分析eBPF采集的海量数据，从中找出异常和问题。

这个组合教主的视频里没怎么提，但我觉得是下一个增长点。当数据采集不再是瓶颈，瓶颈就变成了数据分析——而这正是AI的强项。

七、落地的坑：别光看贼吃肉，要看贼挨打

前面讲的都是AIOps有多好有多厉害，但真要落地，坑多着呢。教主的视频里也提到了一些注意事项，结合我了解的情况，给准备入坑的朋友泼几盆冷水。

7.1 数据质量是地基

AIOps的上限，不取决于AI有多厉害，取决于你的数据质量有多高。

很多公司一上来就想搞最先进的大模型、多智能体，结果连最基础的监控数据都没整明白。指标缺的缺、错的错，日志格式不统一，拓扑信息过时，告警命名乱七八糟……这种数据喂给AI，再牛的模型也白搭。

行业里有个统计，说只有15%的企业AIOps落地效果好，剩下的要么效果一般，要么干脆做不下去。其中很大一部分原因就是数据基础太差。

所以真要做AIOps，第一步不是选模型买平台，而是先把数据治理做好。指标标准化、日志结构化、拓扑自动化、告警规范化……这些基础工作做好了，后面AI才能发挥作用。

7.2 冷启动问题

第二个大坑是冷启动。AI模型不是拿来就能用的，需要数据喂、需要场景训。

尤其是故障数据，哪有那么多？很多系统一年也出不了几次大故障，样本量根本不够训模型。没有足够的故障案例，AI怎么学习识别故障？

现在的解决思路大概有几种：

• 用预训练模型：先在公开数据集或行业通用数据上预训练，到具体场景再微调

• 注入专家知识：把运维专家的经验写成规则、建成知识图谱，先靠规则跑起来，再慢慢积累数据优化模型

• 混沌工程造数据：主动注入故障，制造训练数据。这个成本比较高，适合有条件的大公司

• 大模型零样本能力：靠大模型的通用知识直接上手，边用边优化。这也是为什么大模型时代AIOps落地变容易了——冷启动门槛降低了

7.3 信任问题：敢不敢让AI干活

第三个坑是信任。运维这个活儿，稳字当头。宁可慢一点，也不能出错——出一次错可能就是线上事故。

所以很多公司的AIOps，最后都做成了"只看不碰"——AI负责分析和建议，操作还是人来做。不是不想让AI自动执行，是不敢。

这个问题怎么解？一方面靠可解释性，AI的每一步操作都要有理有据，能让人看明白为什么这么做；另一方面靠分级授权，简单的、低风险的操作让AI自动来，复杂的、高风险的必须人审批；还有就是灰度，先在测试环境跑，没问题再上预发，最后才到生产。

教主视频里也强调了"确定性护栏"（Deterministic Guardrails）的概念——AI的所有操作都要受策略、预案和安全检查的约束，不能让它放飞自我。这点非常重要，尤其是在网络设备上做操作，一个配置错了可能就是整网瘫痪。

7.4 成本与收益的平衡

最后一个现实问题：钱。

大模型推理是要花钱的，尤其是多智能体的模式，一次排查可能要调用好几次模型，Token消耗哗哗的。如果每天告警几万条，每条都让大模型分析一遍，那个账单会很好看。

所以落地的时候一定要算经济账：哪些场景值得用大模型，哪些用传统算法就够了。比如告警降噪，传统聚类算法就能干个八九不离十，没必要每条都扔给大模型。只有那些传统方法搞不定的、需要深度推理的场景，再请大模型出马。

现在行业里的最佳实践是分层处理：

1. 第一层：规则和传统算法处理80%的简单场景，成本低速度快

2. 第二层：大模型处理剩下20%的复杂场景，保证效果

3. 第三层：人工处理AI也搞不定的疑难杂症

这样分层下来，既能享受到AI的好处，又不至于成本爆炸。

八、运维人怎么办？会失业吗？

聊了这么多技术，最后聊聊大家最关心的问题：AI这么厉害，我们运维工程师会不会失业？

我的答案是：低端运维会越来越难，但高端运维会越来越值钱。

8.1 哪些工作会被替代？

说实话，重复性的、技术含量低的运维工作，确实会越来越多地被AI替代。比如：

• 日常巡检、看监控、查指标

• 处理简单告警、重启服务、扩缩容

• 查文档、找资料、写简单脚本

• 基础的故障排查和信息收集

这些活儿，AI干得比人快、比人准、还不用睡觉。以后这些工作不会完全消失，但需要的人会越来越少。原来一个团队十个人干这些活儿，以后可能两三个加上AI助手就够了。

8.2 哪些工作替代不了？

但有些工作，AI短期之内替代不了：

第一，架构设计和容量规划。这需要对业务有深刻的理解，需要权衡各种因素，需要做决策。AI能给建议，但拍板还得是人。

第二，复杂故障的深度排查。尤其是那些从来没出现过的、全新的故障场景，AI的经验都是来自历史数据，遇到新问题容易抓瞎。这时候还是得靠资深工程师的判断力和创造力。

第三，变更管理和风险控制。运维很大一部分工作是管理风险——什么时候能变、怎么变、出了问题怎么回滚。这些涉及流程、规范、权衡的事情，AI做不好。

第四，跨团队沟通和协调。运维是个连接各个团队的岗位，很多时候需要沟通、协调、推动事情。这种人与人打交道的活儿，AI还不行。

第五，AI系统本身的运维。irony啊——AIOps系统本身也需要人来运维。模型训练、数据治理、效果评估、策略调整……这些都得人来做。

8.3 运维人的转型方向

那作为运维工程师，该怎么应对这个趋势？我觉得有几个方向可以考虑：

方向一：往SRE/平台工程方向走。从"操作运维"转向"建设运维"。不是天天手动操作，而是去建设自动化、智能化的运维平台。说白了，就是从"用工具的人"变成"造工具的人"。AIOps越普及，越需要有人来建设和维护这些系统。

方向二：深耕某个领域成为专家。比如网络、数据库、存储、安全……在某个领域钻得足够深，成为AI都替代不了的专家。AI只能处理见过的问题，专家能解决没见过的问题。

方向三：往业务方向靠。懂技术又懂业务的运维工程师永远稀缺。能站在业务视角做运维、做稳定性建设，这种价值AI很难替代。

方向四：拥抱AI，成为AI运维工程师。专门负责AIOps系统的建设、优化、运营。提示词工程、数据治理、模型微调、效果评估……这些都是新的技能点，早学早吃香。

教主其实就是个很好的例子——从传统网络工程师，到NetDevOps，再到现在讲AIOps，一直在跟着技术趋势升级自己的技能树。技术在变，但学习能力强的人永远不会被淘汰。

九、总结与展望

聊了这么多，最后收个尾吧。

9.1 我的整体判断

看完教主的AIOps合集，再结合2026年的行业现状，我对AIOps的整体判断是：

它不是噱头，是真的在改变运维这个行业。但它也不是银弹，不是上了AIOps就能一劳永逸。

现在的AIOps，已经过了"概念验证"的阶段，进入了"规模落地"的阶段。头部公司已经用起来了，而且效果确实不错——MTTR下降、告警减少、运维效率提升。但中小企业要落地，还有很多基础工作要补。

技术路线上，"大模型+知识图谱+多智能体"已经成为公认的主流方向。传统的纯算法路线正在被边缘化，不是说算法没用了，而是算法变成了大模型体系里的一个组件。

9.2 未来几年的趋势预判

最后大胆预测一下未来两三年AIOps的发展：

第一，多智能体架构会成为标配。单模型的能力很快就会摸到天花板，未来一定是多个专业智能体协同工作。就像从个人英雄主义时代进入团队作战时代。

第二，自治程度会不断提高。从L2到L3，再到特定场景的L4。越来越多的日常运维工作会被自动化，运维团队的规模会进一步精简。

第三，端到端的全链路智能会越来越完善。从监控、告警、分析、定位到修复、复盘，形成完整的闭环。不再是一个个孤立的AI功能，而是一个完整的智能运维体系。

第四，运维的工作重心会彻底转移。从"干活"变成"管系统"——管理AI运维系统、制定策略、把控风险、处理疑难杂症。运维工程师的定位会从"执行者"变成"管理者+专家"。

第五，中小公司的落地门槛会持续降低。随着SaaS化的AIOps产品成熟，不用自己建团队也能用得起智能运维。就像当年的云计算一样，从大厂专属变成普惠工具。

9.3 写在最后

作为一个在运维圈摸爬滚打了几年的老兵，看着这个行业从纯人肉运维，到自动化运维，到DevOps，到现在的AIOps，变化真的很大。

每次有新技术出来，都会有人喊"运维要完蛋了"。但这么多年过去了，运维不仅没完蛋，反而要求越来越高，价值也越来越大。变的只是具体的工作内容，不变的是"保障系统稳定运行"这个核心目标。

AIOps不是来消灭运维的，是来把运维人从重复繁琐的体力活里解放出来，让我们能去做更有价值的事情。

就像教主在视频里说的那样——技术一直在变，但解决问题的思路是相通的。与其焦虑会不会被替代，不如主动拥抱变化，学学新东西，让AI成为自己的帮手。

毕竟，未来淘汰你的不会是AI，而是会用AI的人。