1.2 为什么是DevOps
从很多方面来讲，DevOps是对缓慢发布的问题做出的响应。发布投放到市场的时间越长，从中获得的功能或质量提升的收益就越低。理想情况下，我们希望持续发布。常常用术语持续交付或持续部署来表示。我们在第5章和第6章讨论这两个术语的细微差别。在本书中，我们使用术语持续部署，或部署。我们开始时先描述一个正式发布过程，然后深入探讨缓慢发布的一些原因。
1.2.1 发布过程
向客户发布新系统或现存系统的新版本是软件开发周期中最敏感的步骤。不论系统或版本是对外发布、直接由客户使用还是严格限定于内部使用，都是这种情况。只要系统有多于一个人使用，发布新版本就可能招致不兼容或失败，接下来就是客户的不满。
因此，各个组织在定义发布计划的过程上投入了大量精力。下面的发布计划步骤改编自维基百科。传统上，大部分步骤都是手工完成的。
1）与客户/干系人一起定义发布及部署计划并达成一致意见。可以在团队或组织层面完成。发布或部署计划应该包括那些纳入新发布的功能，并确保运维人员（包括帮助台及支持人员）知晓日程安排，资源需求得到满足，并安排所需的各种附加培训。
2）确保每个发布包包含的一组相关资产与服务组件之间是相互兼容的。随着时间的推移，包括库、平台和依赖服务在内的各种东西都会发生变化。变化可能会引入不兼容。这个步骤是为了防止不兼容性在部署之后才显现出来。第5章讨论确保这些兼容性的方法。管理依赖关系是贯穿全书反复出现的一个主题。
3）确保在整个转换活动期间都能保持发布包及组件的完整性并在配置管理系统中准确记录。这个步骤包括两部分：首先，确保组件的旧版本不会无意间被纳入发布中；其次，确保保留此次部署的组件的记录。知道此次部署了哪些要素对于部署后追踪发现的错误是很重要的。我们将在第6章讨论部署的细节。
4）确保所有发布包和部署包都能追踪、安装、测试、验证，以及卸载或者在需要时能够回滚。部署的内容在很多情况下可能需要回滚（卸载新版本、重新部署旧版本），例如代码中存在错误、资源不足、许可证或证书过期。
这个清单中列举的活动可以以不同程度的自动化方式实现。如果所有这些活动都主要是通过人工配合完成，那么这些步骤很费力、耗时并且容易出错。任何自动化活动都反映了团队或组织层面对发布过程的一致性理解。因为工具一般都不止一次地使用，所以将对发布过程的一致性理解嵌入工具中会使得这种一致性在多个发布中都是持久维系的。
正确的发布是一件严肃的事情，如果你不想重视它，可以想想这几个媒体报道过的引起了重大财务损失的事件。
2012年8月1日，骑士资本集团（Knight Capital）升级失败，造成4.4亿美元的损失。
2013年8月20日，高盛集团（Goldman Sachs）升级失败，潜在地可能造成数百万美元的损失。
因为升级失败而导致宕机或故障的例子有很多，这只是其中的两个。在一个组织中，正确的部署升级是大型且重要的活动，并且这种活动应该快速完成，并将出错概率降到最低。有几个组织调查了部署的问题。我们报告其中的两个：
XebiaLabs是一个销售部署工具和持续集成工具的组织。在他们2013年做的一项调查中，有130多位被调查者做出了回应。这些被调查者有34%来自IT服务公司，健康、财务服务和电信公司的各占10%。7.5%的被调查者报告说他们的部署过程“不可信赖”，57.5%的人报告说他们的部署过程“需要改进”。49%的人报告说在部署过程中最大的挑战是“在不同环境和应用程序中不一致的地方太多”。32.5%的人报告说“错误太多”。29.2%的人报告说他们的部署依赖于定制的脚本，35.8%的人报告说他们的部署是部分脚本、部分手工的。
CA科技公司为客户提供IT管理解决方案。他们在2013年做了一项调查，有1300人做出了回应，这些人所在公司的收入超过1亿美元。在那些说是看到了采用DevOps带来的收益的人中，53%的人说他们已经看到软件和服务的部署频率增加，41%的人说他们预计部署频率会增加。42%的被调查者说他们看到部署应用程序的质量提升了，49%的人说他们预计质量会提升。
推广自动化部署是发起这两个调查的组织的利益所在，即使这样，他们也清楚地说明了不同市场的很多公司都在关注部署速度和质量。
1.2.2 配合不佳的原因
考虑在开发团队完成系统的所有编码和测试之后发生的事情。系统需要放入满足以下条件的生产环境中：
只有适当的人才能访问它。
系统与生产环境中交互的所有其他系统都兼容。
有足够的资源满足系统的运行。
用于运行的数据是最新的。
系统生成的数据可以由生产环境中的其他系统使用。
此外，帮助台支持人员需要就新系统的功能接受培训，运维人员需要就如何排除系统运行中出现的问题而接受培训。发布时机可能也很关键，因为发布时运维人员的关键人员不能缺席，时间上也不能和需要使用现有资源的新的促销活动重合。
这些都不是在不经意间发生的，每一项工作都需要开发人员和运维人员之间的配合。如果开发人员和运维人员不就这些项目中的一个或多个进行沟通，不难想象会出现什么情况。开发人员的一种常见的态度是“做完了开发，程序可以跑起来了”。我们在讨论采用DevOps的文化障碍时会探讨这种态度产生的原因。
组织中都有一套过程确保发布过程顺利，其中一个原因是协作配合并不总能以适当的方式进行。这种不满是推动DevOps发展的一个驱动力。
1.2.3 运维人员能力有限
运维人员要做很多工作，但是他们能够完成什么或者他们当中谁对什么系统比较熟悉，这方面是存在不足的。考虑一下像维基百科中详细描述的现代运维人员的职责。
分析系统日志，识别计算机系统潜在的问题。
在现有的数据中心环境中引入并集成新技术。
执行系统及软件的例行审计。
执行备份。
对操作系统进行更新、补丁升级和配置更改。
安装并配置新的硬件和软件。
增加、删除或更新用户账号信息；重置密码等。
回答技术问题并帮助用户。
确保安全。
用文档记录系统的配置信息。
解决所有报告的问题。
优化系统性能。
确保网络基础设施启动和运行。
配置、增加及删除文件系统。
学习卷管理工具的知识，如Veritas（即现在的Symantec）、Solaris ZFS、LVM等。
每一项工作都需要深入理解。难怪我们在问一个因特网公司的IT总裁他最大的问题是什么时，他回答说“找到并留住合格的人”。
DevOps运动采用一种不同的方法。它们的方法把以前由运维人员完成的很多任务都自动化了，并让开发人员承担部分剩余的工作，通过这种方法，可以减少对专业运维人员的需求。
