题图： 本次技术沙龙合影

演讲 | 雷文津

编辑 | 王晔倞

从有这个构思开始算起，前前后后的准备大致耗费了2-3个月，最后报名参会的企业一共有13家之多，这点也让我非常的欣慰。也许有人会问：“开展这场专题的目的是什么呢？”下面我先来简单介绍下本次专题的由来。

-- 开场白 --

大家好，我是好买财富的王晔倞，大家在这么炎热的夏天来参加本次沙龙，再次我代表好买向大家表示衷心的感谢。

与许多金融企业一样，将核心业务运行在IOE架构之上也许并不是一件稀罕事，但随着业务对交付速度的要求不断提升，系统复杂度也随着互联网的兴起逐渐变得复杂，像以前招标、需求归拢、评审就要耗费半年，甚至一年的玩法，在这种唯快不破的场景下，传统打法似乎很难再维持下去，于是我们开始思考，如何构建自己的快速交付流水线？

俗话说“成长最快的方式是不耻下问”，于是乎我们打开心态，拥抱学习，走访了许多互联网企业，但结果却让我有些郁闷。在互联网企业的眼里，类似的事件执行起来并不困难，甚至拿出一些例子来证明这个观点，比如寥寥几个人就能管理上百台服务器，上千个容器节点，又比如其核心应用在设计之初就支持独立（或垂直）发布，还比如超过60%的应用均支持每日构建及随时发布，并且自动化覆盖率达到90%以上等等……

为什么会有如此大的反差呢？

在我看来，金融（或互金）企业与互联网企业存在以下区别：

• 行业强监管，行业弱监管

• 稳定第一，速度第二

• 强业务驱动，弱技术驱动

• 创始人背景，金融多业务，互联网多科技

• 传统技术架构（IOE），互联网技术架构（微服务/分布式）

• 组织结构，金融企业按职能划分，互联网企业按功能划分

当然，我的这些观点过于片面，也过于主观，但无论如何，快速交付对于企业的发展都必须的，合情合理的，而我们也应该直面应对，与时俱进。

在专题分享的5家企业中，有的企业已取得不错的效果，也有些企业人在探索阶段，下面我将话筒交给他们，我们一起来听一听属于我们金融IT自己的故事。

-- 演讲内容 --

下面是整个PPT中的15页核心部分，通过口述化的文字进行了编辑整理：

做为互联网金融科技公司，身负互金行业的专有标签，IT系统免不了会烙下深刻的特殊属性，先来说说强监管。

近些年监管层对金融行业的管控越来越严，监管政策层出不穷，有限制只能做哪些的，也有限制不能做哪些的，还有限制某个时间点前一定要达标的。其次是好买具有金融全产品，业务围绕着基金，覆盖有公募，私募，保险，创新，专户等等。最后是合作方众多，其中包括基金公司，支付机构，保险公司，分销机构，外呼系统，等等。

上述一些列的金融属性，增添了系统复杂度，让时间变得不可控。

业务流程复杂、系统复杂、研发时间不可控等三要素，会对研发造成怎样的影响呢？

明显特征就的是快不起来！ 而中间最最严重的呢，是测试环节。 造成测试环节慢的原因有：

• 第一，环境部署慢且故障多。 我们的部署实现了工具化，但配置尚未很好的自动管理。系统复杂，而我们每次部署都要全系统，或者说80%以上的系统，这样就增加了难度，故障率也自然飙升。

• 第二，因系统复杂，数据依赖严重，测试数据极难造。

• 第三，系统的依赖严重，每次有改动都不敢声明它的影响范围，所以策略就是测试allin。

还有一个特征是质量存在风险，关键因素是测试存在盲区，具体表现为：

一方面，测试人员对系统熟识度较低。 系统没有开发人员熟悉，且高低不一，同样的案例不同的人执行结果不一致。

另一方面，测试本身的反馈机制不健全。 测试案例写完到底覆盖面有多少，没有办法得到标准答案，只能依赖于产线问题的反馈。

尽管问题重重，我们还是要解决问题，我们提出了为实现快速迭代、快速反馈的目标方案。

