打造券商金融科技基础核心竞争力

彭小阳

作者简介：李青，来自华泰证券，我是做效能提升，之前是做DevOps的产品经理和效能经理。

作者的分享从四个方面展开：
第一个是关于传统券商的研发模式，和我们在发展过程中的诉求，这个是我们要做DevOps的基础原因。
第二是我们现在在华泰证券已有的技术转型的探索，就是在DevOps之前我们探索了相关的工作，包括精益，包括敏捷，这些相关的事情是我们做DevOps之前已经有了。
第三个是DevOps平台怎么搭建的。
最后是总结和展望。

1、传统券商的研发模式和发展诉求

说一下我们传统券商，传统券商业务很多，我加入券商行业一年多，对我们这一块的业务熟悉度不是很好，基本上总结一下，是有这4种业务：

第一种就是经纪业务，就是我们个人散户去营业厅开户，券商是帮大家做在交易当中的代理环节，这个是基本的经纪业务，是面向个人用户。
第二是资管业务，是根据用户与券商的合约，规定的一些方式和条件，对客户的资产进行管理，相当于就是代理不同的资管保值增值工作做投资。
第三是投行业务，目前主要是包括了与公司之间的业务，像公司要上市，要发行，要扩增，这个时候券商帮助公司做证券承销，交易，兼并、收购。
第四块就是自营业务，简单说券商获得牌照可以自己炒股，券商可以在股市做投资，获取项目回报。
结合用户的场景这个业务变得复杂了，我们通常做互联网业务，做普通的基础业务也好，大家发现我们的用户基本上是两类，内部用户和外部用户。

内部是我们的营销人员，管理人员在我们系统做一些配置，券商内部的人员会写代码，有一些写算法，会写交易类的自动AI算法，或者是基本的量化投资的算法，这个时候你会发现内部用户除了用户以外，我们理解的用户，就是多了一批程序员。
外部用户，两大类，一个是散户，他们业务的形态在经纪业务范围内，也有一些资本做资管业务。还有一些就是面向公司了，我定义为老板。这样的用户和我们的业务做结合，我们就会发现我们的产品或者说我们内部的系统非常多。据我之前对公司内部了解，华泰证券在已有的所有系统可能是超过300多个，甚至不止。
这样的话我们就需要做一些事情，我们想要做什么？我们想做传统IT的形态，向金融科技的形态转型。这个转型是大部分的券商要做的，随着社会不断发展，随着金融不断的进步，国家对金融有三大，银行、保险，证券，证券业是目前来说整体规模是落后于银行和保险。
券商希望在不断开放的过程中加速自己的发展步伐，必须要能够参考现在已有的国外的先进投行、券商的经验做转型，那么就要引入更多的科技元素。我们转型主要是两个方面：

第一方面就是我们原来券商传统的模式大部分的系统是外购，包括一些交易的核心系统，原来很多的是通过外部系统来操作。我们逐步需要自研，我们要搭建一个平台，引入一些技术框架，去参考现在业界比较火的互联网的技术。
第二个就是通过整体的研发管理模型转变，原来我们传统开发的方式是管外购，管需求，管结果，中间项目管理过程是外包方的手里，我们向自研转型过程中要引入相应的敏捷。
这个过程中我们面临三大类问题，包括项目管理，数据度量，工程实践。

