在2008年多伦多举办的敏捷大会中，Patrick DeBois 和AndrewClay Shafer 先生***提议讨论“敏捷基础架构”话题。接着Flickr的《每天部署10次》的分享横空出世，它也激发了随后2009年在比利时根特举办的首届DevOps Days活动中，Patrick DeBois 先生***在公开场合提出“DevOps”这一名词，“#DevOps Days” 在twitter上被简写为 “#DevOps” 。 此后，“DevOps”一词随即成为全球IT界大咖们在各种活动中热议和讨论的焦点话题。Patrick DeBois先生也随之被全球IT大佬们誉为 “DevOps 之父”!
2010年在美国山景城(Mountain View) 举办的DevOps Days 年会活动中，Damon Edwards先生用一个缩写“CAMS”诠释了DevOps，即文化(Culture)、自动化(Automation)、测量(Measurement or Metrics)和分享(Sharing)。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。
- Culture(文化)- 是指拥抱变革，促进协作和沟通
- Automation(自动化)- 是指将人为干预的环节从价值链中消除
- Lean(精益)- 是指通过使用精益原则促使高频率循环周期
- Metrics(指标)- 是指衡量每一个环节，并通过数据来改进循环周期
- Sharing(分享)- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进
“CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。
随着国内BAT等互联网巨头的崛起，互联网公司的开发运维经验也越来越多的在国内的各种技术大会上传播。从这两年的技术活动日程中可以看出，国内互联网从业人员也不约而同的用DevOps来定位和分享自己的优势和经验。他们是传播和分享运维侧DevOps实践的先头部队。
Docker容器技术在最近三年中异军突起，持续交付的技术门槛因此被降到***，软件生产供应链的格局和效率被彻底提升;基于Docker的微服务架构实践的热度和成熟度也与日俱增。因此，国内的传统企业纷纷试水DevOps和容器技术，在最近两年的各种技术大会中，我们可以看到国内各个行业出现了在不同维度上的DevOps先行者。他们分享的主题大多集中在自动化运维、容器化和PaaS平台的等项目经验。
目前国内大部分企业慢慢地开始关注了DevOps，大型传统企业也开始逐渐地从各个角度做试点和尝试。试点的角度和方向各不相同，有的从底层基础架构的容器化开始，有的从交付部署流水线的自动化开始;总的来说还处于初级的尝试阶段，还没有大规模成体系的推广。以上就是DevOps在国外的形成和推广，以及国内的生根和蔓延的情况。
我把DevOps的按照不同的技术特征做了从到1.0 到2.0的时代划分，并尽量通过以下维度比较与传统方式的差异。
从国内众多DevOps实践中，我们能看到下面三个技术尤其重要和火热：
容器：容器从根本上解决了软件对环境的依懒性，解决了各个环境之间的差异问题;它可以加速部署的速度，提高部署的效率;降低部署的成本。容器技术是在Linux的基础之上发展起来的，因此它本身的实施成本很低，就是在任何物理机和虚拟机的Linux操作系统上安装Docker服务(仅几十兆)就可以完成所有功能。在任何环境中实施Docker需要考虑好以下几个因素：主机的计算资源特性和容器允许的资源需求相匹配(计算密集型、内存密集型、IO密集型等);容器网络类型和服务路由的选型;容器镜像仓库的选择等。
持续部署：这是所有企业普遍的短板，需要设计统一的自动化部署流水线作为软件系统部署和更新的基础设施。持续部署流水线底层是有Jenkins之类的工具来完成的，它能实现快速的、可重复使用的、适用于不同部署环境的发布流水线。所有服务都可以通过它实现各种风格的发布;这些发布风格中比较重要的两种：蓝绿部署和灰度发布。
微服务：为了解决传统软件所特有的巨石应用的缺陷，用微服务的思路，全面地重构巨石应用，全面的在新系统中应用这种架构。微服务架构是容器技术出现之后，有迅猛发展的一项软件架构技术。它的松耦合和面向服务基础架构的特性都是现代软件和数据中心必备的特质。
以上三种技术相辅相成，有着比较深刻的关联。首先微服务和持续部署各自解决了特别多的传统IT的问题，这些问题都是长期以来制约企业业务发展的难题。容器技术由于它的快速、轻量、微服务化的天然特性，很好的从不同侧面支持了持续交付和微服务架构。容器可以为持续交付提供弹性和高速的系统资源，环境管理和利用率提高了很多;容器的不可变性的特点也更好地支持了微服务架构。
企业实践DevOps所需要参考的***实践如下图所示。
(上图来源于：Exin DevOps白皮书)
敏捷管理：在产品的计划、需求、设计和开发阶段主要采用敏捷开发方法论。在这些阶段中DevOps强调，设置合理的任务大小，从而确保能够开展快速迭代和开发;强调持续集成的实施，通过CI提高软件的质量和可用性;强调用更短的发布周期，增强反馈的数量和频度。
持续交付：在开发和部署运营阶段采用持续交付的方法自动化软件系统的发布、变更和升级等工作。DevOps强调使用持续交付工具作为基础架构尽可能的自动化手工部署工作。在研发阶段就开始设计部署自动化的脚本，对其使用流水线工具来操作执行，并辅助自动化测试工具。通过严密的自动化测试方案，确保实现可以重复使用的自动化部署流水线。通过它的反复运作，提高部署的效率，降低部署的风险，提高部署的质量。
ITSM服务管理：DevOps强调从传统的ITSM管理理念上升到关注业务持续性的轻量ITSM管理方法。运维人员在项目的早期要和开发、测试和部署人员充分地沟通和落实运维需求。确保在业务系统开发的初期，系统的业务持续性和可运维性等非功能性需求，都得到充分的落实和满足。
精益管理：业务开发运维的整个生命周期中，以上三类工作实践的所有工作活动中，都必须坚持贯彻精益的原则。DevOps特别强调的点包括：准时制业务流程、精益且无浪费的工作方法、单件流的运作流程、持续改进等。它的这些管理思路需要严格的落实到所有工作环节中。
由此可见DevOps在企业，特别是大规模传统企业的落地和推广还是比较复杂的。虽然相关的***实践都是已经存在了很多年的;但是，通过DevOps的价值观重构企业从研发到交付到运维的价值流谈何容易。基于我10多年的ITSM项目经验，我似乎感觉到DevOps不能单独依靠自顶向下的推广，当然高层领导的支持依然是重要的和必备的支持条件之一。更重要的可能是中层的带动和底层的创新;借鉴生产制造业已经久经考验的精益制造实践也是势在必行。总之DevOps运动会在近几年给IT行业带来较大影响。
【本文为51CTO专栏作者“刘征”的原创稿件，转载请通过作者微信公众号“DevOps教练”(MyDevOps)获取授权】
