中台不是童话！王子和公主真的幸福吗？

　　中台不是童话！王子和公主真的幸福吗？

　　来源 | 映客技术

　　作者 | 刘志强 （ 脸哥 ）

　　中台，绝对是近2年互联网最火的话题之一，不信问问你家公司hr小姐姐，简历上带中台字眼绝对会成为她们眼中的加分项。

　　然而业界对中台的反响和态度实在是冰火两重天。

　　先是”不做中台会死吗“各路媒体跪舔，仿佛没有中台公司就没法生存似的；此后中台百家齐放，除了热门的业务中台、数据中台之外，原来称之为平台的技术平台、移动平台、推荐平台等等，摇身一变从平台改口叫中台，也都蹭上了中台这个热点。

　　然后”中台，信了你的邪“等文章开始刷屏，曝出 CIO / CTO / 技术VP 多家技术高管因为中台在企业落地不利被开除，媒体又开始有集体唱衰中台的趋势。

　　中台就像坐过山车一样，不停的经历着起起伏伏。

　　这也没办法，中台概念诞生时间不长，并没有明确的定义和标准，所以中台到底好不好使，就像”PHP是不是最好的语言“一样，永远只有争论而没有结论。

　　好了，言归正传。映客，一家专注于音视频互动和社交探索的企业，为了低成本高效率的持续性创新，同样进行了中台的建设。

　　本文接下来会介绍映客中台的建设过程，并分析中台在映客顺利落地的几个关键要素：业务阶段、技术能力、组织协作和企业文化。希望对中台有迷茫的同行提供一些借鉴和参考。

　　一、背景介绍

　　映客，从公司成立之日起持续推出耳熟能详的产品：16年引领了千播大战的移动直播产品映客直播，18年全民线上答题疯狂撒币的直播答题产品芝士超人，19年线下相亲线上化的直播相亲产品对缘等等。

　　连续推出成功产品的背后，离不开公司对创新的持续性探索。公司自16年开始不断加注音视频互动和社交方向的创新力度，以 1 v 1、1 v 多、多 v 多 等实时音视频的产品形态，去拓展不同人群和场景；为了提高创新业务的协作效率，分别为每个业务线配备了独立的产品研发运营团队。

　　在16年初期，创新业务只有两三个，每次只需要直接拷贝已有的代码，就能快速高效的搭建一个新的App并快速上线。到了19年同时并存的创新业务已多达数十个，每个新业务上线仍以拷贝代码为主，而这种低效的方式已经造成了各方的不满。

　　技术方面，同一个业务系统被不同创新业务团队拷贝，并行存在多个版本，业务系统并没有形成很好的沉淀；由于创新业务平均存活周期不长，技术同学很少有机会积累对业务系统的理解，有些系统出现问题甚至只能求助原系统的技术同学，导致原系统技术同学疲于应对。技术同学内心os：我基本不怎么生产代码，我好像只是在做代码的搬运工？

　　业务方面，虽然音视频互动产品具有极高的业务相似性，但由于是不同技术团队负责，导致拿到的业务数据无法统一口径，业务之间做业务探讨时会发现数据竟然无法互相参考。业务同学内心os：咱们和别人的产品差不多啊，为啥两边数据没法对齐呢？技术不是复制粘贴了他们的代码吗？

　　老板方面，业务之间的数据指标不统一，无法直观评判每个创新业务的优劣，业务决策效率低；每个创新业务都有预算，而业务初期成本大头在人力上，人力成本大头在技术团队上，相似的业务做了2年了还是需要这么多人这么长时间。老板内心os：每个创新团队2年前就这么多人，为啥都2年了出活还是这么慢，没一点儿长进吗？

　　总之，无论是从技术到业务，还是从老板到员工，大家都逐渐不能接受原来的低效工作方式。于是，中台建设终于被提上了日程。

　　二、中台建设

　　基于业务诉求和各方痛点，我们首先明确了中台目标和定位：提供基于音视频互动和社交业务的整体解决方案，具备快速搭建创新产品的能力和业务数据的标准化能力；通过提高创新业务研发效率和业务决策效率，来提高公司整体的创新效率。

　　既然是提供整体解决方案，所以中台的能力至少包含以下几点：

　　l     基于音视频互动和社交相关的业务服务API接口能力

　　l     与业务服务相对应的移动客户端业务组件SDK（Android / iOS）

　　l     与业务服务相关联的业务数据自动收集、处理、分析、呈现等数据能力

　　总之，中台解决方案需要涵盖移动客户端、服务端和大数据，以业务服务为核心，打通从移动客户端到业务服务以及大数据整条链路的各个环节。

