这两年，很多运维团队都在讨论：AI 能不能自动定位线上故障？
如果只是做告警摘要、日志归类、异常趋势分析、排查建议生成，AI 已经能帮上忙。但如果希望它一接入系统，就能准确判断“根因在数据库、缓存还是某次发布”，那就要冷静一点。
线上故障不是标准题。一个接口超时，可能是慢 SQL，也可能是 Redis 抖动、线程池打满、第三方接口变慢、网络异常，甚至是刚上线的配置改错了。AI 想判断问题，必须先拿到足够可靠的上下文。
1. 监控指标要足够完整
很多系统说自己有监控，但故障时只看到 CPU 高、内存高、磁盘满、接口慢。这些指标能发现异常，却很难直接定位原因。
比如接口响应变慢，至少要同时看 QPS、RT、错误率、线程池、数据库连接数、慢查询、缓存命中率、容器资源、下游接口耗时等数据。
如果监控只覆盖主机层，AI 很可能只能给出“建议检查数据库”“建议查看日志”这类宽泛结论。不是 AI 不行，而是信息不够。
所以，AI 运维的第一步不是上模型，而是补监控盲区。
2. 日志要规范，不是一堆文本
日志是排查故障的重要依据，但很多系统日志质量并不高。
常见问题包括：只打印“error happened”，没有接口名、traceId、错误码、业务 ID；异常堆栈被截断；debug 日志长期打开；业务日志、系统日志混在一起。
AI 擅长从大量日志里提取相似错误，但前提是日志本身有价值。至少要包含时间、服务名、接口名、traceId、错误码、耗时、关键业务字段和异常摘要。
没有这些字段，AI 也只能猜。结构化日志越清晰，AI 聚合异常、串联请求、判断传播路径的效果越好。
3. 调用链关系要清楚
线上故障难就难在：报错的服务不一定是根因。
用户看到下单失败，可能是订单服务报错，但真正问题在库存服务、支付通道、数据库连接池，或者某个公共组件。
如果没有调用链，AI 只能看到多个服务同时告警，很难判断谁是起点，谁只是被影响。
调用链能告诉我们：请求从哪里进来，经过哪些服务，每一段耗时多少，错误在哪个节点出现。AI 基于这些数据，才能更合理地做告警排序和根因候选推荐。
4. 变更记录必须接入
很多故障复盘到最后，都会发现和变更有关：一次发布、一次配置调整、一次数据库索引变更、一次安全组修改，都可能引发线上问题。
但现实中，监控平台、发布平台、工单系统经常是分开的。故障发生后，大家在群里问：“刚才谁动过系统？”
如果 AI 能拿到变更时间线，比如什么时间、谁操作、改了什么、影响哪些服务，就能在异常发生时优先提示“请核查最近变更”。
这不代表所有问题都是变更引起的，但变更一定是排查故障时非常重要的线索。
5. 结果需要人工校正
AI 不适合一开始就直接自动执行生产操作。
它可以先做辅助：归并告警、总结异常、提取高频错误、推荐排查步骤、生成复盘草稿。至于是否重启、扩容、回滚、切流，仍然需要有经验的人确认。
原因很简单，线上系统有业务约束。有些服务不能随便重启，有些数据库不能高峰期改索引，有些任务暂停会影响结算。这些信息不一定都在监控里。
更稳妥的方式，是每次故障后把真实原因、处理过程、有效命令、误判点沉淀进知识库。AI 有了持续反馈，下一次才会更接近实际场景。
AI适合从哪里开始？
不必一上来就追求“自动定位所有故障”。
更现实的落地路径是从低风险场景开始：凌晨告警太多，让 AI 先做摘要；日志太多，让 AI 提取高频异常；排查方向不清，让 AI 根据指标和历史案例给建议；复盘耗时，让 AI 整理时间线和改进项。
这些场景不要求 AI 一次给出标准答案，但能减少值班人员大量重复劳动。
运维基础比AI更关键
我接触过一些企业，系统规模不小，但监控、日志、告警、资产、变更记录分散在不同地方。真正出故障时，大家都在群里发截图，很多时间花在对齐信息上，而不是定位问题上。江苏立维运维服务在做驻场运维、云运维、数据库运维和 7×24 保障时，通常会先帮助企业梳理这些基础：核心系统有哪些，关键指标看什么，日志保留多久，告警谁响应，变更怎么记录，常见故障如何形成手册。
这类工作看起来没有 AI 那么新，但它正是 AI 能发挥作用的前提。没有清晰的资产、监控和流程，AI 很难给出可靠建议；基础治理做好后，再引入智能分析，效果会稳很多。
如果准备做 AI 运维，建议不要一开始就追求全自动定位。可以先做一次运维现状梳理，把监控盲区、告警噪音、日志规范、数据库风险和值班流程理清楚。
AI 能让故障排查更快，但不能替代运维基本功。
监控完整、日志规范、链路清楚、变更可追溯、知识库持续更新时，AI 才能给出更有参考价值的判断。否则，它只是把不完整的信息重新组织一遍。
AI 自动定位故障，本质上不是单个工具问题，而是运维体系成熟度问题。先把数据打通，把流程理顺，再谈智能化，落地会更稳。
