DevOps是什么

这个问题已经可以通过DevOps（开发运维）来解决。通过把开发和运维二者合并成一个团队，使知识和技能得以分享，工作方法得以匹配。这对服务管理过程应该如何组织有重大影响。然而，其优势在于既可以频繁地发布，又有高度的控制能力。DevOps并不像 ITIL那样有一个明确的统一定义或概念。比如，Gartner识别了6种不同的DevOps流程，每种流程对于DevOps都有着不同的解释。

DevOps的公共特性

虽然DevOps没有统一的定义，但是从这些不同的流程中，我们可以找到一些共同的特点，这些特点描述了如何使用DevOps。

人员

文化、行为、开发、合作、可扩展性和亲和力是DevOps的主要内容。

方法

DevOps的一个重要方面是敏捷化思考和工作，无论是敏捷Scrum、看板还是其他敏捷形式，而且，精益思想和持续改善也出现在各种DevOps出版物中。

资源

资源方面主要强调产品的生产方式，比如版本控制、集成、部署和交付等方面会被经常讨论到，主要侧重在这些方面的自动化。

DevOps框架

与 ITIL等不同，DevOps并没有被定义成一组最佳实践和流程。尽管如此，一些常用概念的内在关联性仍可被识别出来，如图2-1所示。

图1-1 DevOps框架

这不是一个放之四海而皆准的DevOps框架，而只是其中的一个DevOps框架。这个框架只指出那些被认可的概念和它们在某种程度上的关系。以下是对每个概念的简要说明。

DevOps持续测试

持续测试是在整个开发过程中协助测试管理的一个测试方法，包括单元测试、集成测试、系统测试和验收测试。测试用例最好在软件开发之前编写，而且除了执行常规测试类型外，测试管理也是高度自动化的。要达到这一点，就需要把需求管理、软件配置管理和测试管理高度集成起来。

DevOps敏捷开发

敏捷开发指的是在DevOps中采用敏捷思想进行软件开发，敏捷宣言无疑是很重要的一项。有多种敏捷方法可以采用，比如Scrum、看板和极限编程。

DevOps持续集成

持续集成提供了让多个程序员可以同时运行应用程序的最佳实践，可以频繁合并源代码、验证代码（静态测试用例）、编译和测试代码（动态测试用例）。

DevOps持续交付

持续交付关注从开发、测试、验收到生产环境的高频生产能力。基于高度的自动化，极端的发布上线时间可以达到分钟级。

DevOps持续监控

持续监控是DevOps的重要组成部分，它不仅监控软件（资源），还监控开发人员（人员）和开发过程（方法）。资源在所有环境中被持续地监控，以便尽早发现问题。人员的衡量标准是能力发展（知识、技能和态度），方法层面的衡量则包括速率（处理能力）和效率。

DevOps敏捷流程

敏捷流程重点关注在标准管理过程中，需要进行哪些调整改进，才能符合敏捷开发方法的要求。

DevOps流程

1 引言

谈到DevOps，出现在我们脑海里的是一起工作的一群人，他们不遵循任何框架或ITIL这样的最佳实践模型。毕竟每个 DevOps 团队都是独一无二的，他们自己决定如何组织开展自己的工作。这个假设是正确的，但同时，关于这个假设还存在着很多争论。因为这群人所做的工作在本质上是重复性的，而且他们也是有着共同目标的。这也是为什么我们仍然可以在DevOps里谈论基于流程驱动的方法的原因。

流程由人员、资源和方法组成。尽管每个 DevOps 团队采用的方法有其独特性，但是流程有着清晰的模式。事实上，法律法规要求这一流程必须受到管控。法律法规是通常意义的，控制也是泛指的。

本文描述了实践中 DevOps 流程的哪些方面构成了一些特定的模式。它也是接下来的一些文章的综述。接下来的每章按照这样的格式——术语、概念、模式、常见问题（FAQ），详述了DevOps流程的一个方面。

2 流程

图3-1显示了一个DevOps流程。它不是DevOps流程的正式定义，而是表述了在大多数组织机构中，为了实现一个服务而会被循环执行的合乎逻辑顺序的一系列阶段。

