每次 同一时间 语言 流程监控 影响 重要性 两个 快速发布 痛点
2009 年 6 月份,John Allspaw 及 Paul Hammond 在速度大会 (Velocity) 上分享了在 Flickr 中如何通过加强 Dev(开发团队)和 Ops(运维团队)之间的协作,从而加快应用部署频率的演讲 。随后,关于 Dev 和 Ops 之间协作的讨论一直在 Twitter 上持续进行,当年的 10 月份,在 Twitter 上首次出现了 DevOps( 开发运维一体化 ) 一词 。在随后的几年里,DevOps 不仅引起了工程界的大量关注和实践,同时,也吸引了大量学术界人士的兴趣。Gartner 2015 年所做的调查结果表明,目前已有 29% 的企业在使用 DevOps。图一所示为 Gartner 对各 IT 技术发展热度预测的研究,根据其研究,目前 DevOps 正处于其发展阶段的高潮期。
DevOps,其主要目的就是通过消除开发部门与运维部门之间的壁垒,从而使得一个企业的 IT 组织能够在敏捷地适应市场变化的同时,将一个企业的业务能力通过创新性的解决方案快速地从 IT 部门的开发过程推向用户。它主要利用了精益的思想,通过消除 IT 部门整个产品交付流中所存在的浪费及障碍,从而达到快速交付的目的。
对于一个较大的组织或者企业来说,其 IT 部门有其多年形成的固有组织结构、文化氛围、开发及发布流程、基础架构及产品体系等,在这种情况下,试图像新创的公司一样,很快就将整个企业的 IT 组织转型到 DevOps 上,显然是不现实的,也是不可行的。在这个过程中,必定会面临一定的困难与挑战。
国内金融企业主要的开发发布模式
对于国内主要的金融企业,虽然有部分企业已经或者正在推行敏捷的开发方法,但是目前普遍采用的仍然是瀑布的开发方法(从立项、开发、测试到发布几个阶段顺次执行),并且主要是以项目为单位进行人力资源的组织和开发过程管理。
一个项目主要是实现一个或者若干个需求,由项目经理主导,组织若干开发人员进行开发(对于大的项目,则可能还会跨越多个大的开发部门,包含多个小的开发小组)。需求主要是由业务单位提出的。在具体执行时,不同的业务单位都会提出不同的业务需求(不同的业务需求会成立不同的项目),而且从每个业务单位的角度来说,都会要求其所提出的需求具有绝对的优先级,因此,在开发阶段,就不可避免地需要并行进行多个项目的开发。项目虽然是多个,但是其背后所修改到的代码及产品则可能是同一个,故而整个产品的交付过程自然而然就被分裂成了两个阶段:开发测试阶段和投产阶段。在开发测试阶段,最主要的是以项目为单位进行开发测试以及部署(每个项目的代码独立部署),而在投产阶段,虽然也是以项目为单位进行相关的流程管理,但是在具体发布时,则是以产品为单位进行部署安装(不同项目中涉及到同一个产品的代码合并到一起发布)。由于项目与产品两个管理维度的切换,在实际的开发发布模式上,就主要演变出了如下三种模式:
当然,现在也有部分大型金融企业在积极探索整个组织都采用敏捷的方式进行开发,并取得了积极的成果,但是毕竟还没有成熟到足以供其他企业模仿照搬的程度。
长期以来,固定版本排期及项目排期的开发模式,为大型金融企业业务的快速发展提供了强有力的 IT 保障,同时也确保了产品的质量和运行风险。但是,近年来,随着大量互联网企业,特别是移动互联网企业的冲击,大型金融企业也不得不面临在业务模式加快创新的同时,需要 IT 团队加快开发节奏,快速推出满足业务发展需求的产品。而这种需求正对金融企业现有的 IT 开发模式提出紧迫的挑战,根据我们的研究,这些挑战主要体现在如下的三个矛盾中(图 2)。
2. 大量手工操作与金融企业对于产品质量一致性、稳定性严苛要求之间的矛盾
随着业务的发展,目前对大型的金融企业来说,对于与用户交互频繁的产品,单个产品只部署在一个或者少量几个服务器节点上是远远无法满足大量的并发访问需求的,因此,一个产品往往都会部署在多个服务器节点,甚至是几十个服务器节点上。尽管部署节点多,对于企业本身来说,最基本的要求就是不同节点在所部署产品的版本、配置等等上必须是保持一致的。 而由于 IT 发展时间的限制,目前整个开发发布过程中,还存在大量的手工操作环节,特别是产品的构建以及到生产环境的部署,对于手工操作来说,每次发布包的构建以及每个节点的发布都是一次全新的操作,很容易出现失误或者不一致的地方。故而,大量的手工操作已经无法适应面对大量节点部署时的一致性以及稳定性要求。
3. 开发团队对于流程简单性、快速性的现实要求与风险管控之间的矛盾。
从开发团队的角度,其根本目的就是满足业务方的需求,能够快速的将开发完成的功能发布到生产环境中,特别是在业务部门对发布频率加快的需求与日俱增的压力下,他们对于开发测试发布流程中所存在的各个管控点就往往颇具怨言,认为有些把控环节不仅延缓了发布时间,而且还浪费了他们的时间,他们希望流程越简单越好。而从项目管理及运维的角度,在每年发布的几千甚至上万个版本中,只要其中有一个版本存在问题或者发布失误,就是难以容忍的,因此,为了防止可能存在的风险,在现有大量依靠手工操作的现实下,他们必须千方百计挖掘可能存在的风险点,并设置各种严格的评审点进行把关,以防止可能的风险流入到生产环境中。因此,现有由于风险管控所叠加上来的流程管控已经无法满足开发团队对于流程简单性及快速性的需求。
显然,目前大型金融企业所面临的挑战既有技术层面上的,也有开发模式以及流程管理上的,试图采用单一的方法进行应对是不可能的,当然也无法一蹴而就进行解决。本文认为,为应对这些挑战,从整个 DevOps 实施的角度,需要通过图 3 所示的三个阶段逐步进行实施。
作为实施的第一步,显然,消除大量的手工操作,构建一个持续交付的流水线平台是最基础也是最迫切的,只有通过流水线平台的自动化和持续流动,才能保证在不同阶段、不同节点上产品发布的一致性和稳定性,同时,也才能消除由于人工操作所引入的人为风险,同时提高效率。
作为实施的第二步,则需要对现有的开发模式及产品架构做进一步的优化,否则,整个流水线是很难顺畅地流动起来的。例如,如果不调整固定版本排期的开发模式,则即使自动化程度再高,紧急需求的上线仍然需要等待整个版本的上线;而对于项目排期的开发模式,在上线前,多个项目代码或者构建包的手工合并也是必不可少的;在传统紧耦合的产品架构下,想要做到自动化的增量迭代发布,也是非常困难的,而每次都将整个产品的所有代码进行发布也是极不现实的,这些其实都是实现整个 DevOps 持续交付过程全自动化的障碍。因此,在构建好持续交付的流水线平台后,其第二步就是开发模式及产品架构的优化。当然,如果没有第一步的自动化的持续交付平台作为基础,则由开发模式调整所带来的发布次数增多也是无法完全用手工完成的。
在通过工具自动化的方式实现产品的持续交付后,由于人工操作的减少,自动化及流水线操作的提高,包括操作过程可追踪性的实现,快速自动回滚操作的实施等,这个时候,在完整的开发测试交付流程中,有些管控步骤可能就是多余的,是可以优化的。因此,实施的第三步就是对整体开发测试发布流程进行优化,去掉冗余的人工评审步骤,从而实现企业级的 DevOps 持续交付流水线。
在 DevOps 实施的三个阶段中,第一个阶段,DevOps 交付流水线平台的搭建是最基础也是非常关键的步骤,对于金融企业来说 ,由于其对产品质量、运营风险的严格要求,以及自身产品的复杂性、特殊性,该平台的构建需要考虑如下问题:
基于以上考虑,本文设计了如图 4 所示的 DevOps 流水线交付平台架构。在该架构中,我们将整体的流水线交付平台分成了四层:基础架构层、流水线工具平台层、流水线引擎层以及流程管控层。
基础架构层是一个企业最基本的基础设施,既包含了存量的硬件平台,也包含了云计算平台,首先,只有在基础实施上实现弹性可伸缩、消除开发测试环境的差异,才能实现真正的 DevOps。而流水线工具平台则是为企业的代码开发、测试及发布提供了一个端到端的工具平台,通过该工具平台的自动化和相互间的无缝对接,实现了从软件代码配置管理、自动化构建、测试到快速的自动化发布。流水线工具分布在整个开发测试发布过程的各个阶段,需要不同的角色在不同的阶段进行配合操作,而且这个操作过程需要置于企业现有流程管控系统的管控之下,因此,我们还需要流水线引擎层,用于根据整体开发测试发布不同阶段的需要,驱动底层的工具平台进行产品的代码管理、构建及部署,同时对上又与企业的流程管控系统对接,使得整个操作过程置于流程监控之下。
显然,在 DevOps 流水线工具平台实施的四层架构中,其核心是流水线工具平台层的搭建,对上,该工具平台需要通过流水线引擎与现有的流程管理系统对接,对下,则需要兼容现有的各种程序语言、开发发布模式、构建方式,以及存量硬件和云平台的基础设施。在本系列文章的后续各篇中,我们将重点围绕流水线工具平台的搭建进行阐述。
流水线交付平台各层实施顺序
对于第四节所述工具平台的实施,不同的企业具体的实际情况可能会略有差别,因此,不可能对所有的企业都采用同样的思路进行实施;同时,对于大型企业来说,由于产品形态的多样化,开发语言的广泛性,各开发团队情况的差异性,该工具平台的完整实施也是不可能一蹴而就的。在具体实施时,需要根据具体情况选择制定相应的策略进行实施。总结而言,有两个维度的问题需要考虑,一个是这四层的实施顺序,另一个则是对于流水线工具平台层中,各个具体工具的实施思路。
从上到下的四层中,根据逻辑上的耦合性,我们将其分成了三组,流程管控层自成一组,称为第一组,流水线执行引擎及流水线工具平台层作为一组,称为第二组,基础架构自成一组,称为第三组。
对于目前大多数的金融企业来说,现在基本都已经存在相应的开发测试发布管控流程,不同的只是成熟度不同而已。因此,流水线管控这一层更多的应该是考虑如何对已有流程进行优化。开发测试发布流程中各个阶段的划分和衔接肯定会影响到流水线执行引擎的实施,因此,这一层的实施可与第二组同时进行,或者在第二组实施之前,但不能在第二组之后。
基础架构层中如果存在云平台,则对流水线工具平台层的影响是流水线工具平台需要扩展到对云平台的兼容,因此,第三组与第二组之间既可同时实施,也可先后实施,只不过,如果是第二组先实施之后再实施第三组的云平台,则第三组实施后,需要对第二组进行扩展。
第二组的两层中,流水线引擎是基于流水线工具平台进行的,因此,流水线执行引擎一定得在流水线工具平台之后实施。因此,完整的实施顺序如图 5 所示。
流水线工具平台层实施思路
在流水线工具平台层中,对于开发测试发布过程的不同阶段,相应的存在配置管理、代码构建、静态分析、自动化测试、构建包管理、自动化部署、监控等众多工具,其实施过程相对较长,也比较复杂。在具体实施时,存在两种可能的思路,一种为逐点突破,然后再全部连接成一个完整的工具平台。这种思路下,会对企业整体的交付流水线进行分析,找出其中最大的痛点(如配置管理、构建管理或者自动化部署等),然后重点实施,并推广至全公司,接着再继续实施下一个痛点,通过一个一个痛点的实施,最后再连接成一个完整的 DevOps 交付流水线工具平台。
第二种则是从项目突破,先找一个比较典型的项目或者产品作为试点,在该项目或者产品上构建完整的工具平台,并进行深入实施,在实施成功后,再推广至其他的项目或者产品。这种方法的特点是,先考虑比较小的范围和需求,在获取到好的收益后,再考虑更广的范围和需求,对原有工具平台做优化。
当然,具体企业有具体企业的固有特点,包括文化、组织结构、现有技术水平等等,真正的实施思路还需要具体根据具体的情况进行更具个性化的制定。
过去的几年中,本文作者所在团队一直在某些金融企业实施本文所述的 DevOps 流水线工具平台,根据实施过程的经验,我们认为,在实施过程中,主要存在如下几大难点:
本文作为系列文章的第一篇,主要讲述了作者在过去几年的 DevOps 实施历程中,所经历过的大型金融企业所面临的共同挑战,以及在应对这些挑战时所采取的思路和 DevOps 实施方案。后续的系列文章将就具体的方案进行详细叙述。
文章出自:《金融行业 DevOps 解决方案概述》
[转载]金融行业 DevOps 解决方案概述
来源: http://www.bubuko.com/infodetail-2321376.html