DevOps详解

最近我阅读了不少有关DevOps的文章，其中一些很是有趣，然而一些内容也很欠考虑。貌似不少人愈来愈坚决地在DevOps与chef、puppet或Docker容器的熟练运用方面划了等号。对此我有不一样见解。DevOps的范畴远远超过puppet或Docker等工具。

这样的见解甚至让我感受有些气愤。DevOps在我看来极为重要，过去15年来，我一直在大型机构，主要是大型金融机构中从事工程业务。DevOps是一种很是重要的方法论，该方法将解决一些最大型问题的基本原则和实践恰如其分地融为一体，很好地解决了此类机构的软件开发项目中一种最使人感受悲凉的失败要素：开发者和运维人员之间的混乱之墙。

请不要误会个人这种观点，除了某些XP实践，大部分此类大型机构对敏捷开发方法论的运用还有很长的路要走，同时还有不少其余缘由会致使软件开发项目的失败或延误。

但在我看来，混乱之墙目前依然是他们所面临的最使人沮丧、最浪费时间、同时也至关愚蠢的问题。

与其独自生闷气，我以为不如说点更实在的东西，写一篇尽量精准的文章，向你们介绍DevOps究竟是什么，能为咱们带来什么。长话短说，DevOps并非某一套工具。DevOps是一种方法论，其中包含一系列基本原则和实践，仅此而已。而所用的工具（或者说“工具链”吧，毕竟用于为这些实践提供支持的工具集有着极高的扩展性）只是为了对这样的实践提供支持。

最终来讲，这些工具自己并不重要。相比两年前，目前的DevOps工具链已经产生了翻天覆地的变化，可想而知，两年后还会产生更大的差别。不过这并不重要。重要的是可以合理地理解这些基本原则和实践。

本文并不许备介绍某些工具链，甚至彻底不会提到这些工具。网上讨论DevOps工具链的文章已经太多了。我想在本文中谈谈最基本的原则和实践，它们的主要目的，毕竟这些才是对我而言最重要的。

DevOps是一种方法论，概括总结了面临独一无二的机遇和强有力需求的网络巨头们，结合自身业务本质构思出全新工做方式的过程当中所采用的实践，而他们的业务需求也很直接：以前所未有的节奏对本身的系统进行演进，有时候可能还须要以天为单位对系统或业务进行扩展。

虽然DevOps对初创公司来讲很明显是不可或缺的，但我认为那些有着庞大的老式IT部门的大企业才是能从这些基本原则和实践中得到最大收益的。本文将试图解释得出这个结论的缘由和实现方法。

本文的部份内容已发布为Slideshare演示幻灯片，可在这里浏览：http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

 

目录

1. 简介
	1.1 管理信条
	1.2 一个典型的IT组织
	1.3 运维人员测挫败感
	1.4 基础架构自动化
	1.5 DevOps：仅此一次，一颗神奇的银子弹
2. 基础架构即代码
	2.1 概述
	2.2 DevOps工具链
	2.3 收益
3. 持续交付
	3.1 从实践中学习
	3.2 自动化
	3.3 更频繁的部署
	3.4 持续交付的前提需求
	3.5 零停机部署
4. 协做
	4.1 混乱之墙
	4.2 软件开发流程
	4.3 共享工具
	4.4 协同工做
5. 结论

1. 简介

DevOps所关注的不是工具自己，也不是对chef或Docker的掌握程度。DevOps是一种方法论，是一系列能够帮助开发者和运维人员在实现各自目标（Goal）的前提下，向本身的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于：虽然都是企业中大型IT部门不可或缺的，但他们有着大相径庭的目的（Objective）。

开发者和运维人员之间目的上的差别就叫作混乱之墙。下文会介绍这个概念的准肯定义，以及为何我认为这种情况很严峻而且很糟糕。

DevOps是一种融合了一系列基本原则和实践的方法论（并从这些实践中派生出了各类工具），意在帮助这些人员向着一个统一的共同目的努力：尽量为公司提供更多价值。

使人惊奇的是，这个问题居然有一个很是简单的“银子弹”：让生产端变得敏捷起来！

