DevOps的概念

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

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组织

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

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

此外作为旁注，这两个团队有时候会使用不同的预算来运营。开发团队使用构建（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年前，计算机科学的“原始时代”就已涌现出运维团队，当时计算机主要运用在工业界，运维人员需要手工运行大量命令来执行自己的任务。为了履行职责，他们已经习惯于按照清单运行各种各样的命令或手工流程。

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

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

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

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

1.4 基础架构自动化

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

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

因此让这一切实现自动化并不惜一切代价避免手工操作似乎是个好主意，对吧？

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

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

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

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

他们这种做法秘密何在？

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

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

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

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

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