　　以基础的单人视频直播为例，中台不仅要提供诸如开关播、弹幕聊天、礼物打赏等服务的API接口能力，还要提供移动客户端配套的相关业务组件SDK，以及直播相关业务数据自动收集和处理等能力。此外，视频直播业务背后的包括机器和人工的内容审核的支撑能力，以及直播秒开和卡顿等质量优化能力，也需要包含在中台提供的能力范畴之内。

　　基于对中台的目标和定位，我们参考了业界案例，以业务中台和数据中台为前台业务提供能力输出。整体的中台规划如下图所示：  

映客中台规划示意图

　　业务中台提供包含用户、金融、直播等音视频互动和社交方向的共性业务能力，如用户中心、金融中心、直播中心等业务能力；

　　数据中台提供如DAU、新增 / 留存、使用深度 / 频度、用户结构、渠道质量等基础数据能力；以及与业务相关的数据能力；如金融业务的充值、打赏、提现等业务数据；直播业务的开播时长、观看时长、主播分级、用户分级等相关业务数据。

　　在中台建设启动之前，我们做了一轮公司技术能力的盘点。

　　首先，后台服务已经完成了从单体服务到服务化以及平台化的演进过程，在演进过程中将C++、PHP、Python等多语言收拢为Golang单一语言，并以Golang服务框架和中间件为基础完善了服务治理等基础设施的建设工作。

　　其次，音视频互动和社交相关的业务系统和客户端组件大部分已完成沉淀，如用户、金融、直播等核心业务系统和业务组件。

　　l     用户：账号注册、账号登录、用户资料、用户关系、．．．

　　l     金融：充值付费、打赏、提现、会员订阅、．．．

　　l     直播：开关播、弹幕、连麦、1 v 1 PK、多人互动、．．．

　　然而，由于不同的业务系统分散在不同技术团队负责维护，服务标准规范并不完全统一；并且有小部分业务系统已经按支持多业务多App的方式进行了升级改造，例如有的在业务服务层面进行了升级改造来支持多业务；有的针对多个业务部署多套同构业务服务，通过proxy来做路由来支持多业务；多业务支持的技术方案不统一。

　　数据方面，大数据平台已经支持了部分创新业务的数据收集、清洗、分析、呈现工作。但由于各个业务线对数据理解角度和深度不一致，数据维度参差不齐，数据统计口径也并不统一。

　　结合中台目标和以上背景，中台建设的方案和实施路线逐渐明确下来：

　　l     服务协议规范化：统一各服务中心和业务系统的协议规范

　　l     数据协议规范化：统一各数据源的协议规范，包括移动客户端埋点、业务服务日志、数据库表等数据源

　　l     服务方案标准化：服务框架 / 中间件升级改造，为单个服务提供支持多业务的技术能力，避免业务侵入性，做到业务系统升级无感知

　　l     数据方案自动化：配合各服务中心进行升级改造，实现数据自动收集、处理、分析、呈现的自动化

　　l     业务系统改造升级：按中台服务协议和数据协议进行改造，通过集成中台服务框架 / 中间件实现能力升级

　　l     客户端业务组件：配合各服务中心和业务系统，完成业务组件的改造和开发

　　考虑到中台建设任务量和当时可投入的研发资源，中台建设计划分两期，一期以整合现有技术能力为主，围绕以下工作展开：

　　l     完成服务协议规范化、数据协议规范化工作，并落地文档

　　l     完成服务方案标准化，服务框架 / 中间件 改造升级

　　l     业务中台，完成包括用户中心、金融中心等核心业务系统对中台服务框架 / 中间件的集成，提供服务API接口能力，以及配套的部分客户端业务组件SDK能力

　　l     数据中台，完成包括 DAU、新增 / 留存、使用深度 / 频度、用户结构、渠道质量等基本数据的数据收集自动化、数据处理模板化、以及数据呈现产品化

　　紧接着，中台一期项目组成立，成员包括来自各业务技术团队和技术平台团队的20名左右技术同学，通过2个月的时间快速完成了中台一期的建设工作。

　　三、中台运营

　　中台一期已经完成，理论上本文可以到此结束了；就像童话故事里美丽的结局：王子和公主住进了城堡里，过上了幸福的生活。

　　但中台不是童话。在中台投入使用之后，我们立即遇到了2个问题。

　　如何推动创新业务接入中台？

　　中台项目初期，某个业务线技术老大拍胸脯说：严重支持中台，一定要成为第1个接入使用方！为了迎合这个中台客户，中台项目甚至以他提的名字做了项目命名，然而项目结束后，他就像永久性失忆一样再也不记得有这事儿。

　　这是可以理解的，中台刚刚上线还没有经过稳定性验证，谁也不想做小白鼠。中台需要一个客户做标杆案例。

　　幸运的是，一个大客户来到了。

　　19年映客公司全资收购了面向潮流青年的知名社交产品积目。积目的业务量上涨导致积累了不少技术债务，同时业务上需要快速在进行商业化的探索。积目技术团队一边要弥补技术债务，一边要进行业务快速迭代。