而这偏偏正是DevOps所要达成的惟一目标！

但在进一步讨论这一点以前，首先须要谈谈其余几件事。

1.1 管理信条

IT管理这场战争的原动力究竟是什么？换句话说，在软件开发项目中，管理工做首要的，以及最重要的目的是什么？

有什么想法吗？

我来提供一个线索吧：在创建一家初创公司时，最重要的事情是什么？

固然是要加快上市时间（TTM）！

上市时间（即TTM）是指一件产品从最初的构思到最终可供用户使用或购买这一过程所须要的时间。对于产品很快会过期的行业，TTM是一个很是重要的概念。

在软件工程方面，所采用的方法、业务，以及具体技术几乎每一年都会变化，于是TTM就成了一个很是重要的KPI（关键绩效指标）。

TTM一般也会被叫作前置时间（Lead Time）。

第一个问题在于，（不少人认为）在开发过程当中TTM和产品质量是两个对立的属性。在下文能够看到，改善质量（进而提升稳定性）是运维人员的目的，而开发者的目的在于下降前置时间（进而提升TTM）。

请容我来解释一下。

IT组织或部门一般会经过两个关键的KPI进行评估：软件自己的质量，于是须要尽量减小缺陷的数量；此外还有TTM，于是须要将业务构想（一般由业务用户提供）变为最终成果，并以尽量快的速度提供给用户或客户。

这里的问题在于，大部分状况下这两个大相径庭的目的是由两个不一样团队提供支持的：负责构建软件的开发者，以及负责运行软件的运维人员。

1.2 一个典型的IT组织

在组织内部负责管理重要IT部门的典型IT组织一般看起来是这样的：

主要因为历史的缘由（大部分运维人员来自硬件和电信业务领域），运维人员和开发者分属不一样的组织结构分支。开发者属于研发部门，而运维人员大部分时候属于基础架构部门（或专门的运维部门）。

别忘了，他们有着不一样的目的：

此外做为旁注，这两个团队有时候会使用不一样的预算来运营。开发团队使用构建（Build）预算，运维团队使用运营（Run）预算。不一样的预算，对控制权愈来愈高的需求，以及企业IT成本的缩水，这些因素结合在一块儿会进一步放大两个团队各自目的的对立性。

（依本人愚见，时至今日，随着人与人之间无时无刻随时随地进行的交互，以及由不一样目的推进着企业和社会进行数字化转型，IT预算方面古老的“规划/构建/运行”框架已经不那么合理了，不过这又是另外一回事了。）

1.3 运维人员测挫败感

接下来看看运维人员，一块儿看看典型的运维团队把大部分时间都花在哪里了：

（来源：Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

生产团队有将近一半（47%）的时间花在了与部署有关的工做中：

• 执行实际的部署工做，或
• 修复与部署工做有关的问题

这样的KPI其实至关疯狂，但实际上咱们早就应该采纳。实际上早在40年前，计算机科学的“原始时代”就已涌现出运维团队，当时计算机主要运用在工业界，运维人员须要手工运行大量命令来执行本身的任务。为了履行职责，他们已经习惯于按照清单运行各类各样的命令或手工流程。

忽然有一天他们终于意识到本身“总在作着相同的事情”，然而长达四十多年的工做过程当中却几乎没人考虑过变革。

考虑到这一点你会发现，实在是太疯狂了。平均来讲，运维人员将近一半的时间都在处理与部署有关的任务！

为了改变这种情况，必须考虑到两个最关键的需求：

1. 经过自动化部署将目前这种手工任务所需的时间减小31%。
2. 经过产业化措施（相似于经过XP和敏捷实现的软件开发产业化）将须要处理的与这些部署有关的问题减小16%。

1.4 基础架构自动化

在这方面也有一个至关富有启发性的统计结果：

以手工操做的数量所表示的成功部署几率。

这些统计告诉咱们：

• 只需手工运行5条命令的状况下，成功部署的几率就已跌至86%。
• 如需手工运行55条命令，成功部署的几率将跌至22%。
• 如需手工运行100条命令，成功部署的几率将趋近于0（仅2%）！