这个项目原来是什么样？我们项目通过外购的方式往自研方式转，大家会要探索和摸索，这个时候会经历一个野蛮生长的阶段，有不同的新技术就要尝试，不同的项目尝试不同的技术，搭建不同的框架，并且项目的数量很庞大，我们发现一些东西可以优化系统，可以带来更多的便捷，我们就做一些改造。
第一是项目管理我们处于比较人去做管理的落后的状态，这个过程是依赖于人来控制和保障，项目经理在其中有很大的作用。同时带来的问题就是QA这个方面的数量不足，项目数量提升了，QA还是原来的数量，这个时候要做过程控制和良好的监控让人做是压力很大，这个是项目管理这一层，这个时候有一个问题就是我们有要求，各个项目团队不一定会执行。
从工程实践来说，我们代码管理这一块，我们建了代码仓库，在这个代码仓库的管理中，你会发现代码的结构是不一样，分支模型也不一样，有的参考了标准的模型，有的不是标准的模型。代码的执行也不到位，有的是有很多的代码，有的不是很多。
第二是制品管理，我们有一个的制品部。实际执行的时候，大家可能发现有一些问题，就匆匆忙忙做修改就放上去了，制品过程就忘记了。
还有就是上线的版本，大家不一定可以记的住，我工单里面是要1.0的版本，上去的时候哪一个版本我也不知道，这个是制品管理方面的问题。
第三是环境管理，一开始欢迎配置和代码有耦合，没有解耦，我们做代码配置修改的时候要从头到尾来一下。并且还有一些问题，是由于环境不一致导致的，环境可能在开发中没有问题，开发完了以后上生产发现了一堆问题，这个是环境导致的。
最后是数据度量，这一层面是依赖手工保障，我们度量在一开始的时候是从系统里面采集的，我们项目管理是靠人，我们靠人来推动，我们采集的度量的数据有偏差，我们项目开始时间靠人点，这个时候可能代码上线了，他忘记了，这个时候我们认为是一个糟糕的数据，我们要剔除，很痛苦。

2、已有技术转型探索

第二是缺乏很有效的衡量工程效率的指标，我们这个会关注于质量控制，我们看发单率是什么样，但是开发的效率我们不知道，我们难以客观的衡量团队之间的能力。因为我们每一个团队都不一样，开发的方式不一样，时间也不一样，这个时候就有问题了。
我们做DevOps之前，华泰证券做了什么事情？第一个是我们做了敏捷转型的推进，我们做DevOps之前，已经落地了敏捷大概一两年了，在这个阶段里面，我们做了敏捷教练下放，到各个团队做培训，和一些跟进，通过一定的周期把一些项目基本敏捷过程培养起来，建立一些制度，这些是在最早的时候做的。

随着敏捷逐步的展开，我们推进了敏捷的成熟度，我们针对敏捷相应的实践建立了这个敏捷成熟度的模型，分5级。到目前为止我们部门自研的项目有60多个，敏捷成熟度2以上可以达到73%，3级以上42%，敏捷推广过程中我们有很长的路要走。
敏捷成熟度看这个，我们分了5大类，包括需求管理，SCRUM迭代执行，敏捷文化，工程时候实践，工程实践这一部分和DevOps有关联。做DevOps之前我们看看工程实践的工作。

在技术框架这一个层面，我们探索有很多不同的点，这些点是做DevOps很重要的基础。我们搭建了一个华泰证券的DUBBO框架，内部做了推广，这个框架是我们微服务团队的技术基础，我们做了K8S容器云，鼓励一些团队在上面部署，我们项目团队现在用的频繁度比较欠缺，从传统应用来看容器云对传统应用的转型要求比较高，这个往容器化的方向也是我们后面会逐步推广和建议项目试探的方向，目前来说这一部分用的比较保守。
我们搭建了私有云和公有云的混合云，这个是我们技术架构。我们还搭建了统一的内网工具的平台。
刚刚讲到基于微服务框架我们有这一套，对这一块服务我们建了要管，我们也有一个基本的微服务标准化治理平台，这个平台上面我们可以看到服务的调用链，在这一块我们要知道我们调用的情况。
我们也搭建了研发测试、生产的隔离环境，每一个环境之间理论上是严格的区隔，必须在每一个环境里面做到相应的部署和测试验证以后才可以晋级下一个环境。组织级定义了单侧的覆盖率，这个是度量和技术层面相结合的结合点，这一部分的要求纳入到流水线中可以实现质量管控。最后是搭建了组织级的PAAS平台，是对中间键的服务已经抽象化。

在CI和CD这一块，我们做敏捷的时候有工程效率，工程效率怎么做？通过CI和CD的探索实现，这个是每一个项目自己通过相应的JENKINS来做，我们CI和CD是依赖于每一个项目自己的能力，他们的规范化是不一样，我们组织级是用SALT来做维护。

