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年前，计算机科学的“原始时代”就已涌现出运维团队，当时计算机主要运用在工业界，运维人员须要手工运行大量命令来执行本身的任务。为了履行职责，他们已经习惯于按照清单运行各类各样的命令或手工流程。

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

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

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

1. 经过自动化部署将目前这种手工任务所需的时间减小31%。
2. 经过产业化措施（相似于经过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鼓励团队自主进行本身应用程序的构建、验证、交付和支持。