成功部署意味着软件可以按照预期在生产环境中运行。未能成功部署意味着有东西出错，可能须要进行必要的分析才能了解部署过程当中哪里出错，是否须要应用某种补丁，或须要修改某些配置。

所以让这一切实现自动化并不惜一切代价避免手工操做彷佛是个好主意，对吧？

那么行业里这方面的现状是怎样的：

（来源：IT Ops & DevOps Productivity Report 2013 - Rebellabs ）

（说实话，这个统计信息比较老了，是2013年的结果，相信如今的结果会有所不一样）

然而这也可让咱们明确的知道，在基础架构自动化方面咱们还有多远的路要走，而且DevOps的基本原则和实践依然是那么的重要。

网络巨头们固然会经过新的方法和实践及时知足本身的需求，他们早已开始构建本身的工程业务，而正是他们所确立的实践逐渐衍生出当今咱们所熟悉的DevOps。

看看这些网络巨头们在这方面目前所处的位置吧，举几个例子：

• Facebook有数千名开发和运维人员，成千上万台服务器。平均来讲一位运维人员负责500台服务器（还认为自动化是可选的吗？）他们天天部署两次（环式部署，Deployment ring的概念）。
• Flickr天天部署10次。
• Netflix明确针对失败进行各类设计！他们的软件按照设计从最底层便可容忍系统失败，他们会在生产环境中进行全面的测试：天天经过随机关闭虚拟机的方式在生产环境中执行65000次失败测试…… 并确保这种状况下一切依然能够正常工做。

他们这种作法秘密何在？

1.5 DevOps：仅此一次，一颗神奇的银子弹

他们的秘密很简单：将敏捷扩展至生产端：

DevOps的共存主要是为了扩展敏捷开发实践，进一步完善软件变动在构建、验证、部署、交付等阶段中的流动，同时经过软件应用程序的全面全部权予力跨职能团队完成从设计到生产支持等各环节的工做。

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协做、集成和自动化，借此有助于改善双方在交付软件过程当中的速度和质量。

DevOps团队更侧重于经过标准化开发环境和自动化交付流程改善交付工做的可预测性、效率、安全性，以及可维护性。理想状况下，DevOps能够为开发者提供更可控的生产环境，帮助他们更好地理解生产基础架构。

DevOps鼓励团队自主进行本身应用程序的构建、验证、交付和支持。

那么核心原则究竟是什么？

下文将介绍最重要的三大基本原则。

2. 基础架构即代码

人总会犯错，由于人脑实在是不擅长处理重复性的任务，相比Shell脚本，人类的速度实在是太慢了。毕竟咱们都是人类，所以有必要像处理代码那样考虑和处理有关基础架构的概念！

基础架构即代码（IaC）是大部分通用DevOps实践的前提要求，例如版本控制、代码审阅、持续集成、自动化测试。这一律念涉及计算基础架构（容器、虚拟机、物理机、软件安装等）的管理和供应，以及经过机器可处理的定义文件或脚本对其进行的配置，交互式配置工具和手工命令的使用已经不合时宜了。

这一原则对DevOps的重要性怎么强调都不为过，它能够真正将软件开发相关的实践应用给服务器和基础架构。

云计算使得复杂的IT部署能够继续效仿传统物理拓扑。咱们能够相对轻松地对复杂虚拟网络、存储和服务器的构建实现自动化。服务器环境的方方面面，上至基础架构下至操做系统设置，都可编码并存储至版本控制仓库。

2.1 概述

以很是归纳的方式来看，基础架构和运维所需实现的自动化程度可经过下图这种架构来表示：

上述架构图中做为示例的工具主要面向不一样层的构建工做，实际上DevOps工具链的做用远不止如此。

我以为在这里能够略微深刻地谈谈DevOps的工具链了。

2.2 DevOps工具链

DevOps实际是一种文化上的变迁，表明了开发、运维、测试等环节之间的协做，所以DevOps工具是很是多种多样的，甚至能够由多种工具组成一个完整的DevOps工具链。此类工具能够应用于一种或多种类别，并可体现出软件开发和交付过程的不一样阶段：

