2009 年 6 月份，John Allspaw 及 Paul Hammond 在速度大会 (Velocity) 上分享了在 Flickr 中如何通过加强 Dev（开发团队）和 Ops（运维团队）之间的协作，从而加快应用部署频率的演讲 。随后，关于 Dev 和 Ops 之间协作的讨论一直在 Twitter 上持续进行，当年的 10 月份，在 Twitter 上首次出现了 DevOps( 开发运维一体化 ) 一词 。在随后的几年里，DevOps 不仅引起了工程界的大量关注和实践，同时，也吸引了大量学术界人士的兴趣。Gartner 2015 年所做的调查结果表明，目前已有 29% 的企业在使用 DevOps。图一所示为 Gartner 对各 IT 技术发展热度预测的研究，根据其研究，目前 DevOps 正处于其发展阶段的高潮期。

图 1. Gartner 关于各 IT 技术发展热度的预测

DevOps，其主要目的就是通过消除开发部门与运维部门之间的壁垒，从而使得一个企业的 IT 组织能够在敏捷地适应市场变化的同时，将一个企业的业务能力通过创新性的解决方案快速地从 IT 部门的开发过程推向用户。它主要利用了精益的思想，通过消除 IT 部门整个产品交付流中所存在的浪费及障碍，从而达到快速交付的目的。

对于一个较大的组织或者企业来说，其 IT 部门有其多年形成的固有组织结构、文化氛围、开发及发布流程、基础架构及产品体系等，在这种情况下，试图像新创的公司一样，很快就将整个企业的 IT 组织转型到 DevOps 上，显然是不现实的，也是不可行的。在这个过程中，必定会面临一定的困难与挑战。

1

大型金融企业在软件交付上通常面临的挑战

国内金融企业主要的开发发布模式

对于国内主要的金融企业，虽然有部分企业已经或者正在推行敏捷的开发方法，但是目前普遍采用的仍然是瀑布的开发方法（从立项、开发、测试到发布几个阶段顺次执行），并且主要是以项目为单位进行人力资源的组织和开发过程管理。

一个项目主要是实现一个或者若干个需求，由项目经理主导，组织若干开发人员进行开发（对于大的项目，则可能还会跨越多个大的开发部门，包含多个小的开发小组）。需求主要是由业务单位提出的。在具体执行时，不同的业务单位都会提出不同的业务需求（不同的业务需求会成立不同的项目），而且从每个业务单位的角度来说，都会要求其所提出的需求具有绝对的优先级，因此，在开发阶段，就不可避免地需要并行进行多个项目的开发。项目虽然是多个，但是其背后所修改到的代码及产品则可能是同一个，故而整个产品的交付过程自然而然就被分裂成了两个阶段：开发测试阶段和投产阶段。在开发测试阶段，最主要的是以项目为单位进行开发测试以及部署（每个项目的代码独立部署），而在投产阶段，虽然也是以项目为单位进行相关的流程管理，但是在具体发布时，则是以产品为单位进行部署安装（不同项目中涉及到同一个产品的代码合并到一起发布）。由于项目与产品两个管理维度的切换，在实际的开发发布模式上，就主要演变出了如下三种模式：

1. 按固定版本排期的开发模式  

这是模式是按照一定的固定时间周期，统一将在此期间开发的所有项目代码合并到一个版本中进行测试并集中发布到生产环境，按照时间周期的不同，有的称为月度版本（即一个月度一个版本），有的称为季度版本（即一个季度一个版本）。在这种模式之下，虽然开发过程是以项目为单位进行，但在真正的投产阶段却是以集中方式进行的，对于需要快速反馈响应的需求，也必须等到整个版本发布的时候才能统一发布。

2. 按项目排期的开发模式  

在这种模式中，每个项目都会安排好自己的测试和发布到生产环境的日期，然后按照自己的开发计划进行开发并发布。但是为了避免多个同时发布的项目重复执行多次发布，并且为了合并对于同一个产品在不同项目上所被修改的代码，对于在同一时间发布的项目，在发布前，会将多个项目的代码或者二进制码进行合并，然后一起发布。这种开发方式下，可以解决固定版本排期中，紧急需求无法快速发布的问题，但是同时所带来的则是频繁的生产环境发布，以及多个项目间的代码冲突合并。

3. 敏捷开发模式  

对于部分比较独立的产品开发，由于不存在与其他产品之间的强关联，可以独立开发、测试、发布，因此对于这些产品，就可以采用敏捷的方式进行开发，即对单个产品按照一定的节奏进行开发、测试、发布等。这是最为理想的开发模式，但是对于金融企业来说，能够满足这种特征的产品只是微乎其微，大量的产品相互之间都还是存在非常紧密的关联的。

