运维遇上中台，瞬间阵亡？我是这样理解的

手工运维
以人工作业为主要表现形式的运维，发布、故障处理、巡检等等

脚本化运维
用一些自动化脚本来代替人工作业，有一些发布的脚本封装了人为操作。

自动化平台运维
用平台可视化封装各种场景化作业，按照场景细分，通道、原子作业库、场景编排库都开始出现了，最终界面可视化操作完成。

数据化运维
动化部分代替了人的事务劳动，此时精细化运营的要求就出来了，而精细化运营的核心就是要借助数据来表达、驱动和优化，相关领域是ITOA。

智能化运维
行业也在提AI代替人的运维，基于模型和算法来把一些运维场景接管起来，比如说事件根因分析、故障影响分析、预测、异常探测等等。最终肯定是希望 AIOps 来实现无人化运维 NoOps。

过去的运维平台建设是碎片的，缺啥立项做啥，其中原因是：

没有整体规划设计
在我几年的创业过程中，也接触了多个行业的客户，能够提出整体规划设计的运维部门寥寥无几，而运维体系建设得好的公司恰恰都是那些做了整体规划的。

竖井式的组织架构
职能式的组织架构导致规划的完全割裂，独自建设。很有意思的是，在传统企业，A部门不了解B部门的平台建设内容。一个例子：联邦CMDB绝对是竖井式组织架构下的妥协结果。曾经见过一个金融企业，运维平台工具加起来有接近百个之多。

历史遗留的累积
历史遗留是不可回避的，但也是事实存在。历史遗留不可怕，可怕的是建设没有延续性，来了就重做，重新立项。我认为一定周期的重建是OK的，否则都是瞎搞。这个和IT发展规律一样，技术是有采用周期的。

过多倚重乙方服务支撑
大部分传统企业都是依赖乙方提供的解决方案，不同的乙方建设方案边界本来就有重复的，最后就变成各种交叉重叠，导致系统职责不清。建设了几年，发现没有很大的变化，还在原地踏步。今天甲乙双方的关系也要发生变化，更应该以“精益Partner”的方式来看待彼此，确保整个发展过程的延续性。

（编辑：PHP编程网 - 湛江站长网）

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