• 编码：代码开发和审阅，版本控制工具、代码合并工具
• 构建：持续集成工具、构建状态统计工具
• 测试：经过测试和结果肯定绩效的工具
• 打包：成品仓库、应用程序部署前暂存
• 发布：变动管理、发布审批、发布自动化
• 配置：基础架构配置和部署，基础架构即代码工具
• 监视：应用程序性能监视、最终用户体验

虽然可用工具备不少，但其中一些环节是组织内部应用DevOps工具链不可或缺的。

诸如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等经常使用、普遍使用的工具都是2016年的DevOps热门工具。

基础架构组件的版本控制、持续集成和自动化测试

基础架构的版本控制能力（而非基础架构的构建脚本或配置文件）及对其进行自动化测试的能力极其重要。

DevOps最终会将30年前软件工程领域所采用的同一套XP实践带至生产端。

此外基础架构元素应该能向软件交付物同样进行持续集成。

2.3 收益

DevOps的收益有不少，包括但不限于：

• 可重复性与可靠性：时至今日，构建生产用计算机只须要运行脚本或必要的puppet命令便可。经过恰当地使用Docker容器或Vagrant虚拟机，只需运行一条命令便可配置好包含操做系统层以及所需软件和配置的生产用计算机。固然，随着各类变动或软件开发、持续集成，并自动测试，这套构建脚本或机制也会进行持续集成。

  最终幸好有了XP或敏捷，咱们在软件开发端所使用的同一套实践也能让运维端获益。

• 生产力：一键部署，一键供应，一键建立新环境……整个生产环境能够经过一条命令或一键点击的方式建立。这样的一条命令也许会运行长达数小时，但在这过程当中运维人员能够从事其余更有趣的工做，而无需等待一条命令执行完毕后继续输入下一条命令，毕竟这样的过程有时候可能须要花费几天时间才能完成……
• 恢复时间！：一键点击便可恢复生产环境，就是这么简单。
• 确保基础架构的同质：完全避免运维人员每次构建环境或安装软件时最终得到的结果与预期有所差别，这是确保基础架构绝对同质（Homogeneous）而且可再现的惟一可行方法。以此为基础，经过对脚本或Puppet配置文件使用版本控制机制，咱们甚至能够重建出与上周、上个月，或软件特定版本发布时彻底一致的生产环境。
• 维持整齐划一的标准：基础架构标准甚至能够不复存在，代码自己就是标准。
• 让开发者自行完成大部分工做：若是开发者本身忽然能够在本身的基础架构上一键点击重建生产环境，他们也就能够自行完成不少与生产环境有关的任务，例如更好地理解生产失败，提供更恰当的配置，实现部署脚本等。

这只是我我的感受IaC可提供的部分收益，相信还有不少其余收益。

3. 持续交付

持续交付是一种能够帮助团队以更短的周期交付软件的方法，该方法确保了团队能够在任什么时候间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

经过对生产环境中的应用程序进行更高频次的增量更新，这种方法有助于下降交付变动过程当中涉及的成本、时间和风险。足够简单直接而且可重复的部署流程对持续交付而言相当重要。

注意：持续交付 ≠ 持续部署 - 有时候不少人会把持续交付误认为成持续部署。持续部署是指每一个变动能够自动部署到生产环境。持续交付是指团队确保每一个变动能够部署至生产环境，但也许并不须要实际部署，这一般多是出于业务方面的缘由。只有成功实现持续交付的前提下，才能进行持续部署。

持续交付的主要想法在于：

• 部署越频繁，对部署流程就会越熟悉，自动化机制就能得到更好的结果。若是同一件事天天须要执行3次，很快你将变的无比娴熟，但很快也会由于日复一日解决一样的问题而感到厌烦。
• 部署越频繁，所部属的变动集就越微不足道，而这些微不足道的内容最有可能出错，甚至可能致使丢失对整个变动集的控制力。
• 部署越频繁，TTR（修复／解决所需时间）指标就会越出色，从业务用户处得到有关功能的各种反馈的速度越快，做出改进以便完美知足对方需求的过程也会越简单（这方面TTR与TTM其实很是类似）。

