大胆预测：再过5年，企业可能不需要传统AIOps了

从分析问题到执行修复：AIOps的本质跃迁

最近一直在想一个问题：大模型越来越强，Agent 也开始能自己调用工具、分析问题、执行任务了，那企业 AIOps 未来到底会变成什么样？

以前我们聊 AIOps，无非就是告警降噪、异常检测、根因分析、故障预测这些东西。

说白了，就是让机器帮运维人员少干点活。

但现在不一样了。

过去的 AI 主要负责告诉你哪里出了问题，现在的 Agent 已经开始尝试自己调查问题、制定方案，甚至直接动手解决问题。

一个是帮人分析，一个是开始替人干活。

别看只是多了一个执行动作，背后的变化可能非常大。

我甚至觉得，再过五年，传统意义上的 AIOps 可能就没那么重要了。

取而代之的，可能是一套真正能够自主运行的 IT 运维系统。

大厂已经开始行动了

这不是凭空想象。

2026 年，Google、AWS、Dynatrace 这些厂商在 AI 运维上的动作，已经能看出一些趋势。

Google 今年分享了内部 SRE 团队使用 Agent 的实践。他们已经开始让 Agent 参与生产事故调查，并在部分场景下自主缓解故障。

注意，不是简单地把日志丢给大模型让它总结一下。

而是让 Agent 结合监控指标、日志、调用链、系统拓扑、历史事故等信息，自己去调查问题。

AWS 也在做类似的事情。

它的 DevOps Agent 能够自动调查故障，关联代码变更、部署记录和服务依赖，分析可能的根因，再生成修复建议。

不过，AWS 在生产修复上仍然比较谨慎，Agent 可以给出方案，但实际修改生产系统还需要人来执行。

Dynatrace 也在今年推出了面向 SRE 等场景的 Agent 能力，尝试从发现问题走向自动处理问题。

把这些事情放在一起看，会发现一个明显的变化：

「以前大家比的是谁能更快发现问题，现在开始比谁能真正解决问题。」

这可能就是下一代 AIOps 的起点。

未来的运维，可能真的不用天天盯监控了

想象一个很常见的场景。

凌晨两点，核心服务突然报警。

值班工程师被电话叫醒，打开监控平台，看指标、查日志、翻调用链。

接着排查数据库、网络，再看看最近有没有发布。

折腾半小时，终于发现是某次配置变更导致数据库连接池耗尽。

然后联系相关人员，确认影响范围，执行回滚，观察业务是否恢复。

这套流程，做过运维的应该都不陌生。

那么未来呢？

可能是这样的。

凌晨两点，系统发现异常，Agent 自动开始调查。

它先分析异常指标，再查询日志和调用链，发现问题出现的时间与某次配置变更高度吻合。

接着继续验证，排除其他可能性，最终定位到数据库连接池配置。

如果属于预先授权的低风险场景，Agent 就执行修复，观察业务指标，确认恢复后生成事故报告。

第二天早上，工程师打开系统，看到的是一份完整总结：

真正值钱的，不是 AI 会分析，而是 AI 敢执行

这里有个问题特别值得思考。

假设再过几年，大模型已经能很好地分析日志、理解系统架构、定位常见故障。

那传统 AIOps 还有什么价值？

以前做根因分析，需要研究各种事件关联算法、异常检测模型、拓扑分析方法。

但现在，借助大模型和工具调用，很多过去比较复杂的分析任务，已经有了新的解决方式。

「未来单纯的日志总结、告警解释、故障问答，可能越来越不值钱。」

因为这些能力很容易被云厂商和可观测性平台集成进去。

真正难的是什么？

是让 AI 安全地操作生产环境。

比如 Agent 判断数据库有问题，建议重启。

但问题来了：

IT REALLY JUDGED RIGHT?

它真的判断对了吗？

重启会不会影响其他业务？

现在是不是交易高峰期？

操作失败了怎么办？

谁来承担责任？

这些问题，光靠模型聪明是不够的。

所以我觉得，未来 AIOps 真正的竞争力，可能是三个东西。

未来谁能把这三件事做好，谁才有机会成为下一代运维平台。

至于底层用哪个大模型，反而未必是最重要的。

2028 到 2030 年，可能是一个关键节点

如果大胆预测一下，我觉得未来几年 AIOps 大概会经历三个阶段。

当然，不同行业的进度肯定不一样。

互联网业务可能快一些，银行核心系统、大型传统企业可能慢很多。

毕竟生产环境不是实验室。

AI 回答错一个问题，可以重新问。

「但 AI 执行错一个操作，可能就是一次严重事故。」

所以我不认为未来几年会突然出现完全无人的企业运维。

更可能的情况是，AI 能够自主处理的范围越来越大，人需要介入的场景越来越少。

传统 AIOps 厂商，可能要面临一场洗牌

这也是我觉得最有意思的地方。

以前企业采购 AIOps，通常会单独买一套平台。

对接监控、日志、CMDB、ITSM，再提供告警压缩、事件关联、根因分析等功能。

但未来，如果 AWS 自己的 Agent 就能调查故障，Datadog、Dynatrace 自己的 Agent 也能处理问题。

「企业为什么还要额外买一套独立 AIOps？」

这是传统厂商必须面对的问题。

我觉得，未来只靠告警降噪、智能问答、事件关联，很难建立长期竞争力。

但这不代表独立 AIOps 厂商没有机会。

恰恰相反，我认为还有一个很大的方向：

做跨平台、跨云、跨系统的 Agent 运维控制层

因为真实企业的 IT 环境往往很复杂。

有公有云，也有私有云；有 Kubernetes，也有虚拟机；有新系统，也有运行十几年的老系统。

这些东西不可能全部交给某一家云厂商管理。

谁能把这些系统连接起来，让 Agent 真正理解整个 IT 环境，并且安全地执行操作，谁就可能获得新的机会。

「未来 AIOps 的竞争，可能不再是谁的算法更厉害，而是谁掌握了企业 IT 系统的上下文和执行入口。」

AIOps 最终的目标，可能根本不是修故障

再往远一点想，我觉得 AIOps 最终要解决的，可能不是故障处理，而是让系统尽量不发生故障。

今天我们经常用 MTTR 衡量运维能力。

以前故障恢复需要一小时，现在只需要十分钟，当然是进步。

但有没有可能，未来 Agent提前发现风险，在故障发生之前就解决问题？

• 发现服务容量快不够了，提前扩容；
• 发现某次代码发布存在风险，提前阻止发布；
• 发现数据库配置存在隐患，主动提出优化方案；
• 甚至根据业务流量，持续平衡系统性能、可靠性和成本。

到那个时候，企业给运维系统下达的任务，可能不再是：

BEFORE

「帮我监控一下支付系统。」

AFTER

「保证支付成功率达到业务要求，同时尽量降低资源成本。」

至于怎么监控、怎么扩容、什么时候优化，由 Agent在授权范围内完成。

这才是我理解的 AIOps 终局：从管理故障，变成管理业务目标。

当然，要实现这一步，还有很多问题要解决。

但如果方向成立，AIOps、DevOps、SRE、FinOps 之间的边界，也可能越来越模糊。