AIOps实战12根因分析与容量预测最费脑和最主动的两件事我是老计。这一篇给传统 AIOps 的核心场景收尾讲两件事根因分析运维最费脑的活故障来了怎么快速找到病根容量预测运维最主动的能力怎么在事情发生前就预知风险。一个是故障发生后的救火提效一个是故障发生前的未雨绸缪合起来讲完传统 AIOps 的主要场景就齐了。一根因分析为什么最费脑先讲根因分析。它是运维里最烧脑、也最能体现功力的活。难在哪故障发生时你面对的往往是一片混乱一堆告警同时炸、多个指标异常、一片报错日志各种现象交织。而这些现象里绝大部分是果不是因是被一个根本原因牵连出来的连锁反应。你要做的是在这一片乱象里快速找到那个最初的、真正的病根。这需要经验、需要对系统的理解、需要抽丝剥茧的推理极其耗费心力。更棘手的是现代系统又大又复杂服务几十上百个、依赖关系错综一个问题的影响会沿着依赖链条层层传播、放大。表面上看是 A 服务出问题追下去可能是 A 依赖的 B再追是 B 依赖的数据库再追是数据库所在的节点。这种层层追溯靠人工在复杂系统里做又慢又容易错。这正是 AIOps 想帮忙的地方。现代系统的故障很少是孤零零的一个点更像多米诺骨牌你看到满地倒下的牌却要回头找出第一张被推倒的。根因分析找的就是那第一张牌。二根因分析的核心思路那 AIOps 怎么帮着做根因分析核心就这么几条思路依赖推理。利用服务拓扑和依赖关系沿影响链条上溯。既然故障会沿依赖传播那就反过来从报警的服务出发往上游追定位到最上游那个最可能是源头的点。没有拓扑这张依赖地图根因推理就无从谈起这也是数据篇反复强调拓扑价值的原因。变更关联。故障与最近的变更强相关这是运维铁律。故障发生时自动拉出时间相近的变更作为高优先级的根因候选。多源关联。把告警、异常、日志、链路、变更多方信息关联起来综合分析而不是孤立看单一数据。一个根因的判定往往要多个证据相互印证而快速汇集关联散落信息正是 AIOps 的强项。带证据的排序而非黑盒结论。输出的不是一个武断的唯一答案而是按可能性排序的几个候选每个都附上支撑它的证据让运维能看懂、能验证、能采信。一个甩给你一个黑盒结论、又不给依据的根因分析运维是不敢信、也不敢用的。给证据、给排序、把判断权留给人才是负责任的做法。这几条里变更关联是我最想让你记住的一招因为它命中率高得惊人。我做 SRE 排障第一反应永远是先问最近改了什么。举个具体场景某次线上服务突然大面积报错一堆告警瞬间炸开。纯靠人从告警日志里一点点查可能要折腾很久但如果系统能自动把这个时间点前后的变更记录拉出来一眼就看到报错前几分钟有一次配置发布顺着这条线索去看那次发布改了什么根因很快就锁定了。这个过程人工做要靠经验和运气系统做则又快又稳前提是变更数据接进来了、和故障时间能对上。变更数据对根因分析的价值怎么强调都不过分。三根因分析的现实局限别神化它讲完思路我必须泼盆冷水因为根因分析是 AIOps 里最容易被过度吹嘘的能力。第一全自动、百分百准确的根因分析目前不现实。现实中的根因往往复杂、多因耦合、甚至是一些偶发的诡异问题。指望系统一键给出唯一正确的根因是不切实际的幻想。谁跟你说他的产品能全自动精准定位一切根因你要打个问号。第二它高度依赖数据的完整度。根因分析要靠拓扑、变更、多源数据来推理这些数据但凡有缺失比如拓扑不全、变更没记录推理就会断链、出错。数据地基不牢根因分析就是空中楼阁这又回到了数据的重要性。第三它的定位是辅助加速不是替代人。AIOps 根因分析真正的价值是把运维从大海捞针里解放出来帮你快速缩小范围、提供有依据的候选让你更快地做出判断。而不是替你拍板。AI 缩小范围、给出线索人做最终判断这是根因分析务实且成熟的定位。摆正这个定位你才不会因为它达不到全自动的幻想而失望也不会因为盲信它而踩坑。四容量预测从被动到主动说完根因分析这个救火的活再说容量预测这个防火的活它代表了 AIOps 从被动到主动的追求。容量预测要做什么基于历史数据预测未来资源的使用趋势提前发现容量瓶颈、预知风险好让你有时间从容准备。比如预测出某个资源照当前增长大概两周后会触顶那你就有充足的时间去扩容而不是等它满了才手忙脚乱地救火。这就是从被动救火到主动预防的价值。容量预测能做的事预测资源CPU、内存、磁盘、流量等的使用趋势、推算容量触顶的时间点、支撑扩容决策和成本规划、识别资源使用的异常增长。用得好它能帮你把容量问题消灭在发生之前。但同样要注意它的局限第一预测有不确定性要诚实给置信度。未来本就难料预测不可能百分百准。一个负责任的预测应该带上置信区间告诉你大概什么范围、有多大把握而不是给一个假装精确的数字。第二突发情况预测不了。预测是基于历史规律的对于历史上没有过的突发事件比如一次意料之外的流量洪峰、一次黑天鹅预测往往失灵。别指望它能预知一切容量规划仍要留有余量和应急预案。第三预测是为决策服务的别为预测而预测。预测的价值在于支撑你提前做扩容、成本等决策。如果预测出来没人看、不指导行动那就是自嗨。让预测真正嵌入你的容量管理流程它才有意义。小结这一篇给传统 AIOps 核心场景收尾讲了根因分析和容量预测根因分析最费脑难在故障时现象交织、要在复杂依赖里追溯真正病根。核心思路依赖推理(沿拓扑上溯)、变更关联(故障与最近变更强相关先看改了什么)、多源关联(汇集印证多方证据)、给带证据的排序而非黑盒结论。但别神化它全自动百分百准不现实、高度依赖数据完整度、定位是辅助加速非替代人。容量预测代表从被动到主动基于历史预测资源趋势、提前预知瓶颈、支撑决策但要诚实给置信度、预测不了突发、别为预测而预测。传统 AIOps 的核心场景到此讲完。下一篇进入第五板块我们专门讲大模型给运维带来的新范式LLM for Ops。延伸阅读《Site Reliability Engineering》Google SRE 官方在线书故障排查与容量规划章节sre.google/booksOpenTelemetry 官方文档链路追踪与服务依赖opentelemetry.io/docsPrometheus 官方文档容量相关指标与查询prometheus.io/docs时序预测方法综述可在 arXiv 检索 time series forecasting surveyarxiv.org本文为技术经验分享旨在梳理AIOps根因分析与容量预测的思路与局限。文中观点结合个人运维与SRE经验不构成具体产品或采购建议实际落地请结合自身环境评估。