（来源：Ops Meta-Metrics: The Currency You Pay For Change ）

但持续交付并不只仅是尽量频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践：

• 从实践中学习
• 自动化
• 更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中，而在于业务用户中。然而不管花多长时间，没人能真正清楚地表达本身的想法，或者将本身的想法用清晰的文档归纳出来。也正是所以，敏捷方法论强调将功能提供给用户，并不惜一切代价从用户处得到尽量多的反馈。

持续交付与持续部署相似，须要尽量减小前置时间，这也是尽快从用户处得到“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。咱们毫不能尽信本身的用户或寄但愿于经过正规形式的反馈了解用户。咱们只能相信本身的度量。

痴迷于度量是精益创业（Lean Startup）活动中一个重要的概念，但这一律念对DevOps一样重要。咱们应该度量一切！肯定最恰当的度量指标可让团队了解某种方法最终可否成功或失败，了解怎样作能够得到更好的结果，以及哪些最成功的作法同时也蕴含着必定的风险。为了帮助团队作出更明智的决策，在肯定要衡量的指标时，必定要抱着“宁多勿少”的原则。

不须要“考虑”，只须要“知道”！“知道”的惟一方法就是度量，度量一切：响应时间、用户思考时间、展现次数、API调用次数、点击率等，但这些并不是须要度量的所有。找出全部能让你更进一步了解用户对功能见解的度量指标，对全部这些指标进行度量！

这种方法能够表示为以下形式：

3.2 自动化

自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是，在没有将与基础架构有关的全部供应和任务实现妥善、全面的自动化以前，持续交付根本无从谈起。

这一点很重要，所以有必要再重复一遍：环境的搭建和生产就绪版本软件的部署只须要一键点击，只须要运行一条命令，整个过程应该自动完成。不然根本没法设想能一天屡次部署同一个软件。

在下文的3.5 零停机部署一节中，还将介绍有助于自动化交付的其余重要技术。

3.3 更频繁的部署

DevOps的信条在于：

“越是困难的事，须要更频繁地进行！”

敏捷思惟中，困难任务更要迎难而上，更频繁地去作，这中想法很是重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 全部这些活动都要尽量频繁地进行。

缘由主要有三点：

1. 首先，随着要作的工做量逐渐增长，这些任务也会变的越发困难，但若是能拆解为小块，则会变的相对容易些。

   以数据库迁移为例：一些涉及大量表的大规模数据库迁移工做很麻烦，容易出错。但若是一次只迁移一部分，则能够相对较容易地成功完成整个迁移任务。此外还能够轻松地将多个小规模的迁移任务安排成必定的序列，在将一个艰难的大任务拆解为一系列容易实现的小目标后，处理起来就简单多了。（这也是数据库重构的本质）

2. 第二个缘由在于反馈。大部分敏捷思惟关注的是设置反馈环路，借此让咱们更快速地学习了解。反馈已是极限编程（Extreme Programming）中一个很是重要，蕴含巨大价值的概念。在诸如软件开发等复杂流程中，咱们须要更频繁地检查本身的最新进展，并进行必要的纠正。为此咱们必须尽一切可能建立反馈环路，并提升反馈的频率，这样才能更快速地酌情作出调整。
3. 第三个缘由是实践。对于任何活动，越频繁地从事就越能得到完善。实践能够帮助咱们理清整个流程，让咱们更熟悉表明有事情出错的征兆。只要认真琢磨本身从事的工做，就能提炼出近一步完善所需的实践。

   对于软件开发，也有可能实现必定程度的自动化。一旦有人将某件事作了屡次，就能够更容易地肯定该如何进行自动化，更重要的是，这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤其重要，由于能够加快速度并下降出错的几率。

那么这就产生了一个问题：使用DevOps方法时，该选择怎样的交付频率？

这个问题没有标准答案，而是取决于产品、团队、市场、公司、用户、运维需求等各类因素。

我认为最佳答案应该是：若是不能实现至少每两周一次交付，或在冲刺阶段结束时交付，那么连敏捷都谈不上，DevOps又从何谈起呢？

