自动化运维下一步怎么走？从告警聚合到事件智能的五级跃迁

答案先说：自动化运维真正卡住的地方，不是采集不到数据，而是数据到了之后没人能把它变成判断。多数团队的第一级早就过关了，卡点在第二级——把两百条告警还原成一个事件。

这个判断在 2026 年被行业重新表述了一次。Gartner 把传统 AIOps 平台重新定位为「事件智能解决方案」（Event Intelligence Solutions），不再以接入了多少数据源为卖点，而看它能不能把跨域事件串起来、解释清楚、并推动处置落地。

ManageEngine OpManager在这条路径上的位置，是把网络侧的采集、拓扑与工作流放在同一个底座上：事件进来时带着设备、链路与依赖关系，处置动作能直接落到设备或工单上。

十年前讨论自动化运维，争议点在采集——协议不全、设备杂、私有 MIB 拿不到。今天这个争议基本消失了：SNMP、流数据、日志、接口都能接，指标数量从几百涨到几万。但值班的人并没有因此轻松。

原因在于采集解决的是「看得见」，而运维真正花时间的是「看得懂」与「动得了」。一台核心交换机的一个端口开始丢包，可能同时触发：端口错误包增长、上联链路利用率上升、下游三台服务器的响应时间变长、两个业务的成功率下降。四条链路、十几个对象，在告警列表里就是几十条独立记录，人要靠经验把它们归成一件事。

这也是为什么 RFC 8632 在定义告警管理模型时，把告警的生命周期写成「上报、确认、清除」，而不是「产生、发送」：告警本身不是终点，能被关联、被确认、被清除，才算完成了一次事件处理。标准层面早就把重点放在后半段，只是很多平台的产品重心还停在采集。

2026 年，Gartner 把 AIOps 平台这一品类重新定位为「事件智能解决方案」（Event Intelligence Solutions），并把这类能力放进基础设施与运营技术成熟度曲线的上升段。行业里过去说的智能运维、智慧运维，多数时候指的是同一件事，但这次的表述把「智能」从一个形容词换成了五条可以勾选的能力。

对照它公开的能力定义，这五条是：

　　① 跨域事件采集：不只接监控工具，还要能接基础设施、网络、应用与云原生的告警与事件流。
　　② 事件关联与富化：把重复通知合并去噪，并补上拓扑、服务、责任人、优先级等上下文。
　　③ 模式识别与聚类：用历史基线识别或预测关键事件，并把运维人员的处置反馈当成强化信号。
　　④ 处置与自动化：给出建议动作、自动执行，或触发外部自动化流程。
　　⑤ 拓扑采集与组装：把跨域的服务拓扑组装出来，包含物理位置、逻辑依赖与资产关系。

这五条对做选型的人有一个直接用处：招标文件里写「具备 AI 能力」无法验收，写这五条才能验收。反过来，拿这五条给自己的平台逐项打分，也能立刻看出缺的是哪一块——多数企业的答案会落在第二条与第五条上。

需要说明的是，Gartner 的完整报告是付费内容，本文只引用其公开的能力定义，不涉及具体评分与厂商排名。

把这五条能力按「数据变成动作」的顺序重新排一遍，就是下面这个五级模型。它描述的不是产品版本，而是能力台阶：可以跳级采购功能，但跳不过踩坑。这套模型不区分行业与规模，任何一轮自动化运维建设都可以拿它对照。

　　第一级 · 采集：把该看的数据接进来。
　　第二级 · 关联：把多条告警还原成一个事件。
　　第三级 · 推理：说清楚这个事件为什么发生。
　　第四级 · 处置：让事件在平台上被处理掉。
　　第五级 · 闭环：让这次处理改变下一次的处理。

每一级都配一个可自测的判据和一道自评题。判据用来对外汇报，自评题用来对内定位——如果自评题答不上来，说明这一级还没有真正落地，哪怕采购清单上打了勾。

判据：核心资产清单里纳入采集的比例，以及数据从产生到可查的延迟。两个数字都要给——只报覆盖率，会把延迟问题掩盖掉。

自评题：随便挑一次半年前的真实故障，把当时需要看的指标列出来，看今天有几项能在一个页面里直接查到。答不上三项以上，说明采集有盲区。

常见卡点有三个。一是只采了网络设备，虚拟化层与云上资源在清单外；二是 SNMP 超时被当成设备离线，实际是采集器并发打满；三是采了指标没采流数据，带宽类问题只能看到结果、看不到来源。

这一级需要的前提很朴素：一份可信的资产清单，加一条统一的采集通道。资产清单通常来自网络发现，采集范围则由网络拓扑决定——拓扑上画不出来的设备，往往也就是采集里漏掉的那批。

判据：一次真实故障产生的事件数不超过五条，且能分出主事件与派生事件。如果一次故障在群里刷出五十条消息，这一级就没有过。

自评题：上周最长的那次故障，从第一条告警到最后一条，你一共看到了多少条？能不能一眼指出哪一条是主事件？

关联做不好的典型表现是「按时间去重」：把同一个时间窗里的告警合并成一条，数量看起来降了，实际把不同原因的事件也揉在了一起。有效的关联要按依赖关系做——交换机端口、上联链路、受影响的服务器、受影响的业务，一条链上的告警归到同一个事件下，链外的保持独立。这样压出来的事件，才带着可用的上下文。

还有个前提常被忽略：关联依赖拓扑与依赖关系，而拓扑本身会漂移。端口改接、虚拟机迁移、服务拆分之后，旧拓扑会把关联带偏。所以这一级和拓扑维护是绑在一起的，不能只做一次。

