AIOps 智能运维现状与落地路径：从告警到根因

一、运维的三个阶段，和 AIOps 真正要解决的问题

运维行业大致走过三个阶段。1.0 时代靠 Shell 脚本、SSH 和手工配置，人是"服务器保姆"；2.0 时代是自动化与 DevOps，Ansible、Kubernetes、Prometheus 把人变成"自动化管道工"；2023 年以后进入 3.0 阶段，大模型、机器学习、知识图谱、因果推断被引入运维场景，目标是把人从"救火队员"的位置整体抬高一层。业内比较认同的定位是：故障排查的核心正在从"敲命令"变成"问对问题、验证假设、做出决策"。

但 AIOps 要解决的，从来不是"监控不够多"，而是三件很具体的事：

• 告警噪音。一个 MySQL 连接池耗尽，下游上百个微服务会同时报警。值班人看到的是告警风暴，而不是故障本身。
• 定位成本。华为云在一份公开分享里给出的口径是：现网真实故障平均需要拉通 10 人以上、花费 4 小时以上才能完成定位，定界本身就很困难，还经常跨团队。
• 经验无法复用。资深工程师知道"看到这个告警先查哪里"，但这种知识大多存在个人脑子里，没有结构化沉淀，人一走就断档。

AIOps（Artificial Intelligence for IT Operations）不是某一款工具，而是利用 AI 技术处理运维数据、实现运维自动化的实践方法集合，典型能力包括异常检测、事件关联、根因分析、故障自愈与智能告警。

二、能力分级：企业现在到底在 L 几

中国信通院从 2019 年起联合运营商、银行、证券、能源、互联网等 80 余家企业编制 AIOps 系列标准，从感知、分析、决策、执行、知识更新五个维度对智能化运维能力做级别划分，整体从 L1 到 L5 五级，系统的参与程度逐级递增。2023 年 12 月，由信通院牵头的智能运维国际标准 ITU-T Y.3550 在国际电信联盟第十三研究组（ITU-T SG13）成功发布，这是国内外首个智能运维国际标准。

用这五个维度打分，就得到 L1（初始智能化运维）到 L5（高度智能化运维）的成熟度等级。信通院的调查显示，现阶段企业的 AIOps 能力大多集中在 L2 辅助智能化运维与 L3 进阶智能化运维，以系统分析、辅助人工决策和操作为主；L4 与 L5 是方向，不是现状。

同一份调查报告里还有两组数字值得记住：

• 企业在运维上的投入并不小——超过四成企业年平均运维投资规模超 5000 万元（占比 47.16%），另有 40.12% 的企业落在 500 万至 5000 万元区间。
• 企业面临的主要挑战不是"缺工具"，而是算法模型的准确性与可解释性，这导致团队要投入大量时间和人力持续优化模型，并为算法不准的场景兜底。

三、三条技术路线：算法、知识、智能体

1. 算法路线：让异常检测和告警关联先跑起来

这条路线最成熟，也最容易先出效果。核心是用时序模型替代拍脑袋的静态阈值：先学出系统在"工作日高峰""夜间低峰"等不同时段的正常区间，再拿实时值和预测区间比较，偏离了就标记异常。

告警关联的常见做法是基于服务依赖拓扑做向上溯源收敛——一个根因引发的几十条下游告警，最后压成一条：

from collections import defaultdict

def collapse_by_topology(alerts, topology):
    # 按依赖拓扑把告警收敛到最上游的根因候选
    groups = defaultdict(list)
    for alert in alerts:
        upstreams = topology.get_upstream(alert.service)
        # 最上游的那个服务作为根因候选
        root = upstreams[-1] if upstreams else alert.service
        groups[root].append(alert)
    # 出现时间最早、依赖层级最靠上的，优先级最高
    return sorted(groups.items(),
                  key=lambda kv: min(a.time for a in kv[1]))

要注意的是，这一层依赖的拓扑图必须是真的、且能更新的。CMDB 数据失真是行业里非常普遍的痛点，很多告警关联失败不是算法问题，是拓扑本身错了。