当然，现在也有部分大型金融企业在积极探索整个组织都采用敏捷的方式进行开发，并取得了积极的成果，但是毕竟还没有成熟到足以供其他企业模仿照搬的程度。

面临的主要挑战

长期以来，固定版本排期及项目排期的开发模式，为大型金融企业业务的快速发展提供了强有力的 IT 保障，同时也确保了产品的质量和运行风险。但是，近年来，随着大量互联网企业，特别是移动互联网企业的冲击，大型金融企业也不得不面临在业务模式加快创新的同时，需要 IT 团队加快开发节奏，快速推出满足业务发展需求的产品。而这种需求正对金融企业现有的 IT 开发模式提出紧迫的挑战，根据我们的研究，这些挑战主要体现在如下的三个矛盾中（图 2）。

图 2. 主要的开发发布模式及面临的主要挑战

1. 为保证产品质量而设定的过长的开发测试流程与快速迭代交付的迫切业务需求之间的矛盾  

在传统的产品开发过程中，哪怕一个再小的需求的开发上线都必须经过立项、测试以及生产发布几个阶段（如图 2 所示），特别是测试阶段，更是需要至少一个测试轮次的时间。在固定版本排期的开发模式中，则再急迫的需求也必须等待大版本的集中上线才能够发布到生产环境中。而从业务的角度，为了适应快速的市场变化，对于部分与用户交互比较频繁的需求，特别是生产环境中发现的亟待修复的缺陷，则需要其能够快速发布，而不是等待冗长的开发测试流程。所以，这种一般化的冗长的开发测试发布流程已经无法适应互联网时代产品快速迭代交付的现实需求。

2. 大量手工操作与金融企业对于产品质量一致性、稳定性严苛要求之间的矛盾

随着业务的发展，目前对大型的金融企业来说，对于与用户交互频繁的产品，单个产品只部署在一个或者少量几个服务器节点上是远远无法满足大量的并发访问需求的，因此，一个产品往往都会部署在多个服务器节点，甚至是几十个服务器节点上。尽管部署节点多，对于企业本身来说，最基本的要求就是不同节点在所部署产品的版本、配置等等上必须是保持一致的。 而由于 IT 发展时间的限制，目前整个开发发布过程中，还存在大量的手工操作环节，特别是产品的构建以及到生产环境的部署，对于手工操作来说，每次发布包的构建以及每个节点的发布都是一次全新的操作，很容易出现失误或者不一致的地方。故而，大量的手工操作已经无法适应面对大量节点部署时的一致性以及稳定性要求。

3. 开发团队对于流程简单性、快速性的现实要求与风险管控之间的矛盾

从开发团队的角度，其根本目的就是满足业务方的需求，能够快速的将开发完成的功能发布到生产环境中，特别是在业务部门对发布频率加快的需求与日俱增的压力下，他们对于开发测试发布流程中所存在的各个管控点就往往颇具怨言，认为有些把控环节不仅延缓了发布时间，而且还浪费了他们的时间，他们希望流程越简单越好。而从项目管理及运维的角度，在每年发布的几千甚至上万个版本中，只要其中有一个版本存在问题或者发布失误，就是难以容忍的，因此，为了防止可能存在的风险，在现有大量依靠手工操作的现实下，他们必须千方百计挖掘可能存在的风险点，并设置各种严格的评审点进行把关，以防止可能的风险流入到生产环境中。因此，现有由于风险管控所叠加上来的流程管控已经无法满足开发团队对于流程简单性及快速性的需求。

应对挑战，推进 DevOps 实施

显然，目前大型金融企业所面临的挑战既有技术层面上的，也有开发模式以及流程管理上的，试图采用单一的方法进行应对是不可能的，当然也无法一蹴而就进行解决。本文认为，为应对这些挑战，从整个 DevOps 实施的角度，需要通过图 3 所示的三个阶段逐步进行实施。

作为实施的第一步，显然，消除大量的手工操作，构建一个持续交付的流水线平台是最基础也是最迫切的，只有通过流水线平台的自动化和持续流动，才能保证在不同阶段、不同节点上产品发布的一致性和稳定性，同时，也才能消除由于人工操作所引入的人为风险，同时提高效率。

图 3. 推进 DevOps 实施的三个主要阶段

作为实施的第二步，则需要对现有的开发模式及产品架构做进一步的优化，否则，整个流水线是很难顺畅地流动起来的。例如，如果不调整固定版本排期的开发模式，则即使自动化程度再高，紧急需求的上线仍然需要等待整个版本的上线；而对于项目排期的开发模式，在上线前，多个项目代码或者构建包的手工合并也是必不可少的；在传统紧耦合的产品架构下，想要做到自动化的增量迭代发布，也是非常困难的，而每次都将整个产品的所有代码进行发布也是极不现实的，这些其实都是实现整个 DevOps 持续交付过程全自动化的障碍。因此，在构建好持续交付的流水线平台后，其第二步就是开发模式及产品架构的优化。当然，如果没有第一步的自动化的持续交付平台作为基础，则由开发模式调整所带来的发布次数增多也是无法完全用手工完成的。

