【干货】DevOps的演进与落地价值

DevOps是当前IT领域最热门的话题之一,了解、掌握、应用DevOps对于提升软件交付与管控具有重要的意义。然而时至今日DevOps尚无统一的定义。

创新互联公司自2013年起,先为裕华等服务建站,裕华等地企业,进行企业商务咨询服务。为裕华企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

本文主要从业务及IT的发展对DevOps的诞生背景、定义演进以及落地价值等方面进行了分析和阐述,以期对DevOps的内涵进行探讨。

DevOps在2009年提出以来,已经走过了十个年头。近几年来,DevOps的热度呈快速上涨趋势,从DORA的年度报告也可以看出来,到2018年末全球主要行业的DevOps的应用程度已达到30%,上升势头迅猛。

然而,时至今日,对于DevOps仍没有一个准确的定义,这对于我们理解DevOps,或者说在落地DevOps的过程中会带来不小的困扰,各方都有自己的理解。那么,DevOps的内涵究竟是什么呢?我们期望从DevOps的发展背景、定义演进以及落地价值等方面进行一次探讨。

DevOps发展背景

业务发展对软件的依赖

民用软件系统的应用崛起于上个世纪八十年代, 2000年后蓬勃发展,其中,作为重要组成部分的软件系统,逐渐深入到社会的每一个角落,从整体的发展过来来看,业务与软件系统的关系可分为三个阶段。

轻度依赖

在这个阶段主要出现在早期,软件系统主要解决业务中重复多或计算量大的问题,支撑范围主要局限在业务中的某一过程或环节。或者说,在这个阶段,业务离开了软件系统也能开展,软件对业务来说不是必选项,软件功能的更新频率可以是数天乃至数月、年。

重度依赖

随着业务的发展,业务的关联性与复杂度提高后,业务完全依赖人工完成已经成为不可能。到这个时期,软件系统成为业务的核心支撑,业务的开展已经离不开软件系统,但尚可接受短暂的非服务期存在,软件功能的更新频率被要求在数天、月。

完全依赖

随着软件服务深入社会各个角落,社会生活的衣、食、住、行、用都依赖于软件系统,从某一领域或应用来说,软件系统相对于业务已经进入了主导阶段,软件系统必须提供365*7*24的服务,任何中断服务可能都会带来极大的经济或社会损失,软件功能的更新频率必须控制在数天、小时、分钟。

IT管理与研发模式演进

IT管理与研发模式的演进,与IT对业务的响应效率密不可分,大致可分为三个阶段;

“稳态”模式

传统稳态模式的管理上,业务、研发、测试、运维依次分阶段管理,各阶段的人员只需关注本阶段内部的相关内容即可,研发以系统软件包交付为目标;整体结构如下图所示:

【干货】DevOps的演进与落地价值

在研发模式上,以瀑布模型为主要特点,其优势是各阶段划分比较清晰、整体成本较低,但迭代速度较慢,其在业务对软件轻度依赖阶段适用性较好。

“稳态+敏捷”模式

随着业务对软件依赖程度的提高,传统模式下软件的迭代效率成为了一个阻碍业务发展的主要问题点,于是针对软件研发过程最耗时的开发过程出现了一系列的优化措施,敏捷研发是其代表。这个时期的IT管理模式变成了“稳态+敏捷”的模式,研发仍旧以系统软件包交付为目标,如下图所示:

【干货】DevOps的演进与落地价值

当然,在这个时期,针对各阶段的效率提升也进行得如火如荼,出现了了一大批针对不同阶段提速的工具软件,如下图所示:

【干货】DevOps的演进与落地价值

“敏态”模式

当业务对软件系统完全依赖时,IT管理与研发模式就需要进入“敏态”模式了。而这个模式也就是我们今天时常提起的DevOps。在这个模式下,研发交付目标不再是系统软件包,而是面向业务的服务能力,如下图所示:

【干货】DevOps的演进与落地价值

由于业务与软件的关系越来越紧密,研发的交付已经由原来的面向软件包产品,而转向面向业务需要的服务能力,然而,这种服务能力也是涉及多个方面,下面我们从DevOps的定义发展,来看看DevOps的内容丰富过程。

DevOps定义演进

