数字化转型浪潮下，金融机构的科技部门在自身组织与企业文化背景下，是否适合做 DevOps？是否能够平稳落地 DevOps？如何在满足监管合规的前提下，利用 DevOps 更快更好的响应业务？

本文围绕传统金融机构是否需要DevOps、传统金融机构落地 DevOps 的难点及落地路径等内容，帮助传统金融机构理清DevOps落地需要考虑的问题，以及为其启动 DevOps 建设提供建设路径与实践经验。

一、传统金融机构是否需要DevOps？

传统金融机构的典型研发流程

大致流程如下：

业务团队

• 角色定义：相对于科技团队之外的业务团队，需求提出方，如银行的网金部、券商的固收部等。

• 主要工作：通过线上OA/线下Excel/线下会议，向科技部门提出原始业务需求。

 

需求/架构团队

• 角色定义：科技部下属的需求团队或架构团队，可能承担着业务需求拆分、重要系统架构选型等工作。

• 主要工作：业务需求评审，拆分成若干系统需求，可能这时已经明确大致的上线时间。

 

开发团队

• 角色定义：科技部下属的开发团队，如某系统开发组、某项目组。该团队可能是1-2个甲方项目经理和一支项目/人力外包服务队伍组成。

• 主要工作：根据系统需求，进一步完成详细的需求、设计工作，经确认后进入开发测试阶段；（做的比较好的，BA阶段测试团队也已经开始介入）。

 

测试团队

• 角色定义：科技部下属的测试团队（可能是独立测试团队资源池化管理，也可能是每个系统开发项目组中有专门几个人）。

• 主要工作：以资源池抽调资源到不同项目，或针对某系统/项目提供相对固定的测试工程师团队以完成相关的工作。另外，性能测试团队也有可能是共同团队。

 

运维团队

• 角色定义：科技部门下属的应用运维团队，可能会存在部分外包人员做辅助技术支撑。

• 主要工作：负责应用的生产环境部署、升级及日常运维。

 

整体来看，传统金融机构的典型研发流程很多时候其实并不那么”敏捷”，而是传统的瀑布模式居多，甚至很多时候，还会有一些临时插播进来的紧急需求（是需求，不是缺陷）。

我们能通过DevOps去解决什么问题？

在现有的流程下有哪些问题，我们可以从研发过程相关的部门/团队的职责边界以及对应的工作内容、关注点上来看：

业务部门

• 业务需求何时能够上线？>>>业务响应速度/及时性。

 

需求团队

• 业务需求何时能够上线？>>>业务响应速度/及时性。

• 业务需求拆分成系统需求后，如何进一步做准确的系统需求拆分与分析？>>>需求分析管理。

• 系统需求完成分析后，后续设计/开发工作是否能够满足进度要求？>>>开发进度。

• 系统需求完成分析后，后续测试工作如何组织，以及组织的如何了？>>>测试质量。

 

开发团队

• 需求/任务开发进度？>>>业务响应速度/及时性。

• 需求分析是否到位？>>>需求侧协同 & 需求分析完整性、准确性。

• 基础工具链是否具备、功能完善、易用？>>>研发基础设施完整性、易用性。

• 代码质量如何？>>>静态代码扫描、人工代码评审、结对编程。

• 功能/性能测试团队是否能够充分理解需求？>>>测试准确性

• 开发过程缺陷跟踪情况如何？缺陷提交情况、缺陷修复情况、缺陷数据统计。

 

测试团队

• 测试计划安排情况？>>>测试管理

• 功能/性能/安全测试团队是否能够充分理解需求？>>>测试准确性

• 开发过程缺陷跟踪情况如何？测试过程跟踪、缺陷提交情况、缺陷修复情况、缺陷数据统计。

 

运维团队

• 应用部署包（含部署脚本、部署说明书）是否完整、易用？>>>合规性、安全性、可验证性、可追溯性。

• 应用巡检、应用监控等。

传统金融机构能通过DevOps带来什么收益？

什么是DevOps？

虽然提到 DevOps，大家第一个想到的就是 CI/CD pipeline，但是 pipeline 并不是DevOps 的全部，甚至业界也几乎看不到单个产品去解决 DevOps 中的所有问题。

为什么？

通过上述传统金融机构的典型研发流程梳理，就可以看出，这已经涵盖了应用/产品从需求提出到上线维护过程中的所有动作。这里涉及到的，不仅是 pipeline 上集成的各种开发工具，包括 jenkins、gitlab、sonar 等，也包括需求管理、测试管理过程中的其他工具，如瀑布/敏捷研发模型、TDD/结对编程/各种估算方法等等实践。并非所有的工具、所有的实践方法都匹配任何一个客户，这中间会有采纳、有适配、有优化、也有放弃。甚至同一个组织，在其发展的不同阶段，所使用的的流程、方法、工具也会有变化、演进。