在通过工具自动化的方式实现产品的持续交付后，由于人工操作的减少，自动化及流水线操作的提高，包括操作过程可追踪性的实现，快速自动回滚操作的实施等，这个时候，在完整的开发测试交付流程中，有些管控步骤可能就是多余的，是可以优化的。因此，实施的第三步就是对整体开发测试发布流程进行优化，去掉冗余的人工评审步骤，从而实现企业级的 DevOps 持续交付流水线。

工具平台建设整体方案

在 DevOps 实施的三个阶段中，第一个阶段，DevOps 交付流水线平台的搭建是最基础也是非常关键的步骤，对于金融企业来说 ，由于其对产品质量、运营风险的严格要求，以及自身产品的复杂性、特殊性，该平台的构建需要考虑如下问题：

1. 该平台一定要与企业目前所具备的基础设施相结合，而不能像一些初创企业，马上就对整个基础环境及设施进行更新。例如，目前大家都已经非常清楚云平台的优势以及对于 DevOps 推进的重要性，但是，对于一个大型金融企业来说，并不是说马上就可以将所有的应用都移到云平台上的。

2. 该平台一定要考虑到企业 IT 组织目前的组织结构现状、人才技能现状以及存量产品特点。风险控制和稳定是金融企业 IT 系统需要考虑的首要问题，这些限制导致了他们无法像一些小型的初创企业一样，一夜之间即进行重大的 IT 组织调整，甚至产品更换。他们只能是逐步的稳健的创新，在创新的同时，还需要保持已有组织、人才以及产品的相对稳定。

3. 该平台一定要与企业目前已有的流程控制系统相结合，而不能独立于现有的流程控制系统。现有的开发测试发布流程，是协调整个组织行为的重要工具，也是控制产品发布风险的有力工具，如果自动化交付平台脱离了这些流程的监管，就有可能变成规避现有流程监控的新工具，从而带来更大的风险。

基于以上考虑，本文设计了如图 4 所示的 DevOps 流水线交付平台架构。在该架构中，我们将整体的流水线交付平台分成了四层：基础架构层、流水线工具平台层、流水线引擎层以及流程管控层。

基础架构层是一个企业最基本的基础设施，既包含了存量的硬件平台，也包含了云计算平台，首先，只有在基础实施上实现弹性可伸缩、消除开发测试环境的差异，才能实现真正的 DevOps。而流水线工具平台则是为企业的代码开发、测试及发布提供了一个端到端的工具平台，通过该工具平台的自动化和相互间的无缝对接，实现了从软件代码配置管理、自动化构建、测试到快速的自动化发布。流水线工具分布在整个开发测试发布过程的各个阶段，需要不同的角色在不同的阶段进行配合操作，而且这个操作过程需要置于企业现有流程管控系统的管控之下，因此，我们还需要流水线引擎层，用于根据整体开发测试发布不同阶段的需要，驱动底层的工具平台进行产品的代码管理、构建及部署，同时对上又与企业的流程管控系统对接，使得整个操作过程置于流程监控之下。

图 4. DevOps 流水线交付平台整体架构图

显然，在 DevOps 流水线工具平台实施的四层架构中，其核心是流水线工具平台层的搭建，对上，该工具平台需要通过流水线引擎与现有的流程管理系统对接，对下，则需要兼容现有的各种程序语言、开发发布模式、构建方式，以及存量硬件和云平台的基础设施。在本系列文章的后续各篇中，我们将重点围绕流水线工具平台的搭建进行阐述。

2

实施思路讨论

流水线交付平台各层实施顺序

对于第四节所述工具平台的实施，不同的企业具体的实际情况可能会略有差别，因此，不可能对所有的企业都采用同样的思路进行实施；同时，对于大型企业来说，由于产品形态的多样化，开发语言的广泛性，各开发团队情况的差异性，该工具平台的完整实施也是不可能一蹴而就的。在具体实施时，需要根据具体情况选择制定相应的策略进行实施。总结而言，有两个维度的问题需要考虑，一个是这四层的实施顺序，另一个则是对于流水线工具平台层中，各个具体工具的实施思路。

从上到下的四层中，根据逻辑上的耦合性，我们将其分成了三组，流程管控层自成一组，称为第一组，流水线执行引擎及流水线工具平台层作为一组，称为第二组，基础架构自成一组，称为第三组。

