百分点 To B 转型之路：技术中台及 DevOps 的建设实践

本文整理自 2019 年 ArchSummit 全球架构师峰会深圳站百分点资深架构师代其锋演讲话题《ToB 技术实践：挑战与破局之道》。

我今天分享的内容主要包括：百分点在发展 ToB 业务过程中遇到的挑战；针对这些挑战，我们在技术建设和组织建设方面的思考；最后，我会针对整个转型过程做个总结。

一．转型之痛

百分点是成立于 2009 年，成立之初，主要是给企业提供基于推荐的 SaaS 服务。2014 年，百分点开始尝试企业级交付，当时我们主要是给传统企业提供包括大数据、人工智能等方面的服务，比如为企业做数据的拉通，用户画像，当时我们的很多思想在业界还是比较领先的。2016 年，百分点响应国家一带一路的政策，开始将我们的数据智能技术赋能给海外国家，当前我们的业务已经覆盖除了欧美之外的所有地区。

SaaS 服务的场景比较简单，主要是根据用户的网络行为做个性化推荐，我们当时服务了电商、媒体行业等一千多家客户。如果客户想要在首页推荐某些商品，可以将需求提交给研发经理，拿到需求之后，研发经理会先对需求做一个分析，比如用户的业务流程，能拿到的数据有哪些，要在哪些地方展现推荐等，有了这些信息就可以直接对接后端开发了，大概一周的时间就可以开发上线。整个价值链非常短，主要以研发驱动为主，上线之后，我们通过大数据分析，会及时的看到效果，例如客户 PV 变化、推荐转化率等。

2013 年，电商行业经历了泡沫期，很多电商企业经营的都不好，这对百分点也产生了一定影响，企业毕竟需要盈利。因此，我们开始思考转型的问题。在这个阶段，我们看到了一些传统企业存在的困难，他们实际上沉淀了很多非常有价值的数据，但是这些数据在企业的数据库中并没有发挥出价值，一方面受限于数据处理能力，另外一方面在数据的运用上缺乏重视和理解，我们开始考虑是否能够借助大数据等新技术帮助这些企业做数字化转型。

2014 年，我们做了 ToB 业务转型之后的第一个客户，帮助客户进行用户画像和推荐，收集完数据之后，再进行数据拉通，然后给客户提供用户画像和推荐服务。

但是这个项目，我们做得比较痛苦，投入也非常大，整个项目执行了 7 个月，包括一个项目经理、三个咨询参与其中，20 个技术在客户现场，30 个研发在后端支持。为什么会做得很痛苦呢？主要原因是我们还在用以前做 SaaS 的讨论做项目，所以不可避免地遇到了一些问题，例如流程问题，咨询在和客户沟通需求之后，没有沉淀出一个很好的需求文档，只画了一个大致的原型图就交给研发，里面的业务交互过程，展现的信息等都没有明确，导致了大量返工工作。另外，大家的配合做的也不好，比如研发给的软件包经常在现场跑不起来，部署文档、软件包等都非常不规范，沟通成本很高。

我们做事的方法存在很多问题，另外就是心理上的挑战，之前做 SaaS 业务，大家认为我与客户是在同一水平线，客户提需求，我们负责完成，整个是研发驱动的过程。而在企业级交付领域，我们需要主动去了解客户需求、主动去服务客户，需要具有极强的客户服务意识。

SaaS 服务与企业级交付有何不同呢？

SaaS 服务的价值链非常短，用户提出需求给到研发，研发经理就可以很快地把用户需求转化成研发。而且因为用户需求很简单，用户也不关心具体的研发过程，只需交付产品即可，所以整个产品的交付周期也非常短，涉及的人员也很少。并且，我们已经把这个过程标准化了，提供的产品也标准化了。

而在企业级交付领域，客户需求是多元化的，没有标准化的产品，更多的工作不在于研发，在于要去了解用户需求，并把用户需求转化成研发能够执行的产品需求。最后交付的不仅只有系统，还包括文档、培训工作、部署手册等等。企业级交付不仅是一个研发的过程，更多的是一种全方位服务，过程要求会更加标准，不然很难去应对用户的需求变化，也很难保证交付的高效。

目前百分点的业务包括 SaaS、To B 业务，业务增长了 10 倍，人员规模由 150 人扩展到 800 人，每年交付的项目超过一百个。下面我要解释一下我们是如何做到的。

二．技术建设

首先介绍一下我们的技术体系，百分点的主要赛道是大数据和人工智能，所以我们提供给客户的解决方案都是围绕大数据和人工智能来展开的。

整个技术体系的最底层是大数据的全栈技术，包括数据存储、数据处理和整个数据生命周期管理，我们有全套的数据中台解决方案；再往上，我们提供了智能的分析和决策系统；所有的这些系统都运行在我们的私有云平台上。

目前，我们每个月差不多并行实施 50 个项目，每个项目的周期不一样，有的项目 6 个月，也有的项目 5 年、10 年，而在人员配备方面也会根据项目周期进行调整，小项目可能一个产品+运维就可以了，大项目可能需要 30 到 40 人。

我们在技术上如何去支撑这些项目呢？

