夜雨聆风研究AIOps已有大半年，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的大模型课程里。
我做AIOps的策略一直都是：能不动现有运维平台尽量不要动！做AIOps，不要妄图把整个运维体系推翻重建，因为你没有那个精力，而且你的老板或者你的Leader也不会同意！
AIOps真正要做的，不是再造一个“大而全”的新运维平台，而是把AI能力做成一个能接入、能复用、能管控的能力底座。
它不一定要求企业推翻原来的监控、日志、工单、发布和值班体系，也不需要所有团队都迁到一个新入口里。
更现实的路径是：把AI能力沉到基础设施和运维流程中，通过API、插件、连接器等方式，嵌入现有系统，让原来的工具在原地完成智能化升级。
这不是简单的产品形态差异，而是落地路径的差异。
01 | AIOps的关键，不是“统一平台”，而是“提供能力”
对于一些体系比较分散、工具老旧、流程混乱的企业来说，平台化建设确实有价值。但问题是，如果一开始就奔着“大一统”去做，项目通常会变得很重。
因为这意味着要重新设计数据模型、流程系统、权限体系，还要推动大量系统迁移和组织协同。平台越大，建设周期越长；迁移越深，见效越慢。等真正进入业务场景时，资源和耐心可能已经消耗得差不多了。
AIOps的核心价值，其实不在于换一套页面，而在于它能不能真正插进生产流程里。
比如：告警来了，能不能更快判断是不是误报？故障发生了，能不能帮忙缩小排查范围？工单流转时，能不能自动生成处置建议？发布前，能不能提前识别风险？处置过程中，能不能把一些低风险动作自动化执行？
这些才是业务真正关心的东西。
所以，AIOps优先要解决的，不是谁来做入口、谁来做平台，而是AI能力怎么低成本、可复用地供给给现有系统。
从这个角度看，比起重做一个平台，更值得投入的是一个AI能力中台，或者更准确地说，是一个AI能力层。
02 | 为什么“大而全平台”越来越不划算
企业里的运维体系，通常不是一天建出来的。
监控、日志、CMDB、工单、发布、自动化、值班系统，背后都有自己的历史原因，也承载着真实的组织分工。想用一个新平台一次性替掉，听起来很理想，实际推进时往往很难。
主要会遇到三类问题。
第一类是系统问题。
数据模型不统一，接口规范不一致，上下游依赖复杂。方案评审时看起来都能接，真正落地时才发现到处都是适配成本。
第二类是组织问题。
平台替换不是单纯的技术动作，它往往还会带来职责、权限和流程的重新划分。系统接入已经不容易，组织协同往往更难。
第三类是价值问题。
业务部门并不关心你是不是上线了一个新门户。他们更关心的是：故障恢复有没有更快？误报有没有更少？值班压力有没有降低？线上风险有没有被提前发现？
所以很多AIOps项目最后卡住，不是因为模型不够先进，也不是因为概念不够新，而是接入太慢、迁移太重、见效太晚。
03 | 真正可落地的AIOps中台，应该具备什么能力
一个有价值的AIOps能力层，不是简单接一个大模型，也不是做几个问答机器人。它至少要沉淀下面这些能力。
1. Agent编排能力
运维场景通常不是一次问答能解决的。
一个告警背后，可能要经历告警理解、服务识别、变更比对、日志检索、指标分析、拓扑关联、根因判断、处置建议等多个步骤。
如果没有编排，Agent更像一个“会聊天的助手”；有了编排，Agent才可能变成可以进入生产流程的能力。
也就是说，AIOps不能只回答“你觉得是什么问题”，还要能一步步把排查链路跑起来。
2. Skill能力
AIOps真正要沉淀的，不只是模型能力，更是动作能力。
比如查SLO、拉日志、查最近变更、比对配置、查询链路、触发回滚、创建工单、通知负责人，这些都应该被封装成可复用的Skill。
这样一来，运维经验就不会只停留在某几个专家脑子里，而是能逐步变成系统能力。
以后遇到类似问题，不同团队、不同系统都能复用同一套能力，而不是每次重新写脚本、重新接接口。
3. 标准化接入能力
现实里的运维工具一定是异构的。
监控有监控的系统，日志有日志的平台，工单有工单的流程，发布有发布的工具。指望它们一夜之间统一，基本不现实。
所以AIOps中台必须有标准化接入能力。
不管是连接器框架，还是类似MCP这样的协议思路，核心都是一件事：让外部工具的能力可以被Agent和Skill稳定调用。
否则，AIOps很快就会被集成成本拖垮。每接一个系统都重新开发一遍，后面基本就跑不动了。
4. RAG和知识接入能力
运维领域其实不缺信息，缺的是能被快速用起来的上下文。
SOP、复盘报告、架构说明、历史工单、变更记录、值班经验，往往散落在不同系统里。人要找都很费劲，更别说让AI直接判断。
所以中台需要把这些知识源接进来，做好检索、重排、权限控制和引用追溯。
但这里也要注意，RAG不是万能的。知识质量不高、文档长期不更新、权限边界不清楚，都会影响最终效果。
所以这层能力不只是“把文档丢进去”，而是要把组织知识整理成AI真正能用、也敢用的上下文。
5. API与嵌入能力
这一层非常关键。
AI能力不能只放在一个新页面里，等着用户主动打开。更好的方式，是把它嵌进用户本来就在用的老运维系统里。
比如：在告警页面直接给出根因分析；在工单页面生成处置草案；在发布系统里提示风险点；在值班群里自动汇总故障进展；在复盘环节自动整理时间线和改进项。
用户不需要换入口，流程不需要重学，组织也不用重新调整，AIOps才更容易真正落地。
6. 治理能力
AIOps一旦进入生产，就不能只追求“聪明”，还必须可控。
哪些场景可以自动执行？哪些动作必须人工确认？模型给出的建议怎么审计？高风险操作怎么审批？结果不可靠时怎么降级？出了问题怎么追溯？
这些都不是附属功能，而是上线前提。
尤其是在自动化处置场景里，治理能力比模型能力还重要。没有治理，AIOps很容易停留在演示阶段，看起来很炫，但很难真正进生产。
7. 度量与评估能力
AIOps不能只展示“回答得像不像”，还要证明它到底有没有带来业务价值。
一个能力值不值得长期投入，不能只看页面多好看、模型多先进，而要看它有没有真正改善指标。
比如：MTTR有没有下降？告警降噪率有没有提升？误报是不是减少了？自动化处置率有没有提高？故障定位时间是不是缩短了？值班人员的负担有没有减轻？
没有度量，中台很容易变成不断堆功能。有了度量，团队才知道哪些能力真的有效，哪些只是看起来热闹。