这两年，运维团队聊AI的频率明显高了。
不少团队的第一反应是：能不能让AI自动看日志、自动找根因、自动修故障？
想法可以理解。毕竟夜里被告警叫醒，打开电脑面对几百行日志，谁都希望旁边有个“老运维”直接告诉你问题在哪。但真到生产环境里，事情没那么简单。
我接触过一些AI运维项目，最后卡住的往往不是模型能力，而是更基础的问题：监控数据分散、告警太吵、日志格式不统一、故障复盘没人维护、CMDB和真实环境对不上。
AI不是万能值班员，它更像一个经验助手。前提是，现场数据要能看懂，历史经验要能查到，处理流程要有人持续维护。
真实故障现场，比演示复杂得多
很多团队做AI运维，最想要的能力是“自动根因分析”。
比如线上接口超时，希望系统直接判断：是数据库连接池耗尽，还是网关转发异常，或者某个下游接口拖慢了整条链路。
但真实故障现场通常很乱。
一次接口异常，可能同时冒出几十条告警：CPU升高、接口超时、数据库连接异常、消息队列堆积、网关返回错误码。日志里刷出大量异常，不同系统的时间还可能有几秒到几十秒偏差。CMDB里的服务关系也不一定准确，有些实例早就下线了，配置还留在系统里。
这种情况下，让AI直接给出根因，风险很高。
更合理的顺序是：先把监控、告警、日志、资源关系整理清楚，再考虑让模型参与分析。否则输入数据本身就不可靠，输出结果也很难稳定。
第一步，不是上AI，而是先治理告警
很多值班人员最痛苦的不是没有告警，而是告警太多。
一次网络抖动，几十台服务器一起报警；一个数据库慢查询，应用层、接口层、网关层都跟着飘红。半夜手机响个不停，但真正需要处理的可能只有一两个关键事件。
所以AI运维的第一步，通常不是接大模型，而是先做告警治理。
实际项目里，我们一般会先看几件事：
第一，基础资源有没有统一纳管。
服务器、数据库、中间件、容器、接口、业务指标，如果分散在不同平台里，排障时就会反复切页面。
第二，告警有没有收敛。
同一个故障引发几十条告警时，系统至少要能识别哪些是源头告警，哪些是连带告警。
第三，服务关系能不能看清。
接口慢了以后，得知道它依赖哪些数据库、缓存、消息队列和第三方接口。
这一层可以选择商业监控平台，也可以基于开源体系自建。比如有些企业会用Prometheus、Grafana、ELK组合，也有团队会选OPSEYE这类偏企业级的监控平台，把资源监控、告警汇聚、事件收敛和业务视图放到一起做。
工具不是重点，重点是先让值班人员在故障发生时看清楚：到底哪一层先出问题，影响了哪些业务，后续告警是不是由同一个原因引起的。
这一步做不好，后面接再强的模型，也只是把混乱的数据换一种方式展示出来。
第二步，让日志和工单能被模型理解
老运维看日志，靠的是经验。
他知道哪些报错可以先忽略，哪些关键词一出现就要警惕；也知道某个系统每次报连接超时，真正原因可能不在应用，而在数据库连接池或者网络策略。
新人不一样，只能一行行翻日志，翻到最后还不确定自己有没有漏掉关键线索。
AI在这个环节能发挥作用，但不是“神奇判断”，而是帮人缩小范围。
比如：
- 找出故障前后突然增多的错误码；
- 摘出异常堆栈里最关键的几行；
- 对比历史工单，提示相似故障；
- 根据复盘文档给出排查顺序；
- 把处理过程整理成复盘初稿。
这类能力需要把日志、工单、知识库、复盘文档接起来。有些团队会基于大模型API自己开发，也有企业会使用XAPEX这类模型平台，统一管理模型调用、知识库检索和内部应用编排。
这里要注意一点：不要指望模型第一次接入就能准确判断所有故障。
更现实的做法是先从低风险场景开始，比如日志摘要、工单归类、相似故障推荐、复盘初稿生成。这些场景不直接影响生产操作，即使模型回答不完整，也不会立刻造成事故。
等团队积累了足够多的反馈，再逐步扩大使用范围。
一个制造企业的落地案例
之前接触过一家制造企业，核心系统包括MES、ERP、WMS，还有多套接口服务。生产排程、订单同步、仓储出入库都依赖这些系统。
他们以前的排障方式很典型：业务群里先有人喊“订单同步失败”，然后运维去看接口平台，数据库管理员去看数据库，应用负责人再去翻应用日志。每个人手里都有一部分信息，但没人能快速拼出完整链路。
有一次夜间订单同步失败，值班人员同时看到几类异常：接口超时、数据库连接数升高、消息队列堆积。因为信息分散，大家一开始都以为是接口服务问题，重启了应用实例，但问题没有明显改善。
后来复盘发现，真正的起点是某个数据库连接池配置偏小。订单高峰期连接数被打满，接口层开始超时，消息队列随后堆积，网关侧也出现错误。
这个项目后面没有直接做“AI自动处置”，而是分了两步。
第一步，把基础资源、数据库、中间件、接口和关键业务指标接到统一监控视图里，并对重复告警做收敛。值班人员可以先看到订单链路上哪些节点异常，而不是在多个平台之间来回切换。
第二步，把历史故障记录、告警文本、日志摘要和处理工单整理到知识库里，再接入模型能力。故障发生后，系统会提示这次异常和过去某次“数据库连接池耗尽”的故障相似，并把当时的日志片段、处理步骤和复盘结论列出来。
最后是否采纳建议，仍然由运维人员判断。但排查起点已经变了。
过去是先猜，再查；现在是先看链路，再对照历史经验。这个变化不炫，但对夜间值班很有用。
上线后也没有出现所谓“无人值守”的效果，但几个变化比较实际：重复告警少了，新人排查有了参考，复盘材料更完整，常见问题定位时间也更可控。
落地AI运维，最容易踩的三个坑
第一个坑，是数据没治理就急着谈智能。
同一个用户字段，A系统叫userId，B系统叫uid，C系统叫account；同一个异常，有的日志写错误码，有的只写“调用失败”。这种数据质量下，模型很难稳定分析。
第二个坑，是只买工具不改流程。
告警没人确认，误报没人标记，工单随手关闭，复盘没人维护，AI就拿不到反馈。没有反馈，系统很难越用越准。
第三个坑，是一开始就做自动处置。
自动清理临时目录、拉起测试环境进程、释放低风险资源，这类动作可以试。但核心生产故障不建议一开始就交给AI处理。
比较稳妥的路径是：
先做监控统一和告警治理；
再做日志摘要、相似故障推荐和知识库问答；
最后再把低风险、高频、规则明确的动作接入自动化脚本。
这条路看起来慢，但更适合生产环境。
运维不会消失，但工作方式会变
很多人关心AI会不会替代运维。
短期看，不太现实。生产环境的问题太复杂，业务影响、变更窗口、责任边界、回滚方案，都不是模型一句话能决定的。
但运维岗位的工作方式一定会变。
重复巡检、基础日志筛选、工单整理、复盘初稿这类工作会被压缩。更重要的能力会变成：理解业务指标、设计监控规则、判断自动化边界、沉淀故障经验。
AI可以给建议，但生产责任最终还是在人手里。
对企业来说，AI运维最实际的价值，不是演示时多炫，而是故障发生时，能不能帮值班人员更快看清现场、少走弯路。