2. 知识路线：运维世界模型与知识图谱

阿里云可观测团队的做法值得参考。他们从 2019 年起做可观测数据建模，路径是四步：数据标准化（借助 OpenTelemetry 定义互操作）、实体与关联（用 EntitySet 描述 IT 世界核心对象，用 Link 建立调用/依赖/归属关系，形成拓扑图谱）、知识表达（通过 Semantic 表达领域专家经验与分析方法）、行动能力建模（把"如何响应"也纳入体系，从观测到分析到行动闭环）。最终形成的是 UModel 统一建模框架。

UModel 用几类原语把运维世界描述出来：EntitySet（实体集合，定义一类资源的唯一标识、属性、状态）、MetricSet / LogSet / TraceSet（把指标、日志、链路与实体做结构化绑定，其中日志必须关联至少一个 EntitySet）、Storage（解耦模型与存储实现，屏蔽 SLS、Prometheus、MySQL 的差异）、Runbook（把操作手册、分析模板、领域知识抽象成可被调用的知识）。

有了这层模型，故障排查就从"翻日志"变成"按图索骥"，具体几种打法：沿实体连接关系逐级排查，每类实体都有对应的可观测数据；基于先验知识定向排查，比如 Service 异常后优先看它依赖的 Service、DB 和中间件；由于多数故障由变更引起，优先看近期变更；把所有告警事件关联到实体，画出最小连接子图辅助排查。这些排查方式无论是人、程序还是大模型，都能基于同一套标准定义工作。

3. 智能体路线：Agentic Ops

2026 年最明显的变化，是 AI 从"给建议"走向"能动手"——以智能体形态完成感知、诊断、决策、执行、验证的闭环。海外动作可以作时间锚点：AWS DevOps Agent 于 2026 年 3 月 31 日正式 GA（2025 年 12 月 re:Invent 预览），能够跨 AWS、多云和本地环境做事件调查与主动预防；微软 Azure SRE Agent 也在同期走向 GA，主打加速诊断与自动化响应流程。

但这条路线恰恰是风险最高的地方，后面第五节会用 Gartner 的数据展开。

四、国内厂商在做什么

阿里云：STAROps + UModel + RCA Benchmark

阿里云在 2026 年发布的全域智能运维平台 STAROps，把理念写成了四个字母：Sense（全域感知，基于 UModel 统一采集日志、指标、链路、拓扑）、Target（目标导向，用自然语言定义运维目标，而不是被动响应告警）、Autonomy（多智能体协同完成"感知→决策→执行→验证"闭环，7×24 自主运维）、Resilience（业务韧性，持续巡检提前发现风险，故障时自动扩缩容、回滚、切流并验证恢复效果）。

它对外的能力形态有三种：智能会话（自然语言问告警、查指标、看日志，把命令行操作变成所问即所得）、长期任务 Mission（跨天/月级的异步运维计划，支持定时与事件触发）、数字员工 SRE Agent（企业自定义职责、权限、工具、技能，既是对话对象也是任务执行者）。

更值得记下来的是它在安全上的处理方式：权限上把"人能做什么"和"Agent 能访问什么"用 RAM 角色分层授权，做到最小化授权；高危写操作与危险命令通过 MCP 接入客户工具并配置人在回路（HIL）人工确认，再由拦截引擎兜底阻断异常执行；Agent 的对话历史、运行产物、工具调用、CLI 指令、数据访问记录全部留存，作为可追溯可复盘的审计证据。

另一个更偏基建的动作是 2026 年 6 月开源的 RCA Benchmark——面向 Agentic Ops 的根因分析基准体系。它搭建在 Kubernetes 集群里的电商微服务架构上，包含 40 多个业务服务、调用链最深 7 层，支持 Agent 检索指标、日志、链路、告警、资源拓扑、K8s 事件、性能剖析共七类观测数据；近 70% 的分数依赖基于"故障类型拓扑语义距离"和"实体拓扑距离"的确定性量化计算，而不是让另一个模型打分。这件事的意义在于，评价根因分析能力终于有了可复现、可审计的尺子。

