昨晚跟浙江移动晓征总畅谈很久，从狭义AIOps做根因分析引出，聊了AIOps的作用，跟SRE的关系，实践的总结，有很多共鸣，也碰撞出很多有意思的观点。

结合晓征总整理的，和我记录的，形成一篇文章，算是抛砖引玉，在AIOps经历了几年实践的基础上，再次探讨下AIOps这个话题。

以下是正文：

和兄弟们和以及江湖上的专家研讨了一番，居然哭笑不得地得出一个初步结论，抛抛砖：狭义上的AIOps存在严重泡沫。

几个观点：

第一、靠AIOps做根因定位靠不靠谱？

AI无论基于机器学习还是深度学习，都依赖于大量的数据。但运维场景往往需要从一次故障中汲取改进的力量，而这个是典型的小数据量建模，需要大量的常识、经验，需要用到归纳和演绎能力，而这些恰恰是人类的优势，现阶段的AI还难以支撑。

所以，实践中，在故障时，再依赖什么AIOps做根因定位，实践中没有成功过。原因也不难理解，因为每次故障的原因，都会跟之前不同，让AI去识别一个从来没见过的故障，也基本不太可能。

举个例子，如果让AI从图片中识别出一只猫？但是你从来没有给AI算法足够的猫的图片样本去学习，怎么能让AI知道什么是猫？

故障时的原因也是如此，如果遇到一个从来没触发过的因素，这时靠AI在这么复杂的体系里去识别这个因素就是根因，基本不太可能。

可行思路是什么呢？通过AI快速识别出局部最小粒度的故障，比如磁盘故障，CPU高，进程响应异常等，或网元粒度的故障，比如数据库异常、服务器异常、dns异常等；

然后咋做呢？目标是不定位，不处理，要让软件自身具备自愈能力，也就是反脆弱的能力，切换、限流、熔断，确保最快的速度隔离掉这些局部问题。

注意这一点需要站在客户感知视角，从应用到基础平台南北向端到端协同，来确定最佳隔离方案，单独站在网元视角来做，有效果，但一定不彻底。

这也是我常说的，云化实现了架构分层解藕，康威推进了组织内聚自治，但没有端到端的协同机制（架构设计上，故障响应上），这些组织将迅速从屠龙勇士蜕变成恶龙。

第二、狭义AI效果最好的是感知，是预测

运维中的关键一环（高价值密度）是故障应急，这个阶段又分为感知（眼）、分析（脑）和处理（手）三步。现阶段狭义AI效果最好的是感知（预测本质上属于感知plus）。

分析这一步遇到了二十年没突破的cmdb哲学问题，我们已经基本放弃了，同时也已经有其他路子可以替代，实操效果还不错，但主要还是用到广义ai（人类主导的基于规则的建模）而不是狭义ai。

第三阶段主要是SRE的代码作用，AI基本用不上。此外，运维数字化、智能化、研发化转型的基础-数据汇通+能力融通+组织拉通，也同样是依赖于人的因素啊。

第三、AIOps、DevOps和SRE是什么关系？

AI是眼睛，发现问题，通过SRE的OPS手段、提供架构上的逃生通道，通过SRE的DEV手段，让线上代码真正解决问题。

浙江移动提出的AIOpsDev就是这个思路，通过AI发现问题，用SRE作为Dev的手段提供代码化的自动化和反脆弱的能力，依靠SRE作为Ops的经验和知识创造逃生通道、设置执行规则。

其实我在17年的时候也同样表达过类似的思路，当时是思考AIOps的意义是什么。当时还写过一篇文章《AI时代，我们离AIOps还有多远？》，大家有兴趣可以看一下。

里面的这张图基本表达了AIOps和SRE的关系，只不过经过业界这三年的实践，跟晓征总探讨下来，中间的RCA根因分析这一步，其实是没有什么意义的，应该从第一阶段可以直接到第三阶段。

第四，运维真的会被机器或AI替代吗？

这种说法，纯属扯淡。江湖上沸沸扬扬人心惶惶的说法什么运维团队的人要被机器替代了，什么运维人员都被砍掉了，什么阿里云运维人员只有几十人啊，人均运维网元数怎么怎么高啊。

一部分是真的，被机器替代了一些人，但主要替代的是纯简单可重复操作的人，但大部分是扯淡，因为大量的工作仍然依赖于有经验的人！

只是这些人不是传统操作人员，而是具备软件工程思维、数智化思维、熟悉技术栈、懂得编程能力的新型运维sre。其实根据我这边的实操看，相当部分的传统二线转型sre是有可能的。

所以也不必过分担心什么运维人员被机器替代的问题。此外，有互联网公司疑似销售人员过度宣传的因素，这些人应该不是真正搞技术的，真正懂技术懂运维转型的互联网专家一般还是有节操的，不会胡说八道。

实际上运维转型以后，看你什么口径了，实际上整体大运维人数上升是常态，但一方面配比变了，有研发和架构能力的人员比例大增强，操作类人员比例下降。

一方面人均战斗力大大提升了是肯定的，云化以后单网元不稳定了，网元层次多了数量多了复杂度高了，所以以前是拼人肉，现在是拼经验拼算力拼数据拼代码拼机制，单兵战力当然大大提升了。

看看美军就知道了，军队数字化，步兵特战化，看着前面没几个兵，问题是看不见的那些人都是作战体系一环啊，同时战力大幅提升。