我们技术建设的思路可以分为三个方面：

• 具备数据应用技术中台能力：因为要应对各个业务线，应对不同的项目，而每个项目中又有些共性的需求，这些共性需求基本都集中在大数据和 AI 层面，所以我们建设了自己的数据中台、AI 中台以及部分业务中台。

• 产品研发的落地，需要一整套全面的研发方法论支撑：为了提高研发效率，百分点有一套完善的 DevOps 体系，让开发、测试、运维能够高效协作。

• 全面深度的技术拉通：把各个业务线的技术进行拉通，统一技术支撑体系，为百分点跨行业和团队提供能力升级。

为什么要建设中台？建设中台的本质是为了提效，同时提高项目交付的质量，我们有专门的人员来建设中台，提高中台的质量。通过技术中台，我们也可以提高百分点的品牌，在行业产生影响力。

在组织上，百分点其实还没有专门的中台部门，所有的中台都是在业务中沉淀出来的，我们沉淀的几款中台产品目前都有专门的团队进行支撑，同时这些中台产品也在尝试进行商业化，比如我们为企业提供数据中台，基本的 NLP 能力等。

目前，我们的中台主要包括数据平台、业务中台和 AI 中台。

其中，数据平台和 AI 中台，不仅是内部使用，同时也承接了商业化的目标，我们会在数据平台中添加行业属性、行业模型帮助企业建设数据中台。例如，如果是人口类型的数据中台，我们会内置一些人口模型，包括字段怎么命名、字段的取值范围、数据的质量规范等。

AI 中台与数据中台类似，媒体行业、社交行业等领域的 AI 能力不太一样，例如我们要做情感分析，那么就要分析社交数据、电商评论数据等，因此，我们针对这些数据会提供专门的分析接口。

业务中台的实践，当前我们做的还比较少。我们有很多业务线，但每个业务线并没有形成非常完备的解决方案，很多业务线其实还处于前期探索阶段，很难去从业务线中沉淀出真正能够支撑所有业务线的业务中台。目前我们更多的是沉淀了一些通用的业务中台，例如用户中心、权限管理、OSS、流程引擎等。

在技术中台方面，我们的大数据平台、AI 中台、流程引擎、用户中心 &权限管理方面做得比较扎实，也收到了不错的效果。

DevOps 的目标是提高研发效率。最早的时候，我们没有 DevOps 概念，开发做开发的事，部署做部署的事，开发完之后，打个包丢给运维去部署，部署完之后，就进行测试、上线。整个过程中沟通效率特别低，部署完全是靠人工的。后来，我们做 SaaS 服务，业务同样比较单一，如果运维不能部署，开发直接上。但是，到了做企业级交付时，并行实施的项目非常多，完全依赖人工显然是不靠谱的。

因此，我们引进了自动化构建工作 Jenkins，开发完成之后，通过 Jenkins 去构建代码，进行部署。虽然 Jenkins 的入门门槛比较低，但是在执行过程中也会存在一些困难，例如需要写自动化脚本，这对研发来说可能就是个大难题；比如面对环境的问题，很多服务可能需要部署到一台机器上，但不同项目依赖的版本不同，这时就容易造成冲突。

之后，我们又引进了 Docker，基于 Docker 做 CI/CD 的集成，开发完之后，提交到 Git，自动地做代码构建，并通过 Jenkins 把镜像打出来，然后在云平台上进行部署。部署之后，我们还可以做一些配置修改，自动化报警、容灾等等，通过这一方法，我们整个开发部署能够在分钟级完成。

上图是整个 DevOps 流程，因为项目和资源都在云平台上，所以首先要去申请资源，技术负责人向运维负责人申请项目资源，并在平台上填写需求，例如 CPU、Core、Memory、节点等的数量。然后租户管理员管理项目分配的情况，一般来说我们会分开发、测试和准上线环境，我们在自己的环境做好测试开发，在准上线环境中模拟每个环节。研发在提交代码之后，需要编写 JenkinsFile、DockerFile，运维完成之后直接打包运行在 K8s 的集群上。从提交到看到效果，5 分钟之内就可以搞定。

这是我们自研的 Sextant 云平台，提交代码之后，完成代码构建，并把代码运行在 K8s 上。

目前我们并没有把所有应用迁移到 DevOps 平台上，上线的应用大概有一百多个，部署和集群利用率都提高了，而且因为研发和运维无相互依赖，运维专注工具化，研发专注业务系统，所以整个协作效率也提高了。

后续我们的 DevOps 还会有一些升级，主要包括以下内容：

• 计算项目资源 &成本评估：因为我们采用的是项目制，这些项目基本上都是由各个事业部承担，资源也是有成本的，所以我们下一步就是核算项目成本，防止事业部随意申请资源；

• 质量度量：量化团队的质量报告，查看大家是否遵守了代码规范，分析日志，从各个角度评估业务质量；

• 智能运维：预测系统故障，提前预警；预测系统资源使用，提前预警；分析日志，评估系统监控；性能分析，调用关系链分析。

• 智能建议：根据系统访问量、资源使用等给出资源建议；根据访问趋势，对空闲资源给出建议。