我们测试自动化这一块，测试团队也有自动化的体系，这个是基于JUNIT做了UT，基于RF框架做了自接口测试，初步尝试了MOCK测试服务。测试团队用JENKINS搭建了自动化测试调度平台。包括做了简单的自动化的测试，包括UI端，PC端，这一块我们做的比较初步。

最后我们有一个相应的做性能测试的框架这部分性能测试是测试人员自己手工触发的。
在DevOps介入之前我们有安全的体系，安全的活动贯穿我们从项目的立项到结项，以及当中的每一个环节，我们把这些项目设计到每一个项目中，我们主要是涉及到代码扫码的阶段，和测试的阶段，和做黑盒的扫描，生产以后是做生产验证。

3、华泰证券DevOps平台搭建

我们是自研还是外购，这个是长期话题，任何企业做项目会考虑这个问题。答案也是很明显，自研来说优点第一可以掌握所有的核心技术，可以理解DevOps的精髓，任何一个事情自己做理解高于你给别人做。
第二，它更容易激发大家作为组织、作为项目，把DevOps作为己任的归属感，这个时候好处坏处都是你的。
第三点我们可以快速的定制我们要的东西，不要找厂商下需求，过一段时间说这个能不能做，这一点是优点。
缺点第一是上手很困难，成本比较高。我们要提一下DevOps整体理念，DevOps在大家查的时候会发现维基有一个定义，这个定义好像没有讲，好像讲了，DevOps在设计之初概念上就是非常开放的方式做的，好处就是任何比较新的东西或者是比较有益于DevOps的东西可以快速吸纳进来，我认为唯一的宗旨是提高组织效率的能力，都可以纳入DevOps的范畴。这个宗旨是非常的开放。
坏处就是一个新上手接触DevOps的人，没有办法知道DevOps是什么样，这个理解是非常的困难，也不知道要怎么下手。如果大家要做自研的话，这个时候第一缺点就是起点很高，上手困难。
第二点可能是在建设的初期平台不成熟，这个时候要推广是很难，试用团队试用一段时间可能很失望，你是自建的平台，和外面的差距很难，你想了解新的需求没有人反馈。
第三点是平台的不稳定性会让大家对你失去信心。要做自研要做好对这些缺点的应对。
外购这一部分，好处是很明显：
第一是开箱即用，有很成熟的体系和解决方案；
第二是避开前人踏过的坑；
第三个就是自有人员只需要关心需求和项目的里程碑节点，不要关心项目的交付。
最后是可以边使用边学习，我们避开了起点比较高的过程，我们用的过程中可以了解到它应该是这样的。
缺点第一个是产品难选择，我们刚刚开始的时候找了一些厂商做沟通，对于现有一些开放的大厂来说他们大部分的方案是结合在他们自己的云上面，包括像阿里、百度，他们最早的时候输出方案是基于自己的云，号称对私有云做兼容，但是这个是有一些差距。
如果是做私有云厂商做的方案，就是K8S的封装，这个是我们做产品是很难找到适合华泰证券的东西。
第二是与组织的贴合有差异，我们要做定制，像券商，包括银行、金融，对监管、控制、质量、流程都有严格的要求，不可避免就有大量的定制化。
第三个就是核心能力这一块，你做完了以后并不了解，这个是自研和外购的优劣势。
我们华泰证券走了前一条路，我们就会发现有一些痛苦。

刚刚开始我们接受DevOps这个事情我们作为项目经理参与，这个时候我很有信心觉得有一批人有做需求，有做开发、有做测试的，但是忽然告诉我产品经理就是你了，做需求也是你，我就想完了。我去网上搜，我想这个DevOps概念不是很好找，搜了一批功能列了一张单子就是这些，这个里面有很多到目前为止我们没有启动，所以说在开始的时候，我可以接触就是这些理念。
做下去以后，我发现这么多东西不知道怎么入手，DevOps贯穿了项目管理，持续集成，持续交付，监控、运维，再反馈过来，这些方方面面的点太多了。你想一开始下手吃透所有是很难，我选择了下一个思路。
我们的想法是我不知道全貌，于是我就用迭代，这个就是迭代最适合的一个方式。
我用迭代的方式构建DevOps的平台，我制定是更加具体的短期目标，我选择了一个容易的切入点，这个就是之前给大家看的，我们具备了一些基础能力的方式，我去把它做整合，我们就做CI和CD。