对于目前大多数的金融企业来说，现在基本都已经存在相应的开发测试发布管控流程，不同的只是成熟度不同而已。因此，流水线管控这一层更多的应该是考虑如何对已有流程进行优化。开发测试发布流程中各个阶段的划分和衔接肯定会影响到流水线执行引擎的实施，因此，这一层的实施可与第二组同时进行，或者在第二组实施之前，但不能在第二组之后。

基础架构层中如果存在云平台，则对流水线工具平台层的影响是流水线工具平台需要扩展到对云平台的兼容，因此，第三组与第二组之间既可同时实施，也可先后实施，只不过，如果是第二组先实施之后再实施第三组的云平台，则第三组实施后，需要对第二组进行扩展。

第二组的两层中，流水线引擎是基于流水线工具平台进行的，因此，流水线执行引擎一定得在流水线工具平台之后实施。因此，完整的实施顺序如图 5 所示。

图 5. DevOps 流水线各层实施顺序

流水线工具平台层实施思路

在流水线工具平台层中，对于开发测试发布过程的不同阶段，相应的存在配置管理、代码构建、静态分析、自动化测试、构建包管理、自动化部署、监控等众多工具，其实施过程相对较长，也比较复杂。在具体实施时，存在两种可能的思路，一种为逐点突破，然后再全部连接成一个完整的工具平台。这种思路下，会对企业整体的交付流水线进行分析，找出其中最大的痛点（如配置管理、构建管理或者自动化部署等），然后重点实施，并推广至全公司，接着再继续实施下一个痛点，通过一个一个痛点的实施，最后再连接成一个完整的 DevOps 交付流水线工具平台。

第二种则是从项目突破，先找一个比较典型的项目或者产品作为试点，在该项目或者产品上构建完整的工具平台，并进行深入实施，在实施成功后，再推广至其他的项目或者产品。这种方法的特点是，先考虑比较小的范围和需求，在获取到好的收益后，再考虑更广的范围和需求，对原有工具平台做优化。

当然，具体企业有具体企业的固有特点，包括文化、组织结构、现有技术水平等等，真正的实施思路还需要具体根据具体的情况进行更具个性化的制定。

实施难点及经验总结

过去的几年中，本文作者所在团队一直在某些金融企业实施本文所述的 DevOps 流水线工具平台，根据实施过程的经验，我们认为，在实施过程中，主要存在如下几大难点：

1. 短期收益与长期收益的平衡

对于开发人员和运维人员来说，每天的工作任务都非常重，其最关心的是眼前的问题能不能解决，当前的效率能不能马上提高。而任何一个新工具，新方法的实施都不可避免地需要投入一定的时间进行学习、适应，会对当前的工作造成影响，甚至短期内反而会降低效率。故而在实施初期会引起部分团队成员的抵触和反对，这个时候，如何将开发人员及发布人员当前迫切关心的短期收益与整个平台实施后的长期收益结合起来就成为实施推进的难点之一。

针对这种情况，在具体实施时，我们既需要一定的耐心，也需要有抓有放，对于部分时间暂时允许，也愿意积极配合的团队先行推进，而对于目前比较抵触的团队，则先放一放，等到先行实施的团队显示出收益，中间观望团队积极推进时，慢慢就会形成一定的气候，从而能够比较好的进行推进。

2. 习惯的改变

任何一个人，都会有其熟悉的行为习惯和方式，当需要其作出改变，适应新的方式时，谁都会作出抵触，都会不愿意。而任何工具和方法的实施，都不可能避免地会对团队成员原先的习惯、方式产生影响，需要他们作出改变。尽管从原则上，也许团队成员是认同新工具、新方法的理念的，也是愿意改变的，但是在具体作出改变的，则仍然是会产生各种各样的担心、顾虑，从而影响实施的进度。

这种情况下，我们更多采用的是先适应，后改造的方式，即在一些不影响平台实施关键的点上，先去适应开发发布团队当前的工作习惯，从平台方面主动做出一些调整，等开发发布团队尝到收益之后，再反过来影响他们，让他们做出改变和调整，这个时候，往往就相对容易一些了。

3. 解决方案如何同时兼容多样化的部署环境、构建方式及发布方式等

任何一个新平台的实施，其最理想的方式就是在试点之后，即可马上进行大面积的推广和实施，但实际上，对一个大型的 IT 组织来说，不可能所有的团队都采用相同的方式进行开发，也都采用相同的程序语言，相同的构建方式等，同时，开发测试及运行环境也肯定会存在一定的差异，这些都影响了平台实施的推进进度。在后续的系列文章中，我们将从技术的角度，具体阐述我们如何去应对这样的挑战。

3

总结

本文作为系列文章的第一篇，主要讲述了作者在过去几年的 DevOps 实施历程中，所经历过的大型金融企业所面临的共同挑战，以及在应对这些挑战时所采取的思路和 DevOps 实施方案。后续的系列文章将就具体的方案进行详细叙述。

原创：刘鹤辉、韩庆