DevOps鼓励咱们尽量频繁的交付。在我看来，你须要对团队进行培训，让他们可以作到尽量频繁的交付。我在个人团队中使用的一种较为可行的方法是在QA环境中天天交付两次。交付过程是彻底自动化的：天天两次，中午和午夜各一次，计算机启动起来，构建软件组件，运行集成测试，构建并启动虚拟机，部署软件组件，对其进行配置，运行功能测试等。

3.4 持续交付的前提需求

在改成使用持续交付方式以前，须要知足哪些要求？

我草拟的需求清单以下：

• 对软件组件的开发和平台的供应和设置进行持续集成。
• TDD - 测试驱动的开发。这一点还有待商榷……但始终仍是须要面对：TDD是目前惟一能经过单元测试对代码和分支进行可接受程度覆盖的方法（单元测试使得问题的修复过程比集成测试或功能测试容易不少）。
• 代码审阅！至少要进行代码审阅……若是能进行结对编程（Pair programming）固然就更好了。
• 软件的持续审计 - 例如使用Sonar。
• 在生产级环境实现功能测试的自动化。
• 更强大的非功能测试自动化（性能、可用性等）。
• 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时，还须要具有健全的软件开发实践，例如零停机部署技术。

3.5 零停机部署

“零停机部署（ZDD）可在不中断现有服务的状况下部署新版系统。”

经过ZDD方式部署应用程序时，可在确保用户不会遭遇应用程序停机的前提下将新版应用引入生产环境。从用户和公司的角度来看，这应该是最佳部署方式，由于能够在不形成任何中断的状况下引入新功能并修复Bug。

下文将介绍4种技术：

1. 功能开关（Feature Flipping）
2. 摸黑启动（Dark launch）
3. 蓝／绿部署（Blue/Green Deployment）
4. 金丝雀发布（Canari release）

功能开关

功能开关可供咱们在软件运行过程当中启用／禁用相应的功能。这种技术其实很是容易理解和使用：为生产版本提供一个能完全禁用某项功能的配置，并只在对应功能完全完工能够正常工做后才将该属性激活。

举例来讲，若要将某个应用程序内的一个功能全局禁用或激活：

if Feature.isEnabled('new_awesome_feature')
    # Do something new, cool and awesome
else 
    # Do old, same as always stuff
end

或者若是要真对具体用户实现相似目的：

if Feature.isEnabled('new_awesome_feature', current_user)
    # Do something new, cool and awesome
else 
    # Do old, same as always stuff
end 

摸黑启动

摸黑启动的目的在于经过生产环境进行负载模拟！

在测试环境中，一般很难为软件模拟出成百上千万用户规模的负载。

若是不进行切实的负载测试，就没法知道基础架构可否承受住最终面临的压力。

此时并不须要模拟负载，而是能够实际部署这样的功能，而后看看在不影响可用性的前提下到底会发生什么。

Facebook将这种作法称之为功能的“摸黑启动”。

假设咱们要将一个有5亿用户使用的静态搜索字段变成一个包含自动补全功能的字段，借此让用户能够更快速得到搜索结果。为该功能构建一个Web服务，而且但愿模拟全部用户同时输入文字，向该Web服务生成大量请求的场景。

此时便可经过摸黑启动策略为现有表单添加一个隐藏的后台进程，经过该进程将输入的搜索关键字发送给新增的自动补全服务，并自动发送屡次。

就算新增的Web服务完全崩溃了，也不会形成任何实质损害。网页上能够彻底忽略服务器错误。而就算该服务崩溃了，咱们至少还能够对该服务进行优化和完善，直到能承受如此大量的负载。

这就等于在现实世界中进行了一次负载测试。

蓝／绿部署

蓝／绿部署是指为下一版产品构建另外一个完整的生产环境。开发和运维团队能够在这个单独的生产环境中放心地构建下一版产品。

当下一版产品所有完成后，能够修改负载均衡器的配置，以透明的方式将用户自动重定向至新发布的下一版。

随后可将上一版的生产环境回收，用于构建下下一版的产品。

以此类推。

（来源：Les Patterns des Géants du Web – Zero Downtime Deployment ）

