从 0 到 1 搭建技术中台之组织架构篇

自去年开始，中台话题的热度不减，很多公司都投入到中台的建设中，从战略制定、组织架构调整、协作方式变动到技术落地实践，每个环节都可能出现各种各样的问题。技术中台最坏的状况是技术能力太差，不能支撑业务的发展，其次是技术脱离业务，不能服务业务的发展。前者是能力问题，后者是意识问题。在本专题中，伴鱼技术团队分享了从 0 到 1 搭建技术中台的过程及心得。

引言

组织架构是围绕提高效率而设计的管理形式，任何新出现的组织架构一定是比之前的组织架构效率更高才有意义。中台是近来大家广泛讨论的一种组织架构，但是因为没有明确的定义，所以每一家公司对中台的理解可能会不尽相同。

但是不论什么样的组织架构，落到根本上都是服务好人才、做好事情，所以伴鱼在中台化落地的过程中，总是从这两个角度来评估当前组织架构对于效率的影响，以及应该怎么来优化当前的组织架构。本文回到组织架构的本质——效率的角度，分别从事情和人的角度讨论中台对组织架构的影响，以及伴鱼技术中台的建设与演进过程。

从事情的角度，中台组织架构应该关注提高复用率

每件事情只由一个团队负责

传统互联网公司的组织架构，一般是基于业务发展来设计的，开展新的业务线，组织架构是整体再建设一遍，这样会产生重复建设的问题。如果一个公司有多条业务线的时候，就会出现多个 DBA 团队，多个运维团队和多个基础架构团队等，这样一件事情在公司内部有多个团队负责，每个团队都需要独立做人才管理和技术积累，从事情的角度来看，复用率是非常低的。

一件事情只由一个团队负责，很多重复的事情只需要做一遍，减少了很多不必要的工作量，并且集中了全公司在这一个方面的人才和资源，这样才能很专业、深入和系统性地把这件事情做好。

对于中台化的组织架构来说，每件事情只由一个团队负责是最基本的要求。这个在伴鱼的组织架构中是严格执行的，比如运维、DB 管理等，全公司只有技术中台的运维研发团队和 DBA 团队。

每件事情都要做成企业级服务

对于中台化的组织架构要求每件事情只由一个团队负责，其实这也对中台团队提出了一个要求，必须把自己负责的事情做成企业级的服务，因为整个公司只有你们负责这一件事情。这是权利与义务的关系，拥有了事情的独享权，那么就必须承担起服务全公司的责任。

目前伴鱼技术中台承担了所有的基础方面的事情，每一件事情都是企业级的服务，比如发布系统就承担了全公司所有业务线的所有端的发布服务，不论是伴鱼绘本还是伴鱼英语等不同业务的发布，还是服务器、安卓、ios 和 web 等不同端的发布；报警系统也一样，它被设计为一个信息的分发平台，前端、后端、运维和数据库等所有需要分发报警信息都先发送给它，由它完成报警信息到 Owner 的分发。

从人的角度，中台组织架构应该关注提高沟通效率

Conway’s law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

康威定律阐述了组织的沟通结构对系统设计的影响，沟通效率越高的组织，其系统设计也会更加合理。中台其实本质上也是通过从优化组织的沟通效率来影响公司的系统设计。比如帐号平台在中台化之前，提高一系列帐号相关服务，每个帐号相关的服务再提供了一系列的 API ，这导致需要使用帐号能力的业务团队，都需要和多个帐号相关服务的 Owner 去对接和接入。这是一种很低效的沟通形式，其实接入帐号服务的流程是差不多的，通过将帐号相关服务成立一个团队，并且将之前多服务多 API 形式的接入方式抽象为提供帐号能力或者服务的形式，这其实就是中台化的核心目标。

所有的哲学是相通的，软件设计的哲学高内聚，低耦合，也是中台的哲学：打造高内聚，低耦合的沟通高效的组织架构，将一些频繁、重复和低效的组织之间的沟通变成高效简洁的组织内的沟通，并且高效简洁的组织内沟通更可能进化出新的能力。伴鱼技术中台在早期阶段建设了各种各样的平台，现在开始将一些平台打通融合，将多个零散的平台能力抽象为更高级的产品能力提供出来。