所以 DevOps 项目的建设过程，与其说是一套工具链的实施和使用，更完整的定义应该是从组织架构、人员角色、流程规范、平台工具等各个层面的改进与提升。对应的，要想通过一期/一年的项目建设，就建立起组织级较完备的 DevOps 体系，其实是不现实的。

DevOps落地是否一定要绑定敏捷研发？

通过上一小节的探讨，其实我们已经知道，在 DevOps 实践的产品/项目研发阶段，我们可以应用到敏捷的一些方法和工具，比如 Scrum、TDD。那是否就意味着 DevOps 落地一定要绑定敏捷呢？

在我们实际落地的过程中，确实并非所有客户、所有的产品/项目都是完全采用 Scrum或者是其他敏捷方法去完成开发过程的。特别是对于中小型金融机构，瀑布流的项目数量可能会远远大于敏捷流的项目，这都是在 DevOps 落地时需要去考虑的问题。

我们来用 Azure 上关于 DevOps 与敏捷的对比与关系的一段描述来体会一下：

DevOps 的表现形式：

• 持续集成/ Continuous Integration：（代码）集成、编译、测试；

• 持续部署/ Continuous Deployment：（制品+配置+数据）部署到环境（非专指生产环境）；

• 持续交付/ Continuous Delivery：（系统=原有线上内容+新上线制品/配置/数据）在生产环境交付，实现业务价值、产生反馈、持续改进。

 

根据以上的分析，在 DevOps 的语境中，敏捷是其中的一种开发方法，DevOps 与敏捷的关系，既非绑定，亦非互斥，而是相辅相成。

所以以绑定敏捷这件事出发来说，在落地 DevOps 的时候，需要充分考虑客户的现状，这个现状，包括现有的组织架构、人员分工、流程规范、各种工具应用情况，甚至外包团队的管理方式等因素。DevOps 的建设，也不是上一套系统就可以全部完成的工作。

DevOps的价值收益

DevOps 的核心目标，其实就是研发能效、研发质量、更快更好地把软件发布上线，就是所谓的尽快交付业务价值。“ 尽快交付业务价值 ”这一目标，无论是敏捷、DevOps、精益等等概念、体系、实践方法中都是一致的。

而这些价值，是如何在传统金融机构中所体现的呢？

数字化发展、有序推进创新、稳妥发展金融科技，已经明确列入十四五规划，银行业、证券业等传统金融机构的数字化转型，已经形成共识并展开探索。

在这个探索的过程中，科技的地位正逐渐产生变化，由原来的纯粹技术点支撑，逐步开始与业务侧产生更多的互动与融合，如近年来国有六大行和股份制纷纷成立的金融科技子公司、金融云子公司；而很多银行客户也在考虑、筹备、成立的数字银行部，其实都是在探索这条道路；而在券商领域，不仅仅是头部券商，包括很多肩部、腰部的券商机构，更是在科技研发上有着非常多的投入，并且逐年还在明显提升。

而随着监管、市场、需求、技术的变化，金融业软件系统的技术、组织的复杂度、响应速度和自身质量要求也在日益提升。所以，在这个过程中，科技需要释放更多的能量，去快速、有效、合规，并且高质量地完成软件应用系统的设计研发、交付运维，是板上钉钉的刚需。

DevOps 作为软件工程领域目前大家公认相对更好的一种工作方式和 IT 组织文化，在流程标准方面，具备相当的弹性；在实践方法上，融合大量的敏捷实践；在工具集合上，具备丰富的开源/商业生态。

作为传统金融机构的科技部门或团队，谈 “ 科技引领 ” 可能并不适合，但科技对业务响应的速度，业务运营中业务团队对科技团队更多的依赖和融合、局部业务快速投入使用获取反馈再继续改进的场景，一定会越来越多。

而 DevOps，可以是一把钥匙，帮助科技部门甚至业务部门去不断地探索和发展。所以当我们掌握了 DevOps 这种工具、方法和文化时，对于科技部门来说，一定是有百利而无一害的。

二、传统金融机构落地DevOps的困难与挑战

自上而下，还是自下而上

自上而下更好，还是自下而上更好，这是所有项目都会面临的一个问题。然而根据我们的经验，对 DevOps 来说，大多数情况下都是自上而下去做的话成功率和效果更高。

为什么呢？

大家请思考一下，我们落地任何一件事情的套路，是不是都是：什么组织、什么角色和人员，在何种环境条件中，在何种规范框架下，采用一种什么方法和工具，去完成一项工作，以达成某个目标。我们可以把这个过程称为一个场景。

而 DevOps 的场景是什么？请回顾下以上关于典型研发流程和 DevOps 要解决的问题相关章节。我们实际上是需要通过多个部门、团队之间的持续协作，在一定周期内去完成某个需求或者应用的研发和交付。这里边大量的人员，他们的文化背景不同、组织归属不同、核心KPI不同、甚至个人诉求也有很大差异。

所以完整的 DevOps 落地，一定是一个跨部门、跨角色、跨流程的工作。这一切的顺利开展，都离不开高层领导的关注、支持、推动与协调。

 建设牵头部门应该选谁