DevOps1.0的目标就是我有这些基础怎么把他们拉齐，我看到我们大家CI、CD过程，大家发现我刚刚讲的点里面都是分散的，不是一个整体，这个是一个方面。
第二点，他们是不规范的，所有的项目不是按照一个标准的方式来运作，每一个项目有每一个项目的做法，并且每一个项目在自己的做法上玩的很HIGH，他们困难就是无法度量，我们想法就是把所有的CI和CD过程整合起来保证我们的版本和制品的映射关系。
第三是我们严控部署的操作，我们做的就是控制这个方面。
最后就是我们希望有质量的数据检查，我们做了数据要求，我们没有检查，我们在这个过程里面要检查出来。来减少人为操作带来的不确定性。
做这个DevOps1.0的时候我们功能是左边这些，我们通过JENKINS打通和CD的通道，整合制品库作为单一的制品可信源，最后是整合测试的报告和整合版本的信息。这个是我们在1.0版本偷懒，我们两周一个迭代，我们想做很复杂的功能会超过我们的迭代吞吐量，我们做了一些拆分。
我们主要的目标就是把JENKINS和我们的CD打通，每一个项目组现在做了一些相应的CI工作，可以保留着，在JENKINS上面写的一些持续集成的东西可以做简单的改造，把这个东西接到这个DevOps平台里面，我们把CI的工作交给项目组做，他们自己做CI这部分，CD这部分由我们的平台控死。
在1.0里面可以保证JENKINS、CI出来的制品进入制品库，从制品库往各个环节发布和部署，部署的通道是我们控。在往制品库放的瞬间，我看你的质量是不是好，我们控制这几个点。

缺点很明显，我们这整个版本是用构建的方式来做配置，这个时候是靠每一个项目组自己写JENKINS脚本完成，对项目组来说接入的代价很高。
第二，因为我把这个构建的过程交给项目组，他们构建是不受控制，不知道他们在构建里面干了什么，有的人构建的时候做一些其他的事，我们不知道。
第三，接入代价相当高，这个是通过项目组驱动，每一个项目组要改JENKINS脚本，就是不要部署。
第四就是UT和SONAR的数据，基于构建产生，可信度有问题。现在这个过程里面，如果他们想做一些动作是可以做的。我们基于对项目组的信任，我们认为可以在初期通过这个方式来放过他们。
最后一个是其他自动化测试还没有，我们只有UT的检查，UT检查是基于构建的。

然后到了DevOps2.0了，这个过程是一直在迭代，项目组试用，反馈意见，我们开发下一个版本。2.0的时候我们目标是新的一些东西上面，我们要做流水线和版本解耦，1.0的时候，我们缺点里面有一条就是版本作为构建参数配置，我们把版本这个事情，我们构建出来这个版本数据放在了构建的过程中，它其实是一个基础的构建参数，我们当时是这么认为，好像不影响任何东西，你做构建，构建完了加进去，很正常。
2.0的时候我们发现流水线是像工厂里面的流水线的概念，我们在上面生产任何的产品，理论上只需要调一些流水线的参数，产品本身就是最后的结果。这个时候我们就认为，版本这个东西不应该是流水线的参数，它其实是流水线生产完了的结果的标签，这个时候我们就把整个版本参数单独拿出来做了流水线的制品结果的选择，一会可以看一下。
第二个是我们需要增加对发布的定义，我们之前的流水线更多是关注部署完毕，部署到生产以后这个版本能不能有效我不知道，能不能回退我知道。我们项目组很多时候不选择回退，在很短的时间把代码改一下，新产出一个版本部署到生产上，我看到就是他部了1.0，1.1，实际上1.0是一个无效的版本。
第三是我们通过流水线推动JIRA单状态，我们用了这个方式以后，我们数据采集就准确多了。
第四是我们打通了OA流程，我们通过流水线发起对OA单的发布申请，这样会减少一些工作。
我们可以打通从度量到反馈的环节，度量数据是比较清晰，这个时候可以从度量的角度看数据。
我们还解决了同一个版本多微服务版本依赖，我们做了版本级的概念，把多条流水线拉到一起，统一到一个环节发布。我们也集成了一些中间键的PAAS平台服务能力，还做了进一步的自动化。

