前段时间，朋友圈里有一篇文章火了，【中台创业2年，项目停工，CIO下岗！还以为中台是发子题，没想到是命题！】.从结果来看，这个项目肯定是失败了。文章透露，中台是“最短的笑话”、“玄学”。很多时候把中国和台湾当成技术问题，但是做了之后发现不对。这也是一个组织问题和业务问题。不久前，我也作为嘉宾参加了关于ERP与中国台湾的【数字奇谈】第一期[见文末]发表个人看法。其实我想表达的是，能和中台相关的东西太多了。回到运维领域，有没有运维中台？这是一个幻想的话题吗？还是为了概念而概念？如果是这样，我们如何概括地理解它？第一章，过去搭建运维平台的想法始于2014年底，互联网运维概念兴起后，传统行业也开始越来越重视运维平台的搭建的运维平台。甚至根据运维平台的建设，划分了运维的成熟度等级。典型的阶段分为：部分自动化脚本替代人工，部分发布脚本封装人工操作。自动化平台运维通过平台可视化封装各种场景化操作。按照场景的细分，通道、原子作业库、场景编排库都已经开始出现，最后完成界面可视化操作。基于数据的运维自动化部分取代了人工事务性劳动。这时候精细化运营的需求就出来了。精细化运营的核心是借助数据来表达、驱动和优化。相关领域是ITOA。智能运维业界也在推动AI替代人工运维，基于模型和算法接管部分运维场景，如事件根因分析、故障影响分析、预测、异常检测等。最后肯定是希望AIOps实现无人运维的NoOps。过去运维平台的建设是碎片化的，不需要立项。原因是：没有统筹规划设计。在几年的创业过程中，我也接触过各行各业的客户，能够提出运维的整体规划设计。部门很少，运维体系完善的公司恰恰是统筹规划好的。筒仓式组织结构职能组织结构导致规划与独立建设完全分离。有趣的是，在传统企业中，A部门并不了解B部门的平台建设内容。举个例子：联邦CMDB肯定是silo组织结构下的妥协。我曾经见过一家金融公司，有近百个运维平台工具。历史遗留的积累历史遗留是不可避免的，但也是事实。历史的遗留问题并不可怕，可怕的是建设没有连续性，来了又要重做，重新立项。我觉得重建一定时期是可以的，否则都是废话。这和IT发展的规律一样，技术都有采用周期。过多依赖乙方服务支持传统企业大多依赖乙方提供的解决方案，不同乙方建设方案的边界本来就是重复的，最终变成各种重叠，导致系统职责不清。经过几年的建设，发现并没有什么大的变化，依旧原地不动。如今，甲乙双方的关系也在发生着变化，更应该以“精益合伙人”的眼光看待对方，以保证整个开发过程的连续性。围绕运维目标：高可用性、连续性、成本、效率、质量目标，碎片化的平台无法提供协同能力。但运维作为服务主体存在，其服务化需要整合各种后端能力，否则无法直接暴露给其服务部门。第二章论述了运维的组织结构。首先，我想讨论一下组织命题：康威定律和反康威定律。康威定律是组织结构影响IT系统架构的设计；反康威定律是IT系统也会影响组织结构的设计。这个地方至少暴露了一个逻辑：组织结构与IT架构设计的匹配度。文章开头提到的项目，如果组织架构不变，失败在所难免。一方面，固化的组织架构无法改变人们的思维方式，中台的落地也是一场灾难；另一方面，中台落地后，组织架构不适应调整，不再重构业务流程，中台也是一块裹脚布。过去，运维组织架构是按照职能组织架构设计的，如网络管理、数据库管理、安全管理、一线NOC等。在一些行业，为了打通这些功能，上面还设计了其他的职能部门：作业调度管理、流程管理等。一个很有意思的现象是：能力是职能部门建设的，管理制度是由职能部门制定的。上级部门。这个时候，断线是不可避免的。我很早之前就说过，今天的运维组织架构设计必须是“面向应用运维+运维开发”的组织架构。我个人喜欢TOGAF架构。我感觉应用架构才是架构的核心。应用架构没有承前启后的作用，也缺少管理支点。未来随着工作负载逐步向容器迁移，大家对应用的理解会更深入，云原生应用标准会越来越流行，大家对应用的理解也会越来越普遍。运维开发取决于平台的建设模式，是自研、联合研究，还是外研，要根据公司自身情况确定。自研需要投入大量的研发资源，必须根据业务系统研发的配置进行，适合大型企业；合作研究是将核心能力外包给第三方，但需要以开源模式共同开发。适用于中型企业；外研是把平台能力交给第三方，适合中小企业。这样的组织架构从业务和技术两个维度把底层职能部门串联起来，保证运维服务的最终输出。在服务上要注意模块化架构和台系架构的区别。2018年年底，我发现自己做了三年多的EasyOps产品是一个模块化的产品，表现为多个客户的需求无法协调，开关随处可见，最糟糕的是事情是为某个客户做的一个开关。注意：模块化平台不等于碎片化平台！随着我们服务的客户越来越多，行业越来越多，挑战也随之而来——我们无法基于模块抽象出公共能力，这使得我们对客户需求的响应速度极慢。这个问题的核心原因是，客户每次提出需求，都要经过宇视的每个角色（项目经理、产品经理、开发经理）。后来给产品做了一个定义：Product=Platform+Plugin。平台需要基于业务领域抽象出公共能力，如资源管理、应用部署、环境管理等微应用。确定了这样的产品结构后，在2019年初，我们对公司的组织架构进行了调整（如下图）。“一个战略的实施，需要大脑的组织先行。”需要将臀部从原来的位置移开，才能产生新的思维方式。组织架构调整好之后，接下来就是业务认知的问题。第三章，运维的业务域是如何划分的？运维是一个复杂的过程。结合IT对象、人员和目标，这是一个非常复杂的主题。以前对外分享一些分析都是从四个维度来做的：这里就不展开复杂的介绍了，抛开这些复杂化的因素，今天提出一个新的方法：运维生命周期分析法。我们先来看一个例子：用生命周期的角度来理解整个运维过程。运维生命周期过程包括四个部分：资产交付。完成从预算、采购到入库、再到开机状态的全流程流程管理。资源交付。根据业务和应用需求，完成一个OS级的资源交付过程，会涉及到云资源交付，这也是当今CMP的核心定位。应用交付。OS交付给应用部门后，应用从部署到运行的过程是当今DevOps的核心定位。运营管理。在各种资源的生产运行过程中，需要辅助各种运行管理方法，基于生命周期过程的监控、事件、变更、可用性、连续性等管理。运维的生命周期流程框架抽象如下：关于生命周期周期流程还可以进一步细化为不同领域（Domain）的业务模型。在这里，我建议大家去了解和学习一下【领域驱动设计】的知识。顺便推荐一本书《领域驱动设计 软件核心复杂性应对之道》，让我们更好地掌握一些业务设计语言和思维，这里不再赘述。基于生命周期流程，我将运维业务域分为以下九个部分：资产管理域（资产预算、采购和交付管理）资源管理域（统一IT资源管理）资源交付域（统一云管理）应用交付域（部署态）应用运行域（运行态）服务交付域（部署态）服务运行域（运行态）运营管理域（流程管理）运营调度域（运营管理）随着业务域的划分，运维平台公司的建设边界也确定了，需要依次支撑业务。运维也是业务领域驱动的。做大而全的产品，推广大而全的解决方案，目前基本靠不住。第四章，如何组建运维中心？前面已经详细分析了组织结构和业务领域，它们是重要的前置因素。不清楚它们的影响，就谈不上运维中台的建设。接下来，我们从技术角度来看一下运维中心是如何形成的？有两个观点需要讨论：运维平台是一个全新的技术平台。如果有人这么说，我认为这太过分了。小心，不要一上来就说要搭建一个新的运维平台，那是很危险的想法！运维平台绝不是一个全新的事物。必须兼顾公司过去的运维平台建设。当然，对不合理的部分必须进行维修和重建。以ITSM为例，如果不能进行流程协同，就需要修复；业务中台所依赖的大部分技术中台部分都需要重新构建，比如命令通道、数据通道、服务编排等。运维平台是一组能力平台的集成，它们协同形成运维业务价值的输出。很多企业已经搭建了自己的部分运维平台，可以兼顾系统建设的现状，提供能力平台的整合，实现业务场景。合作才是正道。在今天的运维平台采购建议中，我给各位甲方一个核心建议：谁不开放API，开放后后续API需要定制，这种平台可以无视。但是今天在中国，因为2B服务商什么都贪，什么都做，最终导致能力重叠，给客户带来麻烦。运维中心是通过集成迭代设计的，不是一次性开发的。因此这里提供的集成方案分为四个层次（暂时手绘）：基于Portal的URI集成。实现各平台入口层级的整合，可形成个人四个入口：任务入口、服务入口、信息入口、产品入口基于微应用的UI整合。通过微应用对服务平台的能力API服务进行重新包装，实现个性化的服务输出。基于中台的API集成。通过统一的API服务网关，整合多个平台的能力，统一服务输出到上层微应用模块。基于CMDB的数据集成。这类似于servicenow的“一个数据模型”思想，实现了所有数据（不包括动态数据）的整合。综合这四层能力平台，给出一个完整的运维中台示例（供参考）：通用能力层。是技术平台的一部分，是公共技术能力的封装服务平台层。是按照业务领域构建的可复用的业务能力平台。必须注意的是，它是按照业务领域来划分的。微应用层。它根据个性化能力、数据个性化和自动化能力进行打包。入口层。底层能力越来越复杂，屏蔽了底层复杂的业务细节，要求门户多维度融合。第五章，运维平台的产业化？深入到行业领域，也看看运维平台在行业（银行、证券公司、运营商、保险）是如何实现的。这个问题其实很复杂，要综合考虑公司的组织架构、制度状况、人力状况、经营目标等因素来决定。我是为了中泰而反对中泰的。过度投资和设计很可能是灾难。不要寄希望于这些新概念新名词（包括AIOps），否则真的会成为命题。我为很多客户设计的运维平台系统架构，以及服务驱动的运维平台系统的构建，是这样的：服务是有业务目标的，我们要非常清楚服务的纵横关系.ITSM如何与后端服务集成？如何细化自动化运维的全流程和全场景？数据运维平台的数据类型是什么？不同数据类型带来的技术和平台有哪些变化？如何进一步提炼数据的IT运营价值？如何整合数据，理解业务？如何从数据模型和数据服务上开放各种能力？作为大型服务主体（比如我们或者大型组织的运维部门），需要从组织架构上打破壁垒，搭建能力复用平台，API全面开放，提供在此基础上快速开发环境RAD将个性化定制能力推向业务部门。由此延伸出来的人员能力有哪些要求？如何组建运维开发团队？每个运维功能组应该如何配备相应的运维专家和运维开发人员？运维研发体系应该做怎样的划分？中台发展与个性化发展如何形成赋能关系？中台发展一方面在不断抽象、提炼和概括中台能力，另一方面如何结合IT趋势实现创新突破？这些都是复杂系统运维面临的问题。更需要领导对运维的业务目标有清晰的认识。业务目标决定了背后的平台形式，不能有“唯技术论”或“技术导向论”。小型初创公司Excel可以解决问题。你给他推荐一个大的管理系统是不合适的。需要了解运维平台的本质，运维平台绝不是技术平台，更不是天方夜谭的技术，而是先有生命周期流程，再有业务领域的划分。一方面，你自己手里的存货要算清楚它的价值，不要一上来就推翻。另一方面，您可以补充需要检查和填写的部分。总结：不要一上来什么都被中台搞定，从技术上了解中台。更应该关注中台化背后的影响因素、服务体系、细分能力建设，打好基础，迈向下一步：中台化。接下来基于中台，写几篇文章：【运维自动化框架深度剖析】【CMDB，统一数据模型的价值】【基于统一公共服务网关的平台能力整合】】【运维中台配备Low-code开发模式，极品组合】附录：【数字故事】，老王观点：1.中台与ERP关系观点：ERP重在流程信息化管理企业内部；中泰专注于企业内外协同的过程统一数字化管理。讨论：ERP是在一套管理理念的基础上，最终延伸出一套IT平台实施的最佳实践。是企业内部的流程能力管理，分为多个模块；中间平台是一个数字化平台架构体系，分域和分层构建能力复用平台，ERP是一些企业业务能力中心的一部分。2、有了ERP，是否需要搭建中台？如何建设？观点：ERP平台是企业数字化中台的一部分。借助中台整合网关的能力，中台的建设更容易形成。讨论：企业中台涵盖业务（应用）和数据两大领域。ERP作为企业业务的核心中枢平台之一，必须实现其集成化。企业应用集成是通过API网关或者ESB技术实现的，但是中台的业务领域也包括很多，尤其是一些大型的互联网业务系统，中台还包括积分、会员、支付、商品等3。.没有ERP，还需要搭建中台吗？如何建设？观点：中台建设与ERP无关。是对企业系统架构和组织架构的全面重构和升级。讨论：中台一方面要注重制度架构，更要注重组织架构和业务能力。没有配套的组织架构，中台建设无从谈起，是缺乏“大脑”指挥；没有业务能力，谈不上中台建设，就是缺乏“心”的执行力。对于不同的业务领域，中台能力的范围会有所不同，并不一定要有ERP作为中台建设的前提，比如DevOps和运维、营销、敏捷供应链等。垂直房地产、汽车、能源等行业。