这是一种至关有效简单的方法，但问题在于这种方式须要双倍的基础架构以及更多的服务器等。

假设一下Facebook但愿将包含成千上万台服务器的环境“照原样再来一套”……

其实还有更好的方法。

金丝雀发布

从本质来看，金丝雀发布与蓝／绿部署很是相似，但无需准备额外的一套生产环境。

这种方式的目标在于以增量的方式将用户切换至新版本：随着愈来愈多的服务器从当前版本迁移至下一版，相同比例的用户也会被同时迁移。

经过这种方式，每一个生产环境都能得到与负载需求相匹配的服务器数量。

首先，只将少许服务器和少部分用户迁移至下一版，借此还能够在无须冒险影响全部用户的前提下对新版进行测试。

当全部服务器最终从当前版迁移至下一版后，发布工做已经完成，又能够从头开始准备下下一版了。

（来源：Les Patterns des Géants du Web – Zero Downtime Deployment ）

4. 协做

敏捷软件开发破除了需求分析、测试和开发之间的一些隔阂。部署、运维和维护等其余活动与软件开发过程当中的其余环节也存在相似的分隔。DevOps方法意在破除全部这些隔阂，鼓励开发和运维人员之间的协做。

若是没有培养出正确的文化，就算有最棒的工具，DevOps对你而言也不过是另外一个热门词汇罢了。

DevOps文化的主要特征在于开发和运维角色之间日益增长的协做。这是一种在团队内部以及组织层面上很重要的文化变迁，经过这样的变迁才能促进更好的协做。

这种方式解决了一个很是重要的问题，而这个问题彻底能够用下面这个网络流行话来体现：

（来源：DevOps Memes @ EMCworld 2015 ）

团队合做对DevOps是如此的重要，大部分方法论所要实现的最终目标总的来讲能够经过两个C来实现：协做（Collaboration）和沟通（Communication）。虽然单纯作到这些距离真正的DevOps工做环境还有很大的差距，但任何公司只要能坚持这两个C，就等于迈出了最正确的第一步。

但为何会那么难作到？

4.1 混乱之墙

由于有一堵混乱之墙：

在传统开发周期中，开发团队将新发布的软件“隔墙扔给”运维人员，意味着本身的工做已经顺利完成。

运维人员接手开发者的成果，准备开始进行部署。运维人员手工修改由开发者提供的部署脚本，固然更多时候这些脚本都是运维人员本身维护的。

运维人员还须要手工修改配置文件，以反映生产环境的需求，而生产环境每每与开发或QA环境有很大差别。

就算最理想的状况，运维人员可能只是作了一些在上一个环境中已经作过的重复工做，而最糟糕的状况，可能会引入或发现新的Bug。

随后IT运维团队开始讨论他们所认为的，目前最正确的部署流程，然而因为开发和运维在脚本、配置、流程，甚至环境等方面的差别，基本上等同于要从零开始将全部工做从新执行一遍。

固然这一过程当中不可避免会遇到问题，他们联系开发者但愿进行排错。运维称开发者提供的代码自己有问题，开发者则回应称代码在本身的环境中一切正常，所以错误确定源自运维端。

因为配置、文件位置，以及面临这种状态所执行的操做与本身的预期等因素存在较大差别，开发者甚至很难对这样的问题进行诊断。变动窗口留下的时间所剩无几，固然也没什么足够靠谱的方法将环境回滚至上一个正常状态。

那么本来应该一路顺风的部署过程，为何最后却变成了“众志成城”的应急演习？必须经历大量指责和错误才能最终让生产环境恢复可用状态？

这种状况常常发生，常常！

DevOps来救场了

经过在共同的业务目的情境中让开发和运维角色与流程变的一致，DevOps有助于促进IT的统一。开发和运维都须要明确，本身是统一业务流程的一份子。DevOps思惟确保了不管组织结构是怎样的，个体决策与行为须要尽力为统一的业务流程提供支持和促进做用。

亚马逊CTOWerner Vogel甚至在2014年说过：

“谁开发，谁运行。”

4.2 软件开发流程