2009 年 6 月份，John Allspaw 及 Paul Hammond 在速度大会 (Velocity) 上分享了在 Flickr 中如何通过加强 Dev（开发团队）和 Ops（运维团队）之间的协作，从而加快应用部署频率的演讲 。随后，关于 Dev 和 Ops 之间协作的讨论一直在 Twitter 上持续进行，当年的 10 月份，在 Twitter 上首次出现了 DevOps( 开发运维一体化 ) 一词 。在随后的几年里，DevOps 不仅引起了工程界的大量关注和实践，同时，也吸引了大量学术界人士的兴趣。Gartner 2015 年所做的调查结果表明，目前已有 29% 的企业在使用 DevOps。图一所示为 Gartner 对各 IT 技术发展热度预测的研究，根据其研究，目前 DevOps 正处于其发展阶段的高潮期。

图 1. Gartner 关于各 IT 技术发展热度的预测

DevOps，其主要目的就是通过消除开发部门与运维部门之间的壁垒，从而使得一个企业的 IT 组织能够在敏捷地适应市场变化的同时，将一个企业的业务能力通过创新性的解决方案快速地从 IT 部门的开发过程推向用户。它主要利用了精益的思想，通过消除 IT 部门整个产品交付流中所存在的浪费及障碍，从而达到快速交付的目的。

对于一个较大的组织或者企业来说，其 IT 部门有其多年形成的固有组织结构、文化氛围、开发及发布流程、基础架构及产品体系等，在这种情况下，试图像新创的公司一样，很快就将整个企业的 IT 组织转型到 DevOps 上，显然是不现实的，也是不可行的。在这个过程中，必定会面临一定的困难与挑战。

1

大型金融企业在软件交付上通常面临的挑战

国内金融企业主要的开发发布模式

对于国内主要的金融企业，虽然有部分企业已经或者正在推行敏捷的开发方法，但是目前普遍采用的仍然是瀑布的开发方法（从立项、开发、测试到发布几个阶段顺次执行），并且主要是以项目为单位进行人力资源的组织和开发过程管理。

一个项目主要是实现一个或者若干个需求，由项目经理主导，组织若干开发人员进行开发（对于大的项目，则可能还会跨越多个大的开发部门，包含多个小的开发小组）。需求主要是由业务单位提出的。在具体执行时，不同的业务单位都会提出不同的业务需求（不同的业务需求会成立不同的项目），而且从每个业务单位的角度来说，都会要求其所提出的需求具有绝对的优先级，因此，在开发阶段，就不可避免地需要并行进行多个项目的开发。项目虽然是多个，但是其背后所修改到的代码及产品则可能是同一个，故而整个产品的交付过程自然而然就被分裂成了两个阶段：开发测试阶段和投产阶段。在开发测试阶段，最主要的是以项目为单位进行开发测试以及部署（每个项目的代码独立部署），而在投产阶段，虽然也是以项目为单位进行相关的流程管理，但是在具体发布时，则是以产品为单位进行部署安装（不同项目中涉及到同一个产品的代码合并到一起发布）。由于项目与产品两个管理维度的切换，在实际的开发发布模式上，就主要演变出了如下三种模式：

1. 按固定版本排期的开发模式  

这是模式是按照一定的固定时间周期，统一将在此期间开发的所有项目代码合并到一个版本中进行测试并集中发布到生产环境，按照时间周期的不同，有的称为月度版本（即一个月度一个版本），有的称为季度版本（即一个季度一个版本）。在这种模式之下，虽然开发过程是以项目为单位进行，但在真正的投产阶段却是以集中方式进行的，对于需要快速反馈响应的需求，也必须等到整个版本发布的时候才能统一发布。

2. 按项目排期的开发模式  

在这种模式中，每个项目都会安排好自己的测试和发布到生产环境的日期，然后按照自己的开发计划进行开发并发布。但是为了避免多个同时发布的项目重复执行多次发布，并且为了合并对于同一个产品在不同项目上所被修改的代码，对于在同一时间发布的项目，在发布前，会将多个项目的代码或者二进制码进行合并，然后一起发布。这种开发方式下，可以解决固定版本排期中，紧急需求无法快速发布的问题，但是同时所带来的则是频繁的生产环境发布，以及多个项目间的代码冲突合并。

3. 敏捷开发模式  

对于部分比较独立的产品开发，由于不存在与其他产品之间的强关联，可以独立开发、测试、发布，因此对于这些产品，就可以采用敏捷的方式进行开发，即对单个产品按照一定的节奏进行开发、测试、发布等。这是最为理想的开发模式，但是对于金融企业来说，能够满足这种特征的产品只是微乎其微，大量的产品相互之间都还是存在非常紧密的关联的。