最典型的中小型金融机构科技部组织架构：开发、运维，可能还有数据；更复杂的可能还会有异地研发中心、重要系统群（对应业务版块）单独成立的二级部门；还有些机构可能直接是需求、架构、开发、测试、生产几个二级部门。

我们接触的客户，在最初去了解 DevOps 的时候，以开发、运维部门发起的更为普遍，少数也有是测试部门发起的。

相同的点在于，不管哪个部门发起，其实中长期目标都不是解决二级部门或者某个个体业务系统的研发交付过程，而是组织级的，这说明大家都充分认可 DevOps 对于科技组织的价值，并理解 DevOps 是一个跨部门、跨角色的一个长链条活动。

不同点在于，如果是开发部门发起，项目的定位会更偏向开发侧，比如需求管理、流水线工具链支撑、单系统多版本并行开发部署等需求点；如果是运维部门发起，项目的重点可能就会更偏向自动化部署，包括我们看到有些项目，名字叫做 DevOps，实际上只是在做应用自动化部署这件事；再有比如测试部门发起，可能也是 DevOps 项目，但他们会更关注测试相关的生命周期环节，包括自动化测试的工具等等这些内容。

认识自身的组织与文化

每个企业和组织有着自身的文化与制度，而文化与制度的关系，文化是上限，制度是底线。有企业文化、企业文化在行动中的组织，与企业文化在墙上和官方网站上的公司，在战略落地过程中是完全不一样的。我们不可能靠流程制度解决所有问题，因为一切事务都在不停变化，而做事情的始终是人，也不是一成不变的机器。

DevOps 由于涉及到不同部门的协作，以及一些所谓 “ 最佳实践 ” 的引入，会带来一些具体工作方法、工具、习惯规约的变化等等，必然会与旧秩序有很多不同的点。很多时候未必是颠覆，但是确实在框架和细节上可能会产生变化。所以如何适配、原有的抛弃哪些、保留哪些，新的采纳哪些、放弃哪些，都需要反复的磨合。

如果分析 DevOps 导入没有达到预期效果的原因的话，就会发现这里面有一些与文化有关。比如说：组织没有能力改变文化，以及对变革的抵触。当发现新的实践方法与现有的组织文化、领导者管理风格、个人绩效产生摩擦，构建跨部门团队受阻，冲突就显现了。

如何保持组织敏捷的持续性与延续性？

花了 1 年时间，上了 DevOps 平台，导入了两个业务系统的软件工程。有了这些，组织就敏捷了？

组织是由人组成的，必然会有流动。

当不停的有人进入、有人离开、有人调岗，我们所沉淀下来的 DevOps 相关经验是否还是适配当前的组织？我们组织中不同团队对于某一领域实践的认知是否仍然保持一致？我们的团队是否还理解我们为什么会对某一具体实践做调整优化？是否还知其然也知其所以然？顾问离场 3 年后，我们如何做到工作模式的与时俱进？

所以组织级敏捷性的持续性、延续性以及文化的传承，实际上不仅仅不是一蹴而就的，还应该是持续纠偏矫正的。

具体的操作上，比如可以间隔性（如两三年）就重启一次组织级的敏捷培训、组织内部不同敏捷项目小组之间的定期、不定期互通交流、组织上对于过程改进除了鼓励之外要给出实际的工作时间（8小时以内的时间）用于改进（认可改进的价值），甚至将改进放入绩效体系。

三、中小金融机构DevOps落地路径思路

 

DevOps/敏捷转型整体视图

可选的一些切入点

项目协同

需求管理、工作排程，是研发管理中最核心的场景之一，同时涉及到线上工具和线下实践，是常见的切入点之一。

CI流水线

CI 流水线可以帮助开发团队完成自动化的代码集成，并可以导入自动日常构建、代码质量扫描、自动化测试、代码分支管理策略固话等线上线下的工具与实践，也是很好的切入点。

测试管理

相对于项目协同和 CI 流水线，选择以测试切入的可能会更少一些。这更多是测试部门、质量管理部门会关注的切入领域。但对于传统金融机构来说，测试可能更多是阶段性的工作，很难贯通整个价值交付的过程，由测试部门发起的 DevOps 项目，需求上往往会更容易往自动化测试、类测试管理平台的方向上走。

注意事项

立项：务必获取高层领导的支持与推动；

目标：分阶段建设，明确年度目标，不宜贪大求全；

组织：结合建设目标和现状，明确牵头部门，关注跨部门协同的难点；

落地：规则约束，可先研讨、线下验证，再线上约束、逐步调整，且不宜初期就设置过于细致的规约；

文化：切勿重系统、轻文化，一定要关注人文关怀，重视组织文化建设，保障一个相对温和的实践环境。

完整的 DevOps 体系建设，不仅仅是新工具、新规则，更是新文化，而且在文化变革打头阵的情况下，很可能取得更好、更持久的成果，让组织具备自我纠偏的能力。