伴鱼技术中台之前提供了 APP 推送平台、短信推送平台和微信推送平台，现在开始往触达平台的方向演进，对不同的业务场景和不同的用户情况可以自动采用不同的触达方式，并且能通过触达反馈的数据来智能推荐不同的触达方式和提升触达能力，这就是从平台化到中台化的进化之路－－从提供基础能力到提供强大的产品或服务能力。

伴鱼为什么需要进行中台化的组织架构

伴鱼是一家快速发展的在线教育公司，教育这个领域天生就有教学科目和教学场景两个维度，这两个维度的笛卡尔积就是它可能的业务类型数量，当然有多个科目和多个场景适合由一个业务线来负责，但总体上由于科目和场景的业务差别会非常大，出现多个业务线是必然的趋势，所以将一些基础和业务能力中台化，提高企业级的复用能力是目前最适应公司业务特点的组织架构。

伴鱼技术中台组织架构的演进

上面阐述了伴鱼对中台组织架构的理解：中台化组织架构应该提高事情的复用率和组织的沟通效率，并在这一基础上提供强大的产品或服务能力。下面我们讲述在这一原则下伴鱼技术中台组织架构的演进过程。

第一个阶段是基础架构阶段，这是伴鱼技术中台的初始阶段，当时只是服务器基础架构组，负责基础服务、微服务框架和服务治理相关的事情，不过当时 DBA 是属于基础架构组的，这是因为我们认为 DB 是基础架构非常重要的一部分，DBA 和基础架构的需要密切沟通和深度配合的，比如数据库路由可以理解为服务发现的一部分，熔断降级等服务治理的方法其实对数据库治理同样非常关键，这是中台化思想在组织架构上落地最初形式。

第二个阶段是平台化阶段，这个时候已经正式成立了伴鱼技术中台部门，前面的服务器基础架构团队和 DBA 团队加上运维研发团队、WEB、安卓和 IOS 基础架构团队合并为伴鱼技术中台，并推行 SRE 文化，各团队都开始将一些需要人工管理的事情平台化，由于技术中台部门包含前端和后端的基础架构团队，所以沟通和配合效率非常高，这一段时间推出了各种各样的平台，并且所有的平台都提供企业级服务能力，比如发布系统、灰度系统、数据库平台、报警平台、APM 平台、账号平台、存储中心、安全中心等等

第三个阶段是中台化阶段，这个也是伴鱼技术中台目前所处的阶段，现在开始，对内我们挖掘平台之间的价值，对外关注业务使用上的研发体验。挖掘平台之间的价值，其实就是做平台之上的平台，打通多个相关平台的数据和接口，提供产品和服务能力更好的平台；另外也从研发体验的角度出发，从使用角度将一些场景相近和关联的平台相互融合，提供统一、简单的使用方式。并且，在平台的融合与调整中，为了获得最好的沟通效率，内部组织架构也会做响应的调整。现在正在进行的 A/B Testing 平台（从数据上报、指标分析和指标信度评估等全功能统一的 A/B Testing 平台）、触达平台（打造统一的触达用户的智能平台）和统一前后端的性能分析平台（全业务和全场景的性能分析平台）等都是在这个方向上的努力工作。

总结

在伴鱼技术中台的发展过程中，组织架构是不断演进的，其实不论有没有中台这一概念，只要不断优化组织的效率，最终都会呈现中台化的组织形态，好比不论使用什么样的软件架构理论，最终目标一定是一个高内聚，低耦合的系统。

只是，恰好，有了中台这一个概念，让伴鱼技术中台不需要再取一个新的名字了，这是非常幸运的事情，一直觉得写代码最难的就是命名。

相关文章推荐：

《从 0 到 1 搭建技术中台之推送平台实践：高吞吐、低延迟、多业务隔离的设计与实现》

《从 0 到 1 搭建技术中台之技术文化篇》

《从 0 到 1 搭建技术中台之协作方式篇》

《从 0 到 1 搭建技术中台之报警平台实践：匹配器演进》

《从 0 到 1 搭建技术中台之发布系统实践：集泳道、灰度、四端和多区域于一体的设计与权衡》

《从 0 到 1 搭建技术中台之 A / B Testing 平台实践》