2008年在多伦多举行的敏捷大会上，PatrickDeBois先生和AndrewClayShafer先生提出要讨论“敏捷基础设施”的话题。随后在Flickr上的《每天部署10次》的分享就出来了，这也启发了2009年在比利时根特举办的第一届DevOpsDays活动。PatrickDeBois先生在公开场合提出了“DevOps”这个词，“#DevOpsDays”缩写为推特上的“#DevOps”。从那时起，“DevOps”一词立即成为全球IT领袖们在各种活动中讨论和讨论的热门话题，PatrickDeBois先生也被IT界誉为“DevOps之父”2010年在美国山景城举行的DevOpsDays年会上，DamonEdwards先生用缩写“CAMS”来诠释DevOps，即文化（Culture）、自动化（Automation）、测量（Measurement或Metrics）)和分享(Sharing)。然后JezHumble先生在其中加入了“L”精益(Lean)原则，最终成为CALMS。Culture(文化)-指拥抱变化，促进协作和沟通自动化(automation)-指消除价值链中的人为干预?精益（lean）——指用精益原则推动高频循环Metrics（指标）——指衡量每一个环节，通过数据共享（Sharing）改进循环——指公开分享成功和失败的经验与他人一起，不断地从错误中学习和改进。“CALMS”恰恰符合PatrickDeBois先生所说的“DevOpsisahumanproblem”（DevOpsisabouthumanproblems）的概念一直被提倡。随着BAT等互联网巨头在中国的崛起，越来越多的互联网公司的开发运营经验正在国内各种技术大会上传播。从近两年的技术活动安排可以看出，国内的互联网从业者也通过DevOps来定位和分享自己的优势和经验。他们是运维端传播和分享DevOps实践的先锋。Docker容器技术近三年异军突起，将持续交付的技术门槛降到最低，彻底改善了软件生产供应链的格局和效率；基于Docker的微服务架构实践的流行度和成熟度也与日俱增。因此，国内传统企业纷纷尝试DevOps和容器技术。在近两年的各种技术大会上，我们可以看到国内各行业从不同维度涌现出DevOps先行者。他们分享的话题大多集中在自动化运维、容器化、PaaS平台等方面的项目经验。目前，国内大部分企业已经慢慢开始关注DevOps，大型传统企业也逐渐开始从各个角度进行试点和尝试。飞行员的角度和方向是不同的。有的从底层基础设施的容器化入手，有的从交付部署流水线的自动化入手；以上就是DevOps在国外的形成和推广，以及在国内生根和传播的情况。我根据不同的技术特点将DevOps从1.0划分为2.0，并试图通过以下几个维度来比较与传统方法的差异。从国内众多DevOps实践中，我们可以看出以下三种技术尤为重要和流行：容器：容器从根本上解决了软件对环境的依赖和各种环境之间的差异；可以加快部署速度，提高部署效率；降低部署成本。容器技术是在Linux的基础上发展起来的，因此其实现成本非常低，即在任何物理机和虚拟机的Linux操作系统上安装Docker服务（仅几十兆）即可完成所有功能。在任何环境下实施Docker都需要考虑以下因素：宿主机的计算资源特性与容器允许的资源需求（计算密集型、内存密集型、IO密集型等）相匹配；容器网络类型和服务路由类型的选择；容器镜像仓库的选择等。持续部署：这是所有企业的通病。需要设计一个统一的自动化部署流水线作为软件系统部署和更新的基础设施。持续部署流水线底层由Jenkins等工具完成，可以实现快速、可复用的适用于不同部署环境的发布流水线。所有服务都可以通过它实现各种风格的发布；两种比较重要的发布方式是蓝绿部署和灰度发布。微服务：为了解决传统软件特有的单体应用的缺陷，利用微服务的思想全面重构单体应用，并在新系统中充分应用这种架构。微服务架构是容器技术出现后迅速发展起来的一种软件架构技术。其松散耦合和面向服务的基础设施特性是现代软件和数据中心的基本品质。以上三种技术相辅相成，有着比较深厚的联系。首先，微服务和持续部署各自解决了大量长期制约企业业务发展的传统IT问题。容器技术由于其快速、轻量、微服务的特性，从不同方面支持持续交付和微服务架构。容器可以为持续交付提供弹性、高速的系统资源，大大提高环境管理和利用率；容器的不变性也更好地支持微服务架构。企业实践DevOps需要参考的最佳实践如下图所示。（上图来自：ExinDevOps白皮书）敏捷管理：敏捷开发方法论主要应用于产品的规划、需求、设计和开发阶段。在这些阶段，DevOps强调设置合理的任务规模，以保证快速迭代和开发；强调实施持续集成，通过CI提高软件的质量和可用性；强调使用较短的发布周期来提高反馈频率的数量和质量。持续交付：在开发部署运行阶段，采用持续交付的方式实现软件系统的发布、变更、升级的自动化。DevOps强调使用持续交付工具作为基础设施，尽可能自动化手动部署工作。在研发阶段，我们开始设计和部署自动化脚本，使用流水线工具来运行和执行，辅助自动化测试工具。通过严谨的自动化测试方案，确保实现可重用的自动化部署流水线。通过其反复操作，可以提高布署效率，降低布署风险，提高布署质量。ITSM服务管理：DevOps强调从传统的ITSM管理理念上升到注重业务连续性的轻量级ITSM管理方法。在项目前期，运维人员应与开发、测试、部署人员充分沟通并落实运维需求。确保业务连续性、系统可操作性等非功能性需求在业务系统开发初期得到充分落实和满足。精益管理：在业务开发和运维的整个生命周期中，在上述三类工作实践的所有工作活动中，都必须坚持精益原则。DevOps特别强调的点包括：just-in-time业务流程、精益无浪费的工作方式、单件流操作流程、持续改进等，其管理思想需要严格贯彻到所有工作环节。可见，DevOps在企业，尤其是大型传统企业的实施和推广，还是比较复杂的。尽管相关的最佳实践已经存在多年；然而，想要通过DevOps的价值观重构一个企业从研发到交付再到运维的价值流并不容易。以我10多年的ITSM项目经验来看，我似乎觉得DevOps不能只靠自上而下的推进。当然，高层领导的支持仍然是重要且必要的支持条件之一。更重要的是，它可能是由中层驱动和底层创新；还必须学习制造业行之有效的精益生产实践。简而言之，DevOps运动将在近几年对IT行业产生更大的影响。【本文为专栏作者“刘征”原创稿件，转载请通过作者微信公众号“DevOps教练”（MyDevOps）获得授权】点此查看更多本作者好文
