技术中台是割韭菜的镰刀？还是落地的丹药！

黄爸爸好 2020-04-27

展开全文

伴随着业务快速发展，为解决垂直架构引发的效率、成本、质量的问题，从而演化出了中台；
这里存在甲方要求乙方掏钱做中台的情况，中台是一把手战略工程，以交付价值为核心；
不要被直播的分享带节奏，分享观点只代表其个人实践、经验与感悟，既不是标准，也不是规范；
本直播纯属于技术公益。

一、演化到中台前遇到的问题

在谈技术中台之前，头哥首先给大家分享了好买财富业务系统的演进过程，方便大家了解分享业务背景。

1. 业务系统的演进过程

好买财富公司以前是做线下金融交易业务，经历了2012年至2013年单体+单产品业务系统1.0 时代，2014年至2016单体+多产品业务系统2.0时代，2017年至2018年多业务线+组合/创新3.0时代。

什么是单体应用架构？

一个典型的单体应用就是将所有的业务场景的前台表示层、中间业务逻辑层和后台数据访问层都放在一个工程中，最终经过编译、打包，部署在一台服务器上。就是大家较熟悉一个war包打天下。

好买财富3.0时代的由来还有一个比较有意思段子。据头哥分享说，有天早上6点钟，CTO打电话给头哥说：“晔倞，我昨天晚上做了个梦，梦见最近很多人都在说中台，要不我们技术团队也改名为技术中台团队，你觉得怎么样？要不咱们也搞个中台玩一玩。”就这样在玩一玩的过程中演进出现有好买财富3.0的业务系统。

2. 技术中台的前提

头哥认为要做技术中台，首先要具备技术组织结构一定要垂直化及业务线又多又复杂两个大前提。

（1）技术组织结构一定要垂直化

好买财富1.0时代及2.0时代组织结构图与大多公司的结果图是一样的，这样的结构会有什么缺点呢？

效率问题

具体表现为每个需求上线，需要研发经理、客户经理、运维经理、产品经理、项目经理、职能经理等在一起开没完没了的会议；一个团队一套代码、多套标准，服务于多家公司；一个产品需要上线，需要各种各样的功能测试，所有人都在忙碌。

质量问题

随着产品功能的不断迭代，后续的问题定位日益困难，没法解决的；运维的处理能力是一直落后于研发处理能力的；随着业务的发展，业务债越积越深。不同部门不允许升级，例如测试部门没时间，导致没测试，运维团队没测试报告，不允许上线，导致技术债累计。

成本问题

各种各样的中间件，没有统一的维护、没有统一的文档整理，管理成本复杂化。

好买财富成立技术中台的前身平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。把质量管理部中的测试团队，与系统运维部中的应用运维团队，按照系统功能拆分至各开发团队，由原开发经理负责，形成各自独立的Feature Team。

分享组织核心观点:按照功能（产品线）拆分不同的团队，运维、测试被打散到产品线上，技术下沉、快速试错、小步快跑，单一职责，统一指挥。

（2）业务线又多又复杂

头哥通过介绍好买财富组合产品的购买，表明核心观点你的业务特性导致后面业务系统绝对不可以用一个简单的、单一的交易系统，来完成整个交易链路。

随着业务的发展，将业务和技术能力分离，以产品化方式向前台赋能，中间件、自动化运维、自动化测试、人员组织结构划分，独立核算，每个单元作为一个产品发展。

分享中台核心观点：起到适配器的作用，利用技术中台能力，让技术前台发挥作用。

二、技术中台实践过程中的问题与挑战

以头哥的观点看来，好买财富的「技术中台」就是一家 “乙方服务公司”，而他们的「技术前台」更像是一家 “甲方电商公司”。不可否认，有了这家 “乙方服务公司”之后，在面对大型项目及快速多变的业务时，技术的投入与主动权更强了，但由于理念、职责、节奏与使命不同，外加 “屁股决定脑袋” 的立场，前台与中台之间很容易引发矛盾。

从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。一个追求效率，一个追求质量，这矛盾是天然存在的。

技术中台同时为多业务前台提供服务，但不同的业务前台因种种原因留下多种技术债。

在「技术中台」看来，“你们只顾自己，不管别人，功劳你们拿，黑锅我们背？”

在「技术前台」看来，“你TM懂个屁！我们都快被业务逼疯了，你们不就多费点人工吗？多加点班会死吗？总扯一些理念干嘛？对你没收益的事，你干嘛？”

因为这样的分工模式，导致这种矛盾在工作中很多，而且似乎并没有更好的方法彻底解决。

中台究竟用什么技术众口难调，表现为CTO的经验有很大决定因素、技术债遗留的技术不得不用、别的大厂使用了某技术跟风使用。