当然，现在也有部分大型金融企业在积极探索整个组织都采用敏捷的方式进行开发，并取得了积极的成果，但是毕竟还没有成熟到足以供其他企业模仿照搬的程度。

面临的主要挑战

长期以来，固定版本排期及项目排期的开发模式，为大型金融企业业务的快速发展提供了强有力的 IT 保障，同时也确保了产品的质量和运行风险。但是，近年来，随着大量互联网企业，特别是移动互联网企业的冲击，大型金融企业也不得不面临在业务模式加快创新的同时，需要 IT 团队加快开发节奏，快速推出满足业务发展需求的产品。而这种需求正对金融企业现有的 IT 开发模式提出紧迫的挑战，根据我们的研究，这些挑战主要体现在如下的三个矛盾中（图 2）。

图 2. 主要的开发发布模式及面临的主要挑战

1. 为保证产品质量而设定的过长的开发测试流程与快速迭代交付的迫切业务需求之间的矛盾  

在传统的产品开发过程中，哪怕一个再小的需求的开发上线都必须经过立项、测试以及生产发布几个阶段（如图 2 所示），特别是测试阶段，更是需要至少一个测试轮次的时间。在固定版本排期的开发模式中，则再急迫的需求也必须等待大版本的集中上线才能够发布到生产环境中。而从业务的角度，为了适应快速的市场变化，对于部分与用户交互比较频繁的需求，特别是生产环境中发现的亟待修复的缺陷，则需要其能够快速发布，而不是等待冗长的开发测试流程。所以，这种一般化的冗长的开发测试发布流程已经无法适应互联网时代产品快速迭代交付的现实需求。

2. 大量手工操作与金融企业对于产品质量一致性、稳定性严苛要求之间的矛盾

随着业务的发展，目前对大型的金融企业来说，对于与用户交互频繁的产品，单个产品只部署在一个或者少量几个服务器节点上是远远无法满足大量的并发访问需求的，因此，一个产品往往都会部署在多个服务器节点，甚至是几十个服务器节点上。尽管部署节点多，对于企业本身来说，最基本的要求就是不同节点在所部署产品的版本、配置等等上必须是保持一致的。 而由于 IT 发展时间的限制，目前整个开发发布过程中，还存在大量的手工操作环节，特别是产品的构建以及到生产环境的部署，对于手工操作来说，每次发布包的构建以及每个节点的发布都是一次全新的操作，很容易出现失误或者不一致的地方。故而，大量的手工操作已经无法适应面对大量节点部署时的一致性以及稳定性要求。

3. 开发团队对于流程简单性、快速性的现实要求与风险管控之间的矛盾

从开发团队的角度，其根本目的就是满足业务方的需求，能够快速的将开发完成的功能发布到生产环境中，特别是在业务部门对发布频率加快的需求与日俱增的压力下，他们对于开发测试发布流程中所存在的各个管控点就往往颇具怨言，认为有些把控环节不仅延缓了发布时间，而且还浪费了他们的时间，他们希望流程越简单越好。而从项目管理及运维的角度，在每年发布的几千甚至上万个版本中，只要其中有一个版本存在问题或者发布失误，就是难以容忍的，因此，为了防止可能存在的风险，在现有大量依靠手工操作的现实下，他们必须千方百计挖掘可能存在的风险点，并设置各种严格的评审点进行把关，以防止可能的风险流入到生产环境中。因此，现有由于风险管控所叠加上来的流程管控已经无法满足开发团队对于流程简单性及快速性的需求。

应对挑战，推进 DevOps 实施

显然，目前大型金融企业所面临的挑战既有技术层面上的，也有开发模式以及流程管理上的，试图采用单一的方法进行应对是不可能的，当然也无法一蹴而就进行解决。本文认为，为应对这些挑战，从整个 DevOps 实施的角度，需要通过图 3 所示的三个阶段逐步进行实施。

作为实施的第一步，显然，消除大量的手工操作，构建一个持续交付的流水线平台是最基础也是最迫切的，只有通过流水线平台的自动化和持续流动，才能保证在不同阶段、不同节点上产品发布的一致性和稳定性，同时，也才能消除由于人工操作所引入的人为风险，同时提高效率。

图 3. 推进 DevOps 实施的三个主要阶段

作为实施的第二步，则需要对现有的开发模式及产品架构做进一步的优化，否则，整个流水线是很难顺畅地流动起来的。例如，如果不调整固定版本排期的开发模式，则即使自动化程度再高，紧急需求的上线仍然需要等待整个版本的上线；而对于项目排期的开发模式，在上线前，多个项目代码或者构建包的手工合并也是必不可少的；在传统紧耦合的产品架构下，想要做到自动化的增量迭代发布，也是非常困难的，而每次都将整个产品的所有代码进行发布也是极不现实的，这些其实都是实现整个 DevOps 持续交付过程全自动化的障碍。因此，在构建好持续交付的流水线平台后，其第二步就是开发模式及产品架构的优化。当然，如果没有第一步的自动化的持续交付平台作为基础，则由开发模式调整所带来的发布次数增多也是无法完全用手工完成的。

