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 运维人员测挫败感
接下来看看运维人员，一起看看典型的运维团队把大部分时间都花在哪里了：
生产团队有将近一半（47%）的时间花在了与部署有关的工作中：
- 执行实际的部署工作，或
- 修复与部署工作有关的问题
这样的KPI其实相当疯狂，但实际上我们早就应该采纳。实际上早在40年前，计算机科学的“原始时代”就已涌现出运维团队，当时计算机主要运用在工业界，运维人员需要手工运行大量命令来执行自己的任务。为了履行职责，他们已经习惯于按照清单运行各种各样的命令或手工流程。
突然有一天他们终于意识到自己“总在做着相同的事情”，然而长达四十多年的工作过程中却几乎没人考虑过变革。
考虑到这一点你会发现，实在是太疯狂了。平均来说，运维人员将近一半的时间都在处理与部署有关的任务！
为了改变这种状况，必须考虑到两个最关键的需求：
- 通过自动化部署将目前这种手工任务所需的时间减少31%。
- 通过产业化措施（类似于通过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次失败测试…… 并确保这种情况下一切依然可以正常工作。
他们这种做法秘密何在？