整个方案围绕两个核心点展开：

• 第一，后台 - 构建标准化操作，如部署系统、测试系统、服务治理系统、覆盖率服务等。通过MOCK方式降低系统的复杂度，为自动化部署及自动化测试开辟新的道路。通过覆盖率服务，为测试提供精准服务。

• 第二，中台 - 搭建持续集成流水线，用于串接各持续集成的各操作环节，形成一套流水线，以实现持续反馈的机制。

当没有持续集成之前，整个交付过程将面临以下痛点：

• 组织模式： 我们的产品、测试、运维组织结构都是资源池模式。大家对系统的熟识度无法得到很好的保障。

• 测试模式： 以手工业务测试为主，辅加测试开发，测试开发主要以非功能性测试为主，功能验证主要还是通过手工测试重复进行。

• 部署模式： 工具化(半人工)部署模式，应用的配置仍旧是人工管理，造成部署结果不稳定，故障时有发生。

如前所说，因为系统耦合高，每个迭代更新都不能很好的理清影响范围，我们常常是测试all in，然后不断的抱怨手工效率低，测试人员巨痛苦，或者，也没办法呀，人都是因人而异的呀，迭代的质量就是如此呀……

故事有了，我们怎么开始第一步呢？

我们认为，通过实现测试自动化，可以在一定程度上解决测试效率及质量风险，所以我们优先建立了接口测试系统，用于服务RPC/HTTP接口测试实现自动化，然后又建立了WEB测试系统，服务于WEB测试。

说到这里，是不是这样就可以完美解决测试快不起来的问题了呢？

可是实际运行了几个月后，自动化测试却磕磕绊绊。

通过复盘，我们对自动化测试遇到的问题进行了罗列：

• 第一，环境故障多。前面说过，系统复杂，而我们每次部署都要部署80%以上的系统，这样就增加了难度，部署质量无法得到保障，故障率较多。

• 第二是，测试数据难造。系统复杂，且又分属不同的研发团队，造A漏B的现象时有发生。

• 第三，无法持续运行。运行一次，数据被更改没法重新跑了。换个版本，得重新部署，又得等上几时。

• 第四，外部支持。接口信息的来源，经历了手工录入(从代码里扒)到APIDOC(注解)批量载入的发展阶段。即使有了批量载入，迭代更新后接口信息未及时更新，屡屡发生。

好了，梦想破灭了，虽然跨出了第一步，但还是快不起来，而且还扯到蛋了。

第一步已经迈出去了，收不回来了，还是想想接下去怎么办吧。

我们召开了一次脑暴，在讨论过程中，有提到组织改革、组织垂直化，有聊到 “要自动，先解耦” 的理论，甚至还提到变革研发模式等，当然，也少不了尽早构建持续集成流水线等等。

脑暴，毕竟是脑暴，暴完之后的执行是关键，而在执行前，必须有方案。

经过讨论，最终我们形成了一套整体的技术方案：建设一套持续集成流水线，利用平台的建设动力，同时带动组织结构的垂直变革，及系统松耦合的拆分。

下面我来大体描述下方案的核心内容：

• 第一，轻量化测试，集中精力优先搞接口测试，通过接口测试快速、及早发现问题，反馈给研发。

• 第二，通过MOCK去依赖，基于MOCK的测试，在造数据方面可以降低难度，大大提升效率及积极性。

• 第三，基于MOCK实现自动部署，MOCK实现后，可简化环境部署的需求，从部署全系统到部署单应用/单系统。这样部署自动化实现难度降低，同时也从平台方面保证了部署的稳定性，故障率可得到一定缓解。

• 第四，建立持续集成流水线，通过CI流水线串接各个子流程，实现持续运行及定时运行。

• 第五，接口扫描，基于代码实现自动扫描生成接口信息，解决APIDOC更新不及时的问题。

说完了技术方案，不得不说一下组织赋能。

在持续集成推进这项工程，组织层面给予的能量也是杠杠的。