深色部分表示开发流程，浅色部分表示运维流程。这两个流程构成了DevOps方法的核心。本篇文章不会涉及资源（包括应用程序、基础架构和工具），也不会涉及人员（包括功能、角色和文化），这两部分会在后续文章中进行讨论。

这两部分流程的每一部分又可以进一步细分为一系列阶段、过程，或被称作另一系列流程，它们都是由反复出现的步骤组成的。这些步骤都是为了达到同一个结果，实现相同的目的。

图2-1 DevOps流程[CollabNet]

把DevOps作为一个流程考虑并就此写一系列文章，并不是为了（也不可能）规范化DevOps，而是为了用一个更结构化的方式来归类、分享故事及最佳实践。

此外，结构化的 DevOps 将更加容易被定义，从而也更容易被解释。当然，我们需要意识到这些流程虽然是按照顺序画出来的，其实它还包含着一些反馈循环。例如，在测试流程中，为了解决缺陷，有可能触发编码流程。当然，在 DevOps 中，从测试流程触发编码流程是一种浪费，应该尽可能避免。事实上，流程比图上标识的范围更宽泛一些。比如，监控流程也包括了监控整个DevOps流程。

最后，每个流程的交付物只包括了最重要的那部分，而不是所有的。接下来的文章会讨论DevOps最佳实践。这些文章并不是为了定义DevOps，而只是一系列的故事，用来阐述这些流程是如何在实践中被应用和实施的。

2.1 规划流程

目的

这个流程的目的是为了和相关方一起确定好以下内容：支持客户所需新服务的商业论证（Business Case）、交付的路线图和实现交付的最佳方案。

输出物

○ 被任命的相关方

○ 确定的业务需求

○ 制定的交付路线图

○ 选定的交付方案

解释

相关方就是定义功能性和非功能性需求并为之付款的第三方。商业论证说明了为顾客产生的价值及为此所需要的时间、预算和需要控制的风险。交付路线图是一个包含构建模块发布进程的季度时间表。每个构建模块都在史诗（Epic）上定义。方案指的是采用何种开发流程，是敏捷还是瀑布式。在实践中，大多数（80%）采用DevOps的组织的商业论证都使用敏捷开发。在这个流程的结束部分，产品待办事项列表已经填好，DevOps团队已经组建，预算也已经确定。

循着这个最初计划，接下来就会是一个瀑布式项目或DevOps方法。在DevOps方法中，服务将会采用循环方式增量交付。对每个增量来说，都需要一个详细的计划，史诗被细化为特性，特性被细化为故事。这个方法经常在敏捷Scrum开发和看板中使用，但是在实践中任何组合都可能被接受。

2.2 编码流程

目的

本流程的目的是产生源代码文件，以便在后续构建流程中，生成需要的应用程序和基础架构组件。

输出物

○ 特性被细化为故事

○ 确定的功能性或非功能性需求，并且伴随着度量规则

○ 定义好的验收测试条件

○ 确定好的技术需求

○ 定义好的测试用例

○ 源文件被保存在一个版本管理系统中

解释

源文件包含了开发人员编写的用来生成应用程序组件的源代码。同时，源文件还包括运维人员创建的用来配置基础架构组件的脚本。为了便于实现，我们使用“特性”来进行描述。特性是使用业务语言描述的需要交付的功能性或非功能性需求。特性分解后的故事就是需要完成的源代码（应用程序）和脚本（基础架构）的技术描述。

由于经常是多名开发人员在一起编写代码，而代码也会随着时间而改变，因此保持源代码文件和脚本的版本控制非常重要。

2.3 构建流程

目的

构建流程的目的是将可应用的源代码转换成目标代码，并执行一系列的单元测试。终极目标是在5分钟内验证源代码是否合格，并且将其签入基线版本中。

输出物

○ 创建目标代码，并且错误日志中没有错误记录。

○ 目标代码被存放在制品库中。

○ 源代码已完成质量检查。

○ 单元测试执行完成，测试结果无任何错误。

○ 源代码被签入基线中。

解释

源代码就是一种适用于某问题域的编程语言，例如，PHP适用于网站Web开发，Java代码适用于业务功能开发。有些源代码可以直接在生产环境中运行，如PHP、Basic和SQL编程语言。但是，大多数语言需要把源代码转换成操作系统可读指令（目标代码）。这一过程产物被称为制品。如果源代码扫描和单元测试都是成功的，就把源代码签入基线中。