在通过工具自动化的方式实现产品的持续交付后，由于人工操作的减少，自动化及流水线操作的提高，包括操作过程可追踪性的实现，快速自动回滚操作的实施等，这个时候，在完整的开发测试交付流程中，有些管控步骤可能就是多余的，是可以优化的。因此，实施的第三步就是对整体开发测试发布流程进行优化，去掉冗余的人工评审步骤，从而实现企业级的 DevOps 持续交付流水线。

工具平台建设整体方案

在 DevOps 实施的三个阶段中，第一个阶段，DevOps 交付流水线平台的搭建是最基础也是非常关键的步骤，对于金融企业来说 ，由于其对产品质量、运营风险的严格要求，以及自身产品的复杂性、特殊性，该平台的构建需要考虑如下问题：

1. 该平台一定要与企业目前所具备的基础设施相结合，而不能像一些初创企业，马上就对整个基础环境及设施进行更新。例如，目前大家都已经非常清楚云平台的优势以及对于 DevOps 推进的重要性，但是，对于一个大型金融企业来说，并不是说马上就可以将所有的应用都移到云平台上的。

2. 该平台一定要考虑到企业 IT 组织目前的组织结构现状、人才技能现状以及存量产品特点。风险控制和稳定是金融企业 IT 系统需要考虑的首要问题，这些限制导致了他们无法像一些小型的初创企业一样，一夜之间即进行重大的 IT 组织调整，甚至产品更换。他们只能是逐步的稳健的创新，在创新的同时，还需要保持已有组织、人才以及产品的相对稳定。

3. 该平台一定要与企业目前已有的流程控制系统相结合，而不能独立于现有的流程控制系统。现有的开发测试发布流程，是协调整个组织行为的重要工具，也是控制产品发布风险的有力工具，如果自动化交付平台脱离了这些流程的监管，就有可能变成规避现有流程监控的新工具，从而带来更大的风险。

基于以上考虑，本文设计了如图 4 所示的 DevOps 流水线交付平台架构。在该架构中，我们将整体的流水线交付平台分成了四层：基础架构层、流水线工具平台层、流水线引擎层以及流程管控层。

基础架构层是一个企业最基本的基础设施，既包含了存量的硬件平台，也包含了云计算平台，首先，只有在基础实施上实现弹性可伸缩、消除开发测试环境的差异，才能实现真正的 DevOps。而流水线工具平台则是为企业的代码开发、测试及发布提供了一个端到端的工具平台，通过该工具平台的自动化和相互间的无缝对接，实现了从软件代码配置管理、自动化构建、测试到快速的自动化发布。流水线工具分布在整个开发测试发布过程的各个阶段，需要不同的角色在不同的阶段进行配合操作，而且这个操作过程需要置于企业现有流程管控系统的管控之下，因此，我们还需要流水线引擎层，用于根据整体开发测试发布不同阶段的需要，驱动底层的工具平台进行产品的代码管理、构建及部署，同时对上又与企业的流程管控系统对接，使得整个操作过程置于流程监控之下。

图 4. DevOps 流水线交付平台整体架构图

显然，在 DevOps 流水线工具平台实施的四层架构中，其核心是流水线工具平台层的搭建，对上，该工具平台需要通过流水线引擎与现有的流程管理系统对接，对下，则需要兼容现有的各种程序语言、开发发布模式、构建方式，以及存量硬件和云平台的基础设施。在本系列文章的后续各篇中，我们将重点围绕流水线工具平台的搭建进行阐述。

2

实施思路讨论

流水线交付平台各层实施顺序

对于第四节所述工具平台的实施，不同的企业具体的实际情况可能会略有差别，因此，不可能对所有的企业都采用同样的思路进行实施；同时，对于大型企业来说，由于产品形态的多样化，开发语言的广泛性，各开发团队情况的差异性，该工具平台的完整实施也是不可能一蹴而就的。在具体实施时，需要根据具体情况选择制定相应的策略进行实施。总结而言，有两个维度的问题需要考虑，一个是这四层的实施顺序，另一个则是对于流水线工具平台层中，各个具体工具的实施思路。

从上到下的四层中，根据逻辑上的耦合性，我们将其分成了三组，流程管控层自成一组，称为第一组，流水线执行引擎及流水线工具平台层作为一组，称为第二组，基础架构自成一组，称为第三组。

