东吴证券张之浩：从理论到落地的 DevOps 体系建设

近日，第四届中国金融科技产业峰会、第三届中新（苏州）金融科技应用博览会在苏州国际博览中心开幕。大会同期举办的博云“云原生应用与实践”分论坛汇集金融行业头部机构与云原生技术领域专家，共同深刻探讨市场发展格局。

东吴证券信息技术总部副总经理张之浩进行了“东吴证券 DevOps 规划与实践分享”主题演讲，以下是演讲实录。

演讲实录 👇

尊敬的各位嘉宾、专家，大家下午好！今天为大家介绍一下东吴证券在 DevOps 体系当中的探索和实践，我是东吴证券信息技术总部的张之浩，负责整个研发条线的管理。

我进入东吴证券做研发有 10 多年的时间，见证了东吴证券从 0 到 1 建设的整个研发体系。在这个过程当中，我们走过很多弯路，也发现了很多问题，感谢博云的邀请，今天借这个平台，让我分享一些相关经验。

01 建设背景

今天的分享包括四个部分，第一部分是整个建设背景。近年来整个金融企业，尤其是券商银行，提的较多的概念就是数字化转型，数字化转型面临了很大挑战，一方面对于新兴技术，尤其是创新技术，包括互联网、大数据、云计算，人工智能甚至区块链，本身发展就特别快，对研发要求比较高，随着研发技术逐步深入，业务发展对技术部门提出了更高要求，一方面是客户的需求一直在变化，另一部分是希望技术直接推动业务。原来我们一直在讲，业务引领技术赋能，现在更多讲的是怎么推动整个业务发展，所以从这张图可以看到，我们当时去摘录金融机构做数字化转型相关文章的关键字，出现最大的是组织效能，怎么做变革、怎么做创新，对 IT 人员来说是比较高的挑战。

东吴证券从 2015 年真正开始做独立的自主研发，2015 年之前，大多数的研发都依赖于供应商，做简单的二次开发，或是简单的工具研发，并不成体系。2015 年研发规模只有 20 人，项目只有 5 个。经过几年发展，2021 年我们研发队伍已经成量级的上升，现在大概有 200 多名研发、50 多个项目。一个量级的发展，对于研发管理的挑战也很大，比如在这个过程当中怎么管需求、怎么跨团队协作、怎么管理环境，在统一柜台集中交易的使用过程当中，不同的外围系统都会用这个资源，有可能 A 团队做的东西会被 B 团队改掉，那怎么按照规范的方式推动整个研发的流程？有一些东西是手工做的，效率非常低，原来还没有 DevOps 体系，整个工具、所有的研发各自搭一套制品库，带来了很多技术问题。

2015 年之后，我们逐步接触 DevOps 体系，也是近几年各个金融机构接触比较多的理论体系。当时我们的做法跟很多家都不一样，我们不是想用 DevOps 直接建一套平台，而是首先要熟悉这套理论，然后做工具的引入。我们的做法是先拿工具引入到各个项目团队，让大家了解整个 DevOps 的自动化工具、流程化工具，提升所有研发人员的文化和意识，让他们知道，我们的研发是可以按照一个标准化流程去做的。也是近两年来，我们才开始真正去做整个 DevOps 大的平台搭建与建设，包括后续会建一些 DevOps 体系标准，以及相关成熟度评估。

02 探索历程

我们 DevOps 的探索历程，是从 2017 年开始的。刚开始没有研发流程，没有统一的研发工具。那时候研发工具五花八门，各个团队背景也不一样，有一些团队是从制造业、或是传统行业去做 C++，有一些是从互联网公司挖来做的比较好的敏捷团队，有的是应届毕业生，只有理论一套。

一开始我们没有整个大的统一工具，2018 年开始我们做了一个事情，整个东吴证券研发中心有两个部分，一个是苏州研发中心，还有一部分是上海研发中心，我们把两个研发中心的基础管理类工具全部做了统一，包括项目管理工具、代码库均做了统一，2019 年专门成立了质量保障团队，跟传统的团队不太一样，除了承担原有测试团队的功能之外，对整个研发质量和流程做管控，部分项目使用流水线。从 2020 年的时候，全面推广 Scrum，双态流程越来越高，我们希望是在同一个体系支撑之下做的，我们全面开放 Scrum 流程，并且能够引入自动化工具，实现代码审查，实现一些接口自动化测试。

在今年开始，我们正式跟博云合作，就是完成整个 DevOps 大平台的搭建，进行度量持续的改造过程。我们做的第一步，就是统一工具，我们用很多成熟统一的工具，让所有研发人员了解 DevOps 是这么做的，我们之前用 JIRA、Bitbucket、Confluence，这是一个全家桶，我们一直认为在工具的使用当中，并不一定哪个是最合适的，你只要用起来，在这个过程当中都是比较合适的。

