对于部分比较独立的产品开发，由于不存在与其他产品之间的强关联，可以独立开发、测试、发布，因此对于这些产品，就可以采用敏捷的方式进行开发，即对单个产品按照一定的节奏进行开发、测试、发布等。这是最为理想的开发模式，但是对于金融企业来说，能够满足这种特征的产品只是微乎其微，大量的产品相互之间都还是存在非常紧密的关联的。
当然，现在也有部分大型金融企业在积极探索整个组织都采用敏捷的方式进行开发，并取得了积极的成果，但是毕竟还没有成熟到足以供其他企业模仿照搬的程度。
面临的主要挑战
长期以来，固定版本排期及项目排期的开发模式，为大型金融企业业务的快速发展提供了强有力的 IT 保障，同时也确保了产品的质量和运行风险。但是，近年来，随着大量互联网企业，特别是移动互联网企业的冲击，大型金融企业也不得不面临在业务模式加快创新的同时，需要 IT 团队加快开发节奏，快速推出满足业务发展需求的产品。而这种需求正对金融企业现有的 IT 开发模式提出紧迫的挑战，根据我们的研究，这些挑战主要体现在如下的三个矛盾中(图 2)。
图 2. 主要的开发发布模式及面临的主要挑战
为保证产品质量而设定的过长的开发测试流程与快速迭代交付的迫切业务需求之间的矛盾
在传统的产品开发过程中，哪怕一个再小的需求的开发上线都必须经过立项、测试以及生产发布几个阶段(如图 2 所示)，特别是测试阶段，更是需要至少一个测试轮次的时间。在固定版本排期的开发模式中，则再急迫的需求也必须等待大版本的集中上线才能够发布到生产环境中。而从业务的角度，为了适应快速的市场变化，对于部分与用户交互比较频繁的需求，特别是生产环境中发现的亟待修复的缺陷，则需要其能够快速发布，而不是等待冗长的开发测试流程。所以，这种一般化的冗长的开发测试发布流程已经无法适应互联网时代产品快速迭代交付的现实需求。
大量手工操作与金融企业对于产品质量一致性、稳定性严苛要求之间的矛盾
随着业务的发展，目前对大型的金融企业来说，对于与用户交互频繁的产品，单个产品只部署在一个或者少量几个服务器节点上是远远无法满足大量的并发访问需求的，因此，一个产品往往都会部署在多个服务器节点，甚至是几十个服务器节点上。尽管部署节点多，对于企业本身来说，最基本的要求就是不同节点在所部署产品的版本、配置等等上必须是保持一致的。 而由于 IT 发展时间的限制，目前整个开发发布过程中，还存在大量的手工操作环节，特别是产品的构建以及到生产环境的部署，对于手工操作来说，每次发布包的构建以及每个节点的发布都是一次全新的操作，很容易出现失误或者不一致的地方。故而，大量的手工操作已经无法适应面对大量节点部署时的一致性以及稳定性要求。
开发团队对于流程简单性、快速性的现实要求与风险管控之间的矛盾。
从开发团队的角度，其根本目的就是满足业务方的需求，能够快速的将开发完成的功能发布到生产环境中，特别是在业务部门对发布频率加快的需求与日俱增的压力下，他们对于开发测试发布流程中所存在的各个管控点就往往颇具怨言，认为有些把控环节不仅延缓了发布时间，而且还浪费了他们的时间，他们希望流程越简单越好。而从项目管理及运维的角度，在每年发布的几千甚至上万个版本中，只要其中有一个版本存在问题或者发布失误，就是难以容忍的，因此，为了防止可能存在的风险，在现有大量依靠手工操作的现实下，他们必须千方百计挖掘可能存在的风险点，并设置各种严格的评审点进行把关，以防止可能的风险流入到生产环境中。因此，现有由于风险管控所叠加上来的流程管控已经无法满足开发团队对于流程简单性及快速性的需求。
应对挑战，推进 DevOps 实施
显然，目前大型金融企业所面临的挑战既有技术层面上的，也有开发模式以及流程管理上的，试图采用单一的方法进行应对是不可能的，当然也无法一蹴而就进行解决。本文认为，为应对这些挑战，从整个 DevOps 实施的角度，需要通过图 3 所示的三个阶段逐步进行实施。