当工作的年限逐渐增加，关注点会从具体的技术转向业务。虽然定位仍然是架构师，但是偏向的更多是业务架构及能支撑这个业务架构的应用架构体系，特别是涉及到复杂业务时，共享复用的设计就更需要架构设计。近几年常看到的软件的技术架构也不乏精妙设计，学习时往往为之拍案。
Anyway，最近因工作需要，回归到运维领域，今日看看运维中台这个近期被炒热的理念。前期虽有接触，但理解较为浅薄，这篇文章仅仅记录我的一些思考。
本文关于中台的部分，参考OSCHINA在知乎的回答和《数据中台产品经理：从数据体系到数据平台实战》
什么是中台
中台的理念
中台这个概念的提出，最广为流传的故事应当是2015年年中马云参观 SuperCell 后感慨这家公司单个员工的创造价值为何如此之大——这家创造了年税前利润15亿美元的公司，却只有不到200名员工。
SuperCell的工作模式是这样的：谁都可以发起新的游戏创意，然后给组织几个人去实施，做出来看看，行不行，火了就进一步推广，风靡一把；火不起来，玩家不活跃，那这个创意立即终止，再来一个新的继续搞。而支撑SuperCell模式的是其游戏构建系统，能通过配置的方式，加上几个美工，系统自动生成一款全新的符合设计的游戏。事实证明，SuperCell 的这套新游戏研发系统已经炉火纯青了。
阿里中台的建设
既然中台是为了解决复用问题，那就需要明确前后台是如何通过中台复用的。根据广泛的理解，前台一般对应着一个具体的商业模式以及配套的用户应用（App、小程序等），对应阿里的中台架构图，前台就是一个个BU业务线。
根据资料，阿里的中台分为了业务中台和数据中台两个维度，业务中台的主要作用是更好地服务前台进行规模拓展与业务创新，所以业务中台集成了大量的组件化产品，使前台需要什么资源就能从中台获取什么资源，以确保前台具备更强的灵活性。
同时，阿里将以数据治理与数据建设等数据管理活动为特征的中台称为数据中台，旨在打破数据隔阂，解决企业面临的数据孤岛问题。从前台、后台流入的各类数据，经过中台的计算与产品化，构成了企业的核心数据能力，为业务提供数据服务与决策赋能。这样的业务与数据双中台的模式，为其他企业开辟了一条新的道路，于是各类中台在各企业内部逐步形成，并衍生出越来越多的中台形式。从形式上看，目前的中台有业务中台、数据中台、技术中台与组织中台等。
其中前台特有领域和中台领域之间的比例是按前台业务差异性不同而变化的，有些场景下，中台领域可以做的非常厚，厚到前台就剩一个前端应用（APP、小程序、PC站等）；有些场景下，中台可能只能做有限的抽象。
中台的本质是复用
SuperCell的理念+阿里的概念的提出，对管理层的冲击是比较大的，对于做管理的人来说，就会想着自己的公司是不是可以适用这样的一种模式：前台部门自己去闯，后台为前台提供足够强大的支撑，前台可以基于这个支撑实现快速的试错，尽量多复用少重复建设。这里就可以看出中台的本质了，中台本质就是如何复用。
在互联网企业或研发能力较强的公司，复用的发起往往是自下而上的，在我们公司也是一样的，同一个部门做了几个业务项目以后，就会发现诸如用户管理、菜单管理等等都是同质化的东西，搞研发的人天然对重复建设有一种抵触心理，就琢磨着是不是该建设一个通用的应用框架之类的东西；搞devops的也一样，建设一个通用的持续集成持续部署的平台，所有的应用都可以复用。
各大互联网中台建设，也都是打着中台的幌子在进行复用性设计战略实施，而且他们的战略实施都有个规律，都是从稳固底部做起，从下至上。究其原因，个人认为是互联网的业务的变化太快，往往只有执行层才能说清、搞明白业务到底是怎么跑的，才能抽象出符合自身的小中台（平台）。
思考：自下而上的复用是最容易形成的，但是自上而下的复用往往是困难的。公司基于复用的理由建设形成了一个平台，往往要花比建设更加大的力气去推广。有几个原因：执行层的学习成本、适用性、热点问题。
传统企业与互联网企业的横向发展模式不同，它们追求从生产到供应的全周期管理，以解决企业的供需关系问题。这种纵向探索的方式，需要由数据服务来承载，所以传统企业一直高呼数字化转型，因此传统企业的业务中台更倾向于数据能力建设。另外，从推动力方面来看，传统企业自下而上发起业务能力复用的中台的推动力不大，反而是数据中台的建设更能看到效果。
中台的建设分析
在OSCHINA的文章中，提出了一个思考，深表赞同。
很多时候，绝大多数人会认定一个死理，难以自拔，而究其本质是一旦大脑好不容易发现了某种理解可行时，不想再接受更多的反例，不愿意再去用第一性原则慢慢推导，这也是一种不想走出舒适区的表现。陷入极端陷阱后引发的问题是，当时你以一个高层领导的身份急着去拍了一个方案，实际上还有很多细节没想明白，这样大概率的结果就是项目烂尾。
作为管理层要慎重，要反复推敲思考自己脑子中的世界观模型下的公司里的结构模型是否合理，不要轻易下定结论。作为架构师也是如此，一方面需要不断补充知识去丰富自己构建思维模式的方式方法，另一方面也要细致推敲，避免架构设计中存在的执行陷阱，避免为了复用而复用所带来更高的复杂度。
中台的抽象
从黄金思维圈的角度来说，为什么要建设中台（why），就是为了共享复用，降低建设成本。接下来要解决的就是怎么建设（how）的问题。
中台是对管理者和架构的抽象能力的挑战，没有一个架构师可以在新问题上做出百分之一百与实际匹配的架构一样，也不会有一个统一的万能中台能在保证开闭原则的基础上适配所有业务。过度贪求高度复用，会陷入“强求陷进”——把不该抽象的东西硬是抽象到了一起，结果就是系统的复杂度并没有降低，而是从多个地方搬到了一个地方。因此，管理层想要的“全集团大中台、小前台”，是一种理想主义，注定难以实现，这其实也是业务建模不清晰的必然结果。
做中台最重要的还是能识别出用户、前台、后台都是什么，以及如何这几层之间是如何交互的。也就是识别业务对象和业务活动，形成业务建模，对业务建好模型以后，才能抽象出适用的通用层。这就又回到了EA（企业架构）理论上。业务架构需要首先抽象出来，然后根据业务架构来设计应用架构、数据架构和技术架构。
既然中台的本质还是复用，那么中台靠什么来区别于以前的诸如组件化、服务化？
中台概念的提出，从自上而下的企业架构视角来看，应该从更广和更深两个角度来看。
- 更广泛的复用：不仅仅是某一个业务，而应该跨业务条线来建设复用的能力，并不断思考不断扩大范围，形成跨BU的企业级的能力复用。（一把手工程？）
- 更深入的复用：抽象提炼出更深入的复用，将前台与后台可复用的功能都抽象到中台，并思考复用的形式。如用户验证，抽象出后台服务，也可抽象出前台登录组件或页面；如IM模块，后台必然抽象出后台对IM消息的发送和接收，前台可抽象出IM的边窗，消息提醒等等。
个人认为，仅仅是后台的抽象，还不足以称之为中台，只能称之为服务网关。必须要配备前台相关的能力，让前台开发时可直接从业务中台选用相应模块，免去从0到1的开发环节，使得前台将更多精力投放在匹配业务逻辑的功能联调上。
中台建设过程中，要着重避免的就是后台能力定制化的问题。业务中台抽象出的复用功能需要具备一定的弹性空间，从而得以应对更多的业务场景，避免造成单点和热点。
中台可能带来的单点和热点问题
中台的抽象必须考虑到单点和热点的问题，如果把一家大集团的所有主要业务系统都放到一个事业部去管理，而又不配备足以支撑的人力和物力，必然会带来单点和热点的问题。这个问题无论是大中小型企业，都是最容易碰到的。
所谓单点问题，指的是这个能力只有一个人/系统能提供，而一旦员工休假，系统宕机，这个业务就无法执行。好的公司会通过设置AB岗来解决，A岗离开了B岗还能顶上。好的系统会增加高可用，单点故障不影响集群对外提供的服务。但是这个也就带来了成本的问题，哪些需要设计成AB岗/高可用，这往往就取决于业务的必要性和系统的重要程度。（写到这里，引申出来一个问题，如果一个单点能承载多个功能/一个员工能随时随地切换工作，那是更好还是更差呢？）
所谓热点，指的是提供服务的人/系统，其服务能力跟不上需求，造成了业务的堆积和响应速度的下降。短暂的热点是可以忍受的，比如年终结算，财务部门人手不足，但是也就需要扛一两天，为了这一两天而给财务部门配备足够的人手是不合算的。但是长期的热点是无法忍受的，比如一个企业所有功能都在办公OA实现，需求排起了长队，响应不及时，影响了业务的开展，这时候就需要对OA的能力进行重构，或者增加新的业务系统来承载一些可抽离出去的功能。
对付热点的解决方法，在系统架构设计里很常见，增加配置，加节点，分库分表，读写分离，。在管理层面也很常见，就是加强人员能力（加配置），增加人手（加节点），划分职责（分库分表）。大道朝天，各走一边，殊途同归。中台也可以此参考。
数据中台的特殊性
业务中台是能力复用平台，它会抽象实际业务中的共有需求，为企业解决“重复造轮子”的问题。而数据中台将前台、后台及业务中台所产生的数据进行抽离，以此打破数据隔阂，解决企业面临的数据孤岛等问题，并以此为基础进行数据产品的落地建设，让数据资产的价值得以更好地发挥。
数据中台的建设往往不会遇到太大的壁垒，有两个方面的原因
- 项目成果能见度高，不管是数据治理（数据资产化），还是支撑业务决策（数据业务化），都能展现出数据中台的建设成果，为决策者增加信心。
- 对现有组织架构影响力小，数据中台主要是从各个系统中获取数据，不会影响各系统原有的运行，也不会对原有组织架构产生过多的影响。各个企业做数据中台，最多的方式是成立一个团队去落地，不会动到现有的组织。
那数据中台和数据仓库有何区别？
在《数据中台产品经理》一书中，对数据中台和数仓的区别主要概括了两点不同：数据实时性不同和业务目标不同。数据实时性指的是传统数仓的T+1的离线计算。业务目标不同指的是数据中台不仅面向关系型的报表，还提供各种分析能力，服务于前台业务。
数据实时性不同这一点，个人有点不以为然，在大数据和流计算快速发展的时候，19年的flink forward asia大会上就已经满是实时数仓的建设成果展示了，数据仓库的实时性已经有了极大的提高。业务目标不同倒是认可，这也带来了维度上的区分，个人认为数据仓库应该是数据中台的一部分，这两者业务目标不同，数据中台的范围更大。数据仓库属于数据工具的范畴，数据中台是数据工具、数据服务模式与数据运营机制的结合体。
运维领域的中台是什么
如果把运维看成一种业务的话，我们就需要区分出运维领域的用户、前台、后台。而后中台作为衔接前后台的中间层，就可以进一步明确其业务价值所在。
根据《工行侯志荣：一体化和自动化运维体系探索》一文提出的OASR模型，用户对应角色，前台对应各种运维场景所需要的场景功能平台，后台对应的应该是基础的能操作运维对象的业务活动。
那么运维中台所要解决的问题就是如何衔接前台和后台，中台所要实现的功能就是能力的编排，可以通过编排将各种业务活动进行拼装整合，形成前台各个业务场景下所需要的视图、操作页面等等。
举个例子，比如自动化操作，抽象出的中台就可以是流程编排+执行的操作中台，能编排流程，能执行，能反馈看结果，这个就自成一个闭环，在此之上的任何场景作只要不超过流程+执行这个范畴，就能很好的适用。剩下的就是根据需要做成一个个的前台页面或按钮就行（配套前端低代码平台？）。
以此为基础，将多个可复用的中台进行封装后，就形成了运维中台（待思考）。因此对于运维中台来说，应具有以下的功能：
- 拼装前台功能，可通过拼装（低代码）的方式，来快速实现前端所需要的视图、操作页面。
- 拼装后台功能，可通过编排的方式，将后台的能力进行封装，提供自定义的服务，并可被前台调用。
- 捏合前后台，形成可运行的功能。
- 配套数据的存储能力，能为前后端提供数据基础，为拼装提供数据支持。
