主动感知在智能运维中的实践

，横坐标代表服务规模。公司业务不断增长，服务规模也相应增长，此处我们简单理解为这是一个线性的变化，不考虑业务的暴增。

然而，业务规模增长反映到运维的复杂度增长上最少体现在三个层面：

• 服务规模的增长直接导致服务器量及网络量的增长，随之而来的是网络拓扑的增长。 

• 业务增长，服务的技术栈也是增长的。以前可能前边跑一个服务，后边跑一个数据库就可以了，现在随着服务规模的不断增长，引入不同服务形式，可能就有了队列、缓存等，相应的，技术栈也不断增加。 

• 服务拓扑不断增长。以前可能一个烟囱型的服务就可以了，而现在随着微服务的应用，服务之间的调度非常多，需要增长服务拓扑来满足需求。

随着服务规模的增长，运维复杂度呈现指数级增长，那运维人员是否也随着增长了呢？纵观各司，答案是否定的。出于节约成本的考虑，各司各岗位人员并不会随着服务复杂度增加而扩张，反而是越来越趋于平稳。基于这个比例，相当于运维复杂度越来越高的情况下，运维人员越来越少了。

中间的差距如何来弥补呢？这就需要运用到运维手段了。即上图所示的：运维质量=运维人员 X 运维手段。运维人员要通过各种运维手段来解决运维困境，进而推动运维的发展。的缺点也越来越明显，主要表现为时间过长、成本过高，不能适应快速多变的需求。于是从工程或运维的角度自发出现了一种文化：DevOps，DevOps强调运维、研发及QA工程师工作的高度融合，要求运维从工程交付的角度不断迭代。

同时从企业IT管理或运营诉求出发也要解决快速演进的问题，于是演化出了标准ITOM。ITOM和ITSM很像，区别是把“S”改成“O”，即把Operation本身及其带来的各种自动化工具纳入模型中，包括主机、运营、发布系统等等。

• DevOps不断发展演变成现在的ChatOps，ChatOps的目标是将研发、运维、QA融合起来，以说话（Chat）的方式进行交流，但 ChatOps 只考虑了交流的形式，并没有就如何实现基于 Chat 方式的整体解决方案，ChatOps 并没有很好的解决 DevOps 的困境。 

• ITOM把所有的Operation线上化、自动化后，发现IT运维所产生的大量数据是非常有意义的，特别是对于企业数字化而言，这些数据经过加工分析，可以对日常业务产生价值。于是Gartner提出了一个新的标准“ITOA”。ITOA强调IT数据的价值，提出对IT运维分析的诉求，但没说明这个数据能干什么。很快Gartner就将ITOA演化成“AIOps”。这时AIOps中的“AI”是指“Algorithm（算法）”，强调的是数据分析本身产生的价值，包括通过算法来解决线上故障发现、日常交互等运维问题。
  

（编辑：我爱故事小小网_铜陵站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!