中国银河证券：缺少 DevOps，企业数字化转型就是带着脚镣跳舞

2022-11-21
广东
本文字数：4141 字
阅读完需：约 14 分钟

中国银河证券股份有限公司，作为中国证券行业领先的综合金融服务提供商，致力于成为在亚洲资本市场上领先的投资银行和具有系统重要性的证券业金融机构。中国银河证券目前已在国内拥有证券市场业务全牌照以及覆盖较广的营业网络，业务遍及全球 15 个国家和地区，覆盖国内 31 个省/自治区/直辖市、178 个地级以上城市，有着近 500 家营业部。

而中国银河证券的 DevOps 建设经历了由下而上和由上至下两个发展阶段，也是国内金融企业在建设 DevOps 过程中比较典型的发展路径，因而中国银河证券 DevOps 建设的破冰之路，是证券行业 DevOps 建设案例中的典型。

今天，很荣幸以 DevOps 负责人的第一视角，带领大家走进中国银河证券 DevOps 建设的破冰之路。接下来将按照中国银河证券 DevOps 建设的时间轴，分为“破冰前夕”、“如何破冰”、“建设现状”以及“下一步规划”四部分来逐一详细介绍，希望能给证券同行构建企业级 DevOps 体系带来一些思路与启发。

以下内容整理自：中国银河证券 DevOps 项目负责人黄金泽于嘉为蓝鲸 2022 研运一体创新峰会的精彩分享——《中国银河证券 DevOps 建设的破冰之路》。欢迎感兴趣的读者关注公众号：嘉为蓝鲸，查看演讲回放和下载演讲 PPT。

01 破冰前夕

在企业级 DevOps 平台建设的前期，中国银河证券已有近百人规模的自主研发团队，此时的工具集以开源与免费的工具为主。研发人员自发组织建设 DevOps 的工具，呈现点状分布、工具功能单一、服务连续性弱的特点，也很少会做业务连续性和工具链集群部署，同时有重复建设的特点，这是大部分国内金融企业 DevOps 的现状。

这个阶段建设 DevOps 的初衷，是为了提高工作效率，解决当下问题。这时候的 DevOps 工具的建设，通常由研发人员自发地建设解决自己的问题为主，并不由上层领导推动，提供的服务也以研发人员解决自己痛点为出发点。

比如像中国银河证券，早期使用了 JIRA、Confluence、Gitlab、SVN、Jenkins、SonarQube、Nexus 和 Ansible 等常见的开源工具。其实当这些工具上来的时候，大家还是眼前一亮的，因为效率工具切实地解放了个体研发人员的双手。这也是很多组织在建设“企业级”DevOps 工具体系前的状态。

但可以看到，这个阶段还只是在局部解决一些效率问题，因为在 DevOps 整体工具建设上的痛点，单靠研发人员本身力量是难以推动解决的。

DevOps 整体工具建设的痛点是指什么呢？

具体来说，就是工具的功能过于单一，都是解决个体研发人员的问题，别人想用还要单独搭一套。而企业内每个人都搭一套工具的话，就是浪费资源的重复建设，同时工具之间也竖起了各种数据流转的隔离墙，企业 IT 的整体效率反而被消耗掉了。

所以 DevOps 工具建设的下一个阶段，需要企业花费大量精力做工具间的集成，通过整合工具、打通权限、打通测试数据和日志等数据流，使代码能够在工具之间流转。

此时，企业建设下一阶段的 DevOps 体系，面临着两个大方向的选择：

一就是增加大量的人手，通过集成工具来搭建企业级 DevOps 平台。
二就是花钱购买成熟的商业产品，来实现同样的目标。

说白了，就是看企业更缺人，还是更缺钱。

当然还有另一个更高级的选择，就是既不缺人也不缺钱的企业，那可以考虑自研 DevOps 平台，自研的东西适配度肯定是最好的。

那回到大多数企业建设 DevOps 工具体系的方向性选择上，我们可以综合来看两者的利弊。

就集成工具方案而言，弊端有三点：

一是人不好找。通过集成工具打造 DevOps 体系化工具，需要去招聘市场上招聘人才，而拥有成熟经验的 DevOps 工程师市场上本就不太多。大多数时候，企业需要自己慢慢地培养。

二是建设周期比较长。工具之间数据标准并不统一，打通权限和任务流转需要做大量的二次开发，开发后需要调试和反复的调优。没有多年的建设，很难说交付一个好用的 DevOps 平台。

三是后期的研发度量其实非常难做。研发度量是在 DevOps 平台建设成熟、稳定使用后更高一层级的需求，可以理解为是研发工具的中台系统，它能提供研发过程的各类数据。在建设到这个阶段的时候，企业就会发现，前期工具整合的深度还远远不够，还需要进一步地整合。而二次开发越多，工具本身的升级就越困难，这就掉入了一个坑里。

那集成工具的优势是什么呢？