2.0的时候我们把制品作为流水线的配置的参数，我们做了一个基本的结果。这里有一个目标版本，这个就是刚刚讲的版本数据源。
第二是新增了版本集的能力，可以把多条流水线放在一起做部署，同时对生产环境做部署，我们可以拉动多个不同的微服务往一个方向走。
第三是新增了RLS阶段，这个就是发布阶段，我们通过项目经理往这个方向推，我知道他之前在生产上的版本是不是有效，我们也同时可以通过推动的状态获得真正的发布成功率这个度量指标。
第四个就是推动JIRA单状态，我们可以通过每一个阶段来推动JIRA单状态。
第五个我们可以通过某一次的构建看到这一次源码的察看。
第六就是流水线可以出发OA工单。
最后一个就是我们做了在流水线具备了各个阶段的展示能力，我们通过这个按纽切换到耗时的页面上，可以看到所有的耗时的子阶段的情况，这样可以帮助系统、项目不断的改进时间。
这个不好的地方就是UI很粗糙，UE基本没有。那个时候我们没有一个系统级的UI，前端的设计都是靠研发人员自己做的。
第二就是仅解决了1.0版本的版本概念，其他的问题还有。原因也是比较简单，我们当时没有想到其他问题的解决方案。
第三就是只是进一步扩展了现有功能，产品临时抱佛脚的能力和项目经理突破的基础方向决定了这个产品的走向，什么意思？项目经理可以突破这个技术方向，就做了这个功能。

下面我们来到3.0，把1.0的问题解决了。我们把之前构建不受控解决了，我们之前构建是交给每一个项目自己做，到3.0阶段，我们研究了一个模式，我们发现可以有一定的手段让项目的构建过程标准化，这个是很重要的一个点。
第二就是我们增加了相应的接口的自动化测试，这一块是我们把测试的能力尽量的左移到构建。
第三就是我们探索了双引擎的构建的模式。
第四我们降低了项目组接入的成本。
第五是构建资源做了池化。
最后做了优化UE的工作。

标准化的构建过程怎么做？就是把JENkinsSHARED LIBRARIES抽先出来，我们把JENkins所有标准的JAVA工程做了细分，我们抽象了整个构建过程所有步骤，为下面一些环节，包括代码获取，包括UT，包括BUILD。
往测试环境还是往开发环境部署的环节是可选的，然后就是入库，最后是发邮件，并且用SHARED LIBRARIES把这些环节所有的方式以参数的方式暴露出来，形成了一个标准的模板，用户在做流水线配置的时候只要选择这个版本，添入和工程相关的参数，就可以让平台生成这个JENkins的流水线，用户不接触JENkins。
这个好处就是他不要了解脚本怎么写，他只要填写URL，以及他这个上面每一个工程相应的参数，就可以找到他们的源码做构建。

第二个就是我们做了自动化的自助接入配置。原来的时候我们用户要做适用之前，拉入的虚拟机要通过一些邮件报表，或者是人工的方式做配置，通过这个页面，他们配置两个东西，第一个是制品库的目录结构，我们在这里通过手工的方式自己去定义制品库，这样用户可以比较好的定义每一个大的项目下的一些制品模块微服务结构。第二是检测他们的虚拟机，他们把自己的虚拟机填进来，我们关联进来，他们可以用。
同时我们做了自检的服务，我们每天晚上会跑一次，虚拟机不可用就可以看到。
同时在每一次部署前，这个系统会帮他们做自检，保障这个虚拟机时刻可以用。

第三我们做了构建资源的池化，这个是做DevOps都会考虑做的一个事情，因为我们原来有了容器云，我们刚刚讲到这个也是我们的基础，我们拿容器云做构建资源的池化。我们构建资源之前是每一个项目有自己的JENkins，每一个项目不一样，构建的环境不标准。做了池化以后可以达到统一的构建资源，并且可以形成一个横向的比较方式。