下图简要描述了敏捷软件开发流程一般的样子。

最开始，业务表明与产品负责人以及架构团队合做定义软件，这一过程可能会使用Story Mapping和用户故事，或者使用更完整的规范。

随后开发团队经过短暂的开发冲刺开发出软件，并在每一个冲刺结束后将生产就绪版本的软件发布给业务用户，进而收集反馈并尽量频繁地调整方向。

最后，经历过每一个新的里程碑后，将软件部署给整个业务线更普遍的用户群体。

DevOps形成的最大挑战在于须要理解运维人员是软件的另外一个用户群体！所以他们也应该被全面归入软件开发流程中。

在预约的时间里，运维应该给出本身的非功能需求，就如同业务用户给出本身的功能需求同样。开发团队应该按照同等程度的重要性和优先级处理这种非功能需求。

在实现的过程当中，运维应该持续提供反馈和非功能测试规范，就像业务用户针对功能特性提供反馈同样。

最后，运维和业务用户同样，成为了软件的用户。

经过采用DevOps方法，运维能够全面融入软件开发流程中。

4.3 共享工具

在传统的大型企业中，运维团队和开发团队分别使用专用的，没有什么交集的工具集。

运维人员一般并不想了解开发团队所使用的SCM系统以及持续集成环境。他们认为这些并不是本身的本职工做，惧怕本身在触及这些系统后会被开发者的各类请求所淹没。毕竟他们为了照料生产系统就有忙不完的工做了。

另外一方面，开发者一般没法访问生产系统的日志和监视日志，有时这是由于没有这样的意愿，有时则是由于制度或安全方面的顾虑。

这种情况须要改变！DevOps应运而生。

这个目标其实很难实现。举例来讲，出于制度或安全方面的缘由，日志可能会被实时匿名化，同时须要对监管工具进行必要的保护，以免未经培训或本应被禁止的开发者更改生产环境的配置。所以实现这一目标须要付出大量时间和成本资源。但这样作所能得到的收益远大于所需进行的投入，这种方法对整个公司的投资回报很是明显。

4.4 协同工做

DevOps的一种基本哲学是认为，开发者和运维人员必须按期进行密切的合做。

这就意味着他们必须将对方视做重要的利益相关者，并积极主动地寻求合做。

受到XP实践中“现场客户”的启发，敏捷开发者受此激励能够与业务进行更紧密的合做，自律的敏捷者还能够更进一步将这样的实践运用给更普遍的利益相关者，例如可让开发者与全部其余相关者进行合做，包括运维和支持人员。

这是一条双行道：运维和支持人员也必须愿意与开发者进行密切的合做。

此外还能够经过协做：

• 让运维人员参与敏捷仪式（每日Scrum、冲刺规划、再次冲刺等）
• 让开发者参与生产环境的推出任务
• 在开发和运维之间打造统一的持续改进目标

5. 结论

DevOps是一次革命，主要是为了消除拥有大规模IT部门的大型企业中，开发团队和运维团队之间因为历史缘由产生的隔阂与孤立所形成的混乱现状。

在我15年的职业生涯中，2/3的时间就任于此类大行机构，其中大部分是金融机构，天天我都在见证者这堵混乱之墙的存在。例如我常常会听到这样的说法：

• “在个人Tomcat上工做很正常，很抱歉，但我彻底不懂你所用的Websphere，帮不上你了。”（开发者说）
• “咱们真的不能从生产数据库中给你提取这张表，里面包含了与客户有关的机密数据。”（运维人员说）

天天都会遇到其余不少相似的对话……每天如此！

好在DevOps日渐成熟，愈来愈多传统企业也在开始逐渐走上正途，开始接受DevOps的原则和实践。但还有不少企业无动于衷。

那么对于那些小规模的，开发和运维职能之间一般不会产生那么大分歧的企业呢？

这样的企业应用DevOps原则和实践，例如自动化部署、持续交付和功能开关，同样能获益匪浅。

我认为DevOps原则能够总结为：

DevOps其实是向着大规模敏捷（Scaling Agility）迈出的另外一步！

做者：Jerome Kehrli，阅读英文原文：DevOps explained