优势是企业经过大量的二次开发，通过与项目团队多年的磨合，不停地迭代、改造，磨合出了企业自己的一套 DevOps 平台，它花费了企业本身很大的精力，那它的优势就是较大程度上适合这家企业的。

但是企业需要经历前面一到两年，甚至两到三年的痛苦期。集成工具的前几年，它可能不会带来效率的提升，甚至可能拖累整个研发效率，DevOps 团队是会被质疑的，甚至团队活不到平台建成那一天。

那砸钱买的成熟平台，优势又是什么呢？

优势就是快。可以马上吸取行业多年的沉淀经验，工具里面固化的经验和方法，企业拿来就能用。
再一个就是不容易走弯路。DevOps 平台的建设非常依赖 DevOps 负责人的经验，他的方向错了，平台很可能就失败了。

可成熟平台的劣势是什么呢？

劣势就是产品只能适配企业七八成的需求。

比如企业里面有一个特殊的系统，有特殊的构建和部署方式，那产品只能优先考虑解决七八成通用构建方式的系统，最后才会考虑适配这些特殊的系统。而且在适配上，也有需要企业项目组自己去适应产品的地方，而不是由产品来适应所有的项目组。产品没有办法保证，能够百分百适应所有团队的使用习惯。

以上就是企业级 DevOps 工具体系建设的两种路线选择，可以根据自身企业的情况来做出选择，并没有一个行业通行的做法。

02 如何破冰

首先，需要自上而下推动企业 DevOps 平台的建设。可能有人会问，怎么自上而下呢？

因为 DevOps 的工具特点就是解决研发测试人员本身的问题，而不是解决上层领导的问题。上层领导可能看不到研发怎么解决的问题、问题解决得怎么样，看不到的问题，那就觉得没有问题。

所以，这就需要有个抓手，能够提起上面领导的重视，同步解决研发人员自己的问题。

这个抓手，就是研发度量。

前面提到，研发度量就是企业研发工具建设的中台系统。通过让研发人员都在 DevOps 平台上来干活，干活就产生数据，有数据就可以作分析，分析出来的内容就可以度量，度量出哪里好、哪里不好、哪里有瓶颈，同时还能考核外部的厂商。

这就抓住了上面领导的需求，同时解决了下面的问题。所以说，度量就是推动自上而下的一个关键，也是破冰的抓手。

DevOps 的建设是企业数字化转型的前提和基础，几乎所有的自主研发型 IT 团队都离不开 DevOps。我们过去时常提及企业数字化，那企业里面研发人员都没能数字化，他们都没有效率工具和研发过程可视化工具，他们都没有自己的中台，又如何让企业内业务部门数字化呢，又如何懂给别人建中台呢？

所以 DevOps 平台是非常重要的基础设施，没有 DevOps 平台的企业搞数字化，研发人员其实就是带着脚镣在跳舞。

中国银河证券从 2013 年起就开始了建设 DevOps，当时首先引进了项目管理工具 JIRA 和 Confluence。

2013 年至 2019 年，是自下而上建设 DevOps 的阶段，这时候使用了大量的免费开源工具，分散式地构建了大量的技术栈。

2019 年至 2021 年，通过引进外部咨询加开源工具的方式，初步整合及搭建起企业级 DevOps 的工具链。

2021 年到 2022 年，公司通过采购成熟的商业产品加整合已有工具的形式，自上而下地建设了 DevOps 平台，帮助我们更好地推动企业数字化转型。

03 破冰现状

目前通过引入嘉为蓝鲸产品，中国银河证券逐步搭建起了适合自身业务特性的 DevOps 平台。

以下是 DevOps 完整流水线的配置示意图，可以看到中国银河证券是重流水线设计型的，而有一些企业是轻流水线设计型的，这个没有好坏之分。在中国银河证券流水线的应用里面，会设置有大量的门禁和审批节点，帮助中国银河证券实现研发管理的自动化和强管控。

以下是我们自动化测试工具接入平台的示意图。目前，中国银河证券已陆续建设了接口测试、单元测试和 UI 自动化测试，后面还计划建设性能测试和安全测试。

以下是 DevOps 流水线的质量门禁。通过整合测试相关的数据，在流水线中加入可以定制化的质量门禁。开发的日常工作中会有很多定制化的数据进来，当不符合门禁要求的代码流经流水线的时候，门禁就会自动化拦截并通知相关开发人员，实现代码质量的自动化管控。

测试作为流水线里边很重要的一个环节，它是后面能做门禁数据的一个前提，也是门禁数据的其中一个来源。只要自动化测试做得好，我们就可以节省很多功能测试的相关人员。

以下是 DevOps 数据打通的示意图，自前期设计的时候开始，中国银河证券就已经做好了打通所有研发数据的准备。中国银河证券基于 JIRA 的需求编号，通过让开发人员在代码提交时，要求在 Git Commit Message 中关联到 JIRA 需求编号的形式，将需求任务、开发任务、缺陷代码、流水线集成、部署制品，数据打通并关联到一起，为后续度量平台的建设提供了数据上的支持。