To B 业务项目多，涉及人员庞杂，如何做技术管理呢？如果不做技术管理的话，大家使用的技术栈都不一样，使用的工具也不一样，做事的方式也不一样，必然会出现一些问题，面对知识传承以及人员变化都很难去响应。

因此，技术拉通就对 To B 业务至关重要。

在技术拉通方面，百分点成立了公司的技术管理委员会，委员都是来自于各个业务线的资深架构师。除此之外，我们还有专家组，专家组主要是在各个职能中比较资深的人员。实际上，百分点拉通了公司所有事业部的项目和业务线。目前，我们有数十个业务线，成立了 7 个技术小组，每两周会进行一次会议，讨论技术规范的执行情况。

之前做 SaaS 服务的时候，我们技术特别多样化，充分尊重大家的技术选择。但是转型到 To B 业务之后，就遇到了很多问题。举个例子，如果从其它项目组抽调开发人员，他可能还需要花费时间熟悉另外一种编程语言，而且项目交付之后，可能还需要长期维护，这时如果人员流失，新人是很难接手该项目的。

所以，我们更坚定了要做技术拉通工作，现在百分点技术栈主要使用 Java 和 Python 两种编程语言，以 Java 为主，Python 主要用来做一些数据分析的工作；前端用 React，代码托管用 git。同时，我们也制定了编码规范，在提交时会审查代码，如果编码不符合规范，不允许提交。短期来看，可能会对大家造成一些影响，但长期来看，还是有好处的，随便打开一个项目，所有人都能够在十分钟之内了解项目的结构。

协作方式我们也做了统一，所有的项目资料都在 Wiki 上；百分点的内部沟通使用的是 zoom us，同时我们还自己开发了翻译管理工具，可以在平台上看到所有的翻译内容，避免出现重复翻译，提高协作效率；在需求 Bug 管理方面，我们自研了适合自己工作方式的工具——PMP。

百分点也有一些自研的开源工具，主要是内部使用，例如 License 服务、正则库、前端组件库、微服务配置中心、自动化安装服务、监控中心等。这些内部的共享库复用率极高，大大节省了大家的交付成本。

三．组织建设

To B 业务以项目为主，当项目很多且执行周期较长时，就需要一个比较好的组织管理方式来把流程标准化，这样整个组织才可以以更标准化的方式来运作。

我们主要是以这三个方面来做组织建设，首先是统一思想，大家的思想步调需要一致，并在此基础上提升大家的技能，当然这里的技能包括软技能、硬技能各个层面，例如管理技能、沟通技能、技术技能等。有了思想和技能的指导，那我们也有相应的这种方法去落实组织管理。

思想建设的目标就是统一大家的思想，有了共同的目标之后，才能去围绕这个目标去做事情。在思想建设上，我们强调为客户创造价值，因为 To B 项目一定是为企业、客户服务的，只有给客户创造出价值，客户才会为你买单。其次，要有成本意识，企业级交付需要格外注重计算能效、管控成本；最后，我们也会做一些思想宣传。

在具体实践方面，我们主要有学习分享、谈话和团建三种方式。

• 学习分享：我们内部会组织关于文化价值观的分享，让大家谈谈自己对文化的理解，讲讲自己的故事；

• 谈话：团队 Leader 会定期与大家交流，了解大家的思想状态；

• 团建：我们会定期组织团建，拉近大家感情。

以上活动，百分点成立了一个部门专门去落实，就是我们的组织发展部。

因为我们是以流程为驱动的，所以我们的组织建设方法也是围绕流程来运转的，从项目启动、需求收集、开发、部署、交付，都有一套完善的项目交付方法论。

我们在每个项目中设置了节点，每个项目管理的节点都有具体负责人，对于该节点的输出，我们会有明确的规范，例如产品需求文档需要包含哪些内容，概要设计如何写，相关的代码约束和规范等等。

在技能方面，我们主要采取了三种方式：管理培训、软实力培训、技能培训。

• 管理培训：主要是针对中层研发为主，中层研发其实是企业中的实际执行者，中层研发管理的好会大大提高企业效率。

• 软实力培训：针对全员培养大家综合能力，内容包括高效沟通、冲突解决等。

• 技能培训：提高大家的技术水平，包括微服务实践、高并发实践、机器学习等。

如何落实组织建设呢？我们是有一个核心班子，这个核心班子大概有 30 多个人，同时我们还成立了相应的部门，包括组织发展部、QA 组运营组、技术管理委员会，共同去落实思想、方法和相关技能的培训。

四．总结

百分点做 To B 业务已经有 5 年多，也沉淀了很多自己的思考。To B 业务做起来很困难，一般来说，需要在一个行业里扎根三到四年，才能见到成效，团队管理、研发人员情绪都有很大挑战。而且 To B 业务不仅是个技术问题，更多的是需要大家具有客户服务意识，需要去了解客户，教客户如何使用系统，给客户讲清楚产品的价值等等，只有客户成功了，我们的事情才能成功。因此，做 To B 业务一定要从内而外的对组织和个人进行升级，从思想到技术，都需要我们修炼好内功，方能应对 To B 行业面临的挑战。