“稳态+敏捷”模型只能实现局部效率提升,而DevOps那么唯一的途径就是从整体上进行优化和提升,使整个研运过程形成一个有机的整体。从2009年提出依赖,DevOps的内涵也在进行着不断的发展与丰富,我们先看一下不同时期的定义。

  • 2009年10月,【Patrick Debois】DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

  • 2010年5月,DevOps是一个重要的理论,它通过敏捷、精益等在方法、在一个传统的组织中,把独立的部门协同在一起实现跨部门集成,建立更加紧密的多部门协作。DevOps不仅仅关注软件部署这一技术问题,它是考虑部门与部门之间沟通和协作的管理方法。

  • 2014年12月 DevOps是一种软件开发方法,它强调软件开发人员和信息技术人员之间的沟通、协作和集成。

  • 2015年11月 DevOps是一种文化、运动或实践,它强调软件开发人员和其他信息技术人员的协作和沟通,同时强调自动化软件交付和基础设施变更的过程。

  • 2018年AWS DevOps定义:DevOps是一组实践,目的是在确保高质量的情况下,快速地把变更导入到生产环境。

我们把不同时期的定义整理为一个时间轴,并做一些关键字抽取:

【干货】DevOps的演进与落地价值

可以看出针对DevOps的定义,随着时间的推移,DevOps的内涵在不断丰富,已经从最初一组过程、方法与系统的组合简的单定义,发展为一套有理论、有方法、有文化、有实践的体系。

DevOps体系与传统模式是有着本质的不同的,主要体现在以下几个方面:

组织方式不同

DevOps中强调以项目或产品的一体化管理为基本管理模式,从而消除传统模式下分阶段任务管理与执行,通过管理模式的调整,消除传统模式下不同阶段的衔接问题。

关注重点不同

DevOps是以最终向业务的服务能力交付为目标,而不是传统模式下分阶段任务交付为目标。

提升维度不同

DevOps关注软件系统的整个生命周期,是从整体上提升软件交付的质量与效率,而不单只关注某一个阶段的提升,各阶段的提升可以更加的有机协同。

管控深度不同

DevOps强调全程监控,全程度量,通过技术手段透明化软件交付的全程,包括过程与结果,而传统模式下过程数据缺乏,难以进行有效的过程度量与分析。

效益效果不同

DevOps支持针对交付过程的持续优化,通过度量数据分析可以快速定位交付过程的问题与努力方向,支持持续科学的优化提升,传统模式难以做到。

DevOps落地价值

DevOps的定义演进以及与传统模式的对比,可以看出DevOps体系本身系统化、整体性的设计思想,其既包括了软件全生命周期的系统化考虑,也包括了了IT管理的多方诉求,DevOps的落地涉及DevOps平台的建设、流程体系建设、人员赋能、标准规范等多个方面,其可以为带来如下方面的提升。

业务响应能力提升

DevOps的落地,在提升效率的同时可以提升交付的质量,自动化程度的提升可以提升对业务需求迭代的响应能力,研运吞吐量可以得到几何级的提升。

研发交付规范提升

不同项目或产品的研发团队,在同一套平台上开展研发交付活动,通过平台预先制定的流程、规则等约束不同研发团队的交付活动,从而实现研发交付规范与标准的统一,实现企业级的优化提升与改进。

研发交付效率提升

通过针对研发交付过程中的环境准备、编译构建、代码质量检查、系统测试、软件部署等过程的自动化实现,降低人工操作或等待人工操作时间,全面提升研发交付过程的自动化水平,提升研发交付效率。

研发交付质量提升

研发交付质量的从现有的部署结果质量保障,延伸到源代码质量保障、测试覆盖度保障等过程,从而实现从源代码到部署全过程的质量检查与提升,全链路提升研发交付质量

研发交付管控提升

针对研发交付的需求、开发、测试、发布和部署等过程,进行全面的数据化和度量,针对重点关注指标建立质量门禁,从而实现自动化的技术管控,结合已有的行政管控,由单一的结果管控,实现研发交付“过程+结果”管控,提升管控力度。

研发交付持续优化

基于DevOps平台,通过流水线过程数据收集,以及进一步的度量分析,实现研发交付过程的持续优化,既包括DevOps平台的优化,也包括研发交付流程、标准规范等方面的优化。

总结

DevOps的演进简单来说就是从一项技术到文化的构建与实践;从无关紧要到依赖;从业务的局部到全部。而DevOps的落地价值实现于研、运的整合并且提升对业务需求的响应。趋势已成,只愿大家都能共襄盛举。


名称栏目:【干货】DevOps的演进与落地价值
转载注明:http://hbruida.cn/article/iecosc.html