1.1 DevOps在企业中存在的意义

DevOps如今的兴起与最近两年云计算的快速普及有很大的关系：在云计算平台上，各种资源，从服务器到网络、负载均衡都是有API可以创建和操作的，这就意味着所有的资源都是可以用“软件定义”的，这就为各种自动化运维工具提供了一个非常好的基础环境。

事实上，需要频繁交付的公司或企业更应该具有DevOps能力，大量的互联网在线应用需要根据用户的反馈随时进行迭代开发，持续改进用户体验，这就需要内部支撑部门（一般是运维开发部门）提供每天几十次乃至上百次的从测试环境发布到线上环境的持续发布能力，这种能力称为持续集成（CI）。如下几个因素更加促进了DevOps的发展。

❑ 虚拟化和云计算基础设施的日益普及。

❑ 业务负责人要求加快产品交付的速度。

❑ 数据中心自动化配置管理工具的普及。

DevOps是一个完整的、面向IT运维的工作流，其以IT自动化以及持续集成（CI）、持续部署（CD）为基础，用于优化程序开发、测试、系统运维等所有环节。DevOps一词来自于Development和Operations的组合，尤其重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps可用于填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维，如图1-1所示。

我们可以将传统运维的一种极端情况描述为“黑盒运维”。在这种文化中，运维与开发是分开的，相互之间一般不进行合作，就算要合作，也是极不情愿的。“黑盒运维”的特点是开发和运维的目标是相反的。开发团队的任务是为产品增加新功能、不断升级产品，并以此制定绩效；运维团队的目标则是稳定第一。如果没有进行足够的沟通和交流，那么两个团队必然会产生矛盾，当开发人员兴致勃勃地快速开发新功能的时候，运维人员可不情愿部署新功能。对稳定系统实施任何类型的变更，都会导致系统产生隐患，因此运维人员会尽可能地避免变更。这里举个例子说明一下，应用开发人员提交的代码中有一个Bug，在特定的边界条件下该Bug会导致无限循环，而QA和测试人员均没有发现这个问题。如果运维人员部署了这个变更，则会导致一些服务器CPU使用率飙升至100%，造成服务不稳定。如果运维人员不去实施变更，那么就不会发生问题，至少是没有新的问题。这就是最左边传统运维的理念。如果我们在这个工作流中引入DevOps，那么在这里开发和运维是同一个角色。这时，开发就是运维，运维就是开发，团队的共同目标是既要增加新特性，又要确保一定程度的可靠性。所以我们实施DevOps就会更加容易，利益也更加明确，结果也是可以预期的。

换句话说，DevOps希望做到的是打通软件产品交付过程中的IT工具链，它的核心理念在于生产团队（研发、运维和QA）之间的高效沟通和协作，使得各个团队减少时间损耗，从而更加高效地协同工作。

DevOps早在九年前就已有人提出来，但是，为什么近两年才开始受到越来越多企业的重视和实践呢？因为DevOps的发展是独木不成林的，现在具备了越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力的提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

那么DevOps的好处是什么呢？

DevOps的一个巨大的好处就是可以高效地交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment（DORA）主办了2016年DevOps调查报告，根据全球4600位来自各IT公司的技术工作者的提交数据统计，可以得知，高效公司平均每年可以完成1460次部署。

与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在规划或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅是指公司产出的效率得到了提高，还指员工的工作质量得到了提升。

DevOps的另外一个好处就是其还能改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。

快速部署同时还能提高IT稳定性。可能有读者会问，这难道不是矛盾的吗？

快速部署其实可以帮助团队更快地发现问题，产品被更快地交付到用户手中，团队就可以更快地得到用户的反馈，从而更快地响应。而且，DevOps小步快跑的形式所带来的变化也是比较小的，出现问题的偏差每次都不会太大，修复起来相对也会容易一些。因此，认为速度就意味着危险是一种偏见。此外，滞后软件服务的发布也并不一定能够完全地避免问题，在竞争日益激烈的IT行业，这反而可能会错失了软件的发布时机。

DevOps会持续流行下去的原因主要有两点，具体如下。

1）条件成熟：技术配套发展。

技术的发展使得DevOps有了更多的配合和技术支撑。早期的时候，大家虽然也意识到了这个问题，但是苦于当时没有完善、丰富的技术工具支持，处于一种“理想很丰满，但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术；也可以进行自动化运维工具Puppet、SaltStack、Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。

2）来自团队的内在动力：工程师也需要。

对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”（You build it, you run it）。

另外，很多时候，我们都必须得关注CI/CD（持续集成/持续部署）。

持续集成（Continuous Integration, CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，这也意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽早地发现集成错误。

持续部署（Continuous Deployment, CD）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。这在某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，使得engineering productivity最大化。

在很多企业或公司里面，这部分的工作都会交付给DevOps人员来具体实施。

自动化运维（即自动化配置管理）在某种程序上应该隶属于DevOps，为什么这么说呢？DevOps的范围应该很大，其包含但不局限于自动化运维，但由于自动化运维在公司的业务比重很大（至少在笔者的CDN公司，由于业务的原因，绝大多数DevOps工作需求其实都是自动化配置管理的），所以很多时候大家提到DevOps时就想到了自动化运维。