这个有一个双引擎构建，这个是我们探索的事情。我们把构建过程分成两类，在构建参数里面用户可以通过配置一个DOCKERFILE方式指名路径，我们每一次构建出两个东西，如果配置了这个，我们就出一个镜像，这样用户可以有两个选择，我们可以部署在虚拟机上，可以部署在K8S容器里面，这个时候我们就是这样子。

在这个DevOps3.0我们做了DevOps3.0+，这个是到现在我们做的事情。我们增加了几个不同的功能，包括独立的配置，独立的数据变更流水线，我们做了MERGE前代码检查，我们做了CI过程并行设计，我们建立了工程指标体系。

独立的配置变更流水线，我们把代码仓库里面让项目组的配置和一些原来的应用做了耦合，配置放在里面以后把基本的配置文件放里面做保存，发布是用阿波罗做发布。通过阿波罗，从制品库拿到相应的代码发布到相应的环境里面去。
数据变更，思路也是基本是相似，我们把数据脚本放进去，我们通过数据变更的流水线把这些脚本逐步逐步向不同流水线做分发，验证。我们可以交验这个数据脚本的一些问题，在这个过程里面流水线会帮忙做。

最后一个就是比较好的一个实践，就是MERGE REQUEST的代码检查，我们通过这个事情来控制项目组对代码仓库的提交，在这个过程里面之前是靠人工审MERGE REQUEST，现在MERGE REQUEST可以出发我们流水线的规则，这个里面可以让这个MERGE REQUEST提交了以后做代码的预编译，做代码的扫描和检查。
等我们架构师拿到这个MERGE REQUEST的时候是一个有解耦报告的MERGE REQUEST，不要关心很多的细节，通过这个报告可以看出来一些基本的要求，这个时候选择到底是否可以接纳还是干掉它。
这个时候可以配置，只要质量可以达标，我们可以选择把这个MERGE REQUEST杀掉。

之前在构建的过程中，我们发现构建比较耗时的点就是在UT阶段，我们做了一个所谓的CI并行的工作，我们是有两个东西，一个是技术构建，这个没有扫描。我们下面起了一个东西JENkins的容器，这样做的好处是什么？
刚刚我们提交阶段已经是强制做了UT扫描了在我们这种发布的流水线做这个事情的时候，我们会考虑这个事情频率不会那么高，我们更关心发布流水线的构建，第一时间我们可以直接做部署，这个时候我们扫描还在跑，没有关系，我们在质量检查的阶段看结果，这个可以提升我们发布流水线这一块的效率。

4、总结和展望

有几点心得，

第一个是让DevOps先DevOps起来，这个有一点绕。我们DevOps小组是一个开发团队，刚刚说了我们是用迭代的方式做，我们也是用敏捷加迭代。试用团队第一个是谁？我们找了一个外部团队，他们试了不理想，后来我们觉得要让自己的小组用这个DevOps做发布，我们就有自己的体会了，然后再修。让DevOps小组自己先DevOps，这个是很重要，可以让别的团队试用的时候发现问题比较少，也可以让自己有一个稳定的平台以后再推广。
第二，提前规划全貌有助于方向控制，我们最初接触产品经理的时候我设计很多东西，很多没有做，我知道我的方向了。我做的过程中，我是不断的纠偏。
第三就是借助DevOps标准明确对最佳实践的下一站目标，这个是华泰证券通过这个标准以后最大的感触，这个可以有效的帮助大家减少对DevOps无所不包的概念的认识，可以帮助大家看到进一步实践的一些点，而且是一些比较靠近你们现有状态的点。
最后心得就是将规则内建于工具，让工具指导实践。我们把工具、规则放进去，我们可以加强对底层的管控。
下一步要做的事情：

第一是现在的规划，我们需要做流水线的可视化看板。
第二是做度量，指示定制化的动作。
第三在生产上面尝试做自动化的测试，这个是现在我们做了这个评估以后发现一个点，我们觉得一些效率手工测试可以在生产上做，我们觉得这部分的能力可以自动化。
最后一个就是我们会把研发环境代码化。