单元测试不同于其他类型的测试，因为这些测试用例保留了目标代码的代码环境。鉴于5分钟构建的要求，因此不需要再对目标代码中需与其他应用组件或基础架构的协作进行测试检查。在DevOps团队中共享的源代码一起形成一个新的服务。

2.4 测试流程

目的

测试流程的目的是在当前冲刺中生成的所有源代码和基础架构脚本上，执行集成测试和系统测试。

输出物

○ 系统和集成测试被成功执行。

○ 服务符合技术要求和度量要求。

○ 技术验收测试执行完成，测试结果无任何错误。

解释

集成测试被定义为测试应用程序组件间的协作。系统测试被定义为测试端到端的服务实现，包括对基础架构的测试。

2.5 发布流程

目的

发布流程的目的是判定服务的新版本是否满足其功能性及非功能性需求。

输出物

○ 服务符合规定的功能性及非功能性需求和度量要求。

○ 验收测试执行完成，测试结果无任何错误。

解释

在 DevOps 中，发布流程和部署流程有所区别。发布流程是关于新版本服务的正确性的验证，部署流程是为分发服务的新版本而服务的。新版本服务的发布则是基于相关需求的测试结果。

2.6 部署流程

目的

部署流程的目的是通过部署流水线尽可能实现以自动化的方式在生产环境中推出新服务。

输出物

基础架构脚本化的生产环境。

解释

自动化创建服务新版本是 DevOps 的一个重要方面，其实现机制就是部署流水线。实际上部署流水线并不只局限于部署过程。部署流水线从设定需求就已开始，其格式可度量并可以自动化（编码过程），最终自动化发布新服务和自动化安装补丁（运维过程），以保持服务永远满足需求。另外，旧版本服务的重置回滚也是部署流水线的功能的一部分。

2.7 运维流程

目的

运维流程的目的是保持服务的稳定可靠，并且运行符合约定的功能和质量要求，保证业务的连续性。

输出物

○ 安全的环境和数据。

○ 执行管理任务。

○ 预防事件发生。

○ 观察并记录发生的事件。

解释

保持服务正常运行实际上包含多个流程，包括最底层的基础架构（基础架构管理）、应用程序（应用程序管理）和数据（信息管理）。为了使服务正常工作，在编码流程需要采取多种测量。请注意，应对程序Bug的解决方案并不是本流程的一部分，而属于编码流程。

2.8 监控流程

目的

监控流程的目的是监控约定的服务标准。其范围不仅仅包括生产环境，还涉及整个DevOps流程。

输出物

○ 已建立的监控指南。

○ 已定义的事件目录。

○ 已装配的监控设施。

○ 确定（潜在）的生产标准偏差。

○ 已登记的事件。

○ 服务报告。

解释

监控合适的运维操作实际上包含多个流程，包括底层的基础架构、应用程序和数据。为了使服务正常工作，我们需要在编码流程中采取多种测量。请注意，列入事件（inclusion of incidents）并不是监控过程的一部分，而是编码流程的一部分。

2.9 DevOps框架结构关系

图3-1给出了DevOps流程与DevOps框架间的关系概览。

图3-1 DevOps流程与DevOps框架间的关系

图3-1是指示性的。图中没有画出清晰的线条，但它向我们展示了其连贯性。以下是对图3-1的简要解释，需要说明的是这种关系不是纯粹的一对一的关系。

规划

规划包含所有DevOps活动，既包含最初的整个路线图，又包含服务最后的增量交付。

编码

敏捷开发主要涉及编码流程中提及的各个方面。

构建

持续集成主要包括构建流程，也包含单元测试。

测试

持续测试在本文中比测试流程范围更大，因为它包括全生命周期中所有测试类型，如构建流程中的单元测试用例。

发布

持续交付不仅是一次发布的推出，还包括部署流水线，这已经在敏捷开发可执行的测试用例中被定义了。

运维

敏捷流程实际包括所有DevOps流程，而不仅仅是运维流程。整个DevOps流程就是敏捷流程。

监控

持续监控不仅包括产品阶段，还包括整个DevOps流程。