我们引入了整个 Scrum 模型，包括我在内，很多同事都去考了 Scrum master ，因为我毕业的时候就加入了东吴证券，对于敏捷开发，包括对于 Scrum 模型了解不够深入，经过几年工作之后，也使用了一些工具，知道了 Scrum 模型在整个研发过程的角色、事件、会议、原则。工作一段时间、运营一段时间之后，才真正了解到 Scrum 可以做什么。现在是按照 2-4 周做冲刺迭代，使整个研发团队的效率变得更快，收集需求的速度更快，发布版本也更快，不管业务条线还是客户条线，给予我们的反馈都是比较正能量的。我们原来稳态的开发，按照 CMI 的逻辑去做，做一些文档，做前期的需求分析，做详细设计、概要设计，最后做测试、验收，周期好几个月。业务部门说你们到底做什么，两到三个月都没有成效？现在不一样了，业务部门 2-4 周，就会出一个版本、做上线，另外一点比较好，当我发布了新版本之后，如果出现任何问题，我们可以立刻做回退，这个是第二件事情。

第三件事情是引入流水线 。我们希望每一件做的事情，都是按照既定的目标去做，我们还可以引入整个自动化环境部署、自动化测试，所有东西不应该是通过“人肉”的方式去做，引入流水线对于传统的研发人员挑战比较高，对于研发的接口测试、单元测试，都有比较高的要求，研发人员写完代码，可以直接上传到内部的 Git 代码仓库，我们通过触发器定时，或是根据事件的触发，对它进行代码抓取、构建，以及最后的发布，也是通过容器技术，可以快速部署整个开发环境、测试环境，甚至是生产环境，这边代码刚提交，那边就打包、编译、上传，甚至发布，Bug 越早发现，修改的成本就越小，如果在生产时已经部署了，再让客户发现对它进行追踪，其实效率就非常低了。

自动化测试分很多种，一方面是做接口测试，一方面做 UI 测试，在这里面，对于研发团队来说往往需要把整个单元测试的覆盖度达到至少 60%-70 %的水平，做的好可以达到 80%，研发人员研发代码之后，自然而然做单元测试，就能覆盖到 80% 以上的分支，对于整个研发质量有比较高的提升。

03 DevOps 平台建设

我们前面讲了引入流程，又做了自动化测试工具，最后回到从底层往上走，怎么规范研发的流程。我讲了要做流水线，这个版本怎么做控制；做了单元测试，测试的规范是怎么样的；代码质量是如何控制、代码分支如何部署，当时一开始的时候我们做了很多规范性的东西，但是发现光做规范是不够的，规范是规范，实际操作是实际操作。这个过程当中，我们发现有一些管理是很难到研发团队真正落实的，这个是做了很多工作以后我们遇到的瓶颈，我们规划的事情往往不能够很有效的推广到各个研发团队里去。怎么去落实，这个是我们近期建的一个 DevOps 的平台建设。

整个 DevOps 建设平台的目标，是希望通过 DevOps 的整个理念，包括使用 Scrum 模型，建设整个研发能效平台，实现从端到端的打通，提升整个研发效率与质量。整体而言，我们希望我们做的事情，第一能够适配各个研发条线的各个技术栈，不管你是做什么的，甚至做各种语言，我的兼容平台，可以兼容所有的开发语言和开发工具。第二点我希望 DevOps 平台建设搭建出来的东西，是简洁应用的，不影响原有研发人员的研发工具使用和操作习惯，该做 Git 上传代码都 OK，他上传之后，我们在平台上做编译和校验。整体而言最后希望通过高效的手段，把整个研发过程完完全全构建出来，比较高效的实现整个研发过程，实现我们整个平台的高效保障，这是我们跟博云共同研发建设 DevOps 平台的总体框架。

从底向上看，我们之前跟博云合作过其它的一些技术，从底我们做相关资源的平台整合，或者是去做应用。往上看从左到右，几乎是整个研发的全过程，这里不类举了，每一个点都非常多，包括怎么管代码、怎么管需求、怎么流水线、流水线出来之后度量怎么分析。一个研发团队，站在我的角度来说，我很关心比如说现在有 50 个研发项目组，怎么看代码好坏、研发是不是达到既定的目标、怎么看项目进度、原有的软件图是否能满足我们要求，在做整个 DevOps 平台的时候，我们通过这种建设，能够在原有代码和项目的管理基础上，为所有的项目组提供相关的服务。

再往上是整个大的门户，所有需要看到的数据、所有度量的指标、所有的流水线进行哪一步、出现了哪些问题，通过整个平台都可以看得到。

