前段时间有篇文章朋友圈疯传,【中台搞了2年,项目叫停,CIO被裁!本以为中台是道送分题,没想到是送命题!】。从结果来说,这个项目肯定是失败的,文章中透露出中台是“最短的笑话”和”玄学”之类的表达。很多时候把中台看成一个技术课题,但做着做着发现不对,它又是一个组织课题和业务课题。在前不久的【数字化奇葩说】第一期关于ERP和中台的讨论,我也作为嘉宾参与并发表了个人观点【见文末】。其实想表达的是,能和中台扯上关系的太多了,回到运维领域,是否有一个运维中台存在?它是否是个玄幻话题?抑或是为了概念而概念?如果有,我们该如何抽丝剥茧的理解它呢?
*第一章,过去的运维平台建设思路*
从14年底开始,互联网运维理念兴起之后,传统行业也开始日益重视运维平台的建设。甚至按照运维平台的建设情况来划分运维成熟度水平,典型阶段划分如下:
过去的运维平台建设是碎片的,缺啥立项做啥,其中原因是:
围绕运维的目标:高可用、连续性、成本、效率和质量目标,碎片化的平台是没法提供协作能力的。而运维作为一个服务主体存在,它的服务化需要整合后端的各个能力,否则无法直接暴露给它的被服务部门。
*第二章,关于运维组织架构的讨论*
首先我想和探讨一下组织命题:康威定律和反康威定律。康威定律是组织架构影响IT系统架构的设计;反康威定律是IT系统也会影响组织架构设计。这个地方至少暴露出一个逻辑:组织架构和IT架构设计的匹配度问题。在文章开头讲的那个项目,如果组织架构不变,失败实在难免。一方面固化的组织架构无法改变人的思维模式,中台落地也是灾难;另一方面,中台落地之后,组织架构不适应调整,业务流程不再造,中台也是裹脚布。
运维组织架构过去一直是按照职能组织架构设计的,比如说网络管理、数据库管理、安全管理和一线NOC等等。在某些行业,为了打通这些职能,上面还设计了其他职能部门:运行调度管理、流程管理等等。很有意思的现象是:能力是职能部门建设,管理制度是上层部门制定的,这个时候脱节也是不可避免。
很早讲过今天的运维组织架构一定要“面向应用运维+运维开发”的组织架构来设计,以应用为中心来驱动整个运维协作过程,拉通前后端资源。个人很喜欢TOGAF架构,觉得应用架构是架构的核心,没有应用架构承上启下的作用,缺少管理支点。随着未来工作负载逐渐迁移到容器之上,你对应用的理解会更加深刻,云原生应用标准会更加的普及,应用的理解也会越来越普遍。运维开发是取决于平台的建设模式,是自研,是共研,是外研,这个要结合企业自己的情况来定。自研是需要投入大量的研发资源的,必须要按照业务系统研发的配置来做,是和规模大的企业;共研是核心能力外包给第三方,但是要求在开放源码的模式,一起开发,适合规模中等的企业;外研,就是把平台能力交给第三方,适合中小型企业。这样的组织架构是从业务和技术两个维度拉通了底层职能部门,保证了最终的运维服务化输出。
我们要注意模块化架构和服务中台化架构的区别。在18年底,我发现连续做了三年多的EasyOps产品,是个模块化产品,表现是多客户需求无法协调,开关随处可见,最糟糕的就是为某个客户做的开关。注意:模块化平台不等于碎片化平台!
随着我们服务的客户越来越多,行业越来越多,挑战就出来了——无法基于模块做公共能力抽象,让我们对客户需求的响应异常缓慢。造成此问题的核心原因,客户每次提的需求都要经历优维的每个角色(项目经理、产品经理、开发经理)。后来对产品做了一个定义:Product = Platform + Plugin。Platform就要基于业务域做公共能力抽象,如资源管理、应用部署、环境管理等等,这就是我所说的运维中台;Plugin 就要基于公共平台能力做个性化封装,我们称之为微应用。确定了这样一个产品架构,19年初,我们对公司组织架构做了一次调整(如下图)。“一个战略的落地必须要组织大脑先动”,必须要把屁股从原有的位置上挪开,才会产生新的思维模式。
组织架构调整到了,接下来就是业务认知的问题了。
*第三章,运维的业务领域是如何划分的?*
运维是一个复杂的过程,结合IT对象、人和目标来看,是一个非常复杂的课题,以前对外分享是从四个维度做过一些分析的:
此处不展开复杂的介绍,抛开这些复杂的因素,今天提出一个新的方法:运维生命周期分析法,先来看个例子:
用生命周期的观点来理解运维整个过程,运维生命周期过程包含四部分:
基于生命周期过程,把运维的生命周期过程框架抽象如下:
关于该生命周期过程,还可以进一步细化成不同的领域(Domain)业务模型。在这个地方,建议大家去了解和学习一下【领域驱动设计】知识,顺便推荐一本书《领域驱动设计 软件核心复杂性应对之道》,以便我们更好的掌握一些业务设计语言和思维,在此也不做赘述。基于生命周期过程,我把运维的业务领域划分成如下九个部分:
有了业务域的划分,运维平台的建设边界也就确定了,要反过来支撑业务。运维也是有业务领域驱动,做大而全的产品,推销大而全的方案,当下看基本上不靠谱。
*第四章,运维中台如何形成?*
前面把组织架构和业务领域都做了详细分析,它们都是重要的前置因素。对它们的影响不认识清楚,运维的中台建设无从谈起。接下来从技术的角度来看看运维中台如何形成的?有两种观点我们需要讨论一下:
运维中台是通过整合,迭代设计出来,不是一次性开发出来的。因此这个地方提供的集成方案是分四个层次(暂时用手绘):
有了这四层集成能力平台,给一个完整的运维中台例子(供参考):
*第五章,运维中台的行业化落地?*
深入到行业领域,也看看运维中台如何在行业落地的(银行,券商,运营商,保险)。这个问题其实是很复杂的,要兼顾企业的组织架构、系统现状、人力情况及业务目标来定。我反对为了中台而中台,过度投入和设计很可能都是灾难。不要寄希望于这些新概念和新名词(包括AIOps),否则就真的变成一个送命题。我给很多客户设计的运维平台体系架构,以服务驱动的运维平台体系的构建,如下:
服务是有业务目标的,服务的上下、横向关系,我们要非常清楚。ITSM如何和后端服务整合?自动化运维整个过程和场景如何提炼?数据化运维平台的数据类型是什么?数据类型的不同带来的技术和平台有什么变化?数据的IT运营价值如何进一步去提炼?数据如何进行整合关联和业务理解?如何从数据模型和数据服务上面去打通各个能力?
作为一个规模化服务实体(如我们或者大型机构的运维部门),此时需要从组织架构的角度打破壁垒,建设能力复用平台,做API全开放,还需要在此基础上提供一个快速开发环境RAD,把个性化定制能力推到业务部门。由此延伸出来对人员能力的要求是什么样的?运维开发team该如何去设置?各个运维职能小组内该如何配备相应的运维专家和运维开发人员?
运维研发体系需要做什么样的划分?中台开发和个性化开发如何形成赋能关系?中台开发一方面不断抽象提炼、共性化中台能力,另外还要结合IT趋势如何实现创新突破?这都是摆在运维复杂系统面前的课题。
更需要领导者对运维的业务目标有清晰的认识,业务目标决定后面的平台形态,切不可“唯技术论”或者“技术至上论”。一个小创业公司Excel是可以解决问题的,你非要给他推荐一个大管理系统,不合适。需要认识运维中台的本质,绝不是一个技术中台,更不是玄幻之术,而是先有生命周期过程,而后是业务域的划分。一方面也要把自己手里的存货价值搞清楚,不要一上来就推倒重来,另外一方面需要查缺补漏的部分,可以补充。
总结:切忌一上来就中台搞定一切,技术化理解中台。我们更应该关注中台背后的那些影响因素、服务体系和分块的能力建设,打好基础,再走向下一步:中台化。
接下来,基于中台,我还会写几篇文章:
*附录:【数字化奇葩说】,老王的观点:
1、中台和ERP的关系
观点:ERP是聚焦在企业内过程信息化管理;中台是聚焦在企业内外协同的过程统一数字化管理。
论述:ERP是基于一套管理理念,最终延伸出一套IT平台落地最佳实践,是企业内部全过程能力管理,其中分了多个模块实现;中台是数字化平台架构体系,分域分层建设的能力复用平台,ERP是部分企业的业务能力中台的一部分。
2、有了ERP,是否要建设中台?如何建?
观点:ERP平台是企业数字化中台的一部分,借助中台能力整合网关,中台建设更易形成。
论述:企业中台覆盖业务(应用)和数据两个领域,ERP作为企业业务的核心中枢平台之一,中台必须实现对其整合。通过API网关或者ESB技术实现企业应用集成,但中台的业务域还包含很多,特别是一些大型的互联网业务系统,中台还包含如积分、会员、支付、商品等等。
3、没有ERP,是否要建设中台?如何建?
观点:中台建设与ERP无关,它是对企业系统架构和组织架构一次全面重构升级。
论述:中台一方面要关注系统架构,更要关注组织架构和业务能力。没有匹配的组织架构,中台建设不起来,是属于无“脑”指挥;没有业务能力,中台建设也无从谈起,是属于无“心”执行。针对不同的业务领域,中台能力涵盖的范围会有所不同,而非必须要有ERP作为中台建设前提,如DevOps及运维、营销、敏捷供应链等等,垂直行业如地产、汽车、能源等等。