运维遇上中台，送分或送命？而我理解的运维中台是这样

前段时间有篇文章朋友圈疯传，【中台搞了2年，项目叫停，CIO被裁！本以为中台是道送分题，没想到是送命题！】。从结果来说，这个项目肯定是失败的，文章中透露出中台是“最短的笑话”和”玄学”之类的表达。很多时候把中台看成一个技术课题，但做着做着发现不对，它又是一个组织课题和业务课题。在前不久的【数字化奇葩说】第一期关于ERP和中台的讨论，我也作为嘉宾参与并发表了个人观点【见文末】。其实想表达的是，能和中台扯上关系的太多了，回到运维领域，是否有一个运维中台存在？它是否是个玄幻话题？抑或是为了概念而概念？如果有，我们该如何抽丝剥茧的理解它呢？

*第一章，过去的运维平台建设思路*

从14年底开始，互联网运维理念兴起之后，传统行业也开始日益重视运维平台的建设。甚至按照运维平台的建设情况来划分运维成熟度水平，典型阶段划分如下：

• 手工运维 以人工作业为主要表现形式的运维，发布、故障处理、巡检等等
• 脚本化运维 用一些自动化脚本来代替人工作业，有一些发布的脚本封装了人为操作。
• 自动化平台运维 用平台可视化封装各种场景化作业，按照场景细分，通道、原子作业库、场景编排库都开始出现了，最终界面可视化操作完成。
• 数据化运维 自动化部分代替了人的事务劳动，此时精细化运营的要求就出来了，而精细化运营的核心就是要借助数据来表达、驱动和优化，相关领域是ITOA。
• 智能化运维 行业也在提AI代替人的运维，基于模型和算法来把一些运维场景接管起来，比如说事件根因分析、故障影响分析、预测、异常探测等等。最终肯定是希望AIOps来实现无人化运维NoOps。

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

• 没有整体规划设计 在我几年的创业过程中，也接触了多个行业的客户，能够提出整体规划设计的运维部门寥寥无几，而运维体系建设得好的公司恰恰都是那些做了整体规划的。
• 竖井式的组织架构 职能式的组织架构导致规划的完全割裂，独自建设。很有意思的是，在传统企业，A部门不了解B部门的平台建设内容。一个例子：联邦CMDB绝对是竖井式组织架构下的妥协结果。曾经见过一个金融企业，运维平台工具加起来有接近百个之多。
• 历史遗留的累积 历史遗留是不可回避的，但也是事实存在。历史遗留不可怕，可怕的是建设没有延续性，来了就重做，重新立项。我认为一定周期的重建是OK的，否则都是瞎搞。这个和IT发展规律一样，技术是有采用周期的。
• 过多倚重乙方服务支撑 大部分传统企业都是依赖乙方提供的解决方案，不同的乙方建设方案边界本来就有重复的，最后就变成各种交叉重叠，导致系统职责不清。建设了几年，发现没有很大的变化，还在原地踏步。今天甲乙双方的关系也要发生变化，更应该以“精益Partner”的方式来看待彼此，确保整个发展过程的延续性。

围绕运维的目标：高可用、连续性、成本、效率和质量目标，碎片化的平台是没法提供协作能力的。而运维作为一个服务主体存在，它的服务化需要整合后端的各个能力，否则无法直接暴露给它的被服务部门。

*第二章，关于运维组织架构的讨论*

首先我想和探讨一下组织命题：康威定律和反康威定律。康威定律是组织架构影响IT系统架构的设计；反康威定律是IT系统也会影响组织架构设计。这个地方至少暴露出一个逻辑：组织架构和IT架构设计的匹配度问题。在文章开头讲的那个项目，如果组织架构不变，失败实在难免。一方面固化的组织架构无法改变人的思维模式，中台落地也是灾难；另一方面，中台落地之后，组织架构不适应调整，业务流程不再造，中台也是裹脚布。

运维组织架构过去一直是按照职能组织架构设计的，比如说网络管理、数据库管理、安全管理和一线NOC等等。在某些行业，为了打通这些职能，上面还设计了其他职能部门：运行调度管理、流程管理等等。很有意思的现象是：能力是职能部门建设，管理制度是上层部门制定的，这个时候脱节也是不可避免。

很早讲过今天的运维组织架构一定要“面向应用运维+运维开发”的组织架构来设计，以应用为中心来驱动整个运维协作过程，拉通前后端资源。个人很喜欢TOGAF架构，觉得应用架构是架构的核心，没有应用架构承上启下的作用，缺少管理支点。随着未来工作负载逐渐迁移到容器之上，你对应用的理解会更加深刻，云原生应用标准会更加的普及，应用的理解也会越来越普遍。运维开发是取决于平台的建设模式，是自研，是共研，是外研，这个要结合企业自己的情况来定。自研是需要投入大量的研发资源的，必须要按照业务系统研发的配置来做，是和规模大的企业；共研是核心能力外包给第三方，但是要求在开放源码的模式，一起开发，适合规模中等的企业；外研，就是把平台能力交给第三方，适合中小型企业。这样的组织架构是从业务和技术两个维度拉通了底层职能部门，保证了最终的运维服务化输出。

