DevOps在2009年提出以来，已经走过了十个年头。近几年来，DevOps的热度呈快速上涨趋势，从DORA的年度报告也可以看出来，到2018年末全球主要行业的DevOps的应用程度已达到30%，上升势头迅猛。
然而，时至今日，对于DevOps仍没有一个准确的定义，这对于我们理解DevOps，或者说在落地DevOps的过程中会带来不小的困扰，各方都有自己的理解。那么，DevOps的内涵究竟是什么呢？我们期望从DevOps的发展背景、定义演进以及落地价值等方面进行一次探讨。
DevOps发展背景
01业务发展对软件的依赖
民用软件系统的应用崛起于上个世纪八十年代， 2000年后蓬勃发展，其中，作为重要组成部分的软件系统，逐渐深入到社会的每一个角落，从整体的发展过来来看，业务与软件系统的关系可分为三个阶段。
轻度依赖
在这个阶段主要出现在早期，软件系统主要解决业务中重复多或计算量大的问题，支撑范围主要局限在业务中的某一过程或环节。或者说，在这个阶段，业务离开了软件系统也能开展，软件对业务来说不是必选项，软件功能的更新频率可以是数天乃至数月、年。
重度依赖
随着业务的发展，业务的关联性与复杂度提高后，业务完全依赖人工完成已经成为不可能。到这个时期，软件系统成为业务的核心支撑，业务的开展已经离不开软件系统，但尚可接受短暂的非服务期存在，软件功能的更新频率被要求在数天、月。
完全依赖
随着软件服务深入社会各个角落，社会生活的衣、食、住、行、用都依赖于软件系统，从某一领域或应用来说，软件系统相对于业务已经进入了主导阶段，软件系统必须提供365*7*24的服务，任何中断服务可能都会带来极大的经济或社会损失，软件功能的更新频率必须控制在数天、小时、分钟。
02 IT管理与研发模式演进
IT管理与研发模式的演进，与IT对业务的响应效率密不可分，大致可分为三个阶段；
“稳态”模式
传统稳态模式的管理上，业务、研发、测试、运维依次分阶段管理，各阶段的人员只需关注本阶段内部的相关内容即可，研发以系统软件包交付为目标；整体结构如下图所示：
在研发模式上，以瀑布模型为主要特点，其优势是各阶段划分比较清晰、整体成本较低，但迭代速度较慢，其在业务对软件轻度依赖阶段适用性较好。
“稳态+敏捷”模式
随着业务对软件依赖程度的提高，传统模式下软件的迭代效率成为了一个阻碍业务发展的主要问题点，于是针对软件研发过程最耗时的开发过程出现了一系列的优化措施，敏捷研发是其代表。这个时期的IT管理模式变成了“稳态+敏捷”的模式，研发仍旧以系统软件包交付为目标，如下图所示：
当然，在这个时期，针对各阶段的效率提升也进行得如火如荼，出现了了一大批针对不同阶段提速的工具软件，如下图所示：
“敏态”模式
当业务对软件系统完全依赖时，IT管理与研发模式就需要进入“敏态”模式了。而这个模式也就是我们今天时常提起的DevOps。在这个模式下，研发交付目标不再是系统软件包，而是面向业务的服务能力，如下图所示：
由于业务与软件的关系越来越紧密，研发的交付已经由原来的面向软件包产品，而转向面向业务需要的服务能力，然而，这种服务能力也是涉及多个方面，下面我们从DevOps的定义发展，来看看DevOps的内容丰富过程。
DevOps定义演进
“稳态+敏捷”模型只能实现局部效率提升，而DevOps那么唯一的途径就是从整体上进行优化和提升，使整个研运过程形成一个有机的整体。从2009年提出依赖，DevOps的内涵也在进行着不断的发展与丰富，我们先看一下不同时期的定义。
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体系本身系统化、整体性的设计思想，其既包括了软件全生命周期的系统化考虑，也包括了了IT管理的多方诉求，DevOps的落地涉及DevOps平台的建设、流程体系建设、人员赋能、标准规范等多个方面，其可以为带来如下方面的提升。
业务响应能力提升
DevOps的落地，在提升效率的同时可以提升交付的质量，自动化程度的提升可以提升对业务需求迭代的响应能力，研运吞吐量可以得到几何级的提升。
研发交付规范提升
不同项目或产品的研发团队，在同一套平台上开展研发交付活动，通过平台预先制定的流程、规则等约束不同研发团队的交付活动，从而实现研发交付规范与标准的统一，实现企业级的优化提升与改进。
研发交付效率提升
通过针对研发交付过程中的环境准备、编译构建、代码质量检查、系统测试、软件部署等过程的自动化实现，降低人工操作或等待人工操作时间，全面提升研发交付过程的自动化水平，提升研发交付效率。
研发交付质量提升
研发交付质量的从现有的部署结果质量保障，延伸到源代码质量保障、测试覆盖度保障等过程，从而实现从源代码到部署全过程的质量检查与提升，全链路提升研发交付质量
研发交付管控提升
针对研发交付的需求、开发、测试、发布和部署等过程，进行全面的数据化和度量，针对重点关注指标建立质量门禁，从而实现自动化的技术管控，结合已有的行政管控，由单一的结果管控，实现研发交付“过程+结果”管控，提升管控力度。
研发交付持续优化
基于DevOps平台，通过流水线过程数据收集，以及进一步的度量分析，实现研发交付过程的持续优化，既包括DevOps平台的优化，也包括研发交付流程、标准规范等方面的优化。
总结
DevOps的演进简单来说就是从一项技术到文化的构建与实践；从无关紧要到依赖；从业务的局部到全部。而DevOps的落地价值实现于研、运的整合并且提升对业务需求的响应。趋势已成，只愿大家都能共襄盛举。