华为：AUTINOps 与"数字员工"

华为在 2026 年 3 月 MWC 期间发布了基于 AI-Native 体系框架的智能运维解决方案 AUTINOps，分三层。平台层是运维域的"操作系统内核"，包含端到端数字孪生网络（DTN，对多厂商网络状态做跨域跨层实时感知与仿真）、运维领域大模型 EDNS 2.0、以及统一语义的数据底座。智能体层已推出超过 20 个 AI Agent，例如用于自主故障闭环的 MBB 故障 Agent、用于主动风险识别的风险处理 Agent，并提供开放的 Agent Studio 供运营商和合作伙伴自行开发。服务层则是"领域专家 + 数字员工"的混合团队作业模式。

按华为公布的口径，EDNS 2.0 加载了基于 Transformer 架构的风险预测模型，实现 80%+ 的风险识别准确率和 90%+ 的诊断准确率，用于支撑"T-1 时刻预测预防 + T0 时刻主动响应"的双保险运维。

腾讯：从变更工单切入的认知型 AIOps

腾讯云开发者社区分享过一条把大模型智能体用在变更工单上的路线，理由是它"落地成本最低、收益最直观、风险最可控"。运维人员用自然语言提变更需求，工单智能体完成：意图理解（识别重启、扩容、扩缩容、配置修改、版本更新等标准变更意图）、信息补全（从 CMDB、拓扑、负载、历史变更中自动拉参数，对老旧 CMDB 数据做多源交叉校验）、风险推理（基于服务依赖知识图谱推演变更影响链路，给出立即执行/窗口执行/分批灰度/禁止变更的建议，并自动生成回滚预案）、生成工单、分级审批、定时灰度执行、异常熔断回滚、复盘归档。

该方案自述的落地效果是：标准工单创建耗时从 5 分钟压缩到 30 秒以内，人工填报错误率从 15% 降到 0.2% 以下，线上变更故障发生率下降 70% 以上。需要提醒的是，这类数字来自方案方自己的实践总结，不同企业的统计口径和基数差异很大。看的时候重点放在"它把哪些环节自动化了、安全边界画在哪里"，而不是直接对标百分比。

五、泼一盆冷水：Gartner 和学术基准怎么说

一个方向如果只听厂商讲，很容易高估。2026 年有两组外部数据值得放在一起看。

Gartner：会先变复杂，再谈收敛

Gartner 在 2026 年 7 月发布的《AI in IT Operations 技术成熟度曲线》里给了一个反直觉的判断：AI 驱动的运维工具在近两年不会减少工具数量，反而会带来"控制台泛滥"（console sprawl）——更多层次、更多控制点、更多专用的可观测与编排能力。报告的原话是，很多叙事承诺"工具整合"，但近期会出现"相反的结果"。它把这归因于"确定性护栏"（deterministic guardrails）的引入，即用策略化规则划定 AI 被允许做什么。

几个更值得注意的预测：

• 到 2028 年，规模化在生产环境使用 Agentic AI 的 I&O 组织中，40% 会遭遇影响业务的严重服务中断；而 2026 年这一比例不到 1%。
• 到 2028 年，大型企业可能有超过 15 万个 AI Agent 在活跃使用，管理这些自主实体的身份、权限与生命周期本身就是架构级难题。
• 到 2030 年，IT 基础设施与运维工作中 25% 由 AI 独立完成、75% 由人借助 AI 完成，且一半的 I&O 团队会因引入 Agent 而重组。

Gartner 认为未来 2~5 年最具影响力的四类工具是：Agentic AI 可观测性（观察其他 Agent，报告失败、不安全行为和成本增长）、Agentic NetOps、增强型 FinOps、多智能体系统。