　　面临技术和业务的双重压力，此时中台对于积目来说绝对是雪中送炭。

　　接下来积目积极拥抱了中台，快速接入了业务中台的用户中心、IM中心和金融中心，成功接管了当时问题频出的用户关系和IM系统，并以较低的接入成本快速上线了会员订阅等商业化功能。

　　有了积目这个百万日活量级的大客户，中台终于解除了创新业务对中台稳定性的质疑。与此同时，创新业务技术团队规模被缩减，让创新业务失去重复造轮子的前提条件，于是各个创新业务线开始接入中台了。

　　中台顺利的推行，不止是童话般美好的一面，还有很残酷的另一面。

　　中台如何维护和持续迭代？

　　中台一期项目是以虚拟项目组进行落地的，项目结束后参与者回到原技术团队，中台只能以兼职维护。

　　为了让中台顺利推行，公司快速抽调人员成立中台团队，聚焦中台的维护和持续性建设。

　　然而，当创新业务想接入中台，但所需业务能力中台暂时缺失的情况下，中台团队和业务团队该如何配合呢？有3个选择方案：

　　1．由中台团队补齐新功能，然后再提供给创新业务使用；

　　2．由创新业务团队开发新功能，待成熟后沉淀到中台进行维护；

　　3．中台团队和创新业务团队合作开发新功能，然后沉淀到中台维护；

　　第1种方案，中台团队任务量太多会成为瓶颈，并且拖累业务后腿；

　　第2种方案，创新业务团队需要具备足够的人手和时间进行沉淀，与此同时剥夺了中台团队的存在感；

　　因此我们选择了第3种方案：对于中台团队来说，能够快速补齐中台能力；对于创新业务团队来说，相当于添加了人手，能够更快速上线新业务功能，并且因为自己参与了开发工作，用起来也更加放心。

　　基于以上的合作模式，中台团队和创新业务团队快速的丰富和补齐中台规划中的各项能力。

　　此外，中台团队不断弥补和完善运营方式，建立了透明化的信息共享同步机制，涵盖了中台能力的立项、评审、开发、测试、上线发布等各个流程环节，以及搭建了面向产品、技术、数据等各部门人员的文档中心，并将中台建设的进展定期同步到各创新业务方。

　　不要小看中台的运营，良好的运营是创新业务线持续使用中台的基本前提。当然这也为中台团队提出了更大的挑战：如何转变原来的工作思维，成为合格的服务团队？

　　四、中台复盘

　　复盘中台在映客的顺利落地，综合来看笔者认为有以下几个关键要素：业务阶段、技术能力、组织协作和企业文化。

　　业务阶段决定了中台的建设前提

　　映客公司的创新业务在19年已多达数十个，并且大部分以音视频互动和社交方向为主，较多的共性业务是中台启动建设的前提。

　　如果回退到16年只有两三个创新业务线的阶段，直接拷贝代码也很高效，中台建设就毫无意义了。

　　技术能力决定了中台的落地成本

　　在中台建设之前，映客已经完成了服务化以及平台化工作，并积累了比较完备的基础设施；共性业务系统已经基本沉淀完成；数据收集、处理、分析、呈现工作已经在部分创新业务线跑通。

　　中台的建设工作相当于是把现有技术资源进行整合，并不需要投入太多额外的开发工作，所以中台一期能够在2个月内低成本的快速落地。

　　如果仍处于基础设施能力缺失上古时代，坑都没填完的情况下，做中台无异于痴人说梦。

　　组织协作决定了中台的迭代效率

　　中台前期的建设工作，以虚拟项目组的形式组织不同技术团队协力实施，之后快速抽调人力成立中台团队；中台后续的能力迭代工作，由中台团队和创新业务团队协作开发；这都离不开高效的组织协作能力。

　　如果团队协作无法搞定，中台的初期建设和长期持续性建设，必将因组织问题遭遇重重阻力。

　　企业文化决定了中台的赋能效果

　　映客具备很强的创新文化，对创新试错有较高的容忍度，所以在公司能够并行数十个创新业务。

　　在移动互联网流量红利见顶的前提下，如何低成本高效率创新是必须解决的核心问题。这使得管理层能够在中台建设上达成一致，将中台作为企业创新发展战略的核心手段之一。

　　通过中台降低成本提高效率，反过来也会加强企业的创新文化，让更多人更大胆的进行创新尝试。中台会持续为创新赋能。

　　五、写在最后

　　中台不是童话故事。王子和公主过的幸不幸福，与是否住进了城堡没有任何关系。

　　不盲目跟风，不刻意鄙夷，根据自己公司的业务、技术、组织和文化各要素来综合判断要不要上中台，才应该是比较合理的方式吧。

海量资讯、精准解读，尽在新浪财经APP

责任编辑：石秀珍 SF183