首先我们的组织资源从资源池转型FT(Feature Team)，把产品，研发，测试按业务线形成一个团队，团队成员形成统一的目标，积极推进持续集成发展。

另外一点，我们通过组织定位了一个超级用户，暨和其中一个FT团队一起合作，共同开发持续集成1.0版本。

有了组织的赋能，又有可靠的技术方案，持续集成总算在3月底完成了1.0版本建设。

部署快了，有保障了，测试环境造数据也方便了，接口信息更加准确了，测试调试顺利了好多，吃闷闷香了，而且还能通过持续集成一键执行，抑或是定时夜晚执行，爽的一塌糊涂了。

但爽了没几周，虽然测试通过了，但上线又出问题了，又郁闷了。

 在复盘时就会发现，测试人员已经根据业务完成了场景覆盖，可是问题偏偏发生在新的业务逻辑与老的业务逻辑混杂的场景，而这一逻辑没有暴露给相应的测试人员。

这时候我们就该深思，为什么测试发现不了这个问题？ 或者说想不到这样的场景？测试没有反馈机制。 

说到反馈机制，以往的测试有没有反馈机制呢？ 有的，只是仅能通过产线故障做反馈分析了。

我们希望将测试的反馈提前一步，在交付前可见，于是我们做了覆盖率分析，并将它集成到持续集成流水线中。

通过覆盖率分析，测试人员可以看到有哪些逻辑、哪些场景还没有被测试到，他就可以针对相应的逻辑扩充测试场景。实现精准测试。负责人也能通过覆盖率看到每次版本的覆盖面，以助于决策可否交付。

到这里，持续集成完成了一个里程碑，一个可持续的生态链。

说了这么多关于持续集成的过程，那它有带来什么好处呢？

我们分三个阶段说起，一个是早期手工为主的石器时代，一个是建设自动化测试后的青铜时代，还有一个是CI建立起来后的电气时代。

举一个联机的迭代为例子，手工时期一个迭代的测试周期大约是5天半，自动化时期测试周期大约缩减到了4天左右，到了持续集成时代，周期缩减到1天半左右。

这里有个数据大家可以看一看，测试用例的准备和调试过程。 在早先的手工时期，仅需要准备测试方案和造数据，时间大约是2天左右。 而在自动化时期，因为造数据及调试时的困难重重，它反而耗费了更多的时间。这个现象是值得引起关注的，它甚至会影响自动化实施人员的情绪，进而起到反效应。

好，说了这么多，我们来做个总结： 持续集成通过轻量化测试（接口测试）实现了快速验证接口功能，通过阉割环境和数据，让部署和测试更快、更顺利地开展，最终提升了测试效率，研发可以通过它快速获取反馈。

那么，仅靠它是不是足以支撑我们快速交付了呢？

还不行，持续集成本身就是通过割舍相关内容实现快速反馈，为了实现快速交付业务功能，我们必须从业务场景上保证质量与效率。

关于持续交付，我们有一个初步的设想： 通过平台的支持，实现快速验证业务场景的测试，它与持续集成还是有所不同。

持续集成的目的是基于代码快速验证接口功能，它关注的是接口的实现；而持续交付是基于业务场景快速验证功能，关注的是业务场景的实现。

其次是环境部署要求不同，持续集成仅要求部署单应用/单系统，因为有mock支撑；而持续交付不可基于mock，需要部署全系统，方可基于多系统验证业务场景。

还有就是数据方面要求不同，持续集成的数据是基于测试用例的要求而人工造的，而持续交付的数据，我们要求进来贴近生产数据，若可能暨生产数据。

最后一点就是测试方案的差异。 持续集成的测试思路和以往一样，从业务出发设计测试用例，再按场景运行用例，而持续交付的差异是，我们基于数据进行测试，有什么样的数据就测试相关场景，无数据则跳过改场景测试。

这也是为何我们要求数据要贴近生产数据的理由了。

这是我们DevOPS平台的业务架构，基于持续集成系统，我们还在路上，在成长。

-- 演讲视频 --

感谢您的阅读

您的支持是我最大的前进动力

- End -