这个是项目里面的截图，整个研发流程，变得可视化了，而不是像以前的黑盒，通过传统汇报的机制，项目进行百分之多少，写一个日报，以前经常去做分解，去做 WBS 分解，现在通过平台完全看得到流水线状态，整个研发状态、研发的人每天在做什么事情，把流水线展开之后，看得到每一个阶段编译的时间是什么样的、涉及到的需求有哪些、最后是不是有出现问题、出现问题我的日志是怎样的，都可以追踪出来。

平台建好之后，能实现整个研发过程的数据可追踪，原来研发是黑盒，现在从需求设计到最后的上线，每一个阶段都看得到，而且是以版本作为一个中心，从需求开始是哪个版本，已经确定下来，这个需求是谁写的代码、哪个版本的代码、什么时候构建的流水线、什么时候做流水线的部署等等，我都可以追踪出来，其中有一个阶段出现问题，在测试环境发现一个 Bug 之后，很快就可以定义到这个代码是谁，在什么时候写的，根据哪个需求做开发，整体以版本做测试，有效提升研发过程和效率，很快能追踪问题，发现问题，数据有了之后可以做度量。

有了数据之后，可以度量整个研发，以前最大的痛点，我们的研发团队，来自各个不同行业，也有一些应届毕业生，对整个度量自己心理都没数，自己做的东西总觉得很辛苦。有数据之后，可以做度量，一方面所有的精细化数据，每一个程序员做什么、研发工程师每天写了多少代码、代码覆盖率是多少、测试之后跑的结果怎么样，通过精细化管理，为所有研发测试人员提供改进手段和数据，通过 DevOps 平台建设，使得原来手工做的东西全部通过自动化实现，做 DevOps 平台的时候是和博云联合开发，各家做 DevOps 一定有自己的不同想法，我们需要跟各家的实际情况做定制，我们在东吴证券做了大量的指标计算也好，做流水线配置也好，这个是比较关键的，最后我们相对来说通过研发度量的数据分析，能够比较准确实现研发过程管控。

这是研发度量里面有指标做的截图，做度量指标的时候，并不是 KPI 和度量做绑定，而其实是作为一个改进的参数，让达到知道在工程维度有哪些地方做的不是特别好，项目维度哪个做的不好，整个开发的过程维度，整个团队的协调组织架构过程，以及交付过程中有哪些改进，比如说都是敏捷类开发的，互联网类的项目，我比其它的项目组有什么不同，这个可以做度量和提升的点，我们整体会出一个大的视图，让大家知道我整个度量维度是怎么样的，最后 Scrum 结束之后，有哪些必须要做改进，这个才是关键的点。

平台搭建完、度量完成之后，我们还做了一件事情，就是整个 DevOps 的成熟度评测，因为我们希望今年年底参加他们整个三级评测，最主要是以评促建，第二个是提质增效，通过外部视角看到我们研发平台有哪些不足，和行业内、行业外有哪些差距，以提升研发的水平和质量。

04 总结展望

至于我们未来要做哪些事情，首先在平台建设完成之后，大家原来用的工具很多，但是平台逐步在用的过程当中，第一是自上而下的推广，平台让大家全部使用起来，但是所有的反馈和持续的建设，一定是从下往上逐步反馈的，所以这个本身来说，就是一个持续改进的过程，我的 DevOps 平台，一定要靠自己运转起来的，不是靠供应商持续给我们提供服务，需要我们自己的研发人员，自己的管控人员持续做度量和分析，最终实现平台真正规范的落地，这个才是我们精细化管理和研发效率提升最主要的方向。

在整个流程方面，我们在做整个 DevOps 的过程当中，发现其实还有很多流程是需要完善的，我们真正希望通过整个平台实现一体化、一站式，最好是不要有人工介入的全流程的研发过程。

云原生三件套，第一是云、容器和云管方面；第二是微服务、服务网格；第三块是 DevOps。怎么把三角套串起来，一方面是通过基础资源的整合，另外是通过 DevOps 把流程串起来，还有微服务化，怎么能比较有效实现服务的快速部署以及最后上线，对于研发队伍和信息技术比较关键。我们怎么拥抱云原生，接受云原生，我们希望把内外网隔离，我的发布往往是层层审核，最后是手工部署上线，因为我们的信息安全要求，包括系统可用性要求是非常高的，怎么通过云原生技术的手段，提升整个的代码质量、提升整个技术系统的稳定性，这个值得探索，券商端 90 以上的券商，系统的上线和部署是通过手工方式去做，我们怎么通过云原生能够高效、高可用、可收缩，怎么能够实现系统的线和运营，怎么实现 DevOps 的体系建设，这个是我们未来持续要做的。希望在座的各位将来能够经常跟我们沟通，也希望整个行业在 DevOps 体系的交流越来越多。

以上就是我的分享，谢谢大家。

公众号后台发送消息 “拥抱云原生”

即可获取本次演讲 PPT