这段预测的正确读法不是"AI 运维会出事所以别上"，而是：自主性每上一个台阶，护栏、回滚预案、权限治理就得同步上一个台阶。Gartner 也明确说，工程师省下来的时间会转移到制定策略、测试恢复路径、审查 Agent 行为上——报表上的人力并不会凭空消失，只是换了位置。

学术基准：答案对了，不等于推理对了

2026 年的论文 Cloud-OpsBench 提供了另一个视角。它用"状态快照"范式在 Kubernetes 上构建了 754 个可复现的故障案例、覆盖 57 种故障类型，用同一套诊断接口跑了十个 LLM Agent，结果是：

这个"结果—过程"落差说明的问题很直接：Agent 在相当比例的情况下"猜对"了根因，但它的排查轨迹并没有真正拿到支撑结论的证据。只评估最终答案准确率，会显著高估 Agent 做证据驱动诊断的能力。论文作者因此主张，把"怎么验证的"和"得出了什么"放在同等重要的位置。

国内实践也是类似的曲线。阿里云一个基于 Dify 构建多智能体 RCA 系统的团队在分享里写得很实在：项目做了 一个多月，经过集成 IDC 的 CMDB、拆分知识库、动态注入上下文、用中心化函数统一时间、重写提示词结构、加入缓存机制等一连串工程优化后，部分场景的根因定位成功率从 20% 提升到 70% 左右，仍有不少可提升空间，后续还要在工程和模型两个层面继续挖。这比任何"10 秒定位故障"的说法都更接近真实的工程节奏。

六、落地路径：四步走，外加一步前置

把上面的东西合起来，可执行的路线大致是这样：

几条已经被反复验证的原则，值得写进方案第一页：

1. 先治理，再智能。阿里云大数据运维团队在云栖大会上的提醒很直接：智能运维是在已有的运维方案已经支撑了稳定性、成本、效率需求之后的"锦上添花"；如果基础运维能力构筑不扎实就引入智能运维，很容易引发更大的稳定性风险。有案例的复盘也印证了这点——前期花三个月做指标标准化和标签规范化，是所有效果数字的前提。
2. 从"读"到"写"，从"建议"到"执行"。前几个月所有 AI 给出的操作建议都应经人工确认后才执行；只在已经被充分验证的故障模式上开放自动修复，新场景强制人工审批。这一条可以写成围栏规则。
3. 每个自动变更都要有回滚预案，而且预案要随执行计划一起生成。Gartner 的表述是：一份说明 Agent 怎么修服务的 Runbook，同时也要说明当 Agent 误读了情况时、工程师怎么把这个修复撤销掉。
4. 权限不扩散。大模型不直连生产系统，中间必须有权限控制层、审批与审计层、执行代理层；越过任何一层都属于给自己挖坑。
5. 把评测做起来。没有可复现的评测集，就无法判断一次迭代是变好了还是只是换了个说法。开源基准和自建故障注入环境都可以，关键是要有。

七、人的位置

关于"AI 会不会取代运维"这个问题，目前能看到的所有严肃材料给出的答案都是一致的：被淘汰的是只会手工巡检、被动救火的那部分工作方式，而新增的价值点在另外几个方向——定义 SLO/SLI 和告警策略的灵敏度、设计混沌工程实验、维护 RAG 知识库与推理约束规则、审查 Agent 的决策边界、处理 AI 覆盖不到的新型复杂故障。

数据库运维领域的讨论也一样：智能预警能把"被动响应"变成"主动预防"，时序预测可以提前 48 小时甚至更早预判磁盘爆满风险，但作用域分析、规则制定、模型校准这些事仍然需要人来做。这个行业里比较务实的一句话是：AI 最擅长放大已有的秩序。如果你的日志没有结构、错误码没有规范、变更记录查不到、复盘没人写，那么再强的大模型也只能在混乱里猜。

所以 AIOps 真正的门槛，从来不在模型选型上，而在数据和流程治理上。先把这层做完，后面的每一分 AI 投入才有复利。