关于「怎么把数量压下来」，网络告警风暴怎么根治？「分级压缩五步法」从每天300条降到10条已经给了一套分级压缩的具体做法；本文要补的是另一半——压完之后，事件要能被下一级用起来，而不是被丢进一个更大的列表。配合自适应阈值之类的动态基线，还能进一步减少由固定阈值带来的伪事件。

判据：根因结论可以被复核。给出一条链路证据，而不是一句「疑似交换机问题」。可复核的意思是，另一个不当班的人拿着结论能自己验证一遍。

自评题：上一次复盘，结论写的是「重启后恢复」，还是「因为 X 导致 Y，Y 又触发 Z」？前者是现象记录，后者才是推理。

这一级最常见的错误是把相关性当因果：CPU 高的时候故障发生了，不等于 CPU 高导致了故障。要排除这种误判，需要两样东西——历史基线，以及变更与事件的时间线对照。很多「莫名其妙的抖动」，在时间线上都能对上一次发布、一次配置变更或者一次批量任务。

工具能帮的部分是把候选范围收窄：从告警直接跳到拓扑上的上下游节点，再按时间窗排序。收窄之后仍然需要人判断，但判断的起点从「全网」变成了「三个节点」。这也是根本原因分析真正的价值所在——不是替人下结论，而是把结论的搜索空间压到人还能处理的大小。

判据：重复性事件里，由平台自动完成第一步动作的比例。注意是「第一步动作」，不是「全自动修复」——第一步通常是限流、重启单个服务、切换链路，或者自动开一张带上下文的工单。

自评题：最近十次同类告警，有几次是人工点了同一个按钮？如果有六次以上，这个动作就该被固化下来。

这一级真正的阻力不在技术，在信任与权限。三个问题必须提前答清楚：动作执行失败怎么回滚；谁批准这类动作在什么条件下自动执行；执行记录能不能审计。答不清楚，团队就会一直停在「只通知、不动作」——这也是很多自动化运维平台上线后使用率不高的真实原因。

所以处置动作应该从低风险、高频、可回滚的那一类开始：重载配置、清理临时文件、重启单个服务、按预案切换链路。等这些动作的成功率与回滚率都有数据了，再谈更高风险的动作。落地时，IT 工作流自动化负责把动作串成流程，网络自动化负责把流程落到设备，必要时还可以通过开放接口接进已有的运维平台。

判据：同一类事件的复发率在下降，同时处置动作库在增长。两个指标要一起看——只看复发率下降，有可能是团队把这类告警直接关掉了。

自评题：过去三个月，处置手册更新过几次？如果一次都没有，说明处理经验还留在个人脑子里，没有进入系统。

闭环的最小形态不是一套复杂系统，而是一张固定格式的复盘表：事件是什么、判断依据是哪条链路、做了什么动作、动作效果如何、下次遇到同类事件第一步做什么。填满二十张之后，动作库自然就有了，模型也有了可训练的历史样本。

这一级做得好不好，有一个很直观的外部信号：新人值班时，遇到同类事件的处理时间是否接近老员工。接近，说明知识已经从人身上转移到了系统里——这才是AIOps这类能力最终要落的地方，而不是停在几张演示看板上。

把五级整理成一张表，方便在复盘会上逐行对照。用法是找最靠前的那一行空白——只要某一级没达标，后面几级的投入基本都会被它抵消。

把五级放到真实团队里看，分布很不均匀。第一级几乎人人都有，因为采集是采购时的默认项；第二级是分水岭，过不去的团队，后面几级基本无从谈起；第三级只有少数团队能做到结论可复核；第四级与第五级往往停留在试点，或者只覆盖两三个高频场景。

补齐顺序建议按投入产出比排，而不是按级别硬推：

　　先补第二级。关联的投入最小、收益最直接。拓扑维护加上事件富化，就能把一次故障的消息量降一个数量级，值班体验立刻不同。
　　再补第三级。有了干净的事件，推理才有意义。这时候补基线库与变更时间线，成本比从零建低得多。
　　第三级与第五级可以并行做小的。每次复盘固定填一张表，处置动作从风险最低的那几个开始固化，两条线互相喂养。

还有一个常见的理解偏差：很多人把 AIOps 直接等同于自动做根本原因分析，其实那是第三级；第四级与第五级要解决的，是把结论变成动作、再把动作变成记忆。少了后两级，再准的结论也只能停在一封邮件里。

有一条顺序不能反：不要跳过第二级直接买第四级。没有关联的自动化，执行的是未经归并的告警——误报也会被自动执行一遍，故障面反而扩大。这是本文最想强调的一句：自动化的前提不是权限，是干净的输入。

1. IETF RFC 8632《A YANG Data Model for Alarm Management》（告警上报、确认、清除的生命周期与关联管理模型）

2. OpenTelemetry Semantic Conventions（跨域遥测数据的命名与语义约定）

说明：文中五级模型为通用实践归纳，请结合自身规模与运维流程调整；文中引用的事件智能能力定义来自 Gartner 的公开页面，完整报告为付费内容；产品能力以官方页面为准。

一句话总结：自动化运维的下一步不是接更多数据，而是把数据变成事件、把事件变成动作；五级模型里最该先补的是第二级「关联」，因为越过它去买自动化，等于把误报也一起自动化了。

网络告警风暴怎么根治？「分级压缩五步法」从每天300条降到10条

网络管理智能运维（AIOps）落地实践：机器学习如何实现异常检测与根因推荐

OpManager x AIOps：开启智能运维新时代