智能运维的下一站不是大屏：从告警收敛到闭环执行的四个现实约束

智能运维并不是一个新话题。过去几年，行业已经把监控大屏、告警收敛、日志检索和根因分析做成了标准配置；2025 年以来，随着大模型和智能体进入运维平台，“自动诊断、自动处置”又被寄予了更高的期待。

但把演示环境里的能力放到生产环境，问题很快会暴露：告警确实少了，责任却没有变清楚；根因建议有了，值班工程师仍不敢点“执行”；智能体可以调用接口，却说不清一次操作会影响哪些业务。智能运维的难点，正在从“能不能分析”转向“能不能在边界内安全地行动”。

一、第一道门槛不是模型，而是运维数据

AIOps 的效果高度依赖数据质量。指标、日志、链路、事件、变更、资产和配置关系，缺任何一类，模型都只能看到局部。很多项目一上来就接大模型，最后发现模型回答不准，根因不在模型，而在 CMDB 关系不完整、告警没有统一语义、变更记录和监控数据对不上。

2025 年发布的《信息技术服务智能运维第 2 部分：数据治理》（GB/T 43208.2-2025）把运维数据治理单独提出来，强调顶层设计、运维数据管理、数据供给和治理过程。这个信号很明确：智能运维首先是一项数据工程，而不是一个算法项目。

对准备建设 AIOps 的团队，至少要先回答三个问题：

这些问题不解决，模型越复杂，错误越难解释。

告警收敛是最容易被感知的 AIOps 能力，也是最快看到“效果”的地方。但如果只做收敛，不做告警分级、服务分级和责任归属，结果往往是把大量告警压成一个“大告警”，值班人员仍然不知道先处理哪一个。

更成熟的做法，是把告警治理和 SLO 放在一起：先定义什么是对业务真正重要的服务，再决定哪些告警需要立即响应、哪些可以进入工单、哪些只做趋势观察。AI 可以参与降噪、聚合和推荐，但告警的优先级和责任边界必须由人和流程来定义。

一个可操作的检查方法是：随机抽取最近一周的告警，逐条问“如果这条告警在凌晨三点触发，谁应该被叫醒，他到场后第一步做什么”。如果答案含糊，说明告警还没有完成治理，此时引入 AI 只会把模糊放大。

从“给出建议”到“自动执行”，是智能运维真正的分水岭。生产环境里，重启一个进程、扩容一个节点、切换一条链路，看起来都是标准动作，但每一次执行都可能带来连锁影响。

要让自动闭环可控，至少需要四件事：

国务院《关于深入实施“人工智能+”行动的意见》把安全能力列为八大基础支撑之一，强调人工智能应用的安全治理。放到运维场景，这意味着智能体不能只是一个“更快的脚本”，它需要有身份、有权限边界、有行为审计，也要有被随时收回的能力。

信创环境让智能运维的复杂度再上一个台阶。CPU 架构、操作系统、数据库、中间件和监控工具都可能与原有环境不同，日志格式、指标语义、接口协议和故障模式也存在差异。原来基于单一厂商设备训练的规则和模型，迁移到多架构环境后往往需要重新校准。

这也是为什么信创项目里的 AIOps 不能简单“复制一套平台”。更现实的做法，是先把运维数据模型做成厂商中立：统一资源标识、统一指标语义、统一事件模型，再通过开放接口接入不同厂商的工具。否则，AIOps 本身会变成一个新的孤岛。

同时，信创环境下的自动闭环要更保守。国产软硬件的版本迭代快，同一故障在不同版本上的表现可能不同，自动化规则需要更频繁地验证和更新。在信创环境里，“可回退”比“全自动”更重要。

智能运维不适合一次性建成。更稳妥的路径是分四步走：

衡量智能运维是否真的产生了价值，也不应只看“接入了多少数据源、上线了多少个模型”。更有意义的指标包括：告警准确率、平均定位时间、自动化处置占比、变更成功率、重复故障率，以及值班人员的工作负荷。