我们要注意模块化架构和服务中台化架构的区别。在18年底，我发现连续做了三年多的EasyOps产品，是个模块化产品，表现是多客户需求无法协调，开关随处可见，最糟糕的就是为某个客户做的开关。注意：模块化平台不等于碎片化平台！

随着我们服务的客户越来越多，行业越来越多，挑战就出来了——无法基于模块做公共能力抽象，让我们对客户需求的响应异常缓慢。造成此问题的核心原因，客户每次提的需求都要经历优维的每个角色（项目经理、产品经理、开发经理）。后来对产品做了一个定义：Product = Platform + Plugin。Platform就要基于业务域做公共能力抽象，如资源管理、应用部署、环境管理等等，这就是我所说的运维中台；Plugin 就要基于公共平台能力做个性化封装，我们称之为微应用。确定了这样一个产品架构，19年初，我们对公司组织架构做了一次调整（如下图）。“一个战略的落地必须要组织大脑先动”，必须要把屁股从原有的位置上挪开，才会产生新的思维模式。

组织架构调整到了，接下来就是业务认知的问题了。

*第三章，运维的业务领域是如何划分的？*

运维是一个复杂的过程，结合IT对象、人和目标来看，是一个非常复杂的课题，以前对外分享是从四个维度做过一些分析的：

此处不展开复杂的介绍，抛开这些复杂的因素，今天提出一个新的方法：运维生命周期分析法，先来看个例子：

用生命周期的观点来理解运维整个过程，运维生命周期过程包含四部分：

• 资产交付。完成一个从预算、采购到上架的过程过程管理，到加电状态。
• 资源交付。按照业务和应用的需求，完成一个OS级的资源交付过程，会涉及到云的资源交付，这也是今天CMP的核心定位。
• 应用交付。OS交付到应用部门之后，应用从部署到运行的过程，这是今天DevOps的核心定位。
• 运营管理。在各类资源在生产运行的过程中，要辅助各种运营管理手段、监控、事件、变更、可用性，连续性等管理

基于生命周期过程，把运维的生命周期过程框架抽象如下：

关于该生命周期过程，还可以进一步细化成不同的领域（Domain）业务模型。在这个地方，建议大家去了解和学习一下【领域驱动设计】知识，顺便推荐一本书《领域驱动设计 软件核心复杂性应对之道》，以便我们更好的掌握一些业务设计语言和思维，在此也不做赘述。基于生命周期过程，我把运维的业务领域划分成如下九个部分：

• 资产管理域（资产预算、采购和交付管理）
• 资源管理域（统一IT资源管理）
• 资源交付域（统一云管）
• 应用交付域（部署态）
• 应用运行域（运行态）
• 服务交付域（部署态）
• 服务运行域（运行态）
• 运营管理域（流程管理）
• 运营调度域（运营管理）

有了业务域的划分，运维平台的建设边界也就确定了，要反过来支撑业务。运维也是有业务领域驱动，做大而全的产品，推销大而全的方案，当下看基本上不靠谱。

*第四章，运维中台如何形成？*

前面把组织架构和业务领域都做了详细分析，它们都是重要的前置因素。对它们的影响不认识清楚，运维的中台建设无从谈起。接下来从技术的角度来看看运维中台如何形成的？有两种观点我们需要讨论一下：

• 运维中台是一套全新的技术平台 如果谁这么说，我觉得是忽悠偏多的。千万注意，不要一上来就说要做一个新的运维中台，危险的想法！ 运维中台绝不是一个全新的东西，必须要照顾企业过去的运维平台建设情况，当然不合理的部分该修理就要修理，该重建就要重建。就拿ITSM来说，无法流程协作，就需要修理；业务中台所依赖的技术中台部分大部分都是要重建，命令通道、数据通道、服务编排等等。
• 运维中台是一套能力平台的整合，协作形成运维业务价值的输出 很多公司的运维平台已经建设了部分，可以兼顾现有的系统建设现状，提供能力平台的整合，面向业务场景实现协作，这个才是正确的思路。在今天运维平台采购建议中，我给所有甲方的一个核心建议：谁不开放API，开放了后续API要定制，这种平台都可以不考虑。但今天在国内，由于2B服务商都喜欢贪大求全，什么都做，最终导致能力不断重叠，给客户也造成了困扰，比较喜欢聚焦模式，聚焦在一个业务域做深做透。

运维中台是通过整合，迭代设计出来，不是一次性开发出来的。因此这个地方提供的集成方案是分四个层次（暂时用手绘）：

