1.背景
1.1 国内金融企业开发模式现状
对于国内主要的金融企业，虽然有部分企业已经或者正在推行敏捷的开发方法，但是目前普遍采用的仍然是瀑布的开发方法（从立项、开发、测试到发布几个阶段顺次执行），并且主要是以项目为单位进行人力资源的组织和开发过程管理。
一个项目主要是实现一个或者若干个需求，由项目经理主导，组织若干开发人员进行开发（对于大的项目，则可能还会跨越多个大的开发部门，包含多个小的开发小组）。需求主要是由业务单位提出的。在具体执行时，不同的业务单位都会提出不同的业务需求（不同的业务需求会成立不同的项目），而且从每个业务单位的角度来说，都会要求其所提出的需求具有绝对的优先级，因此，在开发阶段，就不可避免地需要并行进行多个项目的开发。项目虽然是多个，但是其背后所修改到的代码及产品则可能是同一个，故而整个产品的交付过程自然而然就被分裂成了两个阶段：开发测试阶段和投产阶段。在开发测试阶段，最主要的是以项目为单位进行开发测试以及部署（每个项目的代码独立部署），而在投产阶段，虽然也是以项目为单位进行相关的流程管理，但是在具体发布时，则是以产品为单位进行部署安装（不同项目中涉及到同一个产品的代码合并到一起发布）。由于项目与产品两个管理维度的切换，在实际的开发发布模式上，就主要演变出了如下三种模式：
按版本排期的开发模式
这是模式是按照一定的固定时间周期，统一将在此期间开发的所有项目代码合并到一个版本中进行测试并集中发布到生产环境，按照时间周期的不同，有的称为月度版本（即一个月度一个版本），有的称为季度版本（即一个季度一个版本）。在这种模式之下，虽然开发过程是以项目为单位进行，但在真正的投产阶段却是以集中方式进行的，对于需要快速反馈响应的需求，也必须等到整个版本发布的时候才能统一发布。
按项目排期的开发模式
在这种模式中，每个项目都会安排好自己的测试和发布到生产环境的日期，然后按照自己的开发计划进行开发并发布。但是为了避免多个同时发布的项目重复执行多次发布，并且为了合并对于同一个产品在不同项目上所被修改的代码，对于在同一时间发布的项目，在发布前，会将多个项目的代码或者二进制码进行合并，然后一起发布。这种开发方式下，可以解决固定版本排期中，紧急需求无法快速发布的问题，但是同时所带来的则是频繁的生产环境发布，以及多个项目间的代码冲突合并。
敏捷开发模式
对于部分比较独立的产品开发，由于不存在与其他产品之间的强关联，可以独立开发、测试、发布，因此对于这些产品，就可以采用敏捷的方式进行开发，即对单个产品按照一定的节奏进行开发、测试、发布等。这是最为理想的开发模式，但是对于金融企业来说，能够满足这种特征的产品只是微乎其微，大量的产品相互之间都还是存在非常紧密的关联的。
当然，现在也有部分大型金融企业在积极探索整个组织都采用敏捷的方式进行开发，并取得了积极的成果，但是毕竟还没有成熟到足以供其他企业模仿照搬的程度。
1.2 金融数字化转型中研发管理体系困难和挑战
金融数字化转型主要在于IT服务保障能力的挑战，主要聚焦在三个方面。
系统处理性能方面
随着数字化转型的普及，特别是这次疫情以来，金融服务的广度和深度在不断增加，市场规模在不断扩大，业务量显著增长，对企业的技术系统处理能力提出了更高的要求。
系统构建和交付方面
为了快速响应市场变化，满足日益频繁的业务创新及需求变更，传统的系统架构、开发手段也需要进行迭代升级，系统的构建效率和质量面临挑战。
系统架构治理
随着数字化的深入，企业的业务流程和技术架构日趋复杂，彼此之间的牵连关系也更加复杂，隐藏也更深，同时企业的系统运维比以往面临更多挑战。
1.3 案例分享
背景
某证券行业梳理的DevOps需求
从上面的需求以及对客户组织架构的了解得出，金融客户对于流程自动化的诉求，同时需求与外部第三方工具集成，平台的扩展性能力要要强，所以，在整个方案设计上，需要满足以下几点：
1. 不脱离客户现有管控流程（金融行业是一个强监控行业，对于安全合规的非常敏感，所以生产环境是完全隔离的，导致应用无法devops直接发布生产）
2.集成客户外部工具（客户外采很多第三方的工具，比如常见的测试工具）
3.充分考虑客户现有组织架构特点（IT组织架构人员调整，产品的替换成本等因素）
方案
总结
在金融行业DevOps解决方案设计上，需要充分考虑客户现有架构特点、已有工具以及现有流程，同时需要考虑自身产品的融合度。总之，金融行业的每个客户的情况都可能存在不同差异，但核心逻辑就是上面提到的三个因素。