对于目前大多数的金融企业来说，现在基本都已经存在相应的开发测试发布管控流程，不同的只是成熟度不同而已。因此，流水线管控这一层更多的应该是考虑如何对已有流程进行优化。开发测试发布流程中各个阶段的划分和衔接肯定会影响到流水线执行引擎的实施，因此，这一层的实施可与第二组同时进行，或者在第二组实施之前，但不能在第二组之后。

基础架构层中如果存在云平台，则对流水线工具平台层的影响是流水线工具平台需要扩展到对云平台的兼容，因此，第三组与第二组之间既可同时实施，也可先后实施，只不过，如果是第二组先实施之后再实施第三组的云平台，则第三组实施后，需要对第二组进行扩展。

第二组的两层中，流水线引擎是基于流水线工具平台进行的，因此，流水线执行引擎一定得在流水线工具平台之后实施。因此，完整的实施顺序如图 5 所示。

图 5. DevOps 流水线各层实施顺序

流水线工具平台层实施思路

在流水线工具平台层中，对于开发测试发布过程的不同阶段，相应的存在配置管理、代码构建、静态分析、自动化测试、构建包管理、自动化部署、监控等众多工具，其实施过程相对较长，也比较复杂。在具体实施时，存在两种可能的思路，一种为逐点突破，然后再全部连接成一个完整的工具平台。这种思路下，会对企业整体的交付流水线进行分析，找出其中最大的痛点（如配置管理、构建管理或者自动化部署等），然后重点实施，并推广至全公司，接着再继续实施下一个痛点，通过一个一个痛点的实施，最后再连接成一个完整的 DevOps 交付流水线工具平台。

第二种则是从项目突破，先找一个比较典型的项目或者产品作为试点，在该项目或者产品上构建完整的工具平台，并进行深入实施，在实施成功后，再推广至其他的项目或者产品。这种方法的特点是，先考虑比较小的范围和需求，在获取到好的收益后，再考虑更广的范围和需求，对原有工具平台做优化。

当然，具体企业有具体企业的固有特点，包括文化、组织结构、现有技术水平等等，真正的实施思路还需要具体根据具体的情况进行更具个性化的制定。

实施难点及经验总结

过去的几年中，本文作者所在团队一直在某些金融企业实施本文所述的 DevOps 流水线工具平台，根据实施过程的经验，我们认为，在实施过程中，主要存在如下几大难点：

1. 短期收益与长期收益的平衡

对于开发人员和运维人员来说，每天的工作任务都非常重，其最关心的是眼前的问题能不能解决，当前的效率能不能马上提高。而任何一个新工具，新方法的实施都不可避免地需要投入一定的时间进行学习、适应，会对当前的工作造成影响，甚至短期内反而会降低效率。故而在实施初期会引起部分团队成员的抵触和反对，这个时候，如何将开发人员及发布人员当前迫切关心的短期收益与整个平台实施后的长期收益结合起来就成为实施推进的难点之一。

针对这种情况，在具体实施时，我们既需要一定的耐心，也需要有抓有放，对于部分时间暂时允许，也愿意积极配合的团队先行推进，而对于目前比较抵触的团队，则先放一放，等到先行实施的团队显示出收益，中间观望团队积极推进时，慢慢就会形成一定的气候，从而能够比较好的进行推进。

2. 习惯的改变

任何一个人，都会有其熟悉的行为习惯和方式，当需要其作出改变，适应新的方式时，谁都会作出抵触，都会不愿意。而任何工具和方法的实施，都不可能避免地会对团队成员原先的习惯、方式产生影响，需要他们作出改变。尽管从原则上，也许团队成员是认同新工具、新方法的理念的，也是愿意改变的，但是在具体作出改变的，则仍然是会产生各种各样的担心、顾虑，从而影响实施的进度。

这种情况下，我们更多采用的是先适应，后改造的方式，即在一些不影响平台实施关键的点上，先去适应开发发布团队当前的工作习惯，从平台方面主动做出一些调整，等开发发布团队尝到收益之后，再反过来影响他们，让他们做出改变和调整，这个时候，往往就相对容易一些了。

3. 解决方案如何同时兼容多样化的部署环境、构建方式及发布方式等

任何一个新平台的实施，其最理想的方式就是在试点之后，即可马上进行大面积的推广和实施，但实际上，对一个大型的 IT 组织来说，不可能所有的团队都采用相同的方式进行开发，也都采用相同的程序语言，相同的构建方式等，同时，开发测试及运行环境也肯定会存在一定的差异，这些都影响了平台实施的推进进度。在后续的系列文章中，我们将从技术的角度，具体阐述我们如何去应对这样的挑战。

3

总结

本文作为系列文章的第一篇，主要讲述了作者在过去几年的 DevOps 实施历程中，所经历过的大型金融企业所面临的共同挑战，以及在应对这些挑战时所采取的思路和 DevOps 实施方案。后续的系列文章将就具体的方案进行详细叙述。

原创：刘鹤辉、韩庆