• 基于门户的URI集成。实现各个平台入口级的整合，可以形成面向个人的四大入口：任务入口、服务入口、信息入口、产品入口
• 基于微应用的UI集成。用微应用重新封装服务中台的能力API服务，实现个性化的服务输出。
• 基于中台的API集成。通过统一API服务网关，把多平台的能力整合起来，统一服务输出给上层微应用模块。
• 基于CMDB的数据集成。这个类似于servicenow的“one data model”的思想，实现所有数据的集成（不包括动态数据）。

有了这四层集成能力平台，给一个完整的运维中台例子（供参考）：

• 通用能力层。是技术中台的部分，是公共化技术能力的封装
• 服务中台层。是按照业务领域构建的可复用的业务能力平台，一定要注意是按照业务域划分的。
• 微应用层。是按照个性化能力封装的，数据和自动化能力的个性化。
• 门户层。底层能力越来越多，复杂，屏蔽底层的复杂业务细节，需要门户来做多个维度收敛。

*第五章，运维中台的行业化落地？*

深入到行业领域，也看看运维中台如何在行业落地的（银行，券商，运营商，保险）。这个问题其实是很复杂的，要兼顾企业的组织架构、系统现状、人力情况及业务目标来定。我反对为了中台而中台，过度投入和设计很可能都是灾难。不要寄希望于这些新概念和新名词（包括AIOps），否则就真的变成一个送命题。我给很多客户设计的运维平台体系架构，以服务驱动的运维平台体系的构建，如下：

服务是有业务目标的，服务的上下、横向关系，我们要非常清楚。ITSM如何和后端服务整合？自动化运维整个过程和场景如何提炼？数据化运维平台的数据类型是什么？数据类型的不同带来的技术和平台有什么变化？数据的IT运营价值如何进一步去提炼？数据如何进行整合关联和业务理解？如何从数据模型和数据服务上面去打通各个能力？

作为一个规模化服务实体（如我们或者大型机构的运维部门），此时需要从组织架构的角度打破壁垒，建设能力复用平台，做API全开放，还需要在此基础上提供一个快速开发环境RAD，把个性化定制能力推到业务部门。由此延伸出来对人员能力的要求是什么样的？运维开发team该如何去设置？各个运维职能小组内该如何配备相应的运维专家和运维开发人员？

运维研发体系需要做什么样的划分？中台开发和个性化开发如何形成赋能关系？中台开发一方面不断抽象提炼、共性化中台能力，另外还要结合IT趋势如何实现创新突破？这都是摆在运维复杂系统面前的课题。

更需要领导者对运维的业务目标有清晰的认识，业务目标决定后面的平台形态，切不可“唯技术论”或者“技术至上论”。一个小创业公司Excel是可以解决问题的，你非要给他推荐一个大管理系统，不合适。需要认识运维中台的本质，绝不是一个技术中台，更不是玄幻之术，而是先有生命周期过程，而后是业务域的划分。一方面也要把自己手里的存货价值搞清楚，不要一上来就推倒重来，另外一方面需要查缺补漏的部分，可以补充。

总结：切忌一上来就中台搞定一切，技术化理解中台。我们更应该关注中台背后的那些影响因素、服务体系和分块的能力建设，打好基础，再走向下一步：中台化。

接下来，基于中台，我还会写几篇文章：

• 【深入解析运维自动化框架】
• 【CMDB，统一数据模型的价值】
• 【基于统一公共服务网关的平台能力集成】
• 【运维中台配上低代码开发模式，绝佳的组合】

*附录：【数字化奇葩说】，老王的观点：

1、中台和ERP的关系

观点：ERP是聚焦在企业内过程信息化管理；中台是聚焦在企业内外协同的过程统一数字化管理。

论述：ERP是基于一套管理理念，最终延伸出一套IT平台落地最佳实践，是企业内部全过程能力管理，其中分了多个模块实现；中台是数字化平台架构体系，分域分层建设的能力复用平台，ERP是部分企业的业务能力中台的一部分。

2、有了ERP，是否要建设中台？如何建？

观点：ERP平台是企业数字化中台的一部分，借助中台能力整合网关，中台建设更易形成。

论述：企业中台覆盖业务(应用）和数据两个领域，ERP作为企业业务的核心中枢平台之一，中台必须实现对其整合。通过API网关或者ESB技术实现企业应用集成，但中台的业务域还包含很多，特别是一些大型的互联网业务系统，中台还包含如积分、会员、支付、商品等等。

3、没有ERP，是否要建设中台？如何建？

观点：中台建设与ERP无关，它是对企业系统架构和组织架构一次全面重构升级。

论述：中台一方面要关注系统架构，更要关注组织架构和业务能力。没有匹配的组织架构，中台建设不起来，是属于无“脑”指挥；没有业务能力，中台建设也无从谈起，是属于无“心”执行。针对不同的业务领域，中台能力涵盖的范围会有所不同，而非必须要有ERP作为中台建设前提，如DevOps及运维、营销、敏捷供应链等等，垂直行业如地产、汽车、能源等等。