架构师的企业级-DevOps-指南-全-

架构师的企业级 DevOps 指南（全）

原文：annas-archive.org/md5/db01866ae90fa7f7b6e4cb8d284280f6

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书提供了 DevOps、AIOps 和 DevSecOps 的架构概述——这三个领域推动并加速数字转型。通过逐步解释关键概念、实际示例和自我评估问题，您将了解为什么以及如何将 DevOps 集成到企业架构中，确保其安全性，并实现精益运营和加速数字转型。

本书结束时，您将能够开发强大的 DevOps 架构，并了解可以使用的工具集。您还将更深入地了解实施 Site Reliability Engineering 的下一级 DevOps。您将学到什么是 AIOps 及其对企业的价值。最后，您还将学习如何将零信任和行业安全框架等安全原则与 DevOps 集成到 DevSecOps 中。

本书适合谁？

本书教企业架构师、解决方案架构师和顾问如何在企业架构中设计、实施和集成 DevOps，同时让运营与敏捷开发保持一致，并确保企业安全和弹性。本书不涉及大量不同的工具，而是教会您如何创建成功的 DevOps 架构。

本书涵盖了什么内容？

第一章，定义企业 DevOps 参考架构，将 DevOps 引入企业架构中。

第二章，从架构管理 DevOps，展示了如何从架构层面管理诸如持续集成和持续开发等 DevOps 工件。

第三章，为 DevOps 质量进行架构，教您如何在 DevOps 中确保和管理质量属性，重点是测试方法学。

第四章，扩展 DevOps，展示了 DevOps 不是一次性的活动，而是需要根据企业需求进行扩展。

第五章，通过 SRE 架构下一级 DevOps，介绍了Site Reliability Engineering（SRE）的概念及架构师如何为 SRE 做好准备。

第六章，在架构中定义运营，关注企业运营角色及其在 DevOps 影响下的变化。

第七章，理解 AI 对 DevOps 的影响，详细阐述了实施人工智能（AI）和机器学习（ML）对运营的影响。

第八章，构建 AIOps，详述了在运营中实施人工智能和机器学习的架构步骤。

第九章，将 AIOps 整合到 DevOps 中，讨论了如何将 AIOps 整合到持续集成与持续部署（CI/CD）中，并通过 AIOps 自动化 CI/CD 管道。

第十章，迈向 NoOps 的最后一步，是关于企业运营演变的哲学性章节，从人工智能和机器学习增强的运营开始，讲到 NoOps，即完全自动化、无需人工干预的运营。

第十一章，理解 DevOps 中的安全性，介绍了适用于 DevOps 的安全概念，如扫描代码漏洞。

第十二章，为 DevSecOps 架构设计，讨论了如何创建一个能够集成到开发和部署管道中的安全架构。

第十三章，使用行业安全框架与 DevSecOps 协作，详细讲解了各种安全框架，如 ISO 和 CSA，还包括医疗行业的 HIPAA 和金融机构的 PCI，这些都是企业在其 DevOps 实践中需要遵循的合规要求。

第十四章，将 DevSecOps 与 DevOps 整合，教你如何在 DevOps 实践中整合安全政策、标准和防护措施，以及如何管理 DevSecOps。

第十五章，实施零信任架构，是关于在 DevOps 中应用和管理零信任的最后一章。

获取最大收益

强烈建议你具备一定的企业和云架构的基础知识。对于企业架构，建议了解开放组架构框架（TOGAF）。对于云架构，了解 AWS 和 Azure 等主要公共云的基础知识将大有帮助，能让你从本书中获得更多。

下载彩色图像

我们还提供了包含书中截图和图表的彩色图像的 PDF 文件，你可以在此下载：static.packt-cdn.com/downloads/9781801812153_ColorImages.pdf。

使用的约定

书中的提示或重要说明将如下所示：

提示或重要说明

这样显示。

联系我们

我们始终欢迎读者的反馈。

常见反馈：如果你对本书的任何内容有疑问，请通过电子邮件联系我们：customercare@packtpub.com，并在邮件主题中提及书名。

勘误：虽然我们已经尽力确保内容的准确性，但错误难免发生。如果你发现本书中的任何错误，请不吝告知我们。请访问www.packtpub.com/support/errata并填写相关表单。

盗版：如果你在互联网上遇到任何非法复制的我们的作品，若能提供相关地址或网站名称，我们将不胜感激。请通过版权@packt.com 联系我们，并附上相关材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长并且有兴趣参与写作或为书籍贡献内容，请访问authors.packtpub.com。

分享你的想法

一旦你阅读了《企业 DevOps 架构师》，我们很希望听到你的想法！请点击这里直接进入亚马逊的书评页面并分享你的反馈。

你的评论对我们和技术社区都非常重要，将帮助我们确保提供优质的内容。

第一部分：为企业架构 DevOps

本部分的目标是提供指导方针和框架，帮助你在企业内开发 DevOps 架构。完成后，你将能够定义与企业架构对齐的 DevOps 架构。你将能够处理（业务）服务级别协议（SLA）和关键绩效指标（KPI），并根据VOICE（价值、目标、指标、信心、经验）模型，在企业商业环境中控制 DevOps 项目。

以下章节将在本节中进行讲解：

• 第一章，定义企业 DevOps 的参考架构

• 第二章，从架构管理 DevOps

• 第三章，为 DevOps 质量架构设计

• 第四章，扩展 DevOps

• 第五章，利用 SRE 架构下一代 DevOps

第一章：为企业 DevOps 定义参考架构

本章是关于企业的DevOps 架构的介绍。首先，我们将关注企业的业务。业务制定其目标，并据此定义支持这些业务目标的 IT 交付标准。因此，DevOps 架构必须与企业架构对齐。在本章中，我们将学习如何设置参考架构，并在使用VOICE 模型的过程中设计不同的 DevOps 组件。接下来，我们将学习如何在 DevOps 模型中处理服务级别和关键绩效指标。

在本章结束时，你将清楚地了解如何开始使用架构并定义 DevOps 策略。在本章中，你将学到一个重要的课程：当组织外包了大量 IT 交付工作时，在企业中建立 DevOps 变得更加复杂。在本章中，你将学到如何在拥有外包模型的企业中引入 DevOps。

我们将覆盖以下主要内容：

• 在 IT 交付中引入 DevOps

• 创建参考架构

• 引入 DevOps 组件

• 理解 DevOps 中的 SLA 和 KPI

• 使用 VOICE 模型

在 IT 交付中引入 DevOps

本书将重点讨论在大型企业中实施和扩展 DevOps。在深入探讨企业面临的具体挑战之前，我们需要对 DevOps 有一个共同的理解。

有些地方，企业和他们的领导者一定曾认为，将开发人员和运维人员放在同一个团队是个好主意。实际上，DevOps 就是开发和运维阶段作为一个团队共同工作，管理同一个产品。你构建它，你运营它。

在过去十年中，DevOps 在企业中获得了极大的关注和发展。但实施 DevOps 却变得相当困难。其原因在于，企业的组织结构并不适合 DevOps 的运作。从上世纪开始，大多数企业将其 IT 业务外包。一个大型企业的 IT 能力大部分仍然掌握在系统集成商和软件公司手中。当开发由软件公司完成，而运维由系统集成商外包时，DevOps 的实施变得更加困难。

DevOps 从业务出发。通过将传统上分离运作的开发和运维团队聚集到一个共同的开发和运维环境中，企业能够加快开发进程并发布新的产品和服务。这背后的原理是，开发和运维之间的交接所需的时间减少了。此外，通过消除开发和运维之间的隔阂，产品的质量会得到提升，因为 DevOps 包括了质量保证、测试和安全性。客户反馈会被持续评估，并纳入到产品的新版本中。

DevOps 的好处如下：

• 它将业务、开发和运营结合在一起，没有孤岛。

• 企业能够更快速地响应市场需求，因为它们在吸收持续的反馈。

• 产品不断改进和升级，加入新功能，而不是计划下一个重大版本发布。

• 通过在 DevOps 流水线中的自动化，企业可以降低开发和运营的成本，同时提高产品的质量。

它从业务开始，因此起点是企业架构。这是设定业务目标的地方，我们定义如何实现这些目标。IT 交付是实现这些目标的关键。在大型企业中，架构还定义了 IT 交付流程及其之间的划分。我们将在下一节中更详细地探讨 IT 交付及其流程。

理解企业中的 IT 交付

如我们在本节开始时提到的，大型企业通常采用基于外包的运营模式。这使得实施 DevOps 更加复杂。企业架构师需要非常清楚地了解不同流程之间的划分，以及谁负责执行这些流程。谁在什么时间、以什么方式负责什么？下一个问题是，这如何与 DevOps 对接？

首先，我们需要理解 IT 交付中的主要流程。这些流程如下：

• 业务需求：企业需要了解其交付的产品的需求是什么。这些需求由将使用产品的人来设定。客户会要求产品具备特定的功能和质量。架构必须聚焦于交付满足企业客户需求的最终产品。IT 交付是交付最终产品的关键部分。在 DevOps 中，指定的产品负责人确保产品满足需求。产品负责人必须与企业架构师密切合作。在创建参考架构一节中，我们将学习企业架构与 DevOps 是如何互补的。

• 业务规划：一旦需求明确，产品就需要进行范围定义。在 DevOps 中，产品团队通常从最小可行产品（MVP）开始，这是产品的第一次迭代，满足客户需求。在设计 MVP 时，流程需要能够支持该产品的开发和运营。因此，业务规划还涉及质量管理和测试，这两个是 IT 交付的关键组成部分。这需要在架构中有所体现。

• 开发：在 DevOps 中，产品团队将与用户故事一起工作。团队必须将产品拆解为可以定义为交付物的组件。为此，我们必须清晰地定义用户故事。一个用户故事总是遵循相同的格式：作为[用户的功能]，我想要[用户的需求]，以便我[描述当功能实现且目标达成时，用户将获得的收益]。任何用户故事的关键是其接受标准，或称为完成定义（DoD）。产品何时真正完成，并且满足已设定的目标？在第三章，为 DevOps 质量架构中，你将了解更多关于 DoD 的信息。

一个必须指出的重要事项是，当我们提到产品时，我们指的是基于代码的产品。

提示

IT 交付中有一个主要的趋势：一切都在向代码转移。这是现代 DevOps 宣言的核心原则之一：一切皆代码。这不仅适用于应用程序，也适用于网络设备、服务器、存储设备等基础设施组件。因此，DevOps 不仅包括应用程序的软件开发和运维，也包括基础设施的基础设施即代码（Infrastructure as Code）和配置即代码（Configuration as Code）。AWS、Azure 和 Google Cloud 等公共云在这些发展中起到了重要作用。

换句话说，团队正在开发代码：应用代码、基础设施即代码（Infrastructure as Code）以及测试代码。开发人员将专注于产品待办事项中定义的具体代码片段。整个最终产品——例如一个应用程序——已经被拆分成产品待办事项（PBIs），每个开发人员将处理一个 PBI。代码一旦准备好，就需要进行测试，不仅要单独测试，还需要作为最终产品的一个组件进行测试。因此，在开发过程中，代码需要被合并。这个合并过程是通过拉取请求（pull request）触发的，开发人员请求将代码合并并加入到最终产品中，从而完成用户故事。这一过程通过管道（pipelines）来实现。

在第二章，从架构管理 DevOps中，我们将讨论如何设置和管理管道，既包括应用开发，也包括基础设施管理。

我们可以将整个 DevOps 周期分为两个主要阶段：部署和运维，如下所示：

• 部署：在这个阶段，代码经过测试和验证，以确保它与用户故事一致。现在，它将被部署到生产环境。测试和发布到生产环境的过程，理想情况下，在流水线中是自动化的，集成也是如此。在代码实际推送到生产之前，它还需要与配置进行合并。想想需要应用到生产环境中运行组件的安全包。在测试和质量过程中，完整的包——应用程序代码和基础设施组件——需要被验证为“准备好生产”。最终结果应该是一个“上线”产品。如果在进行测试和验证时发现了错误、缺陷或违反安全规则的情况，产品将被送回开发过程的早期阶段。

• 运维：部署后，生产环境中的产品需要进行运维。为此，企业按照IT 服务管理（ITSM）原则进行操作。运营人员与开发人员在同一团队中，并不意味着 ITSM 过程就不再有效。一个例子是，当发生事件时，必须启动事件管理过程。在运维中，我们区分以下主要过程：

  a) 请求履行

  b) 事件管理

  c) 问题管理（事后分析）

  d) 配置管理

  e) 变更管理

但 DevOps 增加了一些内容；即持续集成与持续交付（CI/CD）：

• 持续集成（CI）：CI 基于共享仓库的原则，在该仓库中，代码经常被更新并在云环境中跨团队共享。CI 使得开发人员能够在同一时间共同工作于同一代码上。代码中的更改会直接集成，并准备好在不同的测试环境中进行全面测试。

• 持续交付（CD）：这是将软件自动传输到测试环境。CD 的终极目标是以完全自动化的方式将软件交付到生产环境。各种测试会自动执行。部署后，开发人员会立即收到有关其代码功能的反馈。

CI/CD 需要一个反馈循环来保持其连续性。它需要反馈已交付的产品和服务。这些反馈会回传给开发人员，进而规划新一轮的迭代，以改善产品或服务。

如果一个企业控制着整个周期，这样运作是顺利的，但大型企业已经将大量活动外包给其他公司。这种外包策略的理由通常是某个活动被认为不是核心活动，而且由专门从事该类活动的公司来执行会更具成本效益。

然而，企业在过去十年经历了巨大的变化。IT 变得越来越重要，在某些情况下，已成为核心活动。银行就是一个很好的例子。如今，银行是 IT 公司，它们的 IT 交付输出是金融产品。由于客户需求，这些产品的发布频率逐渐增加，甚至达到一天几次。其结果是 IT 交付本身发生了重大转变。

接下来的几个部分将讨论 IT 交付在采购模型中的运作方式，以及它如何影响成功实施 DevOps。

IT 交付在采购模型中的运作

在本节中，我们将研究大型企业中的 采购模型。这可能相当复杂，但如果我们学会以采购 层级 的视角来思考，它就会变得更加具体和易于理解。这就是 目标企业模型，如下图所示：

图 1.1 – 目标企业模型

使用此模型，我们可以将 IT 交付拆解为三个层级：

• Tier 1: 战略层级。这是企业治理的层级。企业定义了战略业务目标，这些目标在企业架构中得以体现。总体架构原则是企业架构的产物，并推动 IT 架构的发展，包括 DevOps。在创建参考架构部分，我们将进一步讨论这一点。

• Tier 2: 战术层级。这是开发 IT 架构的层级，包括 DevOps。也是定义 服务水平协议（SLAs）和 关键绩效指标（KPIs）的层级，用于衡量 IT 交付的成果。你将在 理解 DevOps 中的 SLAs 和 KPIs 部分学到更多内容。

• Tier 3: 操作或 服务层级。在这个层级，架构的组件被详细定义，包括与各种供应商和服务提供商的接口。第 2 层定义的协议必须在这个层级中得到采纳，以确保所有相关的开发人员和运维人员以相同的方式工作，使用相同的工具，并对目标有共同的理解。在 理解 DevOps 组件 部分，我们将学到更多内容。

实际上，我们看到服务提供商也在第 2 层级上运作；例如，如果他们参与了跨多个产品的大型项目。此时，第 2 层级就成为了协调层，服务提供商负责调整较低层级中的不同工作流。关键要点是，第 1 层级始终应该是企业层级，在这里定义总体治理和架构。

在本节中，我们了解到很多企业已经将其大部分 IT 外包，这可能会使实施 DevOps 的过程变得复杂。我们了解到，整个企业的战略位于第 1 层级，即最高层级。DevOps 则位于最底层的层级，在这里项目实际上被执行。这个层级是企业与外包公司接触的地方。然而，只有在我们清晰了解架构的情况下，这种模式才能奏效。我们将在下一节讨论这一点。

创建参考架构

在前几节中，我们探讨了 IT 交付中的不同流程，它是如何与 DevOps 集成的，以及如何在外包模型中执行这一过程。我们已经了解到，DevOps 从一个明确的架构开始，清晰地定义了流程。

任何DevOps 架构都必须解决规划、开发、集成、部署和运维的问题。但我们必须记住我们为什么要做 DevOps，那就是以更快速、更敏捷的方式实现业务目标，并不断改进产品。DevOps 架构并非独立存在；它必须与企业架构相连接。

企业架构师很可能会从开放组架构框架（TOGAF）开始。TOGAF 被全球广泛接受为企业和业务架构的标准。它使用架构开发方法（ADM）来草拟架构。下面的图示展示了 ADM：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/entp-dop-arch/img/B17492_01_002.jpg)

图 1.2 – TOGAF 中的 ADM 周期

就像 DevOps 一样，ADM 也是一个循环——除了初步阶段，这是在该阶段确定架构需求。这个过程必须在我们前一节讨论的外包模型的第 1 层级中完成，IT 交付在外包模型中。战略和企业架构总是设置在第 1 层级。

ADM 的核心是架构设计的顺序，即以业务为先，并为实际解决方案设定原则和要求。这些原则驱动数据使用架构、应用程序以及最终将使用的技术。这一点很重要，因为架构首先并不是关于技术的。技术仅仅是实现企业级业务目标的手段。

ADM 假设架构不是静态的。当业务需求发生变化时，架构会随之变化。如果业务需求改变，可能需要调整架构以及即将推出的解决方案。这就是 TOGAF 和 DevOps 相遇的地方，因为这两个框架是互补的。

下表显示了企业架构和 DevOps 之间的互补性。简单来说，企业架构设定了战略商业目标，而 DevOps 将其转化为更具操作性的战术层面，真正告诉我们如何通过开发产品和执行运维来实现这些目标。下表显示了 企业架构（EA）与 DevOps 之间的主要区别：

在下一节中，我们将研究 DevOps 原则。

理解 DevOps 原则

企业架构在一级层面执行，即战略层面。在这里，设定整个企业的目标。下一个层级是二级层面，DevOps 团队将在此将目标转化为产品特性并开始开发。DevOps 团队必须根据一系列原则进行工作。

在本节中，我们将探讨 DevOps 的主要原则。本书中，我们将采用来自 DevOps 敏捷技能协会（DASA）的六项原则：

• 以客户为中心的行动：开发应用时要考虑客户——他们需要什么，以及客户对功能的期望是什么？这也是另一个概念——领域驱动设计的目标，它包含了设计的最佳实践。

• 从结果出发进行创造：产品完全完成时，它将是什么样子？

• 端到端责任：团队需要从产品生命周期的开始到结束，具备承担责任的动力和能力。这导致了像你构建它，你运营它和你破坏它，你修复它这样的口号。另一个要加入的是你摧毁它，你重建它更好。

• 跨职能自主团队：团队需要能够在开发过程中自行做出决策。

• 持续改进：这必须是目标——不断改进产品。

• 尽可能自动化：真正提高交付和部署速度的唯一方法是尽可能自动化。自动化还可以减少故障的发生，例如配置错误。

坚持这些原则将产生以下架构声明，这些原则是 DevOps 的核心：

• 自动化：遵循“万物皆代码”的原则，下一步是“自动化一切”。通过自动化，测试和部署之间的时间间隔将大大缩短，从而加快发布过程。但是，自动化也意味着减少人工干预，从而减少错误的发生。

• 协作：六项原则中的两项是跨职能自主团队和端到端责任。这只能通过协作实现。开发和运维必须紧密合作，以加快发布的速度。尽管这也是一种文化变革，但协作需要一套支持协作的共同工具集。

• 集成：开发和运维紧密结合，同时，业务和 IT 也紧密结合。在 DevOps 中，我们使用用户故事将业务需求与 IT 交付进行整合。代码与来自业务需求的新功能进行集成。如今，这些需求变化得更快，因此开发需要通过持续集成（CI）来跟上变化的步伐。这也将导致运维的变化——它们需要以同样的速度采纳这些新发展。因此，集成是 DevOps 的核心。

• 投资组合和配置管理：自动化和集成需要一个清晰的投资组合，包含可以轻松自动化的构建模块。这些构建模块是 ADM 循环中的工件，代表可以用来满足需求的功能包。构建模块是可重用和可替换的，因此必须清晰且具体地定义。更准确地说，构建模块的配置需要得到良好的文档记录，并纳入配置管理的控制之下。如果做得好，这些构建模块还应具备清晰的接口，以便实现完全自动化。

在这一部分，我们讨论了 IT 交付流程及其如何影响 DevOps。我们了解到，IT 交付是由业务需求驱动的，而这一业务需求是任何架构的起点。这也包含在 TOGAF 企业架构框架中。接下来，我们将企业架构映射到 DevOps 原则。

在下一部分，我们将结合架构的 DevOps 原则与 IT 交付原则，形成一个可重用的参考模型。

使用 DevOps 架构参考模型

最后一步是将 DevOps 原则合并为一个模型，用于我们的参考架构。该模型包含两个圈。外圈是产品圈，而内圈代表运营活动。作为逻辑结果，外圈由企业自身进行管理。

内圈是关于如何实际使用 DevOps 交付产品。外圈和内圈之间有接口：协作、自动化、集成和配置管理。

参考模型如下面的图所示：

图 1.3 – DevOps 架构参考模型

在外圈中，业务目标被转化为架构。从架构中创建一个投资组合，利用构建模块创建产品和服务。产品被推向市场并被采用，但由于需求变化，会有变更请求。这些变更将推动企业规划，最终改变业务目标，意味着企业将不断适应变化的需求。这是企业架构的领域。

计划和实际构建在内圈执行。在这个圈子里，产品被拆分为产品待办事项，这些待办事项将由 DevOps 团队开发并最终投入运营。这些团队不是独立运作的，而是根据外圈的触发器进行运作。这就是接口层的意义——它是业务和执行团队之间进行 IT 交付的接口。架构和开发之间有合作。发布应该尽可能自动化，需求和更改必须与 DevOps 团队的计划和待办事项整合，推送到生产环境的构建必须进行监控，并纳入配置管理控制，以确保架构和产品组合在发生更改时保持一致。

让我们通过将角色投放到模型中来看看它在实践中的运作。这将为企业带来一个DevOps 工作流，如以下图所示：

图 1.4 – 企业的 DevOps 工作流

在这里，我们创建了一个模型，企业对其产品组合和产品拥有完全控制权。然而，通过与跨学科的多元团队合作——即使这些团队来自不同的供应商，它仍能提高质量并加快交付速度。

在下一部分，我们将研究我们模型中的最终、最低层，并发现各种 DevOps 组件。

引入 DevOps 组件

到目前为止，我们已经学习了如何开始定义架构，了解了 DevOps 的架构原则，并草拟了一个参考架构模型。下一步是查看 DevOps 中的不同组件。在这一部分，我们将学习 DevOps 架构中必须包含哪些组件。这是我们目标企业模型的第 3 层——所有活动都在此层执行。

以下图展示了将简要讨论的所有组件：

图 1.5 – DevOps 生命周期

之所以将其呈现为无限循环——或者是椒盐脆饼——是因为来自 ops（运营）的实时产品反馈将不断地回传给 dev（开发）以改进产品。

不同的组件如下：

• 计划

• 创建（在某些 DevOps 组件模型中，这被称为代码和构建）

• 测试（在某些模型中，这被称为验证或确认）

• 预发布（在某些模型中，这被称为预发布）

• 发布

• 配置

• 监控

在这个层面上，互操作性至关重要。请记住，大型企业很可能会与多个服务提供商合作，承担 IT 交付过程中的各个部分。当我们希望这些公司以 DevOps 方式协作时，我们需要确保流程和工具是对齐的。接下来，我们需要对作为这些流程一部分执行的各种活动有一个共同的理解。这里的关键术语是一致性。所有 DevOps 组件必须以一致的方式定义和实施。每个开发人员和运维人员都必须根据相同的定义和相同的组件进行工作。

主要问题是，运维应该在什么阶段参与？答案是，尽可能早，实际上就是在计划阶段。运维在定义产品上线后如何管理方面扮演着关键角色。上线前，他们应该设置需求和验收标准。如果开发人员构建的内容无法由运维管理，产品将会失败，业务需求也无法得到满足。

下表详细列出了各个组件的活动：

在第二章，从架构管理 DevOps，和第三章，为 DevOps 质量进行架构设计中，我们将深入探讨这一点，以及架构师如何通过使用 CI/CD 管道来改进这些组件的设计，从而实现自动化、协作和集成。

在下一部分，我们将从业务角度讨论架构的驱动因素，正如 SLA 和 KPI 所规定的。

了解 DevOps 中的 SLA 和 KPI

在理解企业中的 IT 交付这一部分，我们了解到，在 DevOps 中，IT 交付和 IT 服务管理流程仍然有效。通常，企业会签订 SLA（服务级别协议）和 KPI（关键绩效指标），以完成这些流程，从而支持业务目标。如果其中一个流程失败，产品交付将受到影响，最终结果是，业务将无法实现其目标，例如约定的交付日期或产品的上线版本。因此，了解 SLA 和 KPI 对于任何架构师来说都至关重要。这也是我们在IT 交付中的外包模式部分中讨论的外包模型的一部分。

服务级别协议位于 DevOps 的战术流程和企业层面的战略级别之间，企业层面是设定目标的地方。SLA 和 KPI 应该支持这些目标并指导 DevOps 流程。

在 DevOps 的 SLA 中应包括的六个最重要的度量标准如下：

• 部署频率：通常，DevOps 团队以冲刺的方式工作，冲刺是一个短时间段，团队在此期间处理多个待办事项，作为下一次产品发布的一部分。该 KPI 衡量新特性定期推出的频率。请记住，新特性的发布可以按月（通常跨越多个冲刺）、按周甚至按日进行安排。

• 部署时间：从代码在测试阶段发布到预生产环境，再到最终生产环境所经历的时间，包括基础设施的准备状态。

• 部署故障率：这是指部署后发生故障的比率。理想情况下，这个比例应该是零，但这并不现实。部署——尤其是当变更率较高时——偶尔会失败。显然，数字应该尽可能低。

• 部署故障检测时间：此 KPI 与前一个密切相关。故障是难以避免的，但关键在于这些故障被发现的速度，以及采取修复措施的时间。这一 KPI 通常也被称为平均恢复时间（MTTR）。这是 DevOps 周期中最重要的 KPI。

• 变更前置时间：这是指从上一次发布到下一次变更之间的时间。随后，它通过团队处理该变更所需的时间来衡量。较短的前置时间表示团队的工作效率较高。

• 完整周期时间：每次迭代或每次部署所经历的总时间。

这份清单绝不是详尽无遗的。企业可以想到许多不同的度量标准和 KPI。但这里的建议是保持简单。请记住，任何合同中包含的每一个度量标准都需要被监控和报告，这可能会变得非常繁琐。还需要记住的一点是，最重要的度量标准位于业务层面。最终，唯一真正重要的是：客户对业务的满意度，或者更准确地说：交付给最终客户的价值是什么？

在本章的最后部分，我们将通过解释VOICE 模型来详细阐述价值这一概念。

使用 VOICE 模型

DevOps 团队需要为最终客户交付价值。由 IT 公司Sogeti定义的 VOICE 模型正是为此而设。VOICE 代表价值、目标、指标、信心和经验。该模型的理念是，任何 IT 交付都应该为某人创造价值——通常是企业的最终客户。价值设定了 IT 交付的目标，而这些目标通过指标来衡量。指标还衡量追求的价值是否能够实现。

Confidence is about the indicators and if they contain relevant information to confirm that IT delivery actually results in the targeted value. Lastly, experience tells us if the delivered system is fulfilling the business demands and which improvements will lead to more business value. With that, the cycle starts over again.

This model is shown in the following diagram:

Figure 1.6 – The VOICE model

Since VOICE also involves looping feedback back to the beginning of the cycle with the aim of improving products and adding more value to the business, the model can be used for DevOps projects.

In Chapter 3, Architecting for DevOps Quality, we will explore VOICE in more detail.

Summary

This chapter was the introduction to DevOps for architects. We learned that the enterprise architecture sets the architecture principles for the entire enterprise by using the TOGAF methodology. The business goals are defined at the enterprise level. DevOps projects and teams are concerned with IT delivery and fulfilling the business' demands by building, deploying, and running IT systems.

DevOps needs to adhere to the business goals and, therefore, with the enterprise architecture. Yet, DevOps features a specific architecture that enables CI/CD in IT systems. Because of this, we learned about the six DevOps principles and how these are applied to a reference model in which the enterprise still has full control of the products, but multidisciplinary teams can work autonomously on them.

Next, we looked at the different DevOps components and KPIs to measure the outcomes of DevOps projects. The key takeaway from this is that every project needs to add to a better user experience and thus add business value. Due to this, we briefly studied the VOICE model.

In the next chapter, we will learn more about automation, collaboration, and integration by designing CI/CD pipelines.

Questions

1. True or false: DevOps brings business, development, and operations together, without silos.

2. The DevOps principles lead to four key attributes in the architecture for DevOps. One of them is automation. Name the other three.

3. What does the acronym CI/CD stand for?

4. Ideally, every deployment succeeds, but in practice, some deployments will fail. The time that is needed to detect this failure and start mitigating actions is an important KPI in DevOps contracts. What is the commonly used term for this KPI?

Further reading

• The Modern DevOps Manifesto: medium.com/ibm-garage/the-modern-devops-manifesto-f06c82964722

• Quality for DevOps Teams, by Rik Marselis, Berend van Veenendaal, Dennis Geurts and Wouter Ruigrok, Sogeti Nederland BV.

第二章：从架构管理 DevOps

在上一章中，我们了解了不同的 DevOps 组件，包括自动化、协作、集成和配置管理组件。在本章中，我们将更详细地学习如何设计这些组件，以及如何管理DevOps 周期中的这些组件。我们将了解到，自动化和集成从标准化构建模块开始，这些模块被称为工件。这些工件与由企业架构定义的组合关联。在我们开始使用自动化和集成启动DevOps 项目之前，我们需要理解业务战略和架构的需求。

完成本章后，你将能够识别需求管理的不同组件，以及这些组件如何推动组合管理。你还将了解持续集成（CI）的不同阶段，以及自动化如何帮助企业加速部署过程。在最后一节中，你将看到，协作在这些过程中至关重要，我们将探讨如何使团队共同合作，例如引入看板和其他框架。

在本章中，我们将涵盖以下主要内容：

• 评估需求作为架构的输入

• 设计和管理自动化

• 实施和管理配置管理

• 设计和管理集成

• 设计和管理协作

评估需求作为架构的输入

你不能仅仅从一个 DevOps 项目开始——企业需要知道他们想要达成什么目标，才能启动项目。从这个角度来看，传统的瀑布式项目和 DevOps 在敏捷工作方式下并没有本质区别——你需要知道自己要去哪里。这是一个非常简单的解释，讲的就是需求管理。在本节中，我们将学习需求作为架构输入的意义，以及它如何引导项目的开展。

需求管理可以定义为一个过程，其中企业收集并优先排序改进业务成果的想法。为了做到这一点，企业需要评估来自外部的需求，也就是市场——换句话说：客户想要什么？ 但它还需要评估当前的组合是否仍然是最新的，正在进行的项目是否仍然能够交付预期的结果。组合管理是市场需求和正在进行的活动的持续评估。现代的挑战在于，这种评估的速度必须比十年前更快。需求变化迅速，显著影响组合管理。

投资组合管理至少包括以下几个组成部分和过程（Romano, L., Grimaldi, R., & Colasuonno, F. S. (2016). 需求管理作为投资组合管理的关键成功因素。论文提交于 PMI®全球大会 2016—EMEA，西班牙巴塞罗那。新城广场，宾夕法尼亚州：项目管理协会）：

• 企业愿景与战略的定义：这是企业架构的一部分，定义了企业的战略。

• 需求管理：收集创意并识别投资组合中未来产品和服务机会的过程。

• 持续组件：验证现有产品和服务是否仍然对企业及其客户相关。

• 组成部分评估：这涉及商业案例。开发新产品和服务或更改现有组成部分的投资额是多少？发布或更改后，预期的收入是多少？

• 预算编制：计算启动开发或实现现有组成部分升级所需的资源量。

• 优先级排序与选择：开发和变更需要与企业战略相匹配。什么是必须做的，什么是可选的，以及在什么时间框架内？

• 投资组合治理与沟通：这与需求和投资组合管理中谁负责什么事项相关。建议采用责任、问责、咨询和知情（RACI）矩阵来进行投资组合管理：谁负责哪个组成部分？谁是最终问责人？谁应该被咨询？谁应该被告知？

• 投资组合实施：以结构化的验收过程将新增或更改的组成部分加入投资组合。组成部分是否以适当的方式记录？组成部分是否得到负责人的签字确认？所有的验收标准是否都已满足？

• 投资组合报告与评审：报告应反映投资组合是否与企业战略一致。投资组合是否仍然与战略和期望的业务结果相关？还是企业需要更改组成部分，甚至考虑调整整个投资组合（例如，通过剥离投资组合的部分）？

• 效益实现：投资组合的实际价值是什么？它为企业和其业务带来了哪些效益？

组合项目驱动着企业中的项目，也驱动着 DevOps。DevOps 的关键是自动化，使项目能够跟上业务变化和需求的速度，特别是对信息技术（IT）的需求。自动化的关键在于创建标准化的构建模块。从组合项目中，我们需要定义这些构建模块，称为工件。配置管理就是管理这些工件，使其适配组合项目。为了管理这些，我们需要版本控制。我们将在实施和管理配置管理部分讨论这一点。

我们现在已经有了创建组合项目以管理配置项并实现自动化的周期。如下图所示：

图 2.1 – 配置管理周期

代码库保存着在版本控制下的标准构建模块。这是实现自动化的前提。在接下来的部分中，我们将深入学习自动化的相关内容。

设计和管理自动化

在本节中，我们将讨论 DevOps 的自动化。首先，自动化不仅仅是关于工具，尽管我们将在本节末尾讨论工具。架构师需要回答的第一个问题是我们需要自动化什么和为什么。这不仅仅是关于工具，而是关于过程。

首先，我们需要回答以下问题：我们为什么需要自动化？ 这个问题的答案是因为标准化。企业采用 DevOps 的原因是他们希望加快交付过程。做到这一点的唯一方法就是对构建模块、工作流程、过程和技术进行标准化。通过实施并始终如一地遵循标准，企业将限制交付链中的变异，从而可以开始自动化。自动化的关键在于减少等待时间。

在企业转向 DevOps 之前，IT 交付是由等待时间驱动的。开发人员需要等待服务器。在最坏的情况下，服务器需要先下单，然后安装和配置，才能交付给开发团队。接着，开发人员才能开始工作并将软件交付给测试人员，但随后他们又必须等待测试人员反馈结果。最后，产品准备发布，但此时团队还必须等待最终的是否发布决策。

在 DevOps 和自动化的CI/CD 流水线中（其中CD是持续交付的缩写），如果做得好，等待时间会因为标准化而大大减少。架构师需要牢记，流水线由两个主要部分组成：软件和基础设施，尽管基础设施现在也已经是代码。通常，我们将工作在云环境中，在那里我们不再部署物理服务器，而是采用基础设施即代码（IaC）。

一切都已成为代码。基础设施、配置和软件部署的自动化是 DevOps 的核心。只有通过自动化，公司才能加快交付速度，缩短交付周期到几周、几天甚至几小时。

以下截图展示了 CI/CD 管道的自动化过程。该管道中有两个主要组件：部署管道 和 基础设施管道：

图 2.2 – 部署管道和基础设施管道

软件在部署管道中进行开发、测试和部署。该软件需要部署到基础设施上，例如，在公共云中使用 虚拟机 (VM)，如 Amazon Web Services (AWS) 或 Azure。在某个时刻，我们将不得不将软件代码与该基础设施的基础设施和配置包进行合并。整个包经过测试、验证，最终被推送到生产阶段。

注意

图 2.2 展示了测试的重要性。图中有几个触点，包括测试程序。在 设计与管理集成 部分，我们将进一步解释 CI 中的各种测试，例如静态分析和动态分析。第三章，为 DevOps 质量架构 也有一节关于执行测试的内容。

因此，部署管道用于将代码转换为可部署的应用程序包，部署该包，验证该包，并将该包发布到生产环境中。

在基础设施管道中，我们为应用程序包部署的环境进行配置。在 图 2.2 中，虚拟机被作为示例提到，但基础设施也可以由容器或无服务器组件组成。事实上，本地应用程序将使用容器和无服务器环境，而不是虚拟机。

理解管道组件

让我们更仔细地看一下 图 2.2 中展示的图表，并评论其中的不同组件。管道从版本控制和配置项开始。在下一部分 实现与管理配置管理 中，我们将对此进行更详细的讨论。

实际的部署从包含我们需要运行应用程序的所有文件的包开始。这个包可以部署到某个环境中。可以部署到任何环境吗？ 这就是将部署管道从基础设施中抽象出来的原因。理想情况下，我们希望能够在不同的平台上运行代码，因此我们需要以这样的方式编写代码，使其能够在各种基础设施上运行，例如在 AWS、Azure 等平台上，或者在私人堆栈上，甚至使用不同的操作系统，如 Windows 或 Linux 发行版。

如果我们已经有了包，就可以开始部署：这是一个自动化任务序列，用于将我们的应用程序部署到测试或预发布环境中。在这里，我们可以运行自动化的简单测试—通常称为冒烟测试—来验证代码是否实际运行。这个简单的测试不足以验证所有必需的功能并发现错误：这将在测试阶段完成。我们将在设计和管理集成部分深入了解测试。

如果所有测试都成功执行完毕，我们就得到了一个经过验证的应用程序包，准备推送到生产阶段。

在自动化方面需要考虑以下几个方面：

• 代码开发：在 DevOps 中，自动化从开发者开始编写代码时就已经开始。代码需要是“自动化就绪”的，这意味着从代码提交的那一刻起，实际构建会被触发，并通过自动化测试和代码验证。接下来，代码会被编译并纳入版本控制。最终，当所有测试都执行完毕且完整的包经过验证后，它将被推送到生产环境。开发人员在开发代码时需要考虑这一自动化顺序。代码部署到生产环境后，还需要进行监控。因此，一旦包“准备好”进行上线，脚本会合并到包中，以便使其能够进行监控并收集日志。

• 持续测试：在 DevOps 的周期中，软件会不断被评估和改进。毕竟，这正是 DevOps 的核心：提高敏捷性和持续交付（CD）。因此，代码会定期发生变化。每次代码发生变化时，都需要进行测试和验证。这就是持续测试的作用。自动化测试被用来跟踪和预测代码变更中的问题，执行多种测试，并最终发布经过批准的自动化构建版本。

• 监控：认为只有在应用程序推送到生产环境时才需要监控是一个误解。监控在整个 CI/CD 生命周期中都很重要，是自动化的关键组成部分。监控用于跟踪事件，找出代码故障的原因，优先处理事件，并主动提出可执行的改进建议。

简而言之，通过应用自动化，我们可以将发布周期从几个月或几周缩短到仅仅几天，甚至几小时。这只有在尽可能多地进行自动化的情况下才可能实现。但自动化不仅仅是加快交付速度，它还减少了手动错误的风险，并将使公司能够实现更高的一致性和更高的产品可靠性。DevOps 不仅仅是关于敏捷性和速度，可能更重要的是质量，通过在可重复的过程中创建更高精度的产品，并能够以高速度交付。

选择 DevOps 自动化工具集

目前为止，我们还没有讨论到工具。选择合适的工具确实非常重要。然而，挑战在于市场上有许多可用的工具。架构师的一个任务就是指导工具的选择。架构师需要做出的第一个决定是，他们是否希望自动化是“单一堆栈”的，还是选择多个工具用于不同的自动化领域。

请看以下截图中的DevOps 工具周期表（由 Digital.ai 提供）。对于每个 DevOps 域，有大量的工具选择。这里有用于管理代码、创建包、自动化管道合并、测试代码、修复 bug、提供基础设施、管理基础设施和监控的工具：

图 2.3 – DevOps 工具周期表的概念

组织需要从头到尾管理 DevOps 流程的工具。虽然有一些工具承诺能够提供这种端到端的功能，但通常需要一套工具，从代码构建和提交到测试、部署和运营。需要记住的一点是工具之间的集成水平。这不仅取决于开发人员使用的源代码，也取决于目标平台。如果目标平台是 Azure，那么使用 Azure DevOps 和 Azure Resource Manager（ARM）来部署该平台上的基础设施是完全合理的。如果主要平台是 AWS，那么像 Chef 和 Puppet 这样的工具，结合 AWS CodeDeploy，可能是更好的选择。

另外，从使用虚拟机（VM）到使用容器和无服务器技术的转变正在进行中。许多 DevOps 项目使用容器来部署代码，通过 Docker 和 Kubernetes 作为容器的编排平台。与虚拟机相比，容器对底层基础设施或云平台的依赖更少，但这里的平台也各自有自己的 Kubernetes 引擎。比如，Azure 上的 Azure Kubernetes Services（AKS）和 AWS 上的 Elastic Kubernetes Services（EKS）。

另一个需要考虑的重要因素是将选择的工具类型。开源工具非常流行，但考虑这些工具是否符合企业需求也是很重要的。这在不同领域之间有所不同。Azure DevOps Pipelines 和 AWS CodePipeline 被视为企业级工具，但版本控制工具（Git、GitHub、GitLab、Subversion（SVN）、Cloud Foundry）主要是开源的。企业选择开源工具可能有很好的理由，正如这里所阐述的：

• 社区驱动：大型社区不断改进软件。企业可以从中受益。

• 具有成本效益：通常，开源软件需要许可，但从总成本来看，开源软件往往是一个非常划算的选择。

• 无锁定风险：这对组织来说变得越来越重要。它们不希望完全被一个软件提供商的解决方案或该提供商的生态系统所束缚。开源让组织拥有极大的自由度。

开源软件常被批评的负面因素是，它可能比企业软件更不安全且不稳定。然而，由于软件不断地受到社区的审查和改进，我们发现开源软件在安全性和稳定性上与非开源软件一样。

实现和管理配置管理

在上一节中，我们了解到，自动化始于版本控制和配置项，这些配置项在构件的存储库中形成一个应用包。在本节中，我们将学习如何管理这些构件。

自动化只能在构建块（构件）和流程标准化的情况下进行。标准化需要以下三个组件：

• 投资组合和投资组合管理：投资组合是企业战略和企业交付给客户的产品的体现。这些产品由多个构件组成：产品组件和流程。因此，投资组合处于企业的战略层面，而产品和构件则位于战术层面。投资组合由企业架构、产品和构件定义，并在业务单元和项目层面进行管理。简而言之，产品在没有投资组合定义的情况下无法存在，但投资组合并非我们能够在项目和流水线中自动化的内容。我们可以自动化构件，甚至是产品，只要它们是标准化的，并通过版本控制进行管理。

• 版本控制：在本章的第一节中，我们了解到构件源自投资组合。构件需要进行版本控制。集中式版本控制存储库在 CI/CD 中绝对是首要任务。这个存储库是所有配置项的单一真实来源（SSOT），这些配置项将用于开发和构建部署包。使用版本控制系统（VCS）中的文件版本创建带有配置项的包。版本控制是保持所有配置项一致性的必要条件。构建过程会生成一个版本化的包，用户可以从存储库中检索该包。

• 配置项：术语配置项源自IT 基础架构库（ITIL），这是一种 IT 服务管理的 IT 库。配置项是为了交付 IT 服务而需要管理的资产——基本上，所有执行构建和交付 IT 服务所需的东西。它包括应用程序代码的构建模块，还包括操作系统的镜像、网络设置的配置、安全包、许可证、数据库设置和测试脚本。所有这些项都需要进行管理。配置项通过唯一标识符（UUID）、项的类型（硬件、软件、脚本、许可证等）、清晰的描述以及该项与其他项的关系来定义。为了保持配置项的一致性，它们需要定期或甚至“实时”进行验证和确认。一个最佳实践是自动化这一过程，正如我们在前一节中所看到的那样。代理程序将持续监控环境中的所有资产，并更新配置项在存储库中的状态，通常称为配置管理数据库（CMDB）。

这与企业架构和投资组合有何关联？以安全性为例。从企业战略出发，必须定义安全标准——例如，企业应符合哪个行业框架。这被转化为需要在安全包中设定的安全政策。这些包含安全政策和规则的包被称为配置项。在本书的第三部分，关于DevSecOps的内容中，我们将深入了解这一点。

让我们把这一切具体化一些。我们有一个运行在虚拟机上的应用程序，它连接到一个数据库。然后，可以列出不同的配置项，如下所示：

• 应用程序代码

• 虚拟机模板

• 操作系统镜像

• 应用程序的安全设置

• 虚拟机的安全设置

• 访问规则

• 数据库镜像

• 操作系统许可证

• 数据库许可证

• 网络设置（互联网协议（IP）地址分配；网络端口；路由）

这份清单并不详尽——这里只是一些示例。所有这些项目都需要进行管理，以保持一致性。CMDB（配置管理数据库）使得所有项目的验证和确认成为可能。通过应用版本控制，我们确保新的构建只使用经过验证的配置项——例如，某个版本的操作系统或特定版本的应用程序代码。

一个重要的收获是，每个配置项都与业务战略、投资组合和企业架构紧密相连。

在本节中，我们学习了什么是配置项，以及如何通过单一的存储库（CMDB）来管理这些项，以保持它们的一致性。在下一节中，我们将看到为什么版本控制和一致性如此重要。

设计和管理集成

在本节中，我们将深入了解CI。首先，我们将探讨应用代码的开发与部署。接下来，我们将学习代码管道在应用程序与基础设施中的集成。某些时候，应用代码和基础设施即代码（IaC）需要与特定配置包合并。只有这样，我们才能拥有一个完全集成的模型。

首先，让我们来看看集成的定义。这指的是一系列自动化的任务，用于版本控制、编译、打包和发布应用程序。这包括测试，单元测试用于验证现有代码在不间断的情况下是否表现良好。集成测试运行以确保不会出现集成问题。还可以包括其他检查，例如静态代码分析，以提高质量和反馈。

CI/CD 管道——以及其中的自动化——从源代码的合并开始。代码被转化为构建，这是一个可执行包的产品，能够与其他可执行包集成。代码从仓库中拉取，进行分析，并提交到构建服务器，在那里会执行一系列自动化任务，将代码推送到生产环境中，包括与基础设施的合并。

如前所述，代码的测试和验证是构建过程中至关重要的一部分。代码通过测试验证所有风险已被识别并得到缓解，以确保构建符合企业架构中定义的企业合规性要求，并且符合安全政策。下一步是将代码部署到开发或测试环境中。如我们所见，最好是通过自动化方式进行此操作。代码被纳入版本控制并提交回仓库。

虽然需要大量手动任务，但保持一个由开发人员维护的 wiki——一个包含版本控制的文档集合——是很重要的，里面包含了构建编号的发布说明，以及在测试后遇到并已缓解的问题。测试结果应该列在发布说明中。

总结来说，CI 过程包括以下步骤：

1. 检测新提交的代码：应用仓库中的源代码被分叉，这意味着代码已提交到自动化管道。这会启动一系列构建任务。下一步是验证代码。这就是拉取过程，代码被检出并放置在构建环境中——在大多数情况下是开发服务器。执行静态分析，这是一种不实际运行代码的测试。这个步骤也被称为linting。

2. 源代码质量分析：检查代码是否符合安全性和合规性要求。质量分析的一部分还包括对所用软件的扫描：它是否有许可证，并且是否符合企业标准和软件组合？

3. 构建：这是编译代码并组装包的步骤。实际的构建过程从从工件仓库中提取可执行包开始。该仓库存储着企业用于部署代码的所有标准和政策。源代码与这些包合并。例如，这些包包含操作系统的镜像，还包括安全策略，如硬化模板，用于保护系统免受攻击。基础设施的包通常存储在包含镜像的仓库中：可信镜像注册表。这些镜像用于组装可执行包并进行最终部署。

4. 单元测试：单元测试确保可执行包运行时没有问题。

5. 集成测试：在代码验证中，我们执行了静态分析，现在进行动态分析。测试组装包以验证其运行时没有错误，并生成测试报告。

6. 创建运行时可执行文件：我们接近最后的步骤，即将代码发布到下一个阶段。在此之前，生成运行时可执行文件，以便代码能够按照特定的运行时顺序或常规启动。这些运行时可执行文件通常存储在单独的运行时库中。

7. 构建通知：部署前的最后一步是通知构建已准备好，这意味着代码和可执行包已通过所有测试，包已准备好部署。如果在自动化过程中任何步骤中集成被停止，开发人员将收到通知，以便他们修复任何问题并重新提交代码。然后，按照描述的每个步骤重复执行。

集成过程如下图所示：

图 2.4 – CI 流程

图 2.4显示 CI 路径的输出指向名为晋升路径的东西。应用程序很少直接推送到生产环境。应用程序的发布通常在实际进入生产环境之前会进行“分阶段”处理。下一节将解释这一晋升路径。

理解晋升路径

尽管代码最终会被推送到生产环境，但良好的做法是先将其部署到开发、测试或预生产环境中。这被称为晋升路径，涉及开发、测试、验收和生产（DATP）。在某些情况下，验收环境是晋升路径的一部分。验收环境位于测试和生产系统之间。

见下图：

图 2.5 – IT 系统的晋升路径

强烈建议对业务关键应用程序使用验收环境。事实上，企业通常将验收环境用作生产失败时的灾难恢复（DR）系统。生产系统会切换到验收环境，并且数据损失最小。验收环境在配置上应该与生产系统完全相同。

推荐包含 DTAP 的晋升路径作为最小化设置。可执行包是集成流水线的产物，现在被推送到开发、预生产和测试或暂存环境。在这里，包会被测试，以验证它们在生产环境中运行时不会出现问题。应用程序至少需要具有健壮性、稳定性、安全性和合规性。同时，还需要测试云原生特性，如可扩展性——甚至可能包括自我修复——以及负载和性能测试。最终，最终产品将根据最初从业务收集的规范上线。然后，我们又回到了循环的开始，这个循环从需求管理开始。

为什么我们要进行如此密集的流程来发布代码？因为这样做对业务有很多好处。以下列出了五个主要的好处：

• 代码更改更加可控，并且可以更小，因为这是一个持续的过程，代码的改进可以通过小的迭代进行。

• 由于自动化，代码发布的速度可以大大加快。

• 由于自动化，开发成本将显著降低——这一点将在企业的整体成本中体现出来。

• 自动化测试将导致更可靠的测试和测试结果。

• 管理和更新变得更加简单。

在本节中，我们了解了 CI：它的要求是什么，如何通过自动化流水线启动集成，以及为什么企业应该在项目中实施 CI。作为完整 DevOps 设置的一部分，我们还需要讨论一件事，那就是协作。DevOps 不仅仅是关于技术和工具，它是一种心态。我们将在本章最后一节讨论协作。

设计和管理协作

简单来说，DevOps 只有在团队合作时才能成功。如果团队使用相同的流程，甚至是相同的工具集，那么他们就能够协作。在 DevOps 中，协作将流程和技术结合起来，使团队能够共同努力。

在第一章《为企业 DevOps 定义参考架构》中，我们看到很多企业已经将他们的 IT 外包。这使得协作有时变得困难。DevOps 要求负责运营并且属于某个外包合作伙伴或供应商的团队，必须与来自不同公司的开发人员共同合作。企业必须为此设定场景、参与规则和协作原则。这种责任只能由企业层面承担。

在企业中，很少有单一团队完全负责一个应用程序。通常会涉及多个团队，甚至多个供应商。然而，DevOps 假设有一个 DevOps 团队负责端到端。这样做的主要目的是减少开销，管理团队之间交接时的等待时间。这需要团队成员之间不断的沟通，因为这些成员的技能和任务各不相同。

不要被T 型教条所迷惑。是的，云工程师可能知道如何将存储附加到虚拟机（VM），也许他们还知道如何在 Azure 或 AWS 中构建网络配置，但配置数据库或防火墙是特定任务，通常需要数据库或网络工程师。DevOps 团队将必须引入这些领域专家（SMEs），但是他们会在一个团队中共同工作，而不是在独立的工作单元中。

接下来，企业需要实现协作。这是项目负责人或者在敏捷工作方式下的Scrum大师的任务。他们的关键任务之一是“去除障碍”，帮助团队成员实现共同的目标。为团队设定目标和优先事项是第一步。

我们如何定义目标和优先事项？这是架构师的任务。他们的责任是制定一个清晰的路线图，指出如何达到每个目标，以及顺序是什么。该路线图来源于最终架构，也称为“soll”或目标架构。这个架构定义了环境最终应如何呈现，包含应用架构、所需的基础设施组件以及应用程序编程接口（APIs）。

下面的图示展示了一个路线图示例。该示例来自ProductPlan，完美展示了一个简单的路线图如何帮助创建任务的可视化和清晰度，这些任务是提前预测的：

图 2.6 – 由 ProductPlan 提供的架构路线图示例

最后，路线图展示了团队成员的角色和责任：谁需要做什么，以及需要多少时间？创建清晰的路线图、时间表和任务的一个好方法是使用看板。看板，最初是日本发明的，首次在丰田公司引入，显示在生产过程中何时需要某些组件。Scrum 和 Kanban 都是实现敏捷应用开发方法的工具。

对许多企业来说，这听起来仍然非常新鲜，但事实上，他们可能已经使用类似的规划方法学工作多年，因为这正是看板（Kanban）本质上所做的。它帮助团队将复杂的项目规划成可以实现的小块，从而提高最终产品的质量。

在下一章中，为 DevOps 质量架构，我们将学习更多关于实施质量度量的内容。

概述

本章从需求管理概述开始，作为架构的输入。我们了解到，评估商业需求是驱动投资组合的关键因素。反过来，投资组合定义了我们用来开发产品、服务以及应用程序的构建块和工件。由于需求变化迅速，企业需要加快部署流程。这可以通过尽可能多地实现自动化来实现。自动化是通过管道完成的，在本章中，我们学习了架构应用程序部署和基础设施管道的不同组件。

在上一节中，我们讨论了在 CI/CD 中至关重要的协作，采用了 DevOps。团队将由具有不同技能的工程师组成，他们甚至可能来自不同的公司，这在那些外包 IT 服务的大型企业中非常常见。因此，企业需要鼓励强有力的协作，基于清晰的路线图、明确的目标和计划，明确每个人负责的任务。为此，Kanban 看板是一个不错的方案。

在下一章中，我们将深入探讨 DevOps 项目的质量度量，学习就绪定义（DoR）和完成定义（DoD），并了解如何执行质量保证测试。

问题

1. 需求管理是一个收集想法并识别未来产品和服务机会的过程，这些产品和服务都在一个投资组合中。请判断以下陈述是否正确：商业案例与需求管理无关。

2. 第一个测试之一是在不实际运行代码的情况下进行测试。我们称这种测试为什么？

3. 晋升路径包含多个阶段。这些阶段是什么，它们的顺序是怎样的？

进一步阅读

• 需求管理作为投资组合管理中的关键成功因素。2016 年，Romano, L., Grimaldi, R., 和 Colasuonno, F. S. 在 PMI®全球大会上发表的论文：

  https://www.pmi.org/learning/library/demand-management-success-factor-portfolio-10189

• Kanban 与 Scrum - 最大化两者的优势，Henrik Kniberg 和 Mattias Skarin：

  www.infoq.com/minibooks/kanban-scrum-minibook/

第三章：为 DevOps 质量架构设计

DevOps的总体目标是为 IT 项目提供高性能和高质量。在本章中，你将了解 DevOps 如何为IT 交付的质量增加价值。在本章中，我们将学习如何定义测试策略，证明质量已经按照完成定义（DOD）交付。但如果出现故障怎么办？DevOps 中的黄金法则是你构建它、运行它、弄坏它，然后修复它。但是，我们必须通过执行根本原因分析（RCA）来检测问题是什么。在最后一节中，我们将讨论补救措施，以及由此带来的持续改进。

完成本章后，你将能够在 DevOps 项目中识别和实施质量措施。你将学会可以包含哪些测试，它们如何组织，以及这些测试的价值是什么，从而持续改进产品或服务。

在本章中，我们将涵盖以下主要内容：

• 定义测试策略

• 实施质量措施

• 设计测试自动化和执行

• 理解根本原因分析

• 设计补救措施

定义测试策略

在上一章中，我们得出结论，测试是 CI/CD 过程中确保构建质量的关键步骤。在本节中，我们将学习如何在 DevOps 中定义测试策略。

首先，DevOps 需要一种不同的测试方法：它是持续部署和集成构建的一部分。我们应当采用 DevOps 的原因是企业希望加快发布速度，以便能够更快速地响应变化的需求。对于测试来说，这意味着从测试最终产品转变为持续测试，重点是减少构建和测试时间。

换句话说，测试不再仅仅是检测最终产品中的缺陷，它已经成为整个构建生命周期的一部分，贯穿于整个周期的反馈收集。

测试人员应该是 DevOps 团队的成员。他们的职责是不断收集反馈、衡量周期时间，并寻找减少这些时间的方法。测试人员应该被邀请在整个构建过程中监控代码，这样他们就能在错误和缺陷出现时立即发现。这将为团队提供在代码进入下一个阶段之前修复问题的机会。这种方法的主要好处是，最终产品将已经有更少的问题，并且在每次迭代中总周期时间都会减少。

总的来说，我们可以说，质量保障在 DevOps 中的角色正在发生变化。在传统的 IT 项目中，质量保障通常是在产品——例如应用程序——交付到最终阶段时进行的。测试人员会执行功能测试，并组织一群用户来进行用户验收测试（UAT）。这个过程通常持续一到两周。然后，结果会反馈给开发人员，开发人员会查看问题并修复。之后，整个项目会再次交给测试人员，以便他们重新测试并验证所有问题是否已经解决。在 DevOps 中，我们不再按这种方式工作。首先，因为这种方式花费时间过长，其次，测试人员和开发人员之间几乎没有互动。

在 DevOps 中，确保整个开发周期的质量的测试策略需要满足哪些要求？它们如下：

• 创建用户故事意识：首先，需要有一个明确的用户故事。用户故事将驱动测试场景。这意味着团队会明确测试的主题范围。TMAP，最常用的测试框架，将这些主题分为两类：组织和执行。组织类主题涵盖测试的规划、准备和管理方式。执行类主题则涉及具体的测试内容。

• 制定策略：在 DevOps 中，策略应该是测试在整个构建过程中都得以执行，这意味着测试人员需要在构建的各个迭代中运行自动化测试脚本。换句话说，代码会不断进行测试，以验证其是否顺利运行且没有问题。这需要开发人员和测试人员之间的紧密合作：在构建过程中，开发人员需要向测试人员提供代码，以及临时构建，直到代码稳定为止。

  显然，测试的数量、测试时间以及测试目标之间必须保持平衡。企业进行测试是为了避免潜在的风险，如风险变为现实并造成损害。定义测试策略时需要解决的第一个话题之一是清晰地识别风险。

  要意识到，这不仅仅是技术上的问题。它还涉及到协作和沟通的软技能。过去，测试人员习惯于在开发周期结束时获得整个产品包，然后进行测试，现在他们成为了 DevOps 团队的一部分，持续沟通关于时间安排、测试方式以及将要测试的内容。这对 DevOps 的成功至关重要。

• 定义工具和环境：说实话，这并不是关于工具——而是关于代码和标准化的水平。测试人员需要确保捕获到所有代码：我们称之为代码覆盖率，至少应该达到 100%或接近这个值。测试用例必须自动化。自动化需要标准化：代码需要自动部署到标准化的测试环境中，在该环境中，预测试、清理和后期测试任务都是自动化的。这将提高效率和可靠性，防止在重复任务中出现人为错误，前提是一些测试将会执行多次。

  第一次测试，在开发过程的初期，包括静态分析来检查代码是否完整。在静态分析中，代码不会被执行：工具验证代码是否完整且一致。例如，测试人员可以使用工具和脚本验证安全政策是否已应用于代码，并确保代码符合行业标准。回顾静态分析过程应该提供关于代码及相关文档质量的详细概述。

• 执行：测试场景必须结构化得非常清晰。这需要在测试设计中定义，我们将在设计测试自动化和执行一节中讨论。在那里，我们将查看各种执行技术：

  • 以过程为中心

  • 以条件为中心

  • 以数据为中心

  • 以体验为中心

  DevOps 的一个重要目标是通过减少过程步骤之间的等待时间来加速交付。这也包括测试。我们已经指出，测试人员不必等到代码最终交付后才开始测试，他们可以在构建周期的后续迭代中运行自动化测试。为了减少测试时间——进而减少整个构建时间——建议进行测试的并行执行。

  还有很多方法可以提升质量和测试，这不仅仅是质量工程师和测试人员的责任。DevOps 实际上是一个团队合作的过程，鼓励所有成员参与到各个步骤和阶段中。因此，开发人员也被邀请参与并添加测试用例。一个好的做法是将测试用例、脚本、运行手册、报告以及其他文档集中到质量存储库中。从这个存储库中，质量工程师和测试人员可以挑选用例，并在开发和部署过程中进一步自动化这些用例。

• 创建和解释报告：必须评估测试结果。在本节开始时，我们提到，测试是为了识别、分析并减少风险。测试结果必须与这些风险相匹配，这意味着它们应该得出预期的结果。如果结果完全不同，那么风险需要进一步调查。只有这样，测试才能真正对质量做出贡献。

  因此，测试远不止是发现 bug。测试必须专注于构建的整体期望结果。因此，测试人员需要报告的内容远不止是纯粹的问题。报告现在真正专注于改善构建和构建过程的质量。一个例子是，测试结果可能会显示哪里可以改进自动化，或者代码可以优化。总体目标是降低风险。

  阻塞问题——那些带来巨大风险的问题——必须立即报告，并反馈到开发链的起始阶段。

• 设定退出标准：测试中的结果很重要，它们会导致关于是否以及如何继续的决策。这就是退出标准的作用。如果所有必要的测试都已执行，结果应该能够提供足够的信息，以做出通过/不通过的决定，并将软件推向下一个阶段，通常是生产阶段。

在本节中，你学会了如何制定质量和测试策略。在我们学习如何实施质量措施之前，我们将简要了解不同的测试类型。

理解测试类型

在本节中，我们将介绍不同的、最常见的测试类型。测试分为三个层级：

• 第 1 层：小规模测试，专注于单个组件。单元测试就是一个例子，测试代码的各个小块。

• 第 2 层：集成测试，涉及多个组件。测试集成本身，但也测试组件之间的交互，以及集成包是否能良好运行。在这一层级执行集成和性能测试。

• 第 3 层：可用性测试，专注于最终产品的易用性——例如，使用图形界面——以及是否易于管理。用户验收测试（UAT）通常是这一层级的最终测试。明确来说，UAT 还包括从最终用户的角度进行的性能测试。

这三种层级展示在下图中：

图 3.1 – 测试的层级

随着测试从单一组件扩展到涉及整个解决方案栈的可用性测试，复杂性增加。

在测试策略中，团队将根据业务需求定义必须执行哪些测试，以及成功部署构建所需的预期结果。

还有一些特定的测试尚未提及：

• 回归测试：在传统的软件开发方法中，这些测试非常常见。功能性和技术性的测试会被重新执行，以确保在开发周期中变更的代码在更改后依然能够正常工作。正如我们所看到的，DevOps 已经改变了我们对待测试的方式。这不再是一次性的操作，我们运行回归测试，发现问题，修复后再运行测试。在 DevOps 中，代码在整个构建过程中都会持续进行测试和改进。回归测试变得不那么重要。在某些情况下，执行回归测试仍然可能具有价值。

• 安全测试：同样适用于安全测试，传统上这些测试通常是在构建交付后执行。在 DevOps 中，我们在第一次静态分析阶段就检查漏洞和合规性问题。在第十四章，将 DevSecOps 与 DevOps 整合中，我们将更详细地讨论这一点。

测试是为了验证质量。在接下来的章节中，我们将学习质量措施以及如何在我们的 DevOps 项目中实施这些措施。

实施质量措施

到现在为止，应该很清楚 DevOps 中的一切都是关于持续性，换句话说，这意味着持续部署、持续集成、持续测试和持续质量工程。DevOps 项目始终关注每个开发和运维阶段的质量。这与传统的方法不同，在传统方法中，团队会有一个单独的阶段来修复问题。而在 DevOps 中，团队会不断地衡量产品，并在问题发生时立即进行修复。DevOps 的六大原则之一是持续改进，这不仅指的是在每个迭代中改进产品的反馈循环，也指的是 DevOps 流程本身。

在 IT 项目中，一个常见的做法是设置修复阶段，Gerald Weinberg 在他的书籍《完美软件与关于测试的其他幻想》中描述了这一过程。修复阶段通常安排在开发阶段结束后，软件交付给运维部门之前。在 DevOps 中，我们没有修复阶段，因为质量在整个开发和运维周期中都在不断衡量和测试。可以通过下图看到这一点：

图 3.2 – 持续测试（基于 TMAP）

如何衡量质量？首先，什么是质量？我们在本书的开头提到，一切都始于业务。这就是为什么企业架构师在 DevOps 中扮演如此重要的角色。企业架构师的主要任务是将业务需求转化为解决方案。从业务需求出发，产品组合应清晰地列出这些产品应达到的交付标准。这就是质量。质量是指能够满足用户需求和期望的产品或服务。质量是一个满足用户的产品或服务。因此，测试就是验证用户是否能对交付的产品或服务感到满意。

企业在衡量 DevOps 质量时关注哪些内容？主要有两件事：构建本身和其功能验证。对于构建本身，成功构建的数量、缺陷总数和代码覆盖率等是重要的指标。对于功能验证，主要关注是否所有的需求都已被测试，是否所有识别的风险都已被覆盖。

在接下来的几节中，我们将学习如何定义质量以及如何衡量质量，从验收标准开始。

定义验收标准

在我们开始测试之前，我们需要知道我们将测试什么。这就是为什么我们需要定义验收标准。简单来说：什么时候算“好”，足够好？同样，这从用户故事开始，用户故事定义了产品或服务应该包含什么内容。用户故事确定了范围和产品或服务必须具备的具体功能。

如何设定验收标准？问题是，我们正在构建什么？ "它"必须明确，并且必须使“它”变得具体可触。DevOps 团队从四个角度来看待规格：

• 业务：业务要求是什么？

• 开发：我们如何构建一个满足业务需求的解决方案？

• 质量：我们如何测试解决方案并验证它是否满足需求？

• 运营：我们如何管理解决方案，以便它持续满足这些要求？

在 DevOps 中，我们并不是一次性构建整个包，如同瀑布式项目那样。团队从一个最小可行产品开始，然后迭代产品，持续改进。验收标准是针对每个需求设定的，因此，遵循 DevOps 和质量措施的逻辑，每个需求都会经过测试。这就是测试驱动开发（TDD）的做法。在 TDD 中，团队首先编写测试用例，然后编写代码。代码是根据测试用例的规范编写的，证明需求已经得到满足。TDD 流程如图所示：

图 3.3 – 测试驱动开发

TDD 并不是什么新鲜事物，它自五十年代中期就已存在，但最常用的版本由 Kent Beck 描述（请参见进一步阅读部分）。团队挑选一个需求，编写测试用例，开发代码，并运行测试。当测试成功时，代码将进行重构或重写，也就是对代码进行清理和修复，以达到架构师对代码设定的标准。完成此步骤后，代码将使用测试用例再次进行测试。这个循环将为每个需求重复进行。

下一步是评估“准备好定义”（Definition of Ready）并达成“完成定义”（Definition of Done）。我们将在下一节中详细讨论它们。

定义“准备好定义”和“完成定义”

在上一节中，我们学习了如何设置接受标准，以及 TDD 如何帮助确保我们满足特定要求。然而，一个产品或服务在真正进入生产之前，可能有许多要求。

在 DevOps 中，我们使用两个重要的过程来验证一个完全开发的产品或服务是否准备好进入生产。这两个过程是准备好定义（DoR）和完成定义（DoD）。

为了避免错误，请记住，“接受标准”在 DoR 和 DoD 中并不相同：

• 准备好定义（DoR）：要理解 DoR，重要的是要知道敏捷 Scrum是如何工作的。DevOps 团队通常在短周期内进行工作，这一周期称为迭代（sprint），在此期间开发产品的一个部分。需要完成的工作定义为产品待办事项（PBIs）。整个产品或服务通过用户故事来定义，然后拆解成 PBIs——即团队可以在特定迭代中工作并能够在该迭代中完成的任务。

  Agile Scrum 实际上并没有提到 DoR。然而，已成为一种常见做法，制定一套协议来定义何时 PBIs 准备好由团队接手。用户故事的问题在于，在某些情况下，它们没有足够具体的信息来开始构建。DoR 包含了入场标准，让团队知道要构建什么。定义 DoR 的过程称为细化。

• 完成定义（DoD）：与 DoR 不同，DoD 是 Agile Scrum 的一部分，准确描述了一个产品待办事项（PBI）完成时的状态。因此，DoD 是验证构建质量的一个非常强大的工具。开发人员承诺遵守 DoD。他们承诺必须清楚了解需要构建的内容。在 IT 项目中，DoD 至少应包含以下主题：

  • 所有代码已编写完成。

  • 所有代码已被审核并验证。

  • 相关文档已经编写并可供使用。

  • 所有测试已执行并签字确认。

  • 所有功能已证明已交付。

  在 DoR 负责入场标准时，DoD 包含出场标准——完成声明。所有团队成员必须就 DoD 达成一致：业务方、开发人员、测试人员和运维人员。不要忘记最后一组，运维人员需要签署 DoD 并运行软件。对他们来说，验证代码和相关文档是否完成至关重要。此外，在真正的 DevOps 中，我们不会有单独的开发人员、测试人员或运维人员。相反，我们将有具备开发或测试技能的成员。

到目前为止，我们已经讨论了测试策略、质量措施和验收标准。在接下来的部分，我们将学习如何设计测试自动化和执行。

设计测试自动化和执行

在本节中，我们将学习如何设计和实施测试。我们将研究最常见的各种测试类型，并了解在何种情况下使用它们。当我们开始讨论 IT 中的测试时，我们需要讨论并达成一致的测试管理方法。在本书中，我们将使用 TMAP，这一方法由 ICT 服务提供商 Sogeti 于 1995 年提出，并广泛被接受为软件测试的标准。

TMAP 的传统阶段如下：

• 计划

• 准备

• 规范

• 执行

• 评估

在 DevOps 中，这不是一次性的工作；我们将进行持续测试。与传统工作方式的一个主要区别是，不再有单独的测试单元和经理与测试人员。这些专业人员现在是 DevOps 团队的一部分，他们与开发人员一起工作。接下来，在 DevOps 中，我们按照一切皆代码的原则进行工作，从而使团队能够尽可能地自动化。

在我们深入了解持续测试之前，我们需要了解各种测试类型。最重要的类型如下：

• 过程聚焦：测试关注软件中的路径和流程。在 TMAP 中，这被称为路径覆盖。测试覆盖了事务到达某一终点阶段时所遵循的路径。当需要跟随大量路径时，这可能变得非常复杂。在这种情况下，测试会覆盖所有可能的路径和各种决策点。

• 条件聚焦：条件可以是决策点。测试覆盖了决策点及其指向的条件，判断该条件是真还是假。问题在于这将如何影响测试的结果。需要注意的是，这是一个非常简单的解释。从理论上讲，软件将有许多决策点和特定条件，从而影响测试结果。在条件决策覆盖（CDC）测试中，所有决策点和决策结果将根据条件真或假进行测试。

• 数据驱动：此测试通过数据输入来验证测试结果。这类测试通常通过边界值分析（BVA）进行。在测试中，我们输入最小值和最大值，即所谓的边界。这些值可以是数字，也可以是语句。如果我们作为测试用例输入一个超出这些边界的值，那么结果应为“无效”。任何在指定范围内的输入应导致“有效”的结果。

• 以体验为中心：这些测试通常被称为用户体验（UX）测试。所有前面的测试都是二元的。软件按照预期的路径执行，决策点的条件导致预期的结果，输入的数据产生预期的结果。体验则完全不同，因为它天生非常主观。然而，测试人员还是想知道软件“感觉如何”。它反应够快吗？性能如何？是否易于使用？基本问题是：有没有办法以客观的方式测试体验？ 有一些方法论致力于此，其中之一是“经验蜂巢模型”，该模型由 Peter Morville 于 2004 年开发。以下是该模型的示意图：

图 3.4 – 经验蜂巢模型

然而，经验仍然显得有些难以捉摸。它对于了解软件是否符合用户期望非常有用，但要发现软件中的缺陷和问题，测试人员需要进行更精确的测试。需要注意的是，面向经验的测试非常难以自动化。

再次强调，DevOps 中的测试并不是一次性的。在接下来的部分，我们将讨论持续测试。

理解持续测试的原则

在第二章《从架构管理 DevOps》中，我们了解了 CI/CD 流水线。我们看到测试是流水线的一个集成部分。这假设所有软件都是通过 CI/CD 开发的，但在企业中，这通常并非如此。例如，仍然会有遗留系统未集成到 CI/CD 中。同样，软件即服务（SaaS）应用程序也适用：这些是作为服务购买的，因此不会在企业内“开发”。然而，它们仍然需要进行测试。

持续测试的第一步是自动化测试用例。这说起来容易做起来难，但如果测试是从已知模式设置的——例如模拟用户如何使用应用程序，那么这是可行的。如果我们有一个处理购买的应用程序，我们可以考虑三种使用模式：

• 下订单

• 取消订单

• 检查订单状态

步骤可以自动化，通过这一点，我们可以创建一个可以执行的测试用例。

一旦我们有了测试用例和需要测试的代码，就需要一个环境来执行测试。这也可以自动化。通过使用公共云，轻松地按需创建一个（临时）测试环境，并在测试完成后自动停用它。它甚至可以是完整测试场景的一部分，你可以在 Azure、AWS 或其他任何云平台上创建环境，部署代码（或者更准确地说，部署源代码的副本），运行测试，然后在完成后停用该环境。这确实需要自动化基础设施的设置和基础设施即代码（IaC）的实施，稍后我们将讨论这一部分内容。

总结来说，持续测试需要以下几个方面：

• 集成质量工程与测试：测试是 DevOps 团队的一个集成部分——意味着团队中的每个成员都参与到测试中。然而，在运行多个 DevOps 项目的大型企业中，建议有一个质量团队，帮助实施质量措施并测试这些项目中的策略。

• 自动化测试用例：建议从小规模开始。选择一个测试用例并自动化它。为这个测试用例设定基准：成功执行测试所需的绝对数据是什么？将使用哪些指标，测试需要运行多久？不要让测试过于复杂；使用小规模的测试集并进行短时间运行。评估并在需要时调整测试集和测试时间。

• 测试工具：这些工具需要与 CI/CD 流水线集成。本书并不专注于测试工具，但一些流行的工具包括Selenium和Micro Focus 统一功能测试（UFT）。如何选择合适的工具？这实际上取决于你的方法。有些企业偏好单一堆栈解决方案，意味着一个工具涵盖整个测试策略。其他企业则有一套工具，分别用于测试建模和测试执行。同样，与 CI/CD 流水线的集成至关重要。

• 自动化测试环境：自动化测试数据的提供方式、测试用例的执行方式以及如何通过云服务自动化测试环境的配置。自动化环境要求我们将一切定义为代码：

  a) 基础设施即代码（IaC）：虚拟机、网络组件、容器、防火墙——一切都定义为代码。在 Azure 中，我们使用Azure 资源管理器（ARM）模板，而在 AWS 中，首选的方法是使用CloudFormation。

  b) 配置即代码（CaC）：一旦基础设施组件被部署，就需要对它们进行配置，以确保它们符合企业的标准和政策。比如 DNS 设置、证书以及安全策略（如强化和打补丁）。一旦配置完成，我们就达到了期望状态配置（DSC）。

  重要提示

  DSC 是一个通常与 Microsoft Azure 相关的术语。在本书中，我们将使用 DSC 作为一个通用术语，解释云基础设施需要满足架构定义的特定要求，以确保合规性。

  c) 管道即代码（PaC）：CI/CD 过程中每一步都通过代码来定义，从拉取源代码到实际部署，包括测试流程。

  d) 代码即测试（TaC）：代码即测试指的是测试自动化过程本身，从收集、评估和部署测试数据，到实际执行（运行）各种测试并收集结果。我们还可以使用人工智能和机器学习自动验证结果。

在这一部分，我们了解了测试作为一种方法论，在 DevOps 项目中验证质量的作用。我们看到自动化可以为我们的测试策略带来很大的价值。需要做出一个重要的结论：问题不在于自动化本身。目标应该是优化构建并提高其质量。重要的是质量的价值，而不是测试本身。测试将帮助团队通过识别风险并帮助他们了解如何缓解问题，来提升工作质量。这就是我们将在下一部分讨论的内容。我们已经发现了一个问题——接下来怎么办？

了解根本原因分析

在前面的部分，我们讨论了质量措施和测试，如何以高度结构化和自动化的方式验证这些标准。尽管如此，问题仍然可能发生。DevOps 的黄金法则是你构建它，你运行它，通常后面跟着一句话你破坏它，你修复它。甚至可以是你摧毁它，你重新构建它。如果发生故障，团队需要找出到底发生了什么。在这一部分，我们将讨论根本原因分析（RCA），这是寻找问题根本原因的最重要工具之一。

RCA（根本原因分析）是一种寻找问题确切原因的方法。通过 RCA，团队可以获得如何改进产品或服务的洞见。这些改进可能是快速修复或长期优化。RCA 不仅仅是寻找问题的方式；它是改进的起点。在 RCA 中需要解决的重要问题如下：

• 这个问题是什么？

• 发现问题的地方是哪里？

• 为什么会出现这个问题？

• 是什么导致了这个问题？

• 我们可以做出哪些改进，以避免将来出现这个问题？

有多种方法可以进行 RCA。常用的方法包括5 个为什么和鱼骨图（也称为石川图）。5 个为什么是一种通过简单地连续问五次“为什么”来逐步挖掘问题根本原因的简单方法。这有点像小孩不停地重复同一个问题，直到他们对答案感到满意为止。

鱼骨图由石川教授发明，更适合深入分析复杂问题。它从问题开始，然后团队确定可能导致该问题的因素：基础设施、代码、程序员等。这些就是“鱼骨”。然后分析每一根骨头。其基本图示如下：

图 3.5 – 鱼骨图

无论采用哪种方法论，根本原因分析的基本步骤始终相同，如下图所示：

图 3.6 – 根本原因分析的步骤

根本原因分析从收集数据开始，以找出究竟发生了什么。下一步是问题陈述：它是什么时候发生的？在哪里发生？这个问题的影响是什么？尤其是最后一个问题——影响是什么？——很重要。它驱动了项目和商业案例的优先级。如果影响较小，但缓解解决方案将需要大量时间投资，因此会产生高成本，团队可能会决定给予它低优先级，并将其放在项目的待办事项列表中。如果问题影响较大，它可能会成为障碍。需要在团队开始处理任何新任务之前解决它。这是 网站可靠性工程师 的主要原则之一，我们将在 第五章 中详细讨论，通过 SRE 架构下一代 DevOps。

在分析了原因和影响后，团队可以着手解决方案，以减轻问题。最后一步是最终报告。通常的做法是先测试解决方案，并验证该方案是否真的解决了问题。根本原因分析是一个质量度量，而质量度量需要进行测试，正如我们在前面章节中学到的那样。

通过这些内容，我们讨论了测试以及如何通过解决问题来改善产品。但是像 DevOps 中的所有事物一样，我们的目标是持续改进。这也包括了改进基础构建块的路线图，所谓的基础设施、编码框架和 DevOps 环境。这就是下一节的主题。

设计缓解方案

到目前为止，我们已经讨论了如何编码软件、实现所需的基础设施、通过 CI/CD 管道自动化所有操作、测试环境、检测问题，并在需要时修复问题。但我们还没有讨论的是软件开发和 DevOps 本身的速度。

DevOps 就是学习。随着团队和项目的成长，他们学会了如何改进。他们从产品本身及其使用方式中学习，并通过观察其他项目、技术和方法论来学习。这些教训会被采纳并融入到他们自己的项目中。然而，团队不需要重新开始 – 他们可以在前进过程中采用和调整。我们称之为修复，这是改进现有情况的过程。

修复可以在三个层级进行，如下所示：

• 基础设施：假设我们根据“万物皆代码”的原则在 Azure 或 AWS 等公共云中构建每个人，团队将必须考虑这些平台快速发展的情况。架构师有责任“跟踪”云服务的路线图，然后决定是否将新功能纳入项目的路线图中，并改进基础设施。

• 软件/应用程序代码：软件开发人员在代码框架或版本中工作，例如.NET。该框架包含框架类库（FCL），其中包含用于编写代码的语言，以确保不同平台之间的互操作性。通过使用编译器，用 C#、VB.net 和 J#（Java）编写的代码被转换成公共语言基础架构（CLI），以便它可以在 Windows 平台上运行，而无需我们直接编写机器代码。CIL 生成的可执行文件可以在 Windows 和各种 Linux 发行版上运行，如Red Hat Enterprise Linux（RHEL）、Ubuntu、Debian、Fedora、CentOS、Oracle 和 SUSE 等。 .NET 只是其中的一个例子。其他框架包括 ASP.NET、Java、Python、PHP 和 JavaScript。它们都运行特定版本，开发人员必须确保他们的代码正在运行受支持的版本。同样，建议在技术路线图中列出框架版本，以跟踪生命周期。

• DevOps：最后，DevOps 本身有多种实现方式，通常与特定的敏捷工作方式结合使用。换句话说，不仅仅是工具或工具集发生了变化，尽管跟踪 DevOps 工具路线图也很重要。它对源代码控制至关重要。例如，Azure DevOps – 广泛用于在 Azure 中运行 DevOps 项目 – 目前运行 Azure DevOps Server 2020 作为版本控制系统，允许开发人员在代码上共同工作并跟踪更改。

本节的关键要点基本上是永远不要停止学习，永远不要停止改进。IT 正在迅速变化，DevOps 也是如此。DevOps 团队肩负着保持领先的巨大责任，以便企业能够真正从新技术中受益。架构师有责任指导团队，在这方面做出正确的决策。因此，架构师应专注于质量。

总结

本章的主题是质量。我们学习了如何识别质量度量标准，以及这不仅仅是修复漏洞的问题。质量是关于满足期望的，但 DevOps 团队需要能够衡量这些期望。这就是为什么企业、开发人员和运维人员需要明确验收标准的原因。在本章中，我们讨论了 DoR 作为项目工作入门的标准，以及 DoD 用于衡量产品是否真正完成的标准。

测量意味着团队必须进行测试。在传统的工作方式中，测试是在整个产品交付后进行的。而在 DevOps 中，我们采用持续测试。换句话说，所有团队成员都参与到测试和验证产品质量的过程中。在本章中，我们讨论了 DevOps 中常见的不同测试方式和类型。最后，我们谈到了使用补救措施进行持续改进。云平台、软件开发技术和 DevOps 工具在不断发展，DevOps 团队需要适应并采纳这些变化，以便让企业从中受益。

架构师的角色至关重要，因为他们需要在这些开发中提供指导，并帮助团队做出正确的决策。

在下一章中，我们将讨论 DevOps 的扩展。我们从小规模开始，但在企业中，如果我们希望整个业务开始敏捷工作并在 DevOps 团队中工作，就需要扩展。在这一点上，我们该如何处理现有的程序和项目呢？让我们一起来看看！

问题

1. 在本章中，我们讨论了不同类型的测试。其中之一是单元测试。请简要描述一下单元测试。

2. 在数据导向的测试中，我们输入最小值和最大值。如果我们输入一个在这些边界内的值，测试结果应该是有效的。这种测试方法叫什么？

3. 为了决定一个产品是否完成，DevOps 使用了一种特定的技术。这种技术叫什么？

4. 对与错：鱼骨图是分析问题根本原因的好方法。

延伸阅读

• DevOps 团队的质量，作者：Rik Marselis、Berend van Veenendaal、Dennis Geurts 和 Wouter Ruigrok，Sogeti，2020 年

• 测试驱动开发：通过示例，肯特·贝克著，2002 年

第四章：扩展 DevOps

DevOps 最初—并且在一些公司中仍然是—大量依赖手动任务、脚本和临时测试。许多企业集中精力在应用程序上，往往忽视了平台本身——基础设施——而这对扩展同样至关重要。本章重点讨论从技术和组织角度扩展 DevOps。

完成本章后，您将学会如何处理扩展问题。首先，我们将了解现代 DevOps，它采用云计算和云原生技术作为运行应用程序的目标平台。在此之前，我们可能需要对应用程序进行转型；否则，我们将开发新应用程序。在 DevOps 中，我们需要一种适合工作方式的开发方法；因此，我们将讨论快速应用开发（RAD）。接下来，我们将探讨如何在整个企业中推广 DevOps，从小规模开始，逐步扩展。最后，我们将看看关键任务环境以及如何以 DevOps 模式进行管理。

在本章中，我们将覆盖以下主要主题：

• 理解现代 DevOps

• 与 RAD 合作

• 使用 DevOps 扩展基础设施

• 在企业环境中扩展 DevOps

• 管理关键任务环境与 DevOps

理解现代 DevOps

DevOps 的概念并不新鲜。基本上，理念是，如果开发人员和运维人员真正作为一个团队协作，团队的工作就能得到改进。这个原因很容易找到，正如我们在第一章中已经看到的，为企业 DevOps 定义参考架构。在本节中，我们将学习 DevOps 如何随着时间的推移而发展，以及现代 DevOps 对企业信息技术（IT）的影响。我们还将研究 DevOps 如何通过应用程序现代化帮助转型遗留应用程序。

许多企业在 1990 年代决定 IT 不是核心业务，可以外包给供应商。通常，所有的管理—运营—工作都外包出去。这不仅在企业内部创造了孤岛，也在企业之间创造了隔阂。随着时间的推移，IT 变得越来越复杂，需求增加，企业发现自己必须找到方法重新掌控 IT，而 IT 已经成为企业核心业务。

2009 年，第一届DevOps Days大会在比利时举行。基本理念是：打破孤岛，把开发人员和运维人员重新组织成一个团队，提升软件开发的质量和速度。这些目标依然是 DevOps 的核心，至今未变。

但这并不意味着 DevOps 完全没有变化。主要的区别在于云技术和自动化。这两者是现代 DevOps 的两个最重要支柱，具体概述如下：

• 云：早期 DevOps 的一个主要问题是开发和测试系统的可用性。在现代云平台部署中，即使是临时系统也变得更加容易。

• 云原生：开发者和运维之间的壁垒已经被打破，但同样的情况也适用于不同平台之间的技术壁垒。在云原生中，系统之间的互操作性已成为标准，随着平台即服务（PaaS）、软件即服务（SaaS）、容器技术和无服务器功能的出现，云原生技术逐渐普及。未来 IT 发展的两大趋势可能是从软件到服务以及从虚拟机（VMs）到容器，推动跨云平台的可移植性，甚至实现本地系统与云系统之间的互通。

• 自动化：尽可能实现自动化。这意味着在现代 DevOps 中，我们应该将一切视为代码——不仅是应用程序代码，还包括基础设施、配置和集成。在第二章，《从架构管理 DevOps》中，我们讨论了应用程序和基础设施部署的流水线，但在现代 DevOps 中，一切都是通过流水线构建的。

• 所有代码都存储在代码库中：应用程序、基础设施、工具、治理和安全性都被转化为代码，随着一切成为代码，我们可以将所有内容都纳入流水线。因此，除了应用程序代码的部署流水线和基础设施流水线外，我们还将有工具配置、集成、报告和安全性的流水线。

• 集成安全性：对于安全性，我们将使用 DevSecOps，它从“安全即代码”开始。企业的安全姿态被转化为代码，并从一个单一的代码库进行管理。安全姿态的开发与应用程序和基础设施的开发方式相同，都是通过持续改进，而不仅仅是响应攻击、威胁或漏洞。已经开发的代码将立即与安全代码合并，整合安全姿态。安全性与应用程序和基础设施以相同的速度进行开发。本书的第三章，《通过 DevSecOps 架起安全桥梁》，完全讲解了如何实现 DevSecOps，内容从第十二章，《为 DevSecOps 架构设计》开始。

• 增强技术：现代 DevOps 有时被称为加速或智能 DevOps。借助增强的技术，如人工智能（AI）、机器学习（ML）和机器人流程自动化（RPA），自动化可以真正得到利用。举例来说，包括自愈系统或能从先前部署中自主学习的代码和流水线。通过 RPA，过程可以高度自动化，若与 AI/ML 结合使用，可以思考部署中的逻辑下一步——例如，通过从测试结果或系统行为中学习。人工智能 IT 运维（AIOps）就是这一发展的一个很好例子。第八章，构建 AIOps，以及第九章，将 AIOps 集成到 DevOps 中，将深入探讨 AIOps。

总结一下，现代 DevOps 更多的是关于这个：

• 涉及所有利益相关者——这不仅仅是开发人员和运维人员的问题，还包括业务经理、安全专家、质量和保障经理以及采购人员（比如许可证问题）。

• 云及云原生技术的采纳，包括容器、函数和自动化服务。

• 用代码思维，因此也要思考流水线。请记住，随着一切皆代码和深度自动化的实施，我们还需要思考信任原则。我们需要确保流水线中的代码和资源是可信的。接下来，谁有责任声明这些资源是可信的，并可以应用到流水线中？是安全工程师，还是可以委托给开发人员？或者，如果我们有遵循最小权限原则（POLP）的系统，是否可以实现自动化委托？职责分离变得非常重要——需要控制措施来防止未经授权的代码更改。

在本节中，我们讨论了多年来 DevOps 的变化。企业采用 DevOps 的原因是为了整体现代化 IT。企业有着悠久的历史（也包括 IT 领域），因此通常拥有复杂的大型 IT 生态系统以及遗留的应用程序。应用现代化已经成为现代 DevOps 中的重要话题，接下来的部分将讨论这个内容。

介绍和理解应用现代化

DevOps、云、自动化和代码是数字化转型的核心原则。但许多企业将拥有长时间运行的核心应用程序：这些遗留系统不适合采用 DevOps，甚至不准备迁移到云端。在本节中，我们将讨论应用现代化的过程：将这些应用程序转化为能够在云端运行的系统，跟上现代技术的步伐，并通过能够更快适应新需求来支持业务。

注意

应用现代化市场非常庞大。许多公司，如 IBM 和富士通，都有大规模的项目，将主机应用程序转换为云提供商，例如亚马逊网络服务 (AWS)，甚至运行通用商务语言 (COBOL)。企业将其旧的主机应用程序转移到云的原因很容易理解。原始代码尽可能保持不变，但从昂贵的本地设备迁移到按使用量付费的云环境，风险相对较低。缺点是公司仍然需要具有 COBOL 编程技能的资源来维护应用程序本身。换句话说，应用程序本身仍然是遗留的，可能无法采用和从新的云原生技术中受益。下一步将是通过重写代码或在全新的应用程序中重建功能来进一步现代化应用程序。

企业可以采用多种策略进行应用现代化，例如以下几种：

• 重新托管：这是将现有系统原封不动地搬移到另一个目标平台。应用程序被搬移到另一个目标平台时不做任何更改。然而，将应用程序从例如本地环境迁移到 AWS 或 Azure 将意味着一些修改，特别是在连接性方面。这些修改将非常少，并且不会影响应用程序本身。重新托管的常见方法是将包括操作系统和应用程序代码在内的虚拟机导出到新的云环境。这是一种快速迁移应用程序到云的方式，但通过这种方式，企业将不会真正体验到云服务的实际好处。他们只是在另一个数据中心运行他们的机器，即 AWS、Azure 或任何其他公共云提供商的云数据中心。

• 重新平台化：通过重新平台化，应用程序被优化以在云中运行。一个非常常见的例子是将数据库重新平台化为 PaaS。数据库实例被移至 AWS 关系型数据库服务 (RDS) 或 Azure 结构化查询语言 (SQL)，这两者都是由平台管理的本地数据库服务。开发人员仍然可以像以往一样编写数据库程序，但他们不再需要担心数据库平台本身。这些事项由提供商负责处理。

• 重构：有时也称为重新架构。在这种情况下，应用程序代码会被修改，以便在云中以优化的方式运行。会应用云原生服务。应用程序代码可能会被重写，以便在容器中运行或使用无服务器功能。应用程序的功能保持不变：仅底层技术发生变化。以本节开头的 COBOL 示例为例：COBOL 代码可以重写为 C#或 Java。然而，架构师和工程师首先需要将业务逻辑与代码本身解耦。如果业务要求修改业务逻辑，那么策略就变为重建。

• 重建：在重建的情况下，架构师首先重新验证应用程序的功能。业务所需的功能是什么？哪些数据将被使用，这些数据如何转化为应用程序的使用？接下来，应用程序将根据验证后的业务和技术需求进行重建。功能恢复，技术完全重新审视，应用程序被重建。

现在，重新托管在成本方面不会带来真正的好处。只有当应用程序被重新平台化或重构时，才可能实现成本节省，因为云资源的使用将得到优化。

重建是另一个故事。这可能会导致重大项目，从而产生项目成本。只要应用准备好在云端投入生产，就可能实现可观的节省。然而，企业需要考虑总体拥有成本，因此需要将项目成本和重建应用可能带来的风险纳入考虑。企业架构师在提供建议和支持决策方面发挥着重要作用。下图展示了云成本组成部分的一个非常简单的概览：

图 4.1 – 云和 DevOps 成本的简单概览

企业以及负责的架构师应该采取哪些步骤开始应用现代化？让我们在这里看看：

• 导入：架构师收集与应用相关的所有数据。他们可以通过分析配置管理数据库（CMDB）中的信息，使用工具扫描应用程序，或者通过与利益相关者（如业务和应用所有者）进行研讨会来实现这一目标。

• 评估和架构设计：下一步是评估所有数据。架构是什么样的，它如何与现代的——云——架构进行映射？在这一阶段，目标架构被定义，同时也定义了未来的操作模式，即应用程序的执行和管理方式。DevOps 工作模式和持续集成/持续开发（CI/CD）流水线被纳入未来架构中。这定义了转型的方法。简而言之：在这一阶段，架构师定义了什么（应用程序和架构的样子）和如何（如何将当前应用程序转型为现代应用程序）。什么和如何共同构成了解决方案。

• 决策：所有相关方面的信息都已传达给利益相关者：应用程序的功能、技术实现、风险和成本。商业案例已得到验证，基于此，做出了是否继续的决策。

• 执行：项目启动。交付成果和技术路线图已在功能、产品待办事项和任务中定义。组件被细化并纳入构建迭代周期中。测试被执行，验收标准被验证，完成定义（DoD）随着项目进展逐步签署确认。

下图展示了应用程序现代化的高层次过程：

图 4.2 – 应用程序现代化的高层次过程

总结来说，应用程序现代化包含以下内容：

• 一个引人注目的商业案例。现代化一个应用程序是否值得？该应用程序对业务的重要性有多核心？

• 一项引人注目的策略。是重新平台化、重构，还是重建？或者，是否明智的做法是先进行简单的“提升和迁移”到云端，并在新平台上开始转型？

• 一份引人注目的计划。是否已经识别出风险？团队是否具备缓解这些风险的正确技能和工具？了解了风险之后，计划在多个迭代周期内可行吗？

我们讨论了传统应用程序以及企业如何对这些应用程序进行现代化，但企业还将开发新代码并推出新的或改进的服务。由于我们在 DevOps 模式下工作，我们必须关注一种能够跟上这一进程的开发方法论。RAD 是一种解决方案，我们将在下一节中学习 RAD。

与 RAD 合作

到目前为止，我们讨论了 DevOps 如何打破开发人员和运维人员之间的壁垒，以及它如何帮助加速产品、服务和系统的开发。实施 DevOps 将提高开发速度，但 DevOps 本身仅仅是规划开发的一种方式。它有助于以迭代方式进行规划：从最小可行产品（MVP）开始，然后在下一版本中进行迭代改进。DevOps 不是关于代码本身的开发。我们需要一种开发方法来编写代码，但这种方法应该与 DevOps相契合。在本节中，我们将讨论 RAD。

为什么 RAD 适合 DevOps 和敏捷工作方式？主要原因是 RAD 本身就是敏捷的。RAD 从原型设计（MVP）开始，然后专注于迭代。重点是满足需求，而不是规划。它允许开发人员在开发周期中快速实现改进和调整。

RAD 的关键原则还有代码的重用和利益相关者之间的密切合作：业务代表、架构师、开发人员、测试人员、工程师以及最终将使用该软件的客户。代码不断地进行审查、测试，并根据需求进行验证，这些需求通过小的改进来实现。通过这种方式，最终产品不符合规格的风险更小。团队对每一个小步骤都有完全的控制权。

为了根据 RAD 进行开发，团队需要遵循以下五个基本步骤。这些步骤与 DevOps 的原则完全一致：

1. 定义需求：收集业务需求，设定范围、预算、时间表和验收标准。让所有利益相关者签字确认，以确保每个人都同意交付物和最终产品。

2. 构建：开发从 MVP 开始。接下来，MVP 会经过迭代改进，直到最终产品交付。请记住，在 DevOps 中，开发人员和运维人员需要就产品达成一致，因此他们必须密切合作。运维是否能够管理应用程序，或者它能否进行改进？在 第五章，《通过 SRE 架构下一个层次的 DevOps》中，我们将学习运维如何推动开发中的改进，例如自动化。

3. 收集反馈：我们在前一章中了解到，DevOps 接纳持续测试作为质量衡量标准。这意味着反馈会不断被收集。这是技术性反馈和功能性反馈。开发人员使用这些反馈来改进下一次迭代或版本。这也是 DevOps 文化的一部分：反馈不应被视为批评甚至是判决。反馈实际上是一个改进项目质量的工具。

4. 测试：与收集反馈相结合，软件需要持续测试。代码是否正常工作，是否符合需求？测试可能是 DevOps 项目中最重要的事情之一。在第三章中，我们讨论了测试策略和不同类型的测试。

5. 发布：如果产品已达到最终状态，则可以进行上线并投入使用。在发布时需要注意的两个问题是用户培训和后期维护阶段。用户需要学习如何使用产品和软件，并且要准备好在产品投入生产并实际使用后，可能仍然会出现问题。在后期维护模式下，团队仍然可以快速解决这些问题。

   然而，DevOps 已经在其内部解决了这个问题。问题产生反馈，并被回馈到项目中，推动改进。实际上，团队会创建快速通道，以便优先处理生产环境中的问题。这可能会暂停产品的进一步开发和新功能的开发。正是这一点在站点可靠性工程（SRE）中得到了处理，这也是下一章的主要话题。

总结来说，RAD 过程如图所示：

图 4.3 – RAD

在本节中，我们学习了如何在 DevOps 项目中整合软件开发。软件需要基础设施来运行。在下一节中，我们将讨论扩展基础设施。

使用 DevOps 扩展基础设施

现代 DevOps 的一个关键特性是使用云技术。在本节中，我们将讨论为什么企业通过将基础设施迁移到 AWS、Azure 等云平台中能获得巨大的好处。首先，我们将研究扩展的原理，因为这是使用云基础设施的主要好处之一。在本节的最后，我们还将探讨容器的下一层级扩展，因为在未来几年，将会从虚拟机（VM）转向容器。

在 DevOps 项目中，开发人员使用管道，如我们在上一章所见。代码从代码库中拉取，修改，测试，并推送到下一个阶段。代码遵循一个晋升路径：从开发到测试、验收，最终到生产系统。开发和测试系统可能并不总是需要的；它们只需在流程中需要时出现。如果工作完成，这些系统可能会被暂停或甚至退役。云的好处在于，如果这些系统未使用，企业无需为其支付费用，这与作为一次性投资购买的本地硬件相矛盾。因此，按需扩展开发和测试系统是云基础设施的一个巨大优势。

现代 DevOps 的另一个重要特性是自动化。使用云基础设施的一个主要好处是能够实现自动扩展。然而，架构师和工程师可能需要在自动扩展方面小心一些。确实，企业在云中按需付费，而在传统的工作方式中，企业在需要额外容量时必须购买物理机器。其优点是，架构师真的需要考虑所需的容量。

在云中，可能不再有需要担心容量的驱动因素。然而，这种想法是完全错误的。在需求高峰和没有设置限制的自动扩展情况下，云账单可能会让人吃惊。因此，企业，特别是财务人员，应该不完全依赖扩展。换句话说，架构师仍然需要承担规划容量的责任。

现在，让我们学习不同的扩展类型，如下所示：

• 纵向扩展或纵向扩展：我们以一台服务器为例来解释这个概念。该服务器有一个处理器、2 千兆字节 (GB) 的内存和 100 GB 的磁盘存储。如果我们进行纵向扩展，我们会向该服务器添加处理器、内存或磁盘存储。我们将资源添加到同一台机器上，从而提高其容量。只要服务器有空间添加资源，就可以这样做。我们可以想象，在虚拟的编码世界中，这比在物理机器上容易得多，因为工程师们真的需要拿出螺丝刀来安装，例如，额外的内存条。下面的图示展示了纵向扩展的原理：

图 4.4 – 纵向扩展或垂直扩展

• 横向扩展或横向扩展：现在，我们向环境中添加更多的服务器，而不是增加服务器内部的资源。这在公共云中非常常见，特别是当我们使用负载均衡器来处理流量并将工作负载分配到可用服务器时。通过自动扩展，当负载增加且现有服务器无法处理而不降低性能时，可以自动添加服务器或服务器池。一旦负载减少，环境会再次缩小。负载均衡器—比如 AWs 中的 弹性负载均衡 (ELB)—确保负载均匀分配到可用资源上。

  然而，请记住，应用程序需要具有扩展感知。有些应用程序根本无法处理扩展，而有些则可以进行横向扩展，但如果进行纵向扩展，会影响应用程序的可用性。以下图示展示了水平扩展的原理：

图 4.5 – 横向扩展或水平扩展

• 完全或动态扩展：这是垂直扩展和水平扩展的结合。一旦达到向上扩展的限制，环境可以进行向外扩展。在大多数情况下，水平扩展是通过克隆服务器来完成的。在 Azure 中，我们可以使用 Azure Automation 来执行此操作。在 AWS 中，我们可以复制服务器的镜像，然后使用 弹性计算云（EC2）和 AWS Systems Manager Automation 启动新机器。当然，还有许多第三方工具也可以帮助自动化扩展。

在云中进行扩展有明显的好处。我们可以根据需求获取资源，按需扩展到特定时间所需的容量。由于我们只为使用的部分付费，因此如果不再需要资源，可以通过缩减资源来节省开支。例如，开发和测试系统可能并不总是需要，工作完成后可以暂停使用。也许团队可以完全停用这些系统，只需在项目需要时立即启动新的系统。

最好的一点是，DevOps 团队可以完全自行控制这一过程——他们不再依赖于采购部门来订购硬件或要求工程师将其安装到数据中心。所有这些都是代码，包括扩展集，并且可以完全集成到管道中，随时待命。

使用容器进行扩展

IT 基础设施即将发生一个重要变化，即从虚拟机（VM）迁移到容器。推动这一变化的原因是不同平台之间系统的互操作性。容器似乎是一个非常好的解决方案，能够使软件在不同平台之间实现互操作性，并具备最终的可扩展性。然而，架构师需要考虑几个方面。首先，他们必须明白容器也需要一个基础设施来承载。容器本身无法独立运行。

容器在计算集群上运行，管理层使得资源共享和任务调度能够在容器内的工作负载之间进行。资源是计算集群，即一组服务器——通常称为节点——用来托管容器。管理或编排层确保这些节点作为一个整体来运行容器并执行容器内部构建的进程——即任务。

集群管理跟踪集群中资源的使用情况，如内存、处理能力和存储，然后将容器分配给这些资源，以便以优化的方式利用集群节点，并确保应用程序运行良好。

换句话说，扩展容器并不完全是关于容器本身，而更多的是关于扩展底层基础设施。为了简化这一过程，Google 发明了一个叫做 Kubernetes 的编排平台，它负责集群管理。Kubernetes 使用 pods，允许不同容器之间共享数据和应用代码，形成一个统一的环境。请字面理解上一句话。Pods 遵循共同命运原则，这意味着如果 pod 中的一个容器失败，所有容器都会一起崩溃。

下图展示了 Kubernetes 的基础工作流程：

图 4.6 – Kubernetes 的高层架构

不过，好消息是，pods 可以通过复制控制器进行复制。Kubernetes 会检查指定数量的 pods 是否在集群节点中运行。如果需要，pods 会被复制，确保指定数量的容器正在运行。

容器是一个很好的解决方案，但仍然存在一些不足之处。最重要的一点是，容器和集群可能是互操作的，但通常网络和存储层并非如此。为了扩展容器解决方案，我们还需要网络和存储层的集成。例如，Azure Blob 与 AWS 的简单存储服务（S3）完全不同，但 Kubernetes 可以在两个平台上运行，使用Azure Kubernetes 服务（AKS）和 AWS 的弹性 Kubernetes 服务（EKS）。虽然会有解决方案来克服这一点，但在规划容器平台时，绝对需要考虑到这一点。

在企业环境中扩展 DevOps

我们已经讨论了 DevOps 的好处，以及云计算的采用、自动化和敏捷工作方式如何为企业带来改变。现在的大问题是：如何开始，在哪里开始？ 这里的看法各不相同，从爆炸式方法到逐步实施。

那些将大量 IT 工作外包给不同供应商，并且已经在某种方式下工作了几十年的企业，并不容易改变。首先，员工会有很大的抵触情绪——记住，DevOps 不仅仅是关于技术的变化，它同样涉及到心态或文化的改变。在这一部分，我们采取逐步采用的方法，或称演进而非革命。

这里有一些建议：

• 从小做起：不要一开始就把 DevOps 实施在大型项目上。组织一个小团队和一个简单的项目来学习——更重要的是——识别流程中的可能瓶颈。是什么可能阻碍 DevOps 的工作方式？资源是否具备所需技能，团队是否由合适的人员组成？团队是否具备所需的工具？即使是一个简单的构建，需求是否明确？流程是否与 DevOps 对齐？从瓶颈中学习，并在每个步骤中改进。

• 从最终目标开始：要清楚你要去哪里，最终的产品会是什么样子。分小步迭代工作并不意味着团队不需要对项目的最终目标有明确的了解。同样，在企业中实施 DevOps 也适用。从企业架构的角度，必须清楚该企业的战略是什么：它在 1 年、3 年或 5 年后会处于什么位置？定义企业的路线图有助于设定目标。以下图示给出了一个示例：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/entp-dop-arch/img/B17492_04_007.jpg)

图 4.7 – 企业采用 DevOps 的路线图

上面的截图显示了三个基本阶段，概述如下：

• 基础：架构师定义目标操作模型，基于涵盖应用、技术、安全、服务和治理的参考架构。在这个阶段，云采用是一个重要话题：主要的云平台，如 Azure、AWS 和 Google Cloud，都拥有云采用框架（CAFs），它们将在云中运营系统的基础搭建中提供帮助。

• 采用：这一阶段是关于采用基础和目标操作模型。云环境已经设置完毕，并且在 DevOps 模式下启动了第一个——小规模——项目。可以引入基础设施即代码（IaC）和 RAD 等概念。实施的方法之一是建立一个卓越中心（CoE），由主题专家（SMEs）组成，他们可以在模型的采用过程中提供指导，包括云技术、DevOps 工具的使用以及敏捷教练帮助实施敏捷工作方式。在下一节中，通过 CoE 进行扩展，我们将讨论 CoE 的设置。

• 扩展：我们已经有了参考架构，定义了目标操作模型，并指派了一组专家参与卓越中心（CoE），帮助采用新模型并交付首批项目。在这个阶段，模型可以在企业中进行扩展。

• 确保所有步骤都是可见的：透明度是 DevOps 的关键。这适用于团队内部的工作方式以及产品交付过程。工具必须能够提供开发和发布链中发生的事情的完整可视性，即 CI/CD 管道。理想情况下，团队应该有一个单一的视图来观察发布链中的事件：这些工具能够从管道和系统中收集实时数据。但同样，团队成员需要清楚其他成员的工作内容，因为 DevOps 本质上主要是关于紧密合作。团队成员需要能够跟踪活动、预见问题，并在必要时进行纠正。最终目标是更好的产品。

• 随时准备迎接变革：这一点看起来显而易见，但在 DevOps 中，没有什么是石刻定案的。如果某些方面可以改进，团队应该被激励去采纳那些能够促进改进的变化。这不仅适用于 DevOps 团队及其项目，也适用于整个企业。即使是世界上最大的企业，也时不时需要按下刷新按钮，借用微软首席执行官（CEO）萨提亚·纳德拉的说法。

我们已经介绍了 CoE。在接下来的部分，我们将详细阐述这一点。

使用 CoE 进行扩展

一个起点可以是一个 CoE（卓越中心）。再次强调，这听起来像是个大事情，但其实不一定。相反，CoE 可以是开始转型企业的一个良好切入点。CoE 是一个团队，负责领导或支持员工和组织采用、迁移并运营新技术，甚至是一种新的工作方式。简而言之，CoE 可以是企业数字化转型的起点。与其试图一口气改变整个企业，我们可以指派一个团队来引导这一过程。CoE 的主要目标是定义并帮助实施最佳实践，推动架构实施、转型和优化运营，以及实现治理。

CoE 的安装也应该分步骤进行，首先是定义标准和政策的 CoE。因为这个原因，架构师应该是 CoE 的成员。接下来，CoE 定义守护轨道，确保使用最佳实践。不要重新发明轮子，而是使用已经存在并在其他企业中经过验证有效的方法。但这也有风险。风险在于，团队可能会把事情做得太大。

一个常用的框架来实施敏捷工作方式是SAFe，即规模化敏捷框架。它可能包括实施 Spotify 模型，并设置 tribes（部落）和 squads（小队）。对于任何公司来说，这些都是巨大的变化，即便只是在一个团队中进行，也会影响整个企业，尤其是当 IT 外包并且供应商的资源需要参与新组建的小队时。企业与供应商之间的合同是否考虑到了这种新的工作方式？没多久，我们就可能在实施一个征服全球的计划。

这并不意味着我们不能使用 SAFe 的原则，但我们需要确保它适合并且能够被采纳。CoE 可以帮助定义和控制采纳的关卡，并提出改进建议。这种类型的 CoE——仍然是一个小团队——被称为规范性 CoE。

CoE 的下一个级别是咨询级别。在这个阶段，CoE 作为一个由不同领域的SMEs（领域专家）组成的（虚拟）团队，积极帮助 DevOps 团队执行项目。CoE 负责制定标准和政策，并控制和验证是否遵循这些标准和政策。从这一点开始，DevOps 和敏捷的实施加速，打破了原有的组织壁垒。然而，这一过程是一步一步进行的。

从小团队的简单项目开始，DevOps 和敏捷似乎并不适合开发和运行关键任务环境。但事实并非如此。企业可能想要从关键任务开始，但如果 DevOps 得到了适当的扩展，并且有清晰的应用现代化计划，我们也可以以 DevOps 的方式开始管理关键环境。本章的最后一节，使用 DevOps 管理关键任务环境，将进一步解释这一点。

使用 DevOps 管理关键任务环境

在本节中，我们将讨论 DevOps 在关键任务环境中的应用，以及为什么它能够用于管理核心应用程序。首先，我们来定义一下关键任务。

一个非常直接的定义是：任何企业为了保持业务运营所需的软件。如果一个关键任务系统发生故障，企业可能会损失大量资金，无论是因为直接的交易丧失，还是由于一些较为无形的损失，例如声誉损害。这些系统通过业务影响分析（BIA）过程进行识别。

当我们开始 DevOps 项目时，架构师首先做的事情是收集业务和技术需求。这将包括 BIA 过程的结果，通常是与内部审计员和业务利益相关者合作完成的。通过 BIA，能够识别出在这些系统发生故障时需要迅速恢复的关键系统或系统组件。这是一个非常繁琐的过程，会引发很多讨论。

企业架构师需要理解，利益相关者对于什么是关键系统可能有不同的看法。银行的金融系统是业务关键的，但如果一家汽车工厂的首席财务官（CFO）无法访问财务报告——假设是一个小时左右——该工厂的业务不会立即受到影响。然而，如果该工厂的组装机器人发生故障，生产将立即停止。

企业仍然不愿意将关键系统托管在公共云中，因为他们认为如果这些系统不位于工程师在紧急情况下可以立即进入的私有数据中心，他们就会失去对系统的控制。然而，公共云可能是托管这些系统的最佳选择。由于这些平台具有巨大的容量，很容易在不同的区域和可用区内复制关键系统。如果一个云数据中心发生故障，第二个数据中心可以接管。使用云技术，可以最小化数据丢失的风险。云技术提供了构建更具弹性环境的工具。

DevOps 在哪里发挥作用？它体现在起草业务连续性计划（BCP）中，BIA 是该计划的输入。没有真正的技术原因说明为什么关键任务系统不能托管在云端并通过 DevOps 开发和管理，但考虑到这些系统需要具有高度的弹性，有几个问题需要考虑——例如，在计划和应用变更时。

注意事项

关于没有真正的技术原因表明关键任务系统不能托管在云中的说法，还有一个细节需要注意：延迟可能是一个问题，即信息在系统之间传输所需的时间。另一个原因可能是法律和法规要求的合规性。一些组织根本不允许将系统托管在不位于其所在国家或地区的云数据中心。这些也是在进行 BIA 时需要考虑的因素。

DevOps 中的一个持续主题是 CI。这伴随着变更，而变更也会对业务连续性产生影响。对于关键系统，我们必须确保发布过程的设计能够保障业务连续性。因此，质量保证至关重要。

首先，代码创建后要尽快进行测试。对于关键系统，测试必须集中在确保代码推送到生产环境时，企业的关键业务流程不受影响，或者影响非常有限，并且是以事先明确接受的风险水平进行的。接下来，确保有回退、回滚或恢复机制。

团队如何确保他们计划发布的内容是安全可行的？答案是进行上线运行。这里，我们在 第三章，为 DevOps 质量构建架构 中讨论过的推广路径起到了关键作用。上线运行是一项在接受系统上经过测试的代码的实际操作。该系统的规格应该与生产系统完全相同。更好的是：接受系统是生产的精确副本，它们是类生产系统。上线运行是在 CI/CD 管道中完成的，使用代码并将其处理并推送到接受系统。但这不仅仅是代码的问题。流程、安全性、故障转移到不同的系统以及恢复程序也必须进行测试。DevOps 工具需要能够支持这一点，作为业务连续性计划（BCP）或框架的一部分。

本章结束。在最后一节中，我们讨论了弹性和可靠性。在 第五章，与 SRE 一起构建下一代 DevOps 中，我们深入探讨了如何通过 SRE 架构来实现可靠性。

总结

本章涵盖了很多内容。在大型传统企业中，开始实施 DevOps 并不容易，但这是可能的。在本章中，我们了解到可以从小规模开始，然后逐步扩展。小规模开始并不意味着企业不需要有明确的最终目标：企业架构师在定义目标运营模型以及企业未来如何开发和运营产品方面扮演着关键角色。拥有专业领域专家（SMEs）的卓越中心（CoE）可以在这一转型中提供指导。

公司很有可能有一些遗留环境需要进行转型。我们已经讨论了现代 DevOps 和使用云技术及云原生技术。我们还了解了不同的应用程序转型策略，以及如何在 DevOps 模式下使用 RAD 开发新应用程序。

在最后一节中，我们还了解到，即使是关键任务系统，如果我们专注于这些系统的弹性和可靠性，也可以以 DevOps 方式进行开发和管理。SRE 是实现这一目标的方法。我们将在下一章学习 SRE 中的架构内容。

问题

1. 我们正在将一个应用程序从本地系统迁移到 Azure。SQL 数据库已迁移到 Azure SQL 作为 PaaS 解决方案。我们称这种迁移策略为什么？

2. 请列出 Azure 和 AWS 提供的 Kubernetes 服务。

3. 要评估业务关键系统，我们需要分析这些系统的需求。这种分析的方法论是什么？

进一步阅读

现代 DevOps 宣言 (medium.com/ibm-garage/the-modern-devops-manifesto-f06c82964722)，作者：Christopher Lazzaro 和 Andrea C. Crawford，2020 年

第五章：利用 SRE 架构下一代 DevOps

在前面的章节中，我们讨论了 DevOps 的来龙去脉。之所以叫 DevOps，是有原因的，但实际上，Dev 通常更被强调：通过加速开发来创造敏捷性。站点可靠性工程（SRE）则更强烈地关注运维。那么，在开发交付的产品越来越多，速度越来越快的情况下，运维如何生存下去呢？答案就是 SRE 团队，通过使用错误预算和艰苦工作来应对。

完成本章后，你将了解 SRE 的基本原则，以及如何帮助企业采纳和实施这些原则。你将对如何为 SRE 定义关键绩效指标（KPI）以及这些指标将为组织带来哪些好处有一个清晰的理解。

本章我们将涵盖以下主要内容：

• 理解 SRE 的基本原则

• 评估企业是否具备 SRE 准备条件

• 使用 KPI 架构 SRE

• 实施 SRE

• 从 SRE 中获得商业价值

理解 SRE 的基本原则

在这一部分，我们将简要介绍 SRE，这一方法最早由 Google 发明，旨在解决 Google 因推出大量新开发而完全被运维工作淹没的问题。SRE 有很多定义，但在本书中，我们将使用 Google 自己的定义：如果你允许一名软件工程师设计运维，所发生的事情就是 SRE。

基本上，Google 解决了开发和运维之间的鸿沟。开发人员因需求改变代码，而运维则尽力避免因这些变化导致服务中断。换句话说，开发和运维团队之间总是存在某种紧张关系。我们将在本章中进一步讨论这一点。

那么，SRE 是下一个级别的 DevOps 吗？这个问题的答案是：SRE 在 Dev 和 Ops 之间架起了一座桥梁。基于此，接下来的问题自然是：这座桥梁有必要吗？在下一部分中，我们将了解到，仅仅将开发和运维放在同一个团队中是不够的。两者之间存在天然的利益冲突。因此，企业需要做更多的工作，才能真正从 DevOps 模式中获益。这正是 SRE 所做的事情。

SRE 中的关键主题包括可靠性、可扩展性、可用性、性能、效率和响应。这些内容被整合为七个原则——摘自 SRE 工作手册——与架构相关：

• 运维是一个软件问题：这是 SRE 的出发点。软件会变化，但运维需要保持稳定，以确保服务不被中断。这意味着软件需要具备弹性并经过严格的测试。

• 根据服务级目标（SLOs）工作：为服务设定明确的目标。一个应用程序的可用性应该是什么？这些不仅仅是 IT 相关的目标。商业需求首先设定了参数。这意味着项目必须与业务利益相关者紧密合作，以定义目标。

• 尽量减少无意义的劳动：我们将进一步讨论“无意义的劳动”（toil），但从原则上讲，它指的是单纯的工作。此外，无意义的劳动是指可以通过自动化避免的手动工作。基本上，SRE 的目标是尽可能让计算机为你完成工作。

• 自动化：在第三条原则之后，这一点是合乎逻辑的。如果可以自动化，就应该这样做。

• 快速失败：失败是可以接受的，只要它在非常早期就被发现。在早期阶段修复问题，其影响要远远小于在开发和部署周期的后期阶段发现并修复问题。而且，早期发现并解决问题将降低成本。

• 每个团队成员都是所有者：这一点需要稍微解释一下，尤其是在大型企业中，我们通常会有矩阵式的组织结构。再一次，记住很多企业采用外包模式，其中特定供应商负责基础设施（平台），而其他供应商和企业本身负责应用程序（产品）。在 SRE 中，这些边界是不存在的。产品和平台团队共同承担最终产品的责任。因此，产品和平台团队需要对每个组件有相同的看法：应用程序代码、前端系统、后端基础设施以及安全规则。它们都是项目的平等所有者。

  注意

  我们将在第六章中详细讨论这个问题，架构中的运营定义，我们将在那里了解平台运营和产品运营。

• 使用统一的工具集：所有团队使用相同的工具。你可以有多个 SRE 团队，但他们都使用相同的工具。这样做的原因是，企业需要花费过多时间来管理不同的工具集，而不是专注于项目交付。SRE 的核心也是专注。

没有办法仅用几段话甚至一个章节总结 SRE。本节只是一个非常简短的介绍。不过，SRE 可以为企业带来很多东西——前提是企业已经为此做好准备。SRE 也意味着工作方式和组织的改变。在下一节中，我们将进一步了解这些内容。

评估企业是否具备 SRE 准备条件

在上一节中，我们介绍了 SRE 并讨论了基本原则，但并没有抱有全面阐述的雄心。涵盖整个 SRE 将会填满超过 500 页的书；我们仅提供了最重要部分的快速概览。那么问题来了：我如何知道我的公司是否准备好采用 SRE？我们将在本节中探讨一些 SRE 准备度的标准。

实施 DevOps 的公司常见问题之一是开发人员和运维人员并没有真正合作。他们可能坐在同一个团队里，但开发人员写完代码后，仍然会在认为代码完成时把它扔到另一边交给运维。原因在于开发和运维的工作心态不同。开发人员想要变革，他们根据业务需求进行任务分配，改进或构建新的应用程序。而运维人员则不希望有这样的变动，他们的主要兴趣是确保系统稳定，避免因故障或变更而导致的停机。因此，最初就存在利益冲突。

问题是如何弥合这种冲突。SRE 是对此的答案。然而，SRE 是一种方法论，只有当团队准备好采用这种方法论时，它才能成功。所以，我们需要评估的第一件事就是文化。没错：企业架构师在其中确实起着作用。这关系到流程以及让人们采纳这些流程。记住，架构不仅关乎什么，还关乎如何做。

重新定义风险管理

开发人员会修改代码；运维人员需要确保系统保持稳定，以便业务不受影响。变更可能导致停机。如果停机是计划好的，那么就无需太担心。关键在于未计划的停机。因此，我们需要关注减轻因变更而引发的意外故障的风险。为了避免故障，系统需要可靠且具有弹性。由于在 DevOps 中，迭代和变更是持续部署的，因此设计可靠性的需求变得越来越重要。架构师需要以这样的方式设计系统，使其能够在不干扰服务的情况下应对变更。

首先，让我们统一一下风险管理的定义。基本规则是，风险等于概率乘以影响。企业使用风险管理来确定实施措施的商业价值，这些措施能够限制概率和/或影响——或者用 SRE 术语来说，风险管理用于确定可靠性工程的价值。此外，它还定义了为防止、减少或转移风险而进行的投资水平。

风险管理用于在 SRE 团队的产品待办事项中优先考虑可靠性措施。这是通过遵循称为 PRACT 的风险矩阵来实现的：

• 预防：完全避免风险。

• 减少：降低风险发生的影响或可能性。

• 接受：接受风险的后果。

• 应急措施：当风险发生时，计划并执行相应的措施。

• 转移：风险的后果被转移，例如转移给保险公司。

风险矩阵的一个示例在下面的模板中提供：

图 5.1 – 风险评估模板

首先，我们需要识别并评估风险。风险是什么？它发生的几率有多大？它的影响会是什么？这些内容显示在图的上半部分。接下来，我们需要考虑减缓措施，即可以或必须采取的行动，以防止风险或减少风险的影响。当减缓措施降低了风险水平时，会有风险残留。此时，团队需要评估这些残留的影响以及是否可以接受。

如果故障的影响很大，那么值得考虑采取一种能够防止风险的策略。这将推动 SLO（服务级目标），即系统应该达到的标准。如果可用性设置为 99.99%，那么错误预算只有 0.01%。这对系统架构有影响；毕竟，风险评级允许每年最多 52 分钟的停机时间。架构需要考虑到这一点，例如，采用镜像的热备份系统，一旦主系统发生故障，可以立即接管。

那么代码呢？编写具有弹性代码的关键要素有两个：

• 源代码需要保存在一个具有强大访问和版本控制的安全仓库中。代码更改需要完全可追溯。

• 自动化的持续测试，以便在开发和部署的每个阶段检测代码中的缺陷。测试和自动化可能是架构师在 DevOps 中最需要关注的功能，以确保代码的弹性和安全性。

即使我们作为架构师已经做了所有防止系统停机或软件故障的工作，我们仍然会不时遇到问题。SRE 中的一条重要规则是无责事后总结（blameless post-mortem）。我们将在 使用 KPI 进行 SRE 架构设计 部分讨论这一点。

重新定义治理

DevOps 已经假定团队以高度自主的方式工作，这意味着他们负责整个产品的全生命周期。这需要不同的治理方式。在上一章中，我们讨论了卓越中心作为一种组织形式，用于引导和支持 DevOps 团队。卓越中心定义了整体企业路线图和框架，提供了开发和管理系统的指导方针。

目前，DevOps 仍然是关于开发和运维，实际上它们仍然是分开的。SRE 团队没有这种划分。因此，SRE 团队与 DevOps 团队是不同的。SRE 团队是跨领域的，这意味着他们关注系统监控、日志记录、事件处理和自动化。他们帮助开发和实施自动化，还在 DevOps 过程中发布时提供建议和指导。SRE 工程师能够帮助定义系统架构，但也能通过提供最佳实践和选择合适的工具来推进企业架构。

有三种方式来建立 SRE 团队：

• 拥有专门的 SRE 工程师的团队：这些团队与 DevOps 团队是分开的，但支持 DevOps 团队。一个大优势是，许多团队和不同的项目能够同时得到支持，且使用相同的愿景、工具和流程，从而提高了不同项目的整体质量。

• 嵌入式模型：SRE 工程师嵌入到 DevOps 团队中。这种方式的优点在于，SRE 工程师能够专注于他们所分配项目中的特定问题。

• 分布式 SRE 模型：在这种模型中，SRE 团队更像是一个卓越中心，团队中的专家可以被咨询以解决问题。

一个典型的 SRE 定位方式如以下图所示：

图 5.2 – SRE 在 DevOps 中的位置

必须明确的一点是，SRE 要求文化上的变革。SRE 专注于改善运维，同时也促进高效的开发和发布。这通常意味着，SRE 专家需要对技术和流程进行高度标准化。如果开发和运维得到了标准化，那么自动化过程也会变得更容易。通过这样做，SRE 减少了风险发生的可能性。因此，工程师能够腾出时间去处理其他任务，而不是花费大量时间解决问题。这就是 SRE 的关键要点。

下一个问题是组织如何实施 SRE。这从定义 KPI 开始。在下一节中，我们将研究 SRE 中最重要的 KPI。

使用 KPI 架构化 SRE

在我们深入了解 KPI 的定义之前，我们需要回顾一下 SRE 的基本原则。SRE 团队关注的是可靠性、可扩展性、可用性、性能、效率和响应性。这些都是可衡量的项目，因此我们可以将其转化为 KPI。在本节中，我们将学习如何通过使用 SLO、服务级指标（SLI）和错误预算来实现这一点。

我们在 SRE 中使用的主要 KPI 如下：

• SLOs：在 SRE 中，SLO 被定义为系统应该有多好。SLO 比 SLA 更精确，后者包含了很多不同的 KPI。你也可以说 SLA 包含了一些 SLO。然而，SLO 是 SRE 团队的开发人员与服务的产品负责人之间的协议，而 SLA 是服务提供者与最终用户之间的协议。

  SLO 是一个目标值。例如，Web 前端应该能够处理每分钟数百个请求。开始时不要让它太复杂。通过设定这个 SLO，团队已经面临了不少挑战，因为它不仅涉及前端，还涉及网络和相关数据库的吞吐量。换句话说，通过设定这个目标，架构师和开发人员将需要做大量工作才能达到这个目标。

• SLIs：SLO 是通过 SLI 来衡量的。在 SRE 中，有几个非常重要的指标：请求延迟、系统吞吐量、可用性和错误率。这些是关键的 SLI，用来衡量系统的实际表现。请求延迟衡量的是系统返回响应之前的时间。系统吞吐量是每秒或每分钟的请求数。可用性是系统对最终用户可用的时间。错误率是总请求数与成功返回的请求数之间的百分比。

• 错误预算：这可能是 SRE 中最重要的术语。SLO 也定义了错误预算。预算从 100 开始，通过扣除 SLO 来计算。例如，如果我们有一个 SLO，说明系统的可用性是 99.9%，那么错误预算就是100 - 99.9 = -0.1。这是 SRE 团队在不影响 SLO 的情况下应用更改的空间。它迫使 SRE 团队中的开发人员要么限制更改和发布的数量，要么尽可能地进行测试和自动化，以避免对系统造成干扰并超支错误预算。

要理解 SRE 中的错误预算概念，首先要理解 SRE 如何处理系统的可用性。这不仅仅是简单地从停机时间中扣除得到系统的可用性。SRE 会考虑失败的请求。一个失败的请求可能是因为系统没有响应或者响应很慢。检测失败的请求决定了可用性，从而决定是否超出了错误预算。重要的参数如下：

• TTD：在软件或系统中发现问题的时间。

• TTR：修复或解决问题的时间。

• 频率/年：每年错误的频率。

• Users：受错误影响的用户数量。

• Bad/year：每年系统不可用的分钟数，或每年的不良分钟数。

与错误预算一起工作的流程如下所示：

图 5.3 – 使用误差预算

风险应被视为商业风险：即危及企业业务的风险。认识到风险后，就会产生对系统和软件的需求。这些需求被转化为 SLO（服务水平目标），定义了系统应达到的水平。SLO 通过指标进行衡量，准确地告诉你系统的实际表现。如果 SLO 没有达到要求，将会触发风险的显现。系统可能失败，并且无法满足 SLO 的机会就是误差预算。误差预算——通常在预算超支时——将导致需求调整和系统改进。

尽管我们在可靠性方面做了大量工作，但企业仍然会面临问题，因此也会发生宕机。SRE（站点可靠性工程）的一个关键元素是无责事后复盘，这可以在不同层次上执行。每当发生事件或项目完成后，我们都可以进行事后复盘。无责事后复盘真正强调的是文化：它调查事件发生的原因，而不是归咎于人。SRE 团队只是认为所有参与的团队成员都已尽最大努力避免事件的发生。

团队评估问题，并提出建议，以避免问题再次发生。这可以是对流程的改进或工具的使用。此外，建议还可能涉及人员，例如对某些领域的人员进行培训。这不是为了责怪，而是为了不断改进。

如果将所有内容结合起来，SRE 是一个真正的整体模型。它涉及流程、工具和人员。以下图表展示了 SRE 的整体视图以及它如何与 DevOps 结合：

图 5.4 – SRE 的整体视图

在本节中，我们介绍了 SRE 的主要方面。大多数企业面临的首要问题和挑战是：我们从哪里开始？我们将在下一节中讨论这一点。

实施 SRE

到目前为止，我们已经了解了什么是 SRE 以及其关键元素是什么。在本节中，我们将学习如何开始实施 SRE，但像 DevOps 一样，建议从小规模开始。接下来有两个主要步骤，可以帮助您以受控的方式实施 SRE：

• 达成标准和实践一致：这可以仅适用于一个 SRE 团队，或者如果目标达到了这个程度，也可以适用于整个企业。在某些工作手册中，这被称为厨房水槽，意思是所有内容都是 SRE。这对拥有有限应用程序的公司来说是可行的，但对于企业来说，可能更明智的做法是与 SRE 团队的章程合作。

  让我们用一个非常常见的例子，接下来我们也会在后续章节中使用。企业通常有产品团队负责应用程序，平台团队则负责基础设施。最佳实践是有一个 SRE 团队作为桥梁，连接产品团队和平台团队，为这个特定领域制定标准和实践。产品团队将专注于应用程序的交付，显然会与平台团队密切合作。SRE 团队可以为此提供指导，并为最终产品的可靠性设定标准。这意味着 SRE 团队需要涵盖多个领域，如下图所示：

图 5.5 – SRE 的领域

• 确定服务范围：显然，在 SRE 旅程的开始，SRE 团队不能做所有的事情。因此，我们需要确定 SRE 团队的范围。他们是只做咨询，还是会积极参与 DevOps 项目？或者他们只会参与 DevOps 的自动化？一些公司有专门的 SRE 团队负责工具，一个只关注实现自动化工具的 SRE 团队，涵盖整个 DevOps。SRE 的最终步骤是待命，无论何时运营中出现问题并超出错误预算时，SRE 工程师会被召集来调查问题，指导事后分析，并帮助实施新的解决方案以确保可靠性。

由于 SRE 是 Google 的发明，Google 已经发布了详细的指南，逐步实施 SRE。Google 确定了三个接受标准来开始 SRE：

• SLO 已经定义并与业务负责人达成一致。

• 无责备的事后分析可以执行。

• 企业有一个流程来管理生产问题。这可以是 IT 服务管理框架中定义的标准事件管理流程，例如 ITIL。

SRE 从哪里开始，团队如何开始他们的工作？

1. SRE 专家在企业内部被招聘或培训。

2. 发布流程由 SRE 专家进行文档化并评估。

3. 操作流程进行文档化，包括发布和交接给运营的手册。这些流程由 SRE 专家进行评估。

4. SLO 已经定义并达成一致。

5. SRE 团队被授权调整并实施能够减少重复劳动的流程。与开发人员和运营团队的合作，确保各方的支持，是一个先决条件。

后者至关重要，但更重要的是，SRE 团队应该以无责备的方式进行此工作，正如在上一节讨论的无责备事后分析（blameless post-mortem）所述。对程序、流程以及系统故障根本原因的每次评估都应避免指责，而应专注于改进。SRE 团队可以对所有新的和现有的流程进行此类工作：

• SLO 和错误预算审查

• 事件评审

• 测试和操作手册评审

• 安全审计

然而，在团队真正开始之前，组织需要有明确的优先级。如我们所学，SRE 将引发文化的变革，整个组织必须支持 SRE 的实施。除了我们用于实施 SRE 团队的模型——专职、嵌入式或分布式——SRE 的指导方针和守护机制将影响整个企业。这意味着企业必须有一个战略。

通常，企业不会从绿地情境开始。总会有现有的产品、项目和流程，无法一蹴而就地改变。谷歌在引入该方法论时就意识到了这一点。企业通常是棕地，进入转型阶段。在这种情况下，他们需要考虑优先级以及如何开始转型。2013 年，谷歌的 SRE 工程师 Mickey Dickerson 提出了可靠性层级模型。模型如下：

图 5.6 – Dickerson 的可靠性层级

金字塔的理念是，底部的项目是需要首先实现的基础，它们构成了基础。从这里开始，转型将进展到更高级的项目，例如金字塔顶端的新产品开发和部署中的发布链。

我们已经确定了目标和任务，分配了团队，并在实施过程中达成了优先级的共识。但 SRE 是否真的能为企业带来好处呢？我们将在本章的最后一节回答这个问题。

从 SRE 中获得商业价值

正如我们在上一节中学到的，企业并非在短短几天内就能实现 SRE。正确实施它需要时间和耐心。但这值得吗？显然，答案是肯定的。SRE 将为企业带来巨大的商业价值。在本节最后，我们将解释如何实现这一点。

当今的企业正在持续转型。这给运营带来了巨大的压力，一方面要跟上发展的步伐，另一方面还要保持系统的稳定性和可靠性。在开发与运营之间没有真正的协作，这几乎是不可能的。SRE 解决了这一挑战。SRE 认识到，把开发人员和运维人员放在同一个房间并不能解决问题。SRE 创建了一个解决方案，通过帮助开发人员构建可靠的系统来减少运营问题。关键组件如下：

• 标准化：标准化流程和工具。

• 自动化：自动化带来一致性，但自动化还可以实现扩展性。这需要经过深思熟虑的架构设计。自动化是指一次性完成某项任务，然后让自动化处理其余的工作。如果没有自动化，运营将被手动任务淹没。

• 消除琐事：琐事是手动操作、重复性工作，可以通过自动化来完成。但琐事也是那些对产品没有增值的工作：它们会干扰工作，减缓那些能为产品增值的服务开发进程。

• 简化：软件需要简洁，这是稳定、可靠系统的前提。代码需要简洁和清晰，API 也要尽可能简化。SRE 遵循“少即是多”的黄金法则。

通过这样做，企业将受益于高效的开发，同时在解决问题时花费更少的资源。时间和资源可以投入到进一步的改进中。因此，企业可以从采用 SRE 中获得大量收益。因为 SRE 涉及到一种非常系统的方式来构建、管理和审查系统，企业可以信任可靠的服务。重复的任务将通过标准化和自动化来接管。企业在多个方面都会从中获益：

• 可靠的服务将赢得客户的信任，并可能带来更多的收入。

• 由于自动化，手动任务得以减少。这将降低运营成本。SRE 工程师的首要任务就是自动化那些重复性的工作。

• 由于标准化，系统将变得更加可靠和稳定，减少故障和停机的发生。分析问题和解决故障需要资源，因此非常昂贵。它们无法为业务带来价值，但必须解决，以避免影响业务运转。

• 节省的成本可以投入到新功能和新产品的开发中。换句话说：SRE 将成为创新的推动力。SRE 将为企业带来诸多好处，但实施需要投入和愿意接受不同的文化。和敏捷开发及 DevOps 一样，建议从小规模开始，然后在全公司范围内推广。通过从错误中学习、优化和持续改进。

总结

本章介绍了 SRE 的基础知识。原始工作手册包含超过 500 页内容，因此几乎不可能在几页内总结出整个方法论。然而，完成本章后，你将对 SRE 的基本原则有一个很好的理解，从 SLO 的定义开始，设定系统性能要求。随后，我们通过一些指标来衡量 SLO，看看系统实际表现如何。我们了解到，通过风险管理、错误预算和无责事后分析，SRE 工程师可以帮助 DevOps 团队改善系统，使其更可靠。

本章的结论是，SRE 在企业中的实施并不容易。我们讨论了实施的第一步，了解到如果执行得当，SRE 将带来好处。企业将从 SRE 中获益，因为很多手动工作可以被减少，从而腾出空间来改善现有产品或开发新产品。

本书的第一部分到此结束。在下一部分，我们将迈出下一步，学习现代技术如何帮助企业并进一步优化运营。人工智能是其中一个有前景的新技术，基于此，我们将在本书第二部分介绍 AIOps。

问题

1. SRE 使用什么术语来标记应该减少的重复性手动工作？

2. TTD 和 TTR 这两个术语是什么意思？

3. 当我们转移风险时，我们该怎么做？

进一步阅读

• 多云架构与治理，作者：Jeroen Mulder，Packt 出版社，2020 年

• 实用站点可靠性工程，作者：Pethuru Raj Chelliah，Shreyash Naithani，Shailender Singh，Packt 出版社，2018 年

• 你有 SRE 团队了吗？如何开始并评估你的旅程：cloud.google.com/blog/products/devops-sre/how-to-start-and-assess-your-sre-journey

第二部分：通过 AIOps 实现 Shift Left

在这一部分，您将了解运维在企业中的角色和任务，以及它是如何融入架构中的。您还将了解到，运维的角色正在发生变化。在 DevOps 中，运维与开发人员紧密相连。DevOps 的目标是提高开发的速度。因此，运维将需要更加高效，花费更少的时间来运行操作。这正是 AIOps 带来的优势，它通过自动化和智能化，更快速地发现异常，甚至通过自动修复来解决问题。架构师如何设计为 AIOps 做好准备的系统，甚至可能向 NoOps 转型？

以下章节将涵盖此部分内容：

• 第六章，架构中的操作定义

• 第七章，理解人工智能对 DevOps 的影响

• 第八章，AIOps 架构设计

• 第九章，在 DevOps 中集成 AIOps

• 第十章，迈向 NoOps 的最后一步

第六章：在架构中定义运维

在采用 DevOps 的企业中，运维的角色正在发生变化。运维的首要任务是保持服务的正常运行，但在新的数字化运营模式中，许多这些任务可以并且将会被自动化。在我们开始考虑自动化运维之前，我们需要对企业中运维的角色、任务、活动和领域有清晰的了解。本章是捕捉企业架构中运维的指导框架。我们将学习如何为运维设计架构，并定义数字化运营模型。

完成本章后，你将了解运维的角色和责任是什么，以及如何在架构中处理这些问题。我们还将看到运维如何在云、云原生服务和使用微服务的事件驱动架构的影响下发生变化。我们将设计一个数字化运营模型，并区分平台和产品运维。最后，我们将讨论如何将企业提升到持续运维的水平。

本章将涵盖以下主要内容：

• 了解运维管理

• 在企业架构中定义运维

• 定义数字化运营边界模型

• 了解事件驱动架构中的运维

• 使用成熟度模型进行运维规划

了解运维管理

在我们开始定义企业架构中的运维管理之前，包括这些角色之间的角色划分，我们需要了解 IT 运维的内容。在本节中，我们将讨论 IT 运维的定义以及IT 运维管理（ITOM）。

首先，为什么这很重要？DevOps 有时倾向于专注于开发：探索和构建新特性和新产品。在讨论发布管理和 CI/CD 时，也会关注开发和部署过程。但运维和开发同样重要，而且 IT 运维的角色正在发生变化。不仅仅是因为 DevOps，还因为许多企业正在经历数字化转型。我们将在本节中深入了解这一点。

简单来说，我们可以说，IT 运维包括支持企业用来满足客户服务的硬件和软件的所有过程。因此，IT 运维负责终端用户设备的功能，如笔记本电脑，但也包括为企业客户提供服务的产品。一个简单的例子是一个网站，客户可以在上面订购商品，包括其基础设施（Web 服务器）和应用代码（前端应用和数据库）。IT 运维还有一个重要任务，就是确保 IT 资产的质量。

以下过程在 ITOM 中至关重要：

• 监控：IT 运维是 IT 的“眼睛”，因此，强大且具备弹性的监控系统至关重要。在监控方面，并没有真正的一刀切方法。运维将与不同的系统合作，控制基础设施、应用程序、接口、备份任务以及许多其他组件。挑战在于如何从这些系统中得到一个概览，以便能够关联系统状态、故障和潜在问题。例如，某个 Web 服务可能没有响应，因为数据库不可用。端到端监控是 IT 中常用的术语，它指的是监控系统模拟整个 IT 系统链中的事务。

• 事件管理：任何中断系统正常运行的事件都是一次事件。运维的任务是通过监控识别事件，并尽快解决它。可以通过应用临时解决方法来恢复系统正常，但最好还是修复问题并确保它不再发生。这就是问题管理的核心。

  提示

  作为一名架构师，参与运维工作多年后，我学到了一条每个工程师和架构师都应该好好掌握的重要经验：没有什么比临时解决方案更持久的了，尽管它能快速解决问题。它可能是最快让系统恢复正常的方式，但从长远来看，这些快速修复会导致新问题。其原因之一是，快速修复通常文档不充分，过了一段时间后，没人知道它们是如何应用的。

• 问题管理：在这里，事件会被更深入地分析。此外，还会探讨事件的趋势。运维需要与工程师和架构师保持一致，提出解决方案，以防止事件再次发生。

• 变更控制和发布管理：运维将面临系统变更，在 DevOps 中，这些变更将会经常发生。然而，确保系统在没有重大、未计划的中断情况下持续运行是运维的责任。这就是变更控制过程。这个过程的一部分可能是在变更执行之前进行最后一次备份，以确保系统状态和数据的安全。开发人员和运维需要在应用变更时保持充分的协调。这是在发布管理过程中完成的。

在传统的工作方式中，运维将收到新的发布版本，然后决定何时部署，以确保现有服务能够继续运行而不受干扰。在 DevOps 中，流程则不同。在这里，团队共同承担部署新版本的责任。

总之，运维必须在任何情况下保持服务的持续运行。DevOps 和数字化转型对运维有着重大影响。让我们回顾一些趋势：

• 云与云原生：这可能听起来显而易见，但云和云原生技术对 IT 运维有着巨大的影响。矛盾之处在于，这些技术的许多目标是减少 IT 环境的复杂性，但另一方面，它们也因云端资产而增加了复杂性。IT 环境正越来越变成一个 API 生态系统，运维人员不仅要管理虚拟机、应用程序和网络连接，还要管理将 PaaS 和 SaaS 解决方案与企业 IT 环境连接的应用程序编程接口（API）。

• 数据中心退役：随着企业将 IT 系统迁移到云平台，可以合理推测私有数据中心正在被清空并退役。在这里，传统的运维工作，包括数据中心管理，并没有消失，而是转变为管理云平台中的虚拟数据中心。再次强调，一切都在变成代码，而在传统的数据中心，操作人员仍需照料物理机器。

• 更快的网络：企业对系统与自身更近的需求已不再那么迫切。系统可以托管在全球云平台上。高速网络连接解决了延迟问题，因此几乎没有限制系统可以落地的地方。在不久的未来，我们将看到更快的网络进入市场：这是许多新兴服务的要求。想想实时数据分析、量子计算或仿真技术，以及依赖高速连接的技术，例如跨全球传输图像的技术。网络是一切的基础，运营将需要更多关注这些网络的弹性、敏捷性和性能。

• 全球化：全球云服务提供商，如 Azure、AWS、Google Cloud 和阿里巴巴云，在全球范围内都有数据中心。能够在完全不同的地区启用灾难恢复，从而增强系统的弹性，这是一个巨大的好处。然而，也有许多需要考虑的因素，比如企业是否受到法律法规的约束，要求将数据存储在其所在国家或地区的境内，或是在该地区提供服务。IT 的全球化有其优点，但也有缺点。

• 左移到更左移：过去几年里，IT 知识共享的理念获得了很大的推动。左移也意味着 IT 系统迎合了自助帮助：系统的设计使得用户可以轻松找到解决问题的方法。在更左移的情况下，新增了一个元素：系统从用户那里学习，并调整软件，以避免问题再次发生。这也是最终趋势将发挥巨大作用的地方：人工智能（AI）和机器学习（ML）。

• 人工智能与机器学习：最后但同样重要的，是人工智能（AI）和机器学习（ML）将改变运营领域的主要趋势。这包括自学习、自修复系统，甚至能够预测某些行为并据此采取相应行动的系统。在运营中，我们将看到诊断系统，它们从问题中学习，或者修复问题，或者提供处理建议。这些系统还能够关联事件：如果链条中的某个系统失败，AI 将知道它将如何影响该链条中的其他系统，并采取缓解措施，例如拍摄系统状态的快照，以便更快、更准确地识别根本原因。

此时，你应该知道运营不会变得更简单，IT 也不会变得更不复杂。这种复杂性将会转变和演变。好消息是，这些新技术将帮助你更好地预测系统行为，设计更具弹性，并通过更快地找到问题的根本原因并采取迅速、准确的纠正措施，进一步降低风险。

这如何融入我们的架构？我们将在下一部分讨论。

在企业架构中定义运营

IT 运营不是企业架构的一部分，这意味着企业架构并不定义企业必须如何进行运营。充其量，运营架构是技术架构的一部分。在这一部分，我们将详细阐述企业架构的组件，然后研究运营架构的具体内容。

企业架构包括以下架构组件：

• 业务架构：这涵盖了业务功能和组织架构，包括其运营。从业务架构中，应该能清楚地看到产品和服务是如何交付的，以及在设计、构建和运行它们时所遵循的流程。业务架构从产品战略开始，其中包括描述企业交付的产品和服务。

• 治理架构：这定义了谁负责执行各项流程。这是企业运营的蓝图，包括 IT 的战术计划，明确了流程的实施、操作和监控方式。

  运营是商业和治理架构中的关键组成部分。运营负责在整个交付链中稳定地交付产品和服务。重要的是要意识到运营服务管理和运营管理之间的区别，后者通常被称为 ITOM。服务管理包括我们在第一部分《理解运营管理》中讨论的典型 ITSM 或 ITIL 流程，如事件管理和问题管理。ITOM 更多侧重于 IT 技术，并专注于应用程序和基础设施的运营。企业架构也涉及到这一点。

• 数据架构：这描述了数据如何被使用；即为什么以及由谁或什么过程来履行某项服务。运营在根据企业的数据原则确保数据可用方面起着重要作用。这些原则通常涉及数据隐私和合规性规则。因此，运营需要与安全和数据隐私官员密切合作。

• 应用架构：这描述了应用程序的构建和使用。同样，运营在保持应用程序运行，包括数据库和中间件方面，发挥着关键作用。强烈建议在应用程序开发的最初阶段就将运营纳入其中，以确保应用程序可以真正由运营管理。想象一下将新的云原生技术应用于应用程序：企业需要确保运营团队具备操作这些技术的技能。

• 技术架构：最后，这描述了企业中使用的所有技术组件。它应包括硬件和软件等产品、标准和原则、服务和政策。

下图显示了企业架构中的各个层级：

图 6.1 – 企业架构的组成部分

运营架构可以是技术架构的一部分，但在更详细的层面。它至少包括以下组件：

• 生产调度/监控

• 系统监控

• 性能监控

• 网络监控

• 事件管理（事件、问题、变更）

两个事项值得特别关注：

• 服务级别协议（SLAs）：供应商与客户之间的合同，明确描述服务提供的具体条件，通常使用关键绩效指标（KPIs）。运营需要根据这些 KPIs 提供服务。

• 运营级别协议（OLAs）：SLA 的一部分可以是 OLAs，定义组件之间的相互依赖关系，并构成 SLA 所涵盖的服务。例如，SLA 可能描述一个需要 99.9%时间可用的 Web 应用程序。该应用程序本身可能依赖于数据库服务，而这些服务并不在应用程序链中，由不同的运维组负责。OLA 将处理这种相互依赖关系。

在本节中，我们得出结论，IT 变得越来越复杂。企业期望运维不仅能保持系统稳定，还能跟上新发展的步伐。为了使运维能够完成这些越来越苛刻的任务，他们需要一个调整过的运营模型来应对这种数字化转型。为此，他们还需要合适的工具。在下一节中，我们将讨论这种新的数字化运营模型，然后进入 AIOps 工具的世界。

定义数字化运营划分模型

运维的角色和位置正在发生变化；我们在本章的第一节中已经看到这一点。除了新技术和不断发展的技术对运维的影响外，最重要的原因是从项目导向向产品导向的持续交付转变。

这是什么意思呢？大多数企业曾经习惯于做项目，通常是瀑布式项目。每个项目都有一个明确的结束日期，整个项目按照时间线和里程碑规划。在 DevOps 中，焦点转向了产品：它从最小可行产品（MVP）开始，然后团队在短期的 2 到 3 周的冲刺中不断改进它。

在冲刺结束时，产品和交付物会进行审查。开发人员和运维团队会与这些团队合作。在传统模型中，运维会获得最终产品，然后决定如何以及何时发布。而新的运营模型必须更加敏捷、适应性强，并且嵌入到 DevOps 中。在本节中，我们将更详细地讨论这种新的运营模型。

在数字化运营模型中，理解开发和运维的角色非常重要：

• 开发设计并部署。

• 运维完成并管理，包括检测和修复。然而，在 DevOps 中，检测和修复会反馈回开发阶段。

为了创造敏捷性，我们需要在不同的运维任务中设定划分。我们将有运维专注于产品，运维专注于平台。如果我们希望提供以产品为导向的交付，这是一个必要条件。在基于敏捷和 DevOps 的数字化运营模型中，业务部门与产品团队合作，共同定义所需的产品及其特性。产品运维工程师将支持这些产品的交付，而平台工程师则确保平台——即基础设施——准备好接纳产品并提供持久稳定的服务。

下图展示了一个具有划分层次的模型：

图 6.2 – 具有产品运维和平台运维的分层界定模型

在接下来的章节中，我们将进一步解释该模型：

• 平台运维：平台是着陆区——基础设施。它需要稳定存在，且保持稳定。产品团队不应该担心平台的可用性。在大多数数字化运营模型中，平台通常是（公共）云平台。

  管理平台的团队与产品团队是解耦的。平台运维包括更新、升级和优化，还会部署新的基础设施功能。这些都需要与产品团队紧密合作，以避免对服务的干扰。

  在平台运维中，建议的角色有（云）平台经理、（云）平台架构师和平台工程师。这个运维团队可能还需要有一个 API 集成专家，因为平台越来越像是一个 API 生态系统。这些 API，例如 SaaS 和 PaaS 解决方案，需要与平台集成。

• 产品运维：这是设计、构建、部署和管理产品的层级，以 DevOps 模式进行。简单来说，这就是产品从基本想法开始，通过多次迭代，最终由产品运维控制的层级。在这个团队中，我们需要平台工程师来桥接产品的需求与平台之间的联系。这些平台工程师需要接受培训，具备基础设施即代码、配置即代码、自动化和 API 编程技能。他们将与平台运维团队进行对接。

  在这一层以及产品团队中建议的运维角色有基础设施工程师和测试人员、开发人员，以及参与产品设计的特定领域架构师。

  引入敏捷和 DevOps 的一个陷阱是，企业可能会远离传统的 IT 服务管理流程。然而，在第一节中我们简要讨论的关于理解运营管理的操作流程依然非常有效。这就是为什么在数字化运营模型中，我们需要角色和责任来解决这些流程：

  • （主要）事件经理

  • 问题经理

  • 变更经理

  • 资产经理

  我们可以通过使用 RACI 矩阵来实现这一点。RACI 代表责任人、负责人、咨询者和知情人。下表展示了服务管理流程的一个简单 RACI 示例：

图 6.3 – 服务管理流程的 RACI 矩阵示例

R、A、C 和 I 的位置是有争议的，但这没关系——只要所有相关人员都清楚地知道谁负责什么就行。

• 业务：这是最顶层，战略在此制定，产品的需求也在此定义。在新的数字化运营模式中，新增了一些角色，例如客户旅程分析师和设计师。该模型的核心思想是使企业更具敏捷性，并能更快地将新产品推向市场。企业需要了解客户的需求以及他们如何体验产品，以便使产品成功。

  这对于运维也非常重要。记住，开发和运维必须从头到尾保持一致。运维也需要参与到客户旅程中。在这种情况下，运维的一个特定角色是服务经理：他们需要了解即将到来的内容，以及如何在新服务中采用这些内容，同时确保现有服务不会受到干扰。

还有一个重要的层级缺失了，但实际上这并不是一个单独的层级。安全性和安全管理是一个跨越的层级，应嵌入到每个其他层级中。

因此，我们在各个层级都有工程师和架构师，紧密合作。但应该明确的是，他们需要某种框架来进行工作。那就是企业架构。企业架构师位于模型的最顶部，紧密与客户旅程设计师、开发中的领域架构师以及运维架构师合作。

IT4IT 由 The Open Group 提出，针对这种新模式提出了企业的前进方向。IT4IT 划分了四个阶段或价值流，用于产品的生命周期。这些价值流非常准确，因为 IT 创造了价值——从一个想法到实际服务的产品开发过程：

1. 规划：从战略到组合

2. 构建：从需求到部署

3. 交付：从需求到履行

4. 运行：从检测到修复

以下图表展示了这些价值流：

图 6.4 – IT4IT 价值流

交付和运行价值流是运维流。请求到履行包括目录管理、履行和服务使用管理。运行是关于预测和解决问题。运维可以通过使用事件驱动架构来帮助完成这些任务。我们将在下一部分讨论这一点。

理解事件驱动架构中的运维

让我们再次回顾运维的最重要任务：保持服务的正常运行。为了实现这一点，我们定义了一些帮助管理系统的流程。事件和问题管理是关键流程；也就是说，按照 IT4IT 的术语，从检测到修复。问题在于，事件管理几乎默认是反应式的：一旦发现问题，就会触发行动以寻找并修复问题。在下一个阶段，通常是在问题管理中，会进行更深入的分析，设计解决方案以防止问题再次发生。

事件管理是运营的一个组成部分。在数字化运营模式中，挑战在于如何在不同的 IT 系统甚至平台之间编排和自动化这些事件。事件驱动架构解决了这个问题，实际上，它是 AIOps 的起点。我们将在第八章《AIOps 架构设计》中详细讨论这一点。

事件驱动架构最初旨在帮助设计应用程序，使其能够响应事件。事件被定义为触发反应的状态变化。以下图表提供了一个在 Archimate 中构建的示例：

图 6.5 – 用于处理支付的简单 Archimate 模型

在这里，我们有一个业务事件：订单已下单。这触发了一个业务功能，在这个示例中被称为 订单履行。这个功能的一部分是 支付，它触发了银行的外部系统，提供支付服务。一旦支付被接受，订单就会从该功能转移到下一个业务事件，即 订单配送。

提示

Archimate 是一种推荐的建模方法，用于设计功能并将其映射到 IT 组件需要履行的流程上。Archimate 使用视角来建模从业务流程到应用程序和技术的过程。一个常见的视角是产品视角，它展示了产品为客户带来的价值。架构师可以使用 Archimate 模型来定义产品的组成，包括不同的服务和服务之间的接口。Archi 是一个免费的工具，可以用于设计 Archimate 模型。Archi 可以从 www.archimatetool.com/download/ 下载。

在这个——非常简单——的示例中，客户支付了他们下的订单。订单状态现在变为已支付，并触发一个将订单推送到配送的过程。事实上，支付过程本身也会触发其他新事件，例如需要与银行或支付服务建立连接。在银行内部，会触发一个检查买家账户的过程，并向订单系统发送“OK”或“不 OK”的状态消息。

简而言之，状态的变化将触发许多新的事件。这些事件不一定发生在同一个系统中，正如我们在这个例子中所看到的那样。事件可以驱动通过 API 连接的其他系统中的决策。这是微服务和面向服务架构（SOA）的基础。微服务是独立运行的服务，通过 API 相互通信。这些服务由自给自足的团队管理，团队负责开发、构建和运行这些服务。因此，可以公平地说，采用微服务的事件驱动架构得到了 DevOps 的良好支持，DevOps 团队对交付特定服务负有端到端的责任。

为了实现这种架构，我们需要将服务定义为可重用、可扩展和可互操作的独立功能。这些是 SOA 的基石，实际上，许多云技术源自 SOA 原则。PaaS 和 SaaS 解决方案被定义为 SOA，这意味着它们可以在不同的环境中重用和共享，可扩展，并且在不同平台之间具有互操作性。

这一切如何影响运维？简单来说：他们必须在许多不同的应用、系统和平台之间保持服务——准确地说是微服务——的正常运行。运维必须通过使用连接独立部署服务的接口来处理分散的持续交付。传统的监控方式将不再足够：运维需要一个统一的视图——所有服务及其相互连接的整体视图。

现在，让我们回到我们的例子，假设我们有一个需要支付的订单。订单状态将从未支付变为已支付，并触发配送。只有当银行批准支付后，状态才会发生变化，因此状态变化的触发来自一个与实际持有订单的服务不同的外部服务。如果银行和订单队列之间的 API 失败，操作员需要知道这一情况。因此，监控应该包括监控到银行的 API，并检查银行服务是否在线。在这里，跨整个链路的事件监控变得至关重要，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/entp-dop-arch/img/B17492_06_006.jpg)

图 6.6 – 完整链路事件管理和监控

这必然会增加运维的复杂性，这就是为什么我们需要尽可能寻找自动化的方法。微服务、SOA 和事件驱动架构创建了更可靠的系统：独立服务仅等待触发器执行动作并启动下一个服务。独立服务允许“点火并忘记”模型：系统触发一个触发器，然后忘记它；接着，系统继续下一个事件和下一个触发器。但我们希望确保触发器确实被接收，并可能甚至检查触发器是否被正确处理。

在接下来的几章中，我们将学习如何监控这些过程，以及如何在基于微服务的事件驱动系统中自动化事件管理。这正是 AIOps 的作用：通过 AI 和 ML 使运营变得更加简单。

使用成熟度模型进行运营规划

在本节中，我们将研究 IT 运营的成熟度模型。然后，我们将学习如何将其应用到企业，并使其实现持续运营。最后，我们将学习如何准备好以便 AIOps 可以实施。

基本的运营成熟度模型如下所示：

图 6.7 – 运营成熟度模型

第一级有时被称为混乱阶段。这里的过程没有记录；操作只是简单地在应急情况下应对问题。在这个级别，工具决定了操作的方式，而不是建立一个定义工具集的架构。大多数企业已经经历了这个阶段。

然而，许多企业卡在第二级。这是承诺级别，在这里流程是被定义的。事件、问题变更和项目管理已经就位，但这些流程只是以非常有限的方式集成在一起。没有全面的事件管理或单一面板视图。换句话说，事件仍会触发意外的系统行为，并可能严重影响业务。

大多数企业将处于第 3 和第 4 级之间，具体取决于它们在数字转型过程中的位置。第三级，积极预防级别已经相当具有挑战性。在这个级别，企业可以分析趋势，实施端到端的事件监控，自动化其 IT 的较大部分，并且最重要的是，可以预测事件并采取积极措施。这是 AIOps 可以发挥重要作用的级别。我们将在第七章中详细了解这一点，理解 AI 对 DevOps 的影响。

在四级，IT 交付完全被定义为业务服务。在这一层级中，事件驱动架构变得相关。业务功能与 IT 服务相对应。实际上，IT 服务可以支持业务决策。有一个明确定义的服务目录，所有的流程都已经整合，包括成本管理。IT 成熟度模型中的最终阶段是对业务事件和创新的实时响应，这些都融入了运营过程中，从而为业务创造价值。这是持续运营阶段，在这一阶段，我们将反馈环路整合到开发流程中，但这是实时且完全自动化的。大多数企业会在某些应用程序和业务功能中达到这一层级，但很少会在整个企业和所有业务流程中达到这一层级。

运营成熟度模型与能力成熟度模型（CMM）相一致，后者也有五个层级。一级是初始层级，在这一层级中，流程控制差，难以预测。在三级，最常见的企业层级，流程被明确定义并且得到了很好的理解，从而可以进行主动的事件管理。五级是优化层级，在这一层级中，流程和交付会不断改进。正如我们之前提到的，大多数企业对于某些流程和产品会达到这一层级，但整个企业通常很难达到这一层级。CMM 模型如下所示：

图 6.8 – 能力成熟度模型（CMM）

三级是关注的层级：变得更加主动。在接下来的几章中，我们将学习人工智能（AI）和机器学习（ML）如何帮助我们实现这一目标。

总结

在本章中，我们讨论了运营管理以及由于数字化转型和 DevOps 实施而发生的变化。首先，我们看了运营的角色与责任以及不同的运营服务管理流程。我们还讨论了几种即将在不久的将来影响运营的趋势。我们得出的总体结论是，运营的角色将会发生变化，主要是由于数字化转型以及敏捷和 DevOps 的实施。为了实现敏捷，我们需要运营人员能够专注于他们的独特任务。然后，我们讨论了产品运营和平台运营的划分模型。

接下来，我们学习了架构如何变得更加以事件为驱动，以及运营在这一过程中所处的位置。运营需要有一个统一的视图，全面监控甚至预测整个链条中的事件，以便采取主动措施。这就是运营成熟度模型中三级的描述：主动且可预测。人工智能和机器学习将在这方面提供帮助。

在下一章中，我们将讨论人工智能在企业和 IT 运营中的影响。

问题

1. 列举三个必须包含在技术架构中的组件。

2. 列出 IT4IT 定义的四个价值流，以支持 IT 交付。

3. 事件驱动架构的一个重要组成部分是包含的、独立运行的服务，这些服务通过 API 互相通信。我们称这些服务为什么？

4. AIOps 在成熟度模型中适合哪个层次？

进一步阅读

• 数字化新 IT 操作模型，由 Gartner 发布。发表在 https://www.gartner.com/en/documents/3770165/the-new-it-operating-model-for-digital。

• 设计与实施 I&T 操作模型：组件与相互依赖性，由 Gartner 发布。发表在 www.gartner.com/en/documents/3956725/designing-and-implementing-the-i-t-operating-model-compo。

• Rob Akershoek 在 IT4IT 博客上的文章: www.4me.com/blog/it4it/。

• 解决方案架构师手册，由 Saurabh Shrivastava 和 Neelanjali Srivastav 编著，PacktPub，2020 年。

第七章：理解 AI 对 DevOps 的影响

在本章中，我们将介绍人工智能（AI）以及 AI 对 DevOps 的影响。我们将讨论它如何通过使用 AI 和机器学习（ML）驱动操作中的“左移”，即在 DevOps 周期开始时迅速识别问题。在实施 AIOps 等系统之前，我们首先需要通过创建所有 IT 资产和工作流的可视化，并将其映射到 AI 驱动的流程中，来让企业为 AIOps 做好准备。接下来，我们需要一个整合的工具集，既适用于开发，也适用于运维。领先的公共云提供商提供了原生的工具集，正如我们在本章中将看到的那样。

完成本章后，你将对 DevOps 过程中的 AI 概念有一个清晰的理解。你还将学习到 AI 驱动的系统如何帮助实现“左移”（shift left）。在我们讨论 AIOps 的可能结果和收益之前，我们需要首先实现对企业 IT 所有资产和流程的全面可视化。在本章中，我们还将了解这一点的重要性，以及如何实现全栈可视化。

本章我们将涵盖以下主要内容：

• 介绍 AI 和 ML

• 理解 DevOps 中的左移（shift-left）运动

• 定义第一步——作为服务的 DevOps

• 创建 IT 资产可视化地图

• 衡量 AIOps 的业务成果

介绍 AI 和 ML

在本节中，我们将简要介绍 AI 和 ML 的概念。关于 AI 和 ML 已经有成千上万本书籍被写成书店的库存，但在这一节中，我们仅仅提供定义并描述这些概念如何改变开发和运维：

• AI：AI 的最广泛定义是模拟人类行为的计算机技术。在大多数情况下，AI 用于表示软件能够通过推理和分析事件，自动且智能地做出反应，从而在没有人工干预的情况下做出决策。

• ML：在 AI 之后是机器学习，它通过分析早期的事件，学习如何执行任务和执行操作，然后利用这些经验改善自主决策。为了实现这一点，AI 和 ML 作为技术需要数据，并且需要理解如何解读这些数据。

AI 和 ML 并非魔法。你需要像定义其他任何概念一样，明确这些技术的应用范围。接下来，你需要准备好环境，以便为 AI 和 ML 做好准备。例如，企业首先需要对自动化有一个清晰的理解，并全面了解其所有资产。否则，即使是 AI 也会在盲目操作的情况下工作，无法带来任何价值。

引入和实施 AIOps 从一种不同的思维方式开始：改进从尽早发现潜在故障并学会如何在故障进入生产环境之前加以预防开始，而不是在生产环境中发现并修复故障。这正是 "shift-left" 思维的领域。我们将在下一节深入了解这一点。

了解 DevOps 中的 "shift-left" 运动

在过去几年中，"shift left" 成为了一个流行的术语。那么，这到底是什么意思呢？它是指将原本计划在后期进行的活动提前到流程的开始阶段。这通常发生在测试环节，测试曾经是等到整个产品交付给测试团队后才开始进行的。"Shift-left" 测试已成为 DevOps 中的重要范式：尽早执行测试。通过在开发一开始就进行测试，问题会更早被发现，并可以在早期阶段修复，从而改进最终产品。下图展示了 "shift-left" 测试的影响：

图 7.1 – "Shift-left" 测试的影响

"Shift-left" 原则可以应用于 DevOps 中的更多流程。试想 DevOps 中的第一步：设计。在开始构建解决方案之前，IT 团队，无论是软件开发人员还是云工程师，都应该充分理解业务需求。IT 中的一个主要陷阱就是在没有完全理解这些业务需求的情况下开始构建某些东西。通过采用其他设计方法，商业和 IT 部门的紧密合作可以解决这个问题。设计思维恰好契合这一点，是 "shift left" 的一个很好的例子。

设计思维从评估所有相关方的观点开始：在这种方法论中，这被称为 同理心。接下来的步骤是定义问题，进行头脑风暴并从各个角度生成解决问题的想法，然后构建和测试原型。然而，测试并不是最后的阶段。相反：设计思维是一个迭代过程，就像 DevOps 一样。每个周期产品都会变得更好。关键是要在项目一开始就让 IT 部门参与进来，尤其是在定义业务需求的阶段。以下图展示了这个过程：

图 7.2 – 设计思维过程

最后，"shift left" 同样适用于 DevOps 中的部署和运维。这正是自动化、模板化和蓝图化发挥重要作用的地方。通过自动化模板、预先批准的模式和流程，我们可以将部署阶段提前。使用自动化，我们可以实现一致的部署应用，这将帮助运维管理这些环境。

预先批准的模式还包括测试驱动开发（TDD），将测试移至开发和部署过程的最初阶段。在 第三章 面向 DevOps 质量的架构 中，我们讨论了 TDD，在这种方法中，团队首先编写测试用例，然后编写代码。代码是根据测试用例的规范编写的，从而证明了需求已被满足。

简而言之，左移原则是关于在早期阶段减少故障，使最终产品更加稳定和具有弹性。问题通常只会在生产环境中被发现，通常是由于系统部署中的不一致性所导致。手动任务或使用大量不同工具会增加这些不一致性的风险。开发人员使用与运维不同的工具可能会导致需要通过手动任务来修复的问题。在站点可靠性工程（SRE）中，这被称为 toil，正如我们在 第五章 通过 SRE 架构下一个层次的 DevOps 中看到的那样。或者，问题是由不同的流程引起的。自动化、模板化和 TDD 可以避免这些问题的发生，并减少故障率。模板、模式和蓝图会不断测试和改进，从而实现更加稳定的运营。

AI 和 ML 可以在这一切中提供帮助。首先，AI 驱动的监控将帮助在早期阶段发现问题，特别是不一致性。它将从这些不一致性中学习，并利用 ML 提出甚至实施代码和流程的改进。但在我们深入讨论之前，我们需要先讨论一下自动化，作为左移范式的一部分，尽可能地将工作转移到云服务中，利用集成的工具集，实施 DevOps 作为服务。这是下一节的主题。

定义第一步 – 将 DevOps 作为一种服务

一致性是成功的关键。这几乎适用于任何事情，当然也适用于 DevOps。开发和运维需要在相同的工具集下协作：这就是将 DevOps 作为一种服务的核心。DevOps 作为一种服务使得左移成为可能，同时也是实施全面监控系统的良好起点，包括 AIOps。

注意

AIOps 远不止是一个监控工具，正如我们将在接下来的章节中了解到的那样。然而，AIOps 从监控复杂环境开始。通过收集这些系统的数据并进行分析，它能够跟踪和修复系统和流程，包括自动化重复任务。AIOps 能够发现模式，并为其定义自动触发器。但如果它无法监控源系统，它就无法做到这一点。

DevOps 作为服务将跟踪开发和交付过程中的每一步，但真正的价值在于它能在检测到该过程中的问题时立即提供反馈。其价值在于，这些反馈在软件推送到生产环境之前就已经被收集。从开发周期的开始，集成的工具集使得错误和缺陷的跟踪成为可能，并将其反馈给开发团队，这远在操作团队面临故障软件和系统的异常行为之前。这是真正的“左移”：将通常在后期阶段进行的工作提前到开始阶段。

因此，DevOps 作为服务代表了一种集成的工具集，能够促进开发人员和运维人员之间的协作。这些工具必须涵盖 DevOps 流程中的所有步骤，并且基本上像一个工具一样协同工作。云平台提供这些工具。在本节中，我们将讨论在 Azure、AWS 和 Google Cloud Platform (GCP) 中的这些工具：

• AWS：AWS CodeBuild、AWS CodePipeline 和 AWS CodeDeploy 是需要关注的三大解决方案。CodeBuild 是一个用于通过自动化流程构建、编译和测试代码的托管服务。CodeBuild 还为每个构建的工件提供唯一的加密密钥，这些工件存储在代码仓库中。部署场景在 CodePipeline 中定义，直到生产阶段，CodeDeploy 实现将应用交付到生产环境的目标基础设施中。CodeDeploy 还负责修补、升级和构建的同步。

• Microsoft Azure：Azure DevOps 是 Azure 中的集成工具集，用于开发和部署。它就像一把瑞士军刀：它作为一个工具存在，但在背后却包含了多种协同工作的解决方案。你可以在 Azure Repos 中管理代码，Azure Repos 支持 Git 仓库。代码的构建、测试和部署在 Azure Pipelines 中完成。更全面的测试可以通过 Azure Test Plans 执行。此外，Azure DevOps 还提供 Azure Boards，用于跟踪项目：它类似于看板。最后，Azure DevOps 提供 Azure Artifacts，开发人员可以通过它将来自其他来源的 NuGet、NPM、Python 和 Maven 包共享到 Azure DevOps 中。

• Google Cloud：Google Cloud 提供了 Operations Suite，之前称为 Stackdriver。对开发人员来说，最有趣的部分可能是 Cloud Debugger，它允许在应用程序运行时分析代码并发现错误，而无需停止应用程序。代码部署通过 Deployment Manager 完成。GCP 还提供了一个强大的工具 Cloud Trace，用于快速和自动地检测和分析问题——实际上，这已经非常接近 AIOps。

集成的工具集将帮助我们推动“左移”运动，并为实施 AIOps 提供一个良好的起点。但我们首先需要做一件事，那就是确保能够全面掌控我们 IT 环境中的每一个资产。这是下一节的主题。

创建 IT 资产可视化地图

在《爱丽丝梦游仙境》中有一句著名的话：“如果你不知道你要去哪里，那么任何路都能带你到那里。”你实际上可以将这句话倒过来说：如果你想去某个地方，你需要知道你从哪里来。让我们把这个理念付诸实践：如果我们想要进行企业转型，我们需要了解我们正在转型的是什么。这就是为什么每一种数字化转型方法都始于评估和发现。企业需要对其所有资产有全面的可视性。下图展示了迁移和转型计划的基本步骤，从评估开始：

图 7.3 – 迁移的高级计划

当所有资产都已识别后，我们可以开始规划将这些资产迁移和转型到新的目标区域，通常是公共云中的平台。需要验证应用程序，以便能够定义正确的策略：重新托管、重新平台或重建。这是我们在第四章《规模化 DevOps》中讨论的应用现代化领域。最后一步是分波次规划迁移和转型。大爆炸式迁移可以是一种策略，但在大型企业中，这显然不推荐采用。

回到企业为何采纳敏捷和 DevOps 的原因：企业这样做是为了加快产品交付速度，并变得更加灵活，以便能够更快地响应客户需求的变化。为了获得这种速度，它们需要依赖稳定的系统和操作，这样时间就可以用于开发而不是修复问题。IT 需要变得更加预测性，实际上避免问题的发生。来自资产的数据至关重要。这些数据需要实时收集和分析。

这些数据的第一个来源是配置管理数据库（CMDB）。许多 CMDB 的问题在于它们所持有的信息并不准确。根本原因在于许多数据仍然是手动输入的，例如通过导入电子表格；监控和资产收集没有实时进行；或者数据分散在多个需要同步的 CMDB 中。

接下来，CMDB（配置管理数据库）通常不经常被清理，因此会包含噪声。这通常是因为在执行更改后没有更新 CMDB。CMDB 应该是捕获资产的唯一真实来源，但如果没有实时更新的自动化信息，这就成了一个挑战。CMDB 将不再反映系统的实际状态。

你可能注意到，在本节中我们使用了两个不同的术语：资产和配置。这是两个不同的概念，它们在了解企业 IT 配置时同样重要。只有当我们完全了解资产和配置时，我们才能开始规划迁移，并准备好帮助运营变得更加可预测的工具。运营需要一个能够做到以下几点的系统：

1. 知道 IT 环境中有哪些系统

2. 知道这些系统之间是如何相互关联的

3. 实时跟踪这些系统的状态和配置

我们从了解环境中有哪些系统开始：资产可视化图。这就是资产管理：基本上是每个物理和虚拟系统的清单，包括使用的软件及其许可证，以便我们知道何时需要升级或更换系统，例如，当软件结束支持或许可证到期时。这通过生命周期管理过程来解决。

我们还需要知道这些系统是如何配置的，以及它们与其他系统的关系，包括依赖关系，以便操作人员了解在数据库关闭时可能产生的影响。这就是配置管理。

所以，完全的可视化不仅包括所有资产，还包括对连接、依赖关系和流程的清晰可视化。如果没有这些信息，运营人员将不得不花费大量时间寻找问题的根本原因，并学习如何解决它。

在云中工作使得实时资产收集变得更加容易。例如，在 Azure 中，使用 Get 命令，你可以创建 Azure 订阅中的资产列表。同样，实时性在这里至关重要。由于云系统变化较快，拥有即时、准确的资产数据变得尤为重要。我们如何实现这种可视化？我们定义了五个层次，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/entp-dop-arch/img/B17492_07_004.jpg)

图 7.4 – 资产管理的层次

让我们更详细地探讨这五个层次：

• 基础设施：包括虚拟机和所有网络组件。

• 操作系统：所有操作系统是否都已更新？另外：它们是如何配置的？例如，企业通常会有安全标准，应用于已按这些标准加固的操作系统镜像。所有系统是否都使用了相同的镜像？使用其他镜像设置的系统可能存在安全漏洞。

• 应用程序：安装了哪些应用程序软件，版本是什么？软件是否已正确打补丁并获得授权？

• 数据：数据存储在哪里？是如何存储的？例如，数据是否经过加密，采用何种方式加密？

• 访问：谁或什么可以访问其他四层？

  注意

  图中有两个垂直层次。生命周期管理适用于整个技术栈。所有组件是否仍然符合要求、具有正确的许可证并且没有过期？这对于访问层也是适用的：想想那些不再使用的账户，应该被禁用。

  安全性是所有层次的固有部分。它不是我们只需要在基础设施或数据层中关注的事项。每一层都需要遵守安全政策。在本书的第三部分，我们将讨论在 DevOps 中的安全性，届时我们将深入学习更多内容。

但企业可能不仅仅拥有公共云中的资产。此外，公共云中的资产可能与甚至非云系统存在关系和依赖。因此，我们需要一个全面的系统，来收集所有数据并维护这些数据：单一视图（single-pane-of-glass）或全栈可视化。

Azure、AWS 和 GCP 提供了用于企业服务管理（ESM）系统的 API，例如 ServiceNow 和 BMC。ESM 的范围远远超出了 IT：它将业务流程与 IT 相关联，并提供 IT 如何支持这些业务流程的单一视图。这些系统能够预测 IT 系统的变化将如何影响业务流程。

到目前为止，我们只讨论了企业内部的资产和配置。但在这个快速变化的世界中，企业也将拥有大量来自外部的数据源。想象一下来自网站和社交媒体平台的数据。这些可能对公司来说是真正的资产，但来自这些源的数据可能会影响业务流程。因此，企业也需要分析这些数据。

例如，社交媒体上的一次活动可能会提高销售额，要求销售系统的额外容量，包括公司的网站。如果没有预见到这一点，且由于流量过载导致系统崩溃，这将无疑对公司造成损害，损失不仅限于收入损失，还包括声誉损害。

预测系统行为并衡量其对业务的影响需要对企业 IT 的整个生态系统进行全面可视化。AIOps 将提供帮助，在本章的最后一部分，我们将讨论如何实现这一点。

衡量 AIOps 的业务成果

在前面的章节中，我们讨论了“向左移动”（shift left），并看到我们如何将 DevOps 定义为一种服务。接下来，我们学习了如何创建企业所有资产的全面可视化，作为实施 AI 驱动流程的起点，这些流程将帮助改进开发、部署和运维，从而加速 IT 中的“向左移动”。那么，AI 如何在这方面提供帮助呢？

• AI 是关于分析数据的。AIOps 也不例外：它分析操作数据，并能够提供有关如何改善系统性能和效率的建议。

• 为了获得有效的数据和建议，AIOps 必须减少噪音。噪音是运维中非常常见的问题，特别是在监控系统和 CMDB 中，正如我们在前一部分所学的那样。什么是真正的问题，什么是虚假的警报？AIOps 能够分析这些警报，并借助算法将警报进行分组，识别并优先处理它们。结果是，这将节省大量运维时间：运维人员现在可以集中精力处理那些真正影响系统的警报——从而影响业务。

• AIOps 的一个强大功能是它能够关联警报和事件，找出问题的根本原因。一个前提是我们在前一部分讨论过的全栈可视化。AIOps 是学习系统：这意味着它们首先需要捕获所有资产并理解它们之间的关系。

• 再次强调：AIOps 是学习系统，因此它们会学习系统的正常行为。然后，它们将识别异常并主动与可能的业务影响相关联。以我们之前提到的营销活动导致销售激增为例，AIOps 系统将比运维更快地检测到异常的高流量，并更迅速地触发扩展。

• 触发扩展意味着 AIOps 高度自动化。AIOps 可以用于处理例行任务，例如执行备份。

我们如何衡量添加 AI 的收益？以下 关键绩效指标 (KPIs) 可以提供帮助：

• 检测问题的平均时间 (MTTD)：从问题出现到被检测到需要多长时间？AIOps 将学习如何检测故障，分析系统的模式和行为。AIOps 还将通过分析问题对业务流程的影响来判断问题的严重性。由于 AIOps 使用机器学习，它将学会如何更快地检测问题，如何预测问题，并最终通过主动建议来避免问题。

• 确认问题的平均时间 (MTTA)：这在逻辑上是 MTTD 的延续。MTTD 是关于检测，而 MTTA 是关于 AIOps 能多快地将问题分配给正确的运维人员。这由工作流程过程的自动化来覆盖：AIOps 会首先识别问题，确定影响范围，然后决定将其分配给哪个运维人员进行进一步调查。当关键业务流程受到影响时，例如，AIOps 可能会决定将问题标记为关键，触发危机处理流程。使用这些系统，与人工干预相比，将节省大量时间。

• 解决问题的平均时间 (MTTR)：使用 AIOps，可以快速识别类似问题是否曾经发生过，并执行了什么解决方案来缓解它们。简而言之，AIOps 将帮助快速找到并分析解决方案，尽早恢复服务。

• 监控检测：衡量 AIOps 成功率的一个有用 KPI 是，在用户实际注意到性能下降甚至系统宕机之前，AIOps 检测到的问题数量。

• 自动化修复：有时也称为 自动化自动化。AIOps 将学习解决问题所用的方案。复杂的系统还将学会如何自动化这些解决方案，主动采取措施防止问题再次发生。衡量 AIOps 效果的一个有用 KPI 是跟踪 AIOps 自动化的修复行动数量及其对系统可用性的影响。

请注意，AIOps 仍处于非常早期阶段。相当多的工具自称为 AIOps，但目前还无法做到，例如上一条所描述的“自动化自动化”。然而，AI 和 ML 无疑将在未来几年发展并变得更加成熟。这将是将 AI 和 ML 实现到 DevOps 和整体 IT 中的第一步，并通过以下方式改变软件开发：

• 创建原型

• 自动化检测与分析

• 自动化修正

• 自动化代码生成

• 自动化测试

本章介绍了 AI 和 ML 的概念以及这些技术将如何影响 IT 系统的开发、部署和管理。AI 将有助于创建更可靠的系统，并改进软件开发。AI 当然不会取代开发者或运维人员，但随着他们学习如何与 AI 驱动的系统（如 AIOps）协作，他们的角色可能会发生变化。首先，我们将讨论如何将 AIOps 集成到我们的架构中，这是 第八章 的主题，AIOps 架构设计。

总结

在简要介绍了 AI 和 ML 之后，本章讨论了这些技术如何帮助开发更好的软件和更可靠的系统。AI 支持“左移”运动：将通常在后期阶段完成的工作提前到开发和部署周期的开始阶段。通过 AI，能够在非常早期的阶段检测到问题，并通过自动化手段，AI 还能触发修正行动。

由于 AI 和 ML 是学习系统，它们将学会如何预测并可能预防问题的发生。为此，AI 需要来自源系统的实时数据，因此第一步是全面了解我们 IT 环境中的所有资产，并确保这些系统正在被监控，提供实时日志。我们学习了如何使用五个层次创建这种完整的可见性。

在上一节中，我们讨论了用于衡量 AI 驱动系统成果的 KPI。尽管 AIOps 仍然相对较新，但这项技术在深入了解 IT 行为并预测 IT 事件对业务影响方面非常有前景。在下一章中，我们将学习如何将 AIOps 集成到企业架构中。

问题

1. 设计思维是一种推动左移变革的方法。设计思维从评估所有参与开发方的视角开始。在该方法论中，描述此步骤的术语是什么？

2. AWS 提供使用本地工具的 DevOps 作为服务。用于构建代码、规划部署场景和实际部署到生产实例的三个工具是什么？

3. MTTA 代表什么？

进一步阅读

• AI 速成课程，作者：Hadelin de Ponteves，出版方：Packt Publishing，2019 年

• Clive Longbottom 的博客：DevOps 作为服务（DaaS）

• Azure DevOps 解析，作者：Sjoukje Zaal, Stefano Demiliani 和 Amit Malik，出版方：Packt Publishing，2020 年

第八章：构建 AIOps

在本章中，我们将学习面向 IT 运维的人工智能（AIOps）平台的设计及其与任何其他监控工具的区别。您将更好地理解为什么这些平台将成为未来 IT 的必需品。本章首先解释逻辑架构模型，然后深入探讨使用数据湖和机器学习分析 AIOps 中的关键组件。我们将定义 AIOps 平台的参考架构，并了解如何在 AIOps 中集成技术服务架构。本章将深入探讨算法、异常检测和自动修复。

完成本章后，您将能够识别 AIOps 的各种关键组件并定义参考架构。您将学习在企业中实施 AIOps 时避免一些重要陷阱的重要经验。

在本章中，我们将涵盖以下主要内容：

• 理解逻辑架构

• 定义 AIOps 架构的关键组件

• 将 AIOps 与服务架构集成

• 为 AIOps 定义参考架构

理解逻辑架构

在我们深入讨论 AIOps 的架构之前，我们需要了解逻辑架构的结构。在上一章节（第七章，理解 AI 对 DevOps 的影响）中，我们了解到实施 AIOps 的第一步之一是完全可见所有 IT 资产和流程。这是为了提供 AIOps 模型的基本信息，了解 IT 环境的样貌。大多数 AIOps 工具将使用代理扫描环境，但这并不足够。它还需要了解资产之间的关系以及实施的流程。这些内容都涉及到逻辑架构。

逻辑架构不关注技术。它不在乎使用何种类型的机器或软件。逻辑架构描述的是在不涉及底层技术定义的情况下，系统中逻辑组件之间的关系。特定技术的选择——基础设施、软件、代码——稍后会添加到该架构中。逻辑架构旨在为技术设计提供一个可理解的系统概览。再次强调，逻辑架构通常由各层组成，如以下图表所示：

图 8.1 – 逻辑架构的组成部分

我们将在本节稍后详细讨论这些层及其组件。

逻辑架构应该是任何架构的起点。它包含了系统完成其功能所需的每个组件。因此，从期望的功能出发，架构师必须设计出系统所需的不同组件，以便能够实现该功能，而不受技术选择所带来的不可避免的约束的干扰。架构师需要考虑不同的系统层次、这些层次中的组件以及层次之间的交互。接下来，他们还需要考虑与其他系统的交互。

只有当这个逻辑模型在每个细节上都完全设计出来时，才能定义物理架构，将逻辑组件转换为技术组件，如具有网络设备和服务器的基础设施、操作系统，最终是技术应用组件，包括接口和 API。

为了帮助架构师定义逻辑架构，建议按如前图所示的层次进行工作。层次包括客户端、访问层、展示层、应用层、工作层（在某些文献中称为业务层）和数据层。这遵循系统在执行事务时常用的模式。

注意

事务不一定是金融交易。在系统架构中，事务指的是由输入触发并导致特定输出或请求并得到响应的系统操作。当然，这可以是一个实际的交易，例如订单处理。但事务也可以是传输给另一个系统的消息。

如果我们将请求-响应周期分解为独立步骤，它会是什么样子？

1. 用户通过展示层提出请求。

2. 用户通过访问层进行身份验证。

3. 身份验证后，请求被传输到应用层。

4. 从应用层开始，请求通过工作层进行处理。

5. 所需的数据从数据层收集。

6. 数据通过工作层进行处理。

7. 请求的响应在工作层准备，并发送到应用层。

8. 响应从应用层传输到展示层。

请求-响应流程如下图所示：

图 8.2 – 逻辑架构中的请求-响应流程

圆圈代表请求，三角形显示响应流程。现在，让我们更详细地看看不同的组件：

• 客户端：这是用户开始使用应用程序的入口点。通常，这指的是一个浏览器或设备上的小程序，允许用户连接到应用程序。

• 访问层：我们不希望任何人都能使用系统，因此用户需要进行授权和认证。访问层位于客户端和展示层之间：用户通过客户端访问展示层，然后在访问层进行授权和认证。授权通过后，请求便开始处理。

• 展示层：展示层有两个主要功能。首先，它帮助用户以易于理解的方式提出请求。一旦请求被处理，响应将在此层展示。

• 应用层：这是存储应用技术的层级。

• 工作层：有时这个层级被称为业务层，但这可能有点让人混淆。这个层级是处理请求的地方。基本上，这是存储应用功能的层级。它包含了所有使应用能够准备响应用户请求的组件，包括那些例如收集所需数据并处理数据的 API。

• 数据层：这个层级应该仅用于存储数据。工作层位于数据层和展示层之间，以确保客户端无法直接访问数据。它们总是需要通过工作层来访问数据。

如果只涉及一个系统，这个过程很简单，但企业通常有多个系统。这些系统互相连接，并可能依赖于其他系统。如果企业实现了单点登录（SSO），用户可能只需通过一次访问层。但很可能请求会在不同系统的工作层之间按照某个工作流进行流转。可能需要的数据来自不同的数据源。用户并不一定能在一个展示层中获得所有的响应，尽管从用户的角度来看，这可能是非常希望得到的结果。如果我们考虑到这一点，逻辑架构已经变得相当复杂，更不用说如果架构师在这个阶段尝试融入所有的技术细节了。

AIOps 通过这种逻辑架构工作。从中，它理解系统是如何设计的，以及它们与其他系统的关系。这是 AIOps 参考架构的基础。在我们进入参考架构之前，我们将看看 AIOps 架构的不同组件。这是下一部分的主题。

定义 AIOps 架构的关键组件

在这一部分，我们将讨论 AIOps 的关键组件。接着，我们将查看提供输入的操作服务，最后在最后一部分，我们将草拟参考架构。

首先，让我们回顾一下为什么我们需要在 IT 和特别是在 DevOps 中使用 AIOps。IT 已经变得更加复杂。系统托管在各种平台上，连接到其他系统，使用大量不同的数据源，数据格式也同样多样。我们已经来到几乎无法由人类保持这些复杂景观概览的地步。然而，市场对新功能的需求以迅速增加的速度增长。开发人员面临巨大的压力，需要交付满足新功能需求的代码，而运维人员则需要确保系统稳定运行。AIOps 可以帮助你做到以下几点：

• 处理和评估数据：AIOps 可以迅速、几乎实时地处理来自不同系统的数据，并验证这些数据。通过这样做，AIOps 能够生成警报，并提出减轻行动，以维持系统的期望性能。

• 快速根本原因检测与分析：由于 AIOps 可以访问所有数据并理解系统之间的互联关系，它将能够比操作员更快地找出问题的根本原因。

• 启用自动化：通过处理和评估数据，AIOps 将识别模式。这些模式会被转化为自动化序列，从而消除手动任务。同时，AIOps 会通过分析某些过程的结果，从这些模式中学习。如果一个模式持续导致不希望的结果，它会提出更改该模式的建议措施。工程师将从这些建议中受益。他们将减少花费时间寻找系统问题，而有更多时间用于改进系统。

• 异常检测：因为 AIOps 学习模式，它也能够识别这些模式中的偏差。这些偏差可能是异常：需要关注的事件。这可能是一个用户在几分钟内试图从相距数英里的两个地点获取访问权限，或者是 CI/CD 流水线中 API 被意外触发。因此，AI 也将大大提高系统的安全性，这是我们将在本书第三部分关于 DevSecOps 讨论的内容。

• 自动修复：复杂的 AIOps 系统可能能够自主解决问题，因为它们已经学习了模式并能检测到异常。由于 AIOps 系统高度自动化，它们还可以学习在出现 已知 问题时执行修复行动，通常是过去发生过的问题。AIOps 会学习这些问题是如何解决的，在这种情况下，相关行动可以自动化。请注意，这些问题的条件需要与问题首次发生时的条件相似。

总体而言，AIOps 绝对会提高 IT 效率，尤其是 DevOps 周期。开发者已经开始使用 AI 来发现各种系统中的相关性和模式，帮助他们改进代码，包括预测分析。这意味着反复询问“如果”的问题，只是速度更快，并且更有可能得到更准确的答案。

要能够实现这一点，AIOps 系统需要几个组件：

• 源代码库和控制：与 DevOps 中的 CI/CD 类似，所有代码都有一个源，因此系统始终可以从该源进行恢复。所有设计、模式、配置参数、应用程序代码以及所有其他 IT 工件，都保存在一个源代码库中，并处于版本控制之下。这是所有系统的基线。我们在《第七章》中讨论的配置管理数据库（CMDB），理解 AI 对 DevOps 的影响，也是这个仓库的一部分，但可能不包含应用程序代码。因此，完整的仓库将包含各种来源。

• 大数据存储库：AIOps 系统从各种来源收集大量数据，分析并用于自我训练，将数据建模成模式以实现进一步自动化。这些数据以其原始格式在分布式文件结构中收集，如数据湖。

• 监控：AIOps 系统可能使用代理程序来跟踪系统的性能，以及系统组件之间的连接是否可用。但大多数系统将从其他监控源汇总数据。在公共云中，这可能是 Azure Monitor、AWS CloudWatch 或 Google Cloud Monitoring，结合其他专门工具或供应商特定工具来监控 IT 环境中的特定组件。AIOps 将从这些工具获取原始数据，并用于自我训练。

• 自动化：自动化重复性任务和自动修复。

• 机器学习：这是 AIOps 的核心。从源代码库和收集的数据中，它将学习系统的行为方式以及与其他系统的连接方式。AIOps 将学习应用程序中数据的使用方式以及如何处理请求。AIOps 系统将使用大数据，将其与源代码库进行比较，并不断从这些分析中学习，以自动追踪问题并提出改进建议，为开发者和运维人员提供反馈。

现在我们需要理解这些组件如何协同工作。IT 研究和咨询公司 Gartner 已经定义了 AIOps 的模型，包括三个领域：

• 观察：这涉及跨系统实时跟踪和追踪所有指标。AIOps 通过将数据与来自源代码库的历史数据进行相关性分析，监控性能、连接和异常。

• 参与：这涉及所有与事件和变更相关的数据。参与领域将IT 服务管理（ITSM）流程与 AIOps 集成。这将在下一节中详细讨论。

• 行动：这包括基于监控数据（观察）和流程输出（参与）自动执行的任何操作，以及 AIOps 系统根据这些数据执行的动作。

该模型如下所示：

图 8.3 – AIOps 中的三个领域（原图来自 Gartner）

为了能够采取行动，AIOps 需要了解并学习 IT 服务是如何通过企业交付的。我们将在下一节讨论这一点，届时我们将学习技术服务架构如何与 AIOps 集成，从而以更高效的方式推动运营。

将 AIOps 与服务架构集成

到目前为止，我们已经看过 AIOps 的逻辑和不同组件。将人工智能引入运营的主要原因之一是通过主动监控系统，甚至在风险实际发生之前就减轻许多手动任务，避免潜在风险的出现。换句话说，AIOps 的发明是为了减少站点可靠性工程（SRE）所说的“繁琐工作”。这正是实施 DevOps 和 AIOps 的核心目的：减少繁琐工作并创造时间，持续设计和构建更好的系统。

但这不仅仅是关于系统本身。企业还有交付服务的过程。这就是服务架构的领域。更准确地说，是技术服务架构。它包括以下小节中讨论的过程。

监控

这不是一个开箱即用的功能。相反，架构师需要定义一个监控架构，包括哪些业务功能、应用程序和基础设施需要被监控，以便尽早获得关于系统状态的准确和适当的数据。下一个问题是如何自动化监控：哪些阈值需要引发动作，是否可以自动化这些动作？哪些日志需要存储、存储在哪儿，存储多长时间？建议自动存储日志，作为 AIOps 可以用来训练自身的大数据的一部分。接下来，监控架构会定义警报的路由：这是 AIOps 平台的关键输入。

问题管理

这一过程始于事件，最好是通过监控检测到，而不是用户向服务台报告问题。并不是每个事件都会导致问题。例如，用户因为凭据过期无法登录系统，可能会成为一个事件，但很少会导致根本原因分析和/或问题。如果事件很严重，影响到部分或整个业务，则需要执行问题管理。当类似事件多次发生时也是如此。问题管理需要分析原因，确定是否存在相关的事件和模式。因此，问题管理需要深入了解系统和工具。考虑到当今企业 IT 环境的复杂性，执行问题管理必然会涉及分析来自各个系统的大量数据。AIOps 将帮助分析这些数据，识别趋势，并更快地找到根本原因。

配置管理

系统的期望状态是什么？这是配置管理中的主要问题。配置项（CIs）被保存在一个仓库中，记录它们生命周期的状态。CIs 包括构成系统的每个组件：网络连接、服务器、软件、API 和策略。这些组件必须按照架构中定义的方式进行配置，以保持一致性。

示例：架构师决定 Windows 服务器始终运行 Windows Server 2019 版本，但使用特定设置，这些设置会在服务器策略中捕获。还决定数据库服务器始终运行 SQL 或使用 Azure SQL 作为 PaaS 服务。作为架构的一部分，数据库服务器绝不允许直接与外界通信，因此架构还将制定数据库服务器如何与其他服务器通信的策略，包括防火墙规则和连接字符串。

配置管理需要确保这些配置在组件的整个生命周期内保持一致，甚至在这些组件迁移到不同平台或不同阶段（开发、测试、验收和生产）时也不例外。因此，准确的配置管理对于确保系统质量和良好的变更管理至关重要。配置管理和期望状态是 AIOps 的基本输入。

变更管理

每当系统或系统组件被迁移、更新、升级、更改或淘汰时，都涉及变更管理。换句话说，变更管理不仅仅负责实施新系统。每当系统发生任何形式的变更时，变更管理都扮演着重要角色。为了支持变更管理，它需要一个关于配置项（CI）和组件配置的单一真实数据源——期望状态。它需要依赖于配置管理、准确的监控和一致的事件报告，这些事件是由系统记录的。在 AIOps 中，这被标识为历史数据，用来与变更进行比较，并验证系统是否仍然在期望的状态下运行。异常检测将在变更实施过程中帮助识别问题。

迄今为止讨论的所有这些过程都会产生数据，这些数据存储在由用户提交的工单中，或者更好的是，存储在由系统记录的事件中。在我们上一节中讨论的 AIOps 架构关键组件定义模型中，Gartner 将这类数据称为参与数据。

参与数据用于以下内容：

• 任务自动化

• 变更风险分析

• 性能分析

• 知识管理

参与意味着 IT 服务管理（ITSM）与通过监控、事件和系统指标衍生的操作数据进行沟通。所有这些数据都会聚合到一个存储库中，即大数据平台，以便 AIOps 系统拥有一个数据库，可以用来分析系统的健康状况和性能。

AIOps 中的大数据

这个大数据平台是 AIOps 的核心：它将捕捉来自不同系统的数据，而不受这些系统的孤岛限制。我们说的孤岛是什么意思？一个系统可能在私有数据中心中有多个组件，并且与公共云中的 PaaS 或 SaaS 服务进行通信。为了获得整个系统的集成视图，AIOps 需要访问一个聚合的数据源——大数据平台。该平台将包含历史数据、系统迭代数据以及通过交互式大数据分析获得的实时系统数据。

总结一下，AIOps 平台具有操作数据和过程数据：

• 来源于许多不同系统的数据

• 分析流式实时数据和历史数据的能力

• 处理来自事件、日志、警报和根本原因分析的数据

• 将 IT 流程集成并与操作系统数据进行关联的能力

• 以易于理解的方式可视化数据的能力

下图展示了 AIOps 技术栈：

图 8.4 – AIOps 技术栈的高层建模

我们已经广泛覆盖了 Gartner 模型中的观察和参与领域。基于数据和服务模式，AIOps 现在可以开始执行活动，这是 AIOps 的最终阶段。它可以通过使用运行手册和脚本来自动化任务。最后一步是将组件转化为 AIOps 平台的架构。在最后一节中，我们将定义一个参考架构，并将所有内容整合起来。最后，我们将提供一些工具，帮助你开始使用 AIOps。

定义 AIOps 的参考架构

在前面的章节中，我们研究了系统的逻辑架构、AIOps 的组件以及技术服务架构。所有这些构建模块都用于定义 AIOps 的架构。在本节中，我们将讨论 AIOps 的参考架构。

首先，让我们回顾一下 AIOps 的目标。在 第七章，理解 AI 对 DevOps 的影响 中，我们讨论了 AIOps 的关键绩效指标（KPIs）：

• 平均检测时间（MTTD）

• 平均响应时间（MTTA）

• 平均解决时间（MTTR）

AIOps 将人工智能引入 IT 操作，利用大数据分析和机器学习（ML）。AIOps 系统从各种系统和工具中收集和汇总数据，以便快速检测问题和异常，将实时数据与反映系统原始期望状态的历史数据进行比较。通过机器学习，它学会了如何通过自动化操作来缓解问题。最终，它将学会如何预测事件并避免它们对系统造成影响。

为了实现这一目标，AIOps 基于算法和异常检测来处理预测性警报。它知道系统应该如何反应和响应，以及系统如何与其他系统交互。偏差会迅速被发现、分析和验证：这些偏差是处于正常行为范围内，还是超出了该范围？如果系统出现异常，可能会带来什么后果？

AIOps 只有在提供数据时才能评估这些事件：系统数据和过程数据，例如请求以及已发生的事件和问题的数据。它需要这些数据来学习并适应算法，从而随着时间推移变得更准确。

在上一节中，我们学习了 AIOps 的三个领域：观察、参与和行动。现在我们需要将其转化为参考架构。我们可以通过创建四个层次来执行操作任务来实现这一点。如下图所示：

图 8.5 – AIOps 的逻辑参考架构

这四个层次包含了各种组件，就像我们在本章的定义 AIOps 架构的关键组件一节中讨论的系统逻辑架构一样：

• 收集

• 组织

• 分析

• 行动

过程从不同的服务作为输入开始：请求、事件、问题和更改。在上一节中，我们了解到这些都包含在参与数据中。AIOps 系统现在将执行几个步骤：

1. 收集是 AIOps 系统执行的第一步：它将从尽可能多的来源收集观察结果和参与数据，包括系统指标、事件、日志，甚至来自服务台提出的工单信息。所有这些数据都将发送到数据湖，即 AIOps 系统的主要存储库。

2. 数据湖将保存原始数据：从系统和监控工具中获取的源数据。原始数据格式将保持不变。因此，下一步是对这些数据进行组织。请记住，AIOps 可以访问尽可能多的数据时，准确性会提高。随着更多数据源被添加到数据湖并与之集成，AI 分析的结果会更可靠。这带来了一个挑战：原始数据会包含噪声。必须清洗这些导入的数据。

   数据科学中的一个重要教训是“垃圾进，垃圾出”。为了让 AI 提供准确的建议并学习正确的数据，我们需要确保它只使用合适的数据集。数据模型也需要进行训练。这将需要一些时间：系统需要被告知什么是好数据以及这些数据可以用来做什么。这样，算法会随着时间的推移变得更加准确。

   通过一个例子可以更清楚地说明。监控将收集服务器中 CPU 的数据。这个 CPU 可能会有 90% 的使用峰值，但总体使用率大约为 20%。AIOps 需要学习，例如 20% 到 40% 之间的值是正常的。它还需要学习，如果 90% 的峰值持续时间非常短，那是可以接受的，而且不必为此触发警报。现在，模型可以根据这些参数筛选事件和日志数据，并识别出超出该阈值的系统。事实上，常规监控系统已经能够做到这一点，但 AIOps 将能够将 CPU 性能的异常与其他事件关联起来。而且它能够自动启动修复措施。

3. 经清洗和结构化的原始数据将用于训练 AI 模型，采用机器学习和深度学习。

4. 实时数据与历史数据进行比较，包括原始配置、已执行的更改和已发生的事件。通过不断比较这些数据，AIOps 系统会学习，并能够展示事件的时间线。这使得在某些情况下，操作员能够通过一系列事件进行时间旅行，调查系统状态何时以及为何发生变化。

5. 最后一步是执行。经过训练的 AI 模型将根据对先前事件的学习以及在特定事件发生时所采取的行动，发送预测警报并开始缓解措施。显然，所有的警报和措施都作为数据返回到数据湖中。

我们准备开始实施 AIOps 平台了。在接下来的部分，我们将讨论成功实施的方案，并指出一些潜在的陷阱。在最后一部分，我们将简要概述一些流行的工具。

成功实施 AIOps

AIOps 仍然是 IT 操作中的一个相对较新的现象，实施 AIOps 平台可能非常复杂。然而，考虑到以下步骤，成功实施应该是可以做到的。第一个，也是可能最重要的教训是，从小处着手，就像 DevOps 和 SRE 一样。

在你开始之前，你需要一个计划。确定哪个系统适合做试点。选择一个具有基础架构的系统：一个只有网站作为前端的应用程序、应用程序本身和数据库。验证与此应用程序相关的所有资产是否已被良好记录，并在 CMDB 中识别出来。接下来，确保你对与该应用程序相关的工作流和流程有一个良好的——并且是有文档记录的——理解。

为什么这很重要？AIOps 平台以及工程师——操作员——需要学习如何与 AI、机器学习和分析工具一起工作。操作员希望从平台中得到什么？什么类型的警报？并且，是否清楚他们应该如何处理这些警报，或者如何利用 AIOps 来分析警报并帮助自动化行动？操作员需要了解 AIOps 系统所需的数据类型，因此他们需要学习数据要求、数据流、将数据存储在数据湖中以及建模数据分析。这肯定需要时间。

现在，AIOps 系统可以进一步配置，并可以添加更多 IT 组件，以确保系统能够从不同的使用场景中学习。强烈建议在前几周，甚至长达 2 个月的时间内，以测试模式运行平台，让 AIOps 进行学习。一旦操作员对功能和分析结果满意，就可以将其推向生产环境。但始终需要通过原始系统指标和实施 AIOps 时设定的目标来验证结果。简单的问题是：这些目标在测试阶段是否达成？如果目标是加快定义事件根本原因所需的时间，那么这个目标应该是可衡量的，并与原始指标进行比较。换句话说：任何系统的实施必须有一个有效的商业案例。

所以，第一步是捕获操作数据：来自基础设施组件、应用程序、数据库和 API 的日志和指标。接下来，我们需要来自工作流和业务流程的数据。我们可能还需要其他关联数据，例如，关于销售和市场情绪的数据，"预测"某些服务在特定时期内的流行程度以及在什么条件下流行。

使用案例

一家国际运营的铁路公司几年前实施了 AIOps。他们的基础设施建立在多个平台上，包括 AWS 和 Google Cloud，使用了许多不同的工具进行监控和开发。这些平台及其依赖项缺乏实时可见性，导致开发进度放缓，还导致根本原因分析的严重延迟。这导致了一些重大停机事件，影响了旅客。通过将来自不同平台的数据汇集并整合 AWS CloudWatch 和 Google Analytics 等监控工具，该公司能够对所有相关系统进行集成视图。通过利用这些数据，实施了 AIOps 工具来实时分析事件，显著降低了 MTTD 和 MTTR。

该使用案例表明，我们能够获取的数据越多，我们的 AIOps 平台就会越准确。这些数据将揭示事件之间的相关性，并最终确保 AIOps 理解这些事件的根本原因。从这一点开始，您可以通过监控中的实时观察和创建自动化响应来训练平台进行解决方案。

实现 AIOps 平台的一个关键步骤是要真正让操作员参与其中。他们是并且将始终是从平台中获取实际价值的重要角色。换句话说，AI 不是为了取代操作员——恰恰相反。该系统将使他们能够摆脱繁琐、重复且通常是手动的任务——记住 SRE 中的劳动——并让他们能够专注于其他更具挑战性的任务，这些任务是开发、测试和推出新系统所必需的。

不涉及操作员只是其中一个陷阱。在接下来的部分中，我们将简要概述一些其他潜在的陷阱。

避免 AIOps 的陷阱

在实现 AIOps 平台时，除了不涉及操作员外，还有三个主要的陷阱必须避免：

• 数据不足：只有有限的数据集，AIOps 平台无法正常工作。没有足够的数据，系统永远无法准确。发现、问题、事件和异常将无法或只能偶尔被检测到，这将使系统不可靠，产生误报，甚至解决不需要解决的问题。

• 错误或无关的数据：这可能比数据不足还要糟糕。错误的数据肯定会导致错误的结果和意外或不希望出现的行动。为了以正确的方式学习，AI 需要足够且有效的数据。

• 数据孤岛：AIOps 平台从多个系统获取数据。然而，AIOps 需要将这些数据从一个来源提供，以便进行数据分析。操作数据、应用性能数据、连接性数据和安全数据：这些数据需要汇集到一个来源，以使系统在生成有价值的数据集时既快速又高效。换句话说，数据孤岛需要被打破。

总结来说，AIOps 需要足够的数据、相关的数据，并将其存储在一个仓库中，以便能够创建用于运营分析的有价值数据集。到现在，你应该已经意识到 AIOps 系统是复杂的，但越来越多的工具可以帮助你入门。我们将在本章最后一节列出一些这些工具。

AIOps 中的流行工具

最后，我们将提供一些工具，帮助你开始使用 AIOps。近年来，AIOps 领域发展迅速。请看下图中的 DevOps 工具周期表：AIOps 类别是最近才加入的，已经列出了大量的工具，例如 Splunk、Datadog、Dynatrace、New Relic 和 Elastic ELK Stack：

图 8.6 – 来自 DevOps 工具周期表的片段，展示了 AIOps 工具（Digital.ai）

选择合适的工具并不容易。原因在于，这些工具之间的差异非常大。它取决于企业评估合适工具和工具集的角度。需要考虑的事项包括以下几点：

• 侧重于应用程序和应用程序性能管理的工具，而非基础设施组件

• SaaS 或本地部署工具

• 原生 AI 和 ML 或需要扩展的工具

• 数据驱动的 AI 或者同时具有上下文感知的 AI

  注意

  Gartner 每年发布一次魔力象限，识别这一新兴市场中的领导者和有前景的新兴公司。该报告可以从 Gartner 网站下载：www.gartner.com/en/documents/4000217/market-guide-for-aiops-platforms。请注意，你或你的雇主需要成为客户，才能从 Gartner 网站下载内容。

显然，更复杂的工具会有较高的价格。企业必须问自己最重要的问题是，它希望从 AIOps 中获得什么。这将推动商业案例，并可能证明投资的合理性。

总结

本章深入探讨了 AIOps。这是一个相对较新的领域，但前景非常广阔。我们学习了 AIOps 平台是如何构建的，并随着它们在企业中的实施不断学习。重要的是要理解，你需要一个逻辑架构，以便全面了解系统如何完成功能以及它们如何与其他系统相关联，而不需要已经知道这些系统的所有技术细节。

接下来，我们定义了 AIOps 的关键组件，即大数据和机器学习或深度学习。AI 只有在获得足够相关数据的情况下，才能执行分析模型。这些模型将教平台如何检测问题、异常和其他事件，预测对 IT 领域的影响，更快找到根本原因，并最终触发行动。这些行动可以被自动化。AIOps 平台将避免许多繁琐、重复的工作，这种工作在 SRE 中被称为 toil。

我们已经了解了 AIOps 的参考架构是什么样的，以及企业如何成功地实施该系统。在上一段中，我们简要地了解了一些该领域的流行工具。

在下一章中，我们将学习如何将 AIOps 融入 DevOps。

问题

1. 逻辑架构中的展示层是做什么的？

2. AIOps 平台能够通过算法检测与预期系统行为的偏差。我们称这种检测偏差的过程为何？这是 AIOps 的一个关键特性。

3. AIOps 处理来自操作系统的数据和来自事件（如事故和问题）的数据。Gartner 如何称呼这种后者类型的数据？

4. 对错：数据清洗在 AIOps 中至关重要。

进一步阅读

实用企业架构，詹姆斯·V·卢伊西，2014 年

第九章：将 AIOps 融入 DevOps

到目前为止，我们从 DevOps 视角探讨了自动化开发，并已实现自动化运营。接下来的步骤是人工智能（AI）驱动的 DevOps。DevOps 工程师管理着多个库和各种管道。为了加速数字化转型，及时发现并解决问题至关重要。AI 在这些 DevOps 流程中也能带来巨大的附加价值。本章将向你介绍如何实现 AI 驱动的 DevOps，并推动快速创新。

完成本章后，你将对实现和集成 AI 驱动的开发与部署管道所需采取的各种步骤有较好的了解。你将接触到一些主要工具，并了解实现这些工具作为数字化转型创新一部分的要求。

在本章中，我们将讨论以下主要内容：

• 引入 AI 驱动的 DevOps

• 为数字化转型启用快速创新

• 使用 AIOps 监控管道

• 评估企业对 AI 驱动 DevOps 的准备情况

引入 AI 驱动的 DevOps

在上一章中，我们研究了 AIOps 平台，得出结论，它将帮助运维人员摆脱繁琐的重复任务，更快地检测和解决问题，并实现更稳定的系统。稳定性和弹性仍然是运维人员在 IT 系统中追求的关键目标，但随着新功能和系统更改以更快的速度开发和发布，如果 AI 能帮助运维，它也能帮助开发。本节将解释为什么 AI 驱动的 DevOps 有助于以更高的速度创造更好的系统。

AI 可以帮助开发者比单纯的手动操作或没有 AI 支持的自动化过程更快地监控和检测构建中的问题。借助 AI，可以持续监控代码变化，将其与其他代码构建模块进行比较，并迅速发现问题。同时，AI 还能实现预测性缓解：它将学习某些代码更改可能对系统产生的影响。考虑到系统的复杂性不断增加，且新功能和新代码以越来越快的速度开发，AI 驱动的 DevOps 是确保系统稳定性的解决方案。AI 将帮助管理各种代码库，跟踪配置和部署脚本，并避免意外的应用行为。

它是如何工作的？就像我们在第八章中讨论的 AIOps 一样，架构 AIOps。AI 驱动的 DevOps 将从 DevOps 周期中的模式中学习。为了做到这一点，它需要数据。它将使用存储在代码库中的代码数据，以及用于构建 CI/CD 管道的过程数据，然后运行各种测试和部署程序。此外，它还会从历史数据中学习；即，发生过的问题和事件，以及这些问题是如何解决的。通过分析和机器学习，AI 将学会如何优化代码构建、测试和部署。

DevOps 在过去十年中确实有所发展，但开发人员和运维人员仍然面临一些繁琐的任务，如编码、测试和将新特性部署到系统中。许多工作仍然非常手动，且在测试和代码审查中需要多个步骤。由于代码变得越来越复杂，系统也越来越与各种平台交织在一起，问题可能无法及时或根本无法被发现。为了节省时间，代码审查有时通过抽样进行：随机挑选一些代码，并对这一特定代码段进行审查，不能保证其余代码是正确的。那么，什么时候代码是 OK 的呢？通常，重点是去除空行或过时的空格，但这些问题可以通过格式化工具轻松解决。显然，必须消除 bug，但代码也需要优化以便表现良好。所有这些都需要在生产环境保持运行和稳定的情况下完成。

AI、机器学习（ML）和深度学习可以帮助克服这些问题。接着，就是 AI 驱动的 DevOps。这需要以下组件：

• 访问和控制源代码库

• 用于建模的数据湖和数据集市

• AI 集成管道

基本过程包含下图所示的步骤：

图 9.1 – AI 集成管道的概念

我们将在使用 AIOps 监控管道一节中详细说明这些步骤，我们将讨论用于监控 DevOps 管道中流程的各种工具和技术。

AI 是 DevOps 中的一个新领域。这是一个可以加速企业数字化转型的创新。在深入探讨如何将 AI 融入 DevOps 管道之前，最好先更好地理解创新周期以及为何要引入 AI 和机器学习（ML）。我们将在下一节讨论这一点。

促进数字化转型中的快速创新

现代企业大多数都在积极推动业务转型，使其更加数字原生。我们在本书的前两章中已经详细讨论了这一点。客户不断要求新的功能，而且他们希望这些功能几乎能立即交付。为了控制这一过程，企业需要制定一个创新战略，以适应快速创新。创新战略可以被描绘为一个金字塔，AI 驱动的创新位于这个金字塔的顶端。

这可以在下图中看到：

图 9.2 – AI 驱动创新金字塔

企业不会一蹴而就地登上金字塔的顶端；它们通常从底部开始，创新由节约成本驱动。从这里，它们需要开发下一步，从而通过 AI 和 ML 实现快速创新。

第一阶段通常涉及如何寻找预算，这通常是通过实施能够带来大幅节约成本的技术来实现的，例如，通过迁移到另一个平台。平台的选择至关重要：企业会希望确保他们做出的是未来可持续的选择，并且已经规划好通过这些创新来推动数字化转型。这样的平台可以是公共云，提供的不仅仅是托管服务，还允许我们使用云原生技术，并将其与 DevOps、AI 和 ML 集成。

更为重要的一步是收集并利用数据。AI 和 ML 需要数据，而数据需要进行聚合，以便用于分析和训练数据模型。数据可能是任何企业中最有价值的资产，因此这一步将耗费大量时间。

聚合数据并不意味着每一条数据都需要存放在同一个数据湖中。不同的数据集会有不同的需求，但架构师必须考虑如何在没有企业传统数据孤岛的情况下高效地创建这些数据集。接下来是数据安全：谁有权查看哪些数据以及出于什么原因？如何防止数据流向不该去的地方？身份和访问管理（IAM）和数据丢失防护（DLP）是非常重要的话题。为此，企业需要拥有一个一致的数据分类系统。

现在，我们可以将 AI 和 ML 引入讨论。数据模型需要进行训练、部署，并与 CI/CD 流水线集成，以增强编码和应用程序开发。这些流水线将不得不与选定平台的 数据分析模型和 AI 服务进行集成。这一过程的终点可能是一个由 AI 控制的 CI/CD 流水线。这就是下一节的主题，我们将在其中查看主要公共云平台中的一些 AI 驱动工具；即 Google Cloud Platform、AWS 和 Azure。

使用 AIOps 监控流水线

在本节中，我们将研究由 AI 驱动的技术，这些技术将帮助开发人员监控和改进他们的 CI/CD 流水线。首先，让我们回顾一下流水线的基本原理。流水线应该被视为一个工作流：它引导代码通过一个过程，在这个过程中，代码会经过测试，最终部署到平台上。按照这个过程，代码会被推送到推广路径中的不同阶段：开发、测试、验收和生产。这个过程可以被自动化。

在这个过程的开始，也就是流水线的起点，有一个存储系统各个组件的代码库。由于一切都是代码，代码库将保存应用程序代码、基础设施组件、配置模板以及启动 API 的脚本。在通过流水线构建系统时，DevOps 软件会确保从代码库中提取适当的组件，并将其编译成可以部署的包。一种常见的做法是使用容器，比如通过 Kubernetes 编排的 Docker 镜像。容器也非常适合将 AI 和机器学习注入到流水线中。下图展示了 Kubernetes 的基本功能：

图 9.3 – Kubernetes 的功能

在 DevOps CI/CD 流水线中，可以通过 Kubernetes 指示如何使用容器将组件推送到目标平台。为了实现这一点，我们可以使用 Kubernetes 的kubectl命令行工具。该工具可以向 Kubernetes 集群发送命令，告诉这些集群如何部署应用代码，同时监控集群的资源和主机。

介绍谷歌的 Kubeflow

根据其官方文档，Kubeflow 是 Kubernetes 的机器学习工具包。它允许我们在 Kubernetes 上实现并监控复杂的工作流和应用开发过程，使用机器学习在任何云平台上运行，如 AWS、Azure 和 Google Cloud 等。

对流水线中所有组件的深入监控和分析是 Kubeflow 的核心功能之一。最初，TensorFlow 和 PyTorch 用于训练数据模型。用 Kubeflow 本身的话说，它通过使用机器学习处理所有的无聊的部分，使开发人员能够专注于新特性。

Kubeflow 的高层架构如下面的图所示：

图 9.4 – Kubeflow 的概念架构

机器学习（ML）用于加载大量数据，验证这些数据，处理它们，并通过这些操作训练模型，使其能够从数据中学习。然而，开发人员希望能够大规模地执行这些操作。一个例子是图像识别。你可以训练 ML 模型识别图像，这一功能在医院的诊断成像中变得越来越流行。例如，利用 AI 和 ML，CT 扫描等临床图像可以被评估、去噪，并突出显示可能的关注区域，帮助医生更快地做出更准确的诊断。为了大规模运行这种类型的模型，使用容器是一种可行的选择。这正是 Kubeflow 的作用。

注意

在 www.kubeflow.org/docs/examples/ 上，你可以找到 Kubeflow 用例的教程和示例，包括图像识别的示例和如何在 Kubeflow 集群上使用 Jupyter Notebook 的教程。

Kubeflow 的架构表明，AI 驱动的 DevOps 需要多个组件，且不同的工具需要进行集成。其中一些工具是平台原生的，比如 AWS 的 CodeGuru 和 Azure 中的 MLOps。我们将在以下章节中简要评估这些工具。

引入 AWS 的 CodeGuru

还有更多的开发正在进行中，证明这是一个增长中的市场。例如，AWS 在 2021 年 5 月宣布引入 DevOps 中的 ML，使用的是 CodeGuru。

CodeGuru Reviewer 是一个使用 ML 检测代码中的问题和漏洞的工具，它还能发现已应用于代码的安全策略中的漏洞。它还提供改进代码的建议，无论是解决漏洞，还是提出对代码的增强建议。

CodeGuru 的第二个组件是 CodeGuru Profiler。完成代码审查后，Profiler 验证代码的运行时，识别并去除代码中的低效之处，从而提高应用程序的性能。AWS 声称它还有助于降低计算成本，因为 Profiler 还会检查代码在运行过程中所调用的资源。通过使用 ML，它可以主动地执行这一操作，因为它通过比较新代码与现有代码模式来学习如何优化代码。根据 AWS 的文档，自 CodeGuru 推出以来，它已经审查了超过 2 亿行代码。

以下图表展示了使用 CodeGuru Reviewer 和 CodeGuru Profiler 的 CodeGuru 架构：

图 9.5 – AWS 的 CodeGuru 和 CodeGuru Profiler

该领域的下一个步骤是 Amazon DevOps Guru。DevOps Guru 更侧重于 DevOps 的基础设施层面。它运行预训练的 ML 模型，分析系统日志和度量指标，与操作基准进行对比，从而检测基础设施组件中的异常。由于它使用深度学习，模型会持续训练和增强。

在 Azure 中引入 MLOps

所有主要的云服务提供商都拥有基于人工智能的解决方案。我们将简要讨论的最后一个是 Azure 中的 MLOps。其基本原理与 CodeGuru 相同：MLOps 会从代码库中拉取代码，这通常与 Azure DevOps 集成。下图展示了 MLOps 的架构：

图 9.6 – 微软 Azure 中的 MLOps 架构

MLOps 对提交的代码执行各种测试。尽管结果与其他基于人工智能的工具类似，但 MLOps 的工作方式有所不同，它使用 Azure ML 管道来训练模型。然而，MLOps 还在容器化基础上运行，采用 Azure Kubernetes 服务（AKS）和 Azure 容器实例（ACI）。

总结来说，使用基于人工智能的 DevOps 会让你能够做到以下几点：

• 识别缺失的代码。

• 检测写得不好的代码。

• 检测不必要的代码。

• 检测预期和/或必需但缺失的依赖项。

• 执行配置检查。

• 提出改进建议。

• 触发自动化改进行动。

基于人工智能的 DevOps 是一个快速增长的市场，因此，除了 Google 推出的原生服务如 CodeGuru 和 Kubeflow 外，过去几年中许多初创公司也推出了大量新兴工具。例子包括 Pipeline.ai、DataRobot 的 Enterprise AI、Hydrosphere.io 和 Xpanse AI。前三个主要专注于机器学习驱动的管道，而 Xpanse AI 是一个用于使用人工智能创建数据模型的环境。

注意

在本章中，我们讨论的是增强了人工智能和机器学习的 DevOps 管道。为了开始数据建模和数据分析，你还需要一些工具来支持它们。在这个领域中，流行的工具包括 Databricks、MapR、Cloudera 和 RapidMiner。

总结来说，企业投资于基于人工智能的 DevOps 是有意义的，这可以促进快速创新并加速数字化转型。那么，第一个需要回答的问题是，企业何时准备好进行这种范式转变？我们将在接下来的部分简要讨论这个问题。

评估企业在人工智能驱动的 DevOps 方面的准备情况

到目前为止，我们已经了解到，数字化转型是一个渐进的过程。它不会一步到位；企业需要为此做好准备。它包括采用云平台和云原生技术。企业将拥有遗留系统，并且可能有大量数据存放在不同的数据孤岛中，这给企业带来了如何优化利用这些数据的挑战。认为人工智能驱动的工具和数据科学能够一开始就解决这个问题是一种误解。

企业需要对所有资产进行全面的概览，还需要了解其技能和能力。首先，数据专家需要评估数据源的位置、格式和可用性。接着，数据科学家将需要设计数据模型。他们不能单独进行此操作：他们必须与 DevOps 工程师和应用所有者合作，达成版本控制、模型训练和测试等方面的共识。

达成共识的数据模型随后可以集成到 DevOps 流水线中。在上一节中，我们了解到，必须选择并与 CI/CD 工具集成工具，例如，通过使用容器和容器编排平台如 Kubernetes。专注于 ML 的工程师可以通过利用 AI 的优势来帮助实施、跟踪和训练这些数据模型。

这还不是全部。流程——我们称之为参与流程——如事件、问题和变更管理，需要与新的开发和部署设置保持一致。服务经理将需要理解与 ML 和 AI 驱动的平台相关的新指标。平台出现警报或建议时，应该怎么做？监控了哪些内容，为什么要监控这些？任务是否可以进一步自动化，从而节省时间并降低成本？

然而，最重要的问题是，哪些建议需要采取行动以改进开发并加快发布速度？人工智能可以提供帮助，但它需要时间来学习企业的运作。需要经过培训和具有技能的员工来帮助人工智能熟悉企业。这不是魔法。

总结来说，企业需要具备以下内容：

• 完整的资产可视化

• 对所有数据源的全面可视化，以及这些数据源与业务流程的关系

• 在整个企业中实施的参与流程，以确保一致性

• 经过培训和具有技能的员工，如 DevOps 工程师、数据科学家和 AI/ML 工程师

• 一个具有现实时间表的创新路线图

前述的路线图可能会引领到一个遥远的未来，在这个未来，运营完全由 AI 和 ML 自动化，不再需要人工干预。这就是 NoOps 的作用。在 第十章，迈向 NoOps 的最后一步，我们将介绍这一概念。

总结

在本章中，我们学习了如何将 AI 和 ML 集成到 DevOps 流水线中。我们讨论了实施 AI 驱动的 DevOps 的基本要求和步骤，从访问源代码仓库、创建数据湖、启动和训练数据模型到后续建议和行动。我们还了解到，AI 驱动的 DevOps 是数字化转型的一个阶段，但企业需要制定一条路线图，最终使他们能够将 AI 和 ML 集成到开发和部署过程中。基于 AI 的开发和运营处于数字化转型创新的顶端。

接下来，我们介绍了一些能够帮助我们实施 AI 驱动 DevOps 的工具。我们了解到，这是一个快速增长的市场，主要云服务提供商正试图将它们的原生 DevOps 工具与 AI 和机器学习结合起来。比如谷歌的 Kubeflow、AWS 的 CodeGuru 和微软 Azure 的 MLOps。

最后，我们讨论了希望实施 AI 驱动 DevOps 的企业的准备评估。制定一个全面的路线图至关重要，其中包括不同的步骤和一个现实的时间表。该路线图的最终目标可能是实现完全自动化的管道编排，无需任何人工干预：NoOps。这是下一章的主题。

问题

1. 我们介绍了数字化转型的创新金字塔。那么，这个金字塔的基础平台是什么？

2. 将 AI 集成到 DevOps 管道中通常是通过容器化完成的。我们讨论了一种容器编排工具，允许我们将容器无缝地部署到各种平台上。这个工具叫什么名字？

3. 列举三个 AI 驱动的 DevOps 可能带来的结果/成果，特别是在提升代码质量方面。

进一步阅读

• 实用企业架构，作者：James V. Luisi，2014 年

• Kubeflow 文档：www.kubeflow.org/

• 关于 AWS 推出 CodeGuru 的博客：www.allthingsdistributed.com/2021/05/devops-powered-by-machine-learning.html

• 由 Lee Stott 撰写的关于微软 Azure 中 MLOps 的博客：techcommunity.microsoft.com/t5/educator-developer-blog/machine-learning-devops-mlops-with-azure-ml/ba-p/742150

第十章：迈向 NoOps 的最终一步

是否可以在没有实际操作的情况下执行 IT 运维？研究和咨询公司，如 Gartner 和 Forrester，预见到基于 NoOps 的 IT 未来。NoOps 背后的核心理念是，几乎一切都可以自动化。这意味着 AI 的作用将更为重要，并且有一种叫做启发式自动化的技术。企业如何向 NoOps 转型，架构师在这一领域中的角色是什么？我们将在本章中讨论这些问题。

完成本章后，你将能够解释 NoOps 这一概念，并了解为什么企业应采纳 NoOps 的原则。你将学习什么是启发式自动化，它如何推动 NoOps 的架构。你将学到的最重要的一课是，NoOps 不仅仅是指完全不需要任何运维。

本章将涵盖以下主要内容：

• 理解向 NoOps 的范式转变

• 理解 AI 在 NoOps 中的角色

• 为启发式自动化创建架构

• 定义 NoOps 的路线图

理解向 NoOps 的范式转变

在前几章中，我们讨论了人工智能（AI）和机器学习（ML）在运维和开发中的应用。在第九章《将 AIOps 融入 DevOps》中，我们学习了企业如何在 DevOps 流水线中利用 AI 和 ML。这样做的原因是通过智能自动化让大量手动任务变得过时。NoOps 将这一点推向了一个更远的层次：完全自动化 IT 系统，不再需要操作员手动干预系统。我们离这一范式转变还有多远？此外，这是否现实？ 我们将在本节中讨论这个问题。

对于最后一个问题的回答是：NoOps 似乎更像是一种理想，而非现实实践。关于 NoOps 的讨论始于一个观点：团队实际上可以在开发过程中自动化很多流程，尤其是应用程序的部署。这一想法起源于将服务作为软件即服务（SaaS）提供，这意味着企业不再需要担心维护这些服务。SaaS 和平台即服务（PaaS）中的更新和升级由提供商负责。获取软件和维护应用程序变得像使用智能手机一样简单：晚上你把手机放到一边，手机制造商更新你的手机，早上重新启动时，所有应用程序仍然可以正常使用。事实上，要实现这一点，很多操作必须在后台执行。换句话说，NoOps 可能是表面上的。

然而，NoOps 的理念确实值得肯定。它符合 DevOps 的原则，尽可能自动化代码的开发、部署和操作。根据德勤的说法，NoOps 是自动化 IT 任务和将活动从运维转移到开发中的一种逻辑演进，专注于业务成果。这并不是什么新鲜事。DevOps，特别是站点可靠性工程（SRE），将这些作为基本原则。

要明确的是，NoOps 并不等同于自动化基础设施的配置。NoOps 是关于全栈的自动化管理——包括应用程序、中间件、数据库和基础设施。在基础设施方面，NoOps 的概念依赖于可以通过代码编写和控制的基础设施组件。虚拟机可能是一个选择，但在操作自动化方面，它们仍然不够灵活。容器，尤其是无服务器解决方案，更具逻辑性。

我们可以自动化编码、基础设施的配置、API 的部署和配置。我们可以加入技术，快速检测问题和异常，甚至可能让系统根据预定义的策略自动进行修复。我们可能能够完全自动化某个应用程序，但现实情况是，今天的企业 IT 由复杂的生态系统组成，涵盖企业内部和外部。这使得在实践中真正实现 NoOps 变得困难，甚至不可能。相反，运维变得更加复杂。但再说一遍，NoOps 并不是要完全摆脱运维。

NoOps 应该被视为一种概念和指导思想，旨在利用自动化节省成本、加快开发进程，同时保持系统的稳定性、弹性，并避免手动操作的干扰。NoOps 将帮助架构师实施 Shift-left 原则，将 AI 融入操作中，并且有助于自动化 IT。我们将在接下来的章节中进一步探讨 Shift-left 和 AI 驱动的操作。

理解 AI 在 NoOps 中的作用

在上一节中，我们讨论了 NoOps 是否为未来企业提供了一种切实可行的运营方式。我们的结论是，NoOps 应该被视为一种概念和思维方式，旨在通过自动化来优化运维。它并不是要完全摆脱运维——企业的 IT 环境已经过于复杂，无法做到这一点。不过，企业依然面临如何最优化使用 IT 人才的挑战。

IT 人才变得越来越稀缺，因为市场对熟练且经过培训的工程师的需求正在以高速增长。因此，人才的稀缺性也导致了员工成本的增加。为了降低成本，同时尽可能保持敏捷，企业架构师必须寻找其他方式来运营 IT。这样，IT 人才就可以专注于开发工作。

然而，仍然需要运维人员。我们需要有人来照看系统，并确保这些系统的稳定运行。不能把所有事情都交给机器。因此，将 NoOps 的定义略微缩小是好的。我们可以将 NoOps 定义为不再需要专门的运维人员来管理 IT 的阶段。它将是企业 DevOps 演进的一个逻辑步骤，在这个阶段，团队在开发、部署和运维中作为一个整体协作。

要达到这一阶段，有两个因素将起到重要作用：

• 采用左移策略： 第七章，理解 AI 对 DevOps 的影响中，我们得出结论，左移策略同样适用于 DevOps 中的部署和运维。通过自动化模板、预批准的模式和流程，我们可以在开发的早期阶段开始测试，并将一致且稳定的代码部署到后续阶段（包括生产环境）。这无疑将减少运维的工作量。

  运维人员通常定义如何监控生产环境，而开发人员在沙盒、开发和测试环境中自行控制这一过程。在 NoOps 中，这一职责被移到整个生命周期的开始——DevOps 团队决定如何测试和监控代码。团队承担端到端的责任。运维人员和开发人员之间的区别变得不再重要。

• 人工智能和机器学习：正如我们在 AIOps 中看到的，AI 和 ML 将帮助快速检测问题，甚至可以经过训练给出建议或启动如下操作：

  • 自动化软件生命周期管理：AI 将帮助识别何时需要更新软件，并负责更新过程，保持运行在软件上的服务的稳定性和可操作性。可以参考第一部分中的智能手机类比。当手机进行更新后，用户重新启动时，所有功能通常会恢复正常。这是因为手机知道不同应用程序之间的依赖关系，以及底层协议和代码。它利用 AI 来实现这一点。

  • 自动化修复：AI 可以在问题出现之前就触发自动化操作来修复问题，从而实现预测性维护。

  • 自愈：当出现意外问题时，AI 将检测到问题，并根据历史记录或学习的方式知道如何解决问题，最终应用修复。这一解决问题的过程称为自愈。请注意，所有这些操作——生命周期管理、修复和自愈——都需要进行日志记录，以便每个变更都可以追溯。

现在，我们已经讨论了 DevOps 中的自动化，介绍了 DevOps 中的 AI，并且还讨论了在 NoOps 中进一步利用自动化。此级别自动化的基础是启发式自动化。在下一节中，我们将研究启发式自动化的架构。

创建启发式自动化的架构

首先，让我们定义一下启发式：在文献中，它被指应用一种解决方案来解决问题，目的是解决当前发现的问题，而非达到最优解决方案。试错法显然符合这个定义。匈牙利数学家乔治·波利亚在他 1945 年首次出版的《如何解决问题》一书中使用了这个术语。他提供了一些实际的解题方法。

他的一个原则常用于应用机器学习（ML）的架构中：如果没有解决方案，可以假设自己有一个解决方案，然后看看它的效果。保留有效部分，分析不太有效的部分。再试一次迭代的解决方案，并从中学习。这是启发式自动化的基础。它使用启发式学习，可以通过能够识别和学习模式的人工智能来实现。人工智能将使用算法和自动化——它不断学习并调整分析，直到解决方案得到优化。

首先，我们需要理解学习原理。自动化中的人工智能和机器学习通常使用演绎推理。如下图所示。还有更多的学习原理，如归纳和溯因，但这些对自动化的目标没有实际帮助：

图 10.1 — ML 中的演绎原理

通过演绎，系统将通过观察事件并与先前的经验、示例和常见理论进行比较来分析事件。基于该分析，系统将得出结论。规则库将告诉系统下一步该做什么。显然，这个规则库是动态的，因为系统会将其学习到的内容添加到规则库中。

记住这一点，我们可以定义启发式自动化的组件：

• 事件源：从系统及其组件的事件中聚合数据。

• 模式和关联数据：包含已知模式和系统间关联的存储库。

• 分析引擎：支持分析和预测结果的算法和规则。

• 分析过程：告知系统在检测到异常时应做什么，以及应从规则库中应用哪些解决方案。

• 动态规则库：基于归纳模式的可能解决方案。这是一个动态过程，因为解决方案会不断改进。根据发现，解决方案会被更新。

启发式自动化的逻辑架构如下图所示：

图 10.2 – 启发式自动化的逻辑架构

启发式自动化将使企业能够做到以下几点：

• 通过自动分析复杂系统，识别并解决问题，无需人工干预。

• 识别、识别并理解系统之间的关系，预测问题的影响。

• 通过机器学习使用各种数据源和实时分析解决问题。

我们再次强调，NoOps 和启发式自动化绝不是为了取代操作员。它将帮助他们更快地解决问题，同时帮助企业建立更稳定、更具弹性的系统。

定义 NoOps 的路线图

NoOps 不是一场盲目的信任跳跃。与 DevOps 和 AIOps 一样，任何下一步都需要一个计划和路线图。利用启发式自动化和 AIOps 的原则，我们可以利用自动化实现智能自动化，与云原生自动化协作，并在 CI/CD 流水线中实现自动化应用部署。

下图显示了 NoOps 由三个主要组成部分构成。这三个部分是达到自动化水平的路线图，在这个水平上，专门的运营不再需要。DevOps 团队对代码的开发、部署、运行和维护承担端到端的责任，得到完全自动化的流程和人工智能的支持：

图 10.3 – NoOps 的组成部分

最终状态是使用预测分析的自动化，通过分析当前数据来最终做出未来的预测。它包括以下内容：

• 为未来的需求扩展，例如通过分析软件使用情况，预测未来的使用，并在系统扩展时采取相应行动

• 预见业务趋势并为此准备系统，包括通过收集和分析需求来准备代码

• 改进代码的建议，满足预测的未来需求

一个非常简化的 NoOps 路线图可能如下图所示：

图 10.4 – NoOps 路线图的简化表示

采用 NoOps 需要正确的思维方式和企业管理层的全力支持。管理层需要学会信任自动化。只有当这种信任建立起来时，他们才会愿意投资合适的工具。这将需要时间，这个时间表需要是现实的，正如路线图所反映的那样。最后，要准备面对反对和挫折。NoOps 和完全自动化更关乎采用而非技术，采用是一个过程。

NoOps 是一场盲目的信任跳跃吗？是否可以实现没有人工干预的自动化？想一想：早在 2018 年，Open Road 项目就已被定义，研究计算机设计自己新一代芯片的可能性。在 2021 年 6 月，科学杂志《自然》发表了一篇文章，指出计算机不再需要人类来设计新芯片。通过使用人工智能，计算机可以在数小时内设计芯片，而人类则需要几个月才能达到相同的结果。为此所使用的基础技术是机器学习，以及在 Google Cloud 中使用云原生分析工具运行并行会话，从而实现设计结果的可预测性。

在本书的这一部分，我们深入讨论了 DevOps、SRE 和 AIOps 的方法论。这些方法论都在开发和运营中大量使用自动化，甚至到了人类干预可能变得过时的地步。那么，随之而来的问题是——这安全吗？我们真的可以把 IT 留给自动化和 AI 吗？我们的系统安全性如何保障？我们需要将 DevOps 战略与安全标准对接，包括行业安全框架和企业专有的安全政策。这些都需要嵌入到 DevOps 中。这就是 DevSecOps 的领域。在本书的第三部分，我们将进一步讨论这个问题。

摘要

在本章中，我们讨论了 NoOps 的概念——无操作。我们发现这个术语可能具有误导性，因为 NoOps 并不意味着企业将完全不再需要运营。NoOps 是一个最大化自动化潜力的概念。通过自动化开发、部署和运营，稀缺的 IT 人才可以专注于新功能，因为 NoOps 会通过快速识别和解决 IT 系统中的问题来帮助他们。我们了解到，NoOps（像 AIOps 一样）使用了 AI 和 ML。但 NoOps 还意味着企业需要接受“向左迁移”的思维方式。

我们还了解到，NoOps 需要一种特定类型的架构来支持启发式自动化：应用迭代解决方案，从这些解决方案中学习，并持续改进它们。我们还讨论了启发式自动化的不同组成部分。在最后一部分，我们探讨了从 DevOps 到 NoOps 的可能路线图。我们得出结论，虽然我们已经具备了可用的技术，但企业需要采纳这些技术，才能真正实现全面自动化，进而实现 NoOps 的概念。

在本书的下一部分，我们将探讨一个与企业 DevOps 相关的重要话题——安全性。我们将学习如何将安全性与 DevOps 融合到 DevSecOps 中。

问题

1. 一个系统检测到一个意外问题，能够通过历史记录或学习知道如何解决它，并最终自动应用修复措施。我们如何称呼这种行为？

2. AI 驱动的系统通常使用什么类型的学习来自动化修复操作？

3. 判断正误：预测性自动化用于预测系统未来的使用情况以进行扩展。

深入阅读

• 关于 NoOps 的博客，发表于 CIO.com，由 Mary K. Pratt 撰写：www.cio.com/article/3407714/what-is-noops-the-quest-for-fully-automated-it-operations.html

• 关于基础设施启发式自动化的博客，由 Ramkumar Balasubramanian 撰写：www.linkedin.com/pulse/heuristic-automation-infrastructure-ramkumar-balasubramanian/

第三部分：架起安全性与 DevSecOps 之间的桥梁

在前面的章节中，我们实现了开发和运维的自动化。现在，最后一步是将安全性与其一同自动化。这就是 DevSecOps 的起点：它将安全性融入到每一个开发步骤以及运维的发布过程中。DevSecOps 包括测试、部署和最终交付。在这一部分，你将深入了解 DevSecOps，并学习架构的具体样貌以及如何将安全性与 DevOps 进行集成。

以下章节将在本节中进行讲解：

• 第十一章，理解 DevOps 中的安全性

• 第十二章，面向 DevSecOps 的架构设计

• 第十三章，使用行业安全框架与 DevSecOps 协作

• 第十四章，将 DevSecOps 与 DevOps 集成

• 第十五章，实施零信任架构

第十一章：理解 DevOps 中的安全性

如果不谈论安全性，你无法谈论云、现代应用程序，甚至数字化转型。一个流行的术语是安全设计。但即使是安全设计，也需要嵌入企业架构中。它同样适用于 DevOps 周期：DevOps 需要有安全设计。在我们讨论这个问题以及零信任等原则之前，我们首先需要深入理解安全性及其对 DevOps 实践的影响。本章将介绍 DevOps 中的安全性。

完成本章后，你将了解到为何在企业架构中包含安全性非常重要，以及架构师如何收集和评估风险，并能够识别 DevOps 中的具体风险。你还将学习设置安全控制措施，以及需要在 DevSecOps 中解决的主要问题。

在本章中，我们将涵盖以下主要内容：

• 将安全性嵌入企业架构中

• 理解 DevOps 中的安全风险

• 提升 DevSecOps 的安全意识

• 定义需求和指标

将安全性嵌入企业架构中

这是你几乎每天都能看到的话题：受到某种黑客攻击或袭击的企业。系统中的任何一个小漏洞都会被犯罪分子发现并加以利用。目前（2021 年），最流行的攻击类型如下：

• 勒索软件

• 网络钓鱼

• 拒绝服务攻击

前两种攻击，勒索软件和网络钓鱼，实际上是利用了企业防御层的漏洞。最后一种攻击基本上是通过大规模的流量攻击系统，直到系统崩溃。这三种攻击都相对容易执行。事实上，你可以购买软件，甚至购买可以针对特定地址发起攻击的服务。而且不，你不需要去暗网。它们就在开放的普通互联网中。

企业如何保护自己免受这些攻击？首先，必须认识到，任何企业的 IT 系统已经变得越来越复杂，正如我们在前几章所看到的那样。IT 系统不再仅仅存在于一个私有的数据中心，它已经变成了一个使用公共云、私有数据中心或托管服务中的私有堆栈、平台即服务（PaaS）和软件即服务（SaaS）的生态系统。安全性必须在企业使用的每项服务中内嵌。

企业安全的四个传统原则如下：

• 预防

• 检测

• 修正

• 方向

前三个是关于检测安全问题，并通过缓解措施加以纠正，但显然，如果问题能够预防，效果会更好——因此，预防是第一优先。方向性是关于指导方针和警戒线：企业制定政策和安全标准以确保所有系统的安全。这就是第五个原则——一致性——的作用所在。在一个拥有多个部门、集群和团队的企业中，你需要确保安全措施在企业的每个角落都得到实施。不能有任何一个部门或团队不遵守企业的安全要求。换句话说：链条的强度由最弱的环节决定。

那么，我们从哪里开始进行企业安全呢？企业架构框架可以帮助你入门。一个例子是Sherwood 应用商业安全架构（SABSA），它提供了一种定义安全架构的方法论。它由六个层次组成，如下图所示：

图 11.1 – SABSA 安全架构模型

信息系统审计与控制协会（ISACA）将 SABSA 与更为人知的信息与相关技术控制目标（COBIT）五个原则结合起来。这五个原则如下：

• 满足企业利益相关者的需求

• 覆盖整个企业端到端

• 应用统一的集成框架

• 实现整体方法

• 将治理与管理分开

SABSA 与 COBIT 的结合形成了一种自上而下的方式，用于定义整个企业的架构。企业架构师必须至少与首席安全架构师合作执行以下步骤：

1. 确定业务目标：这是企业架构的第一阶段。企业架构总是从商业战略、目标和宗旨开始。

2. 确定业务风险。

3. 确定管理风险所需的控制措施。

4. 设计并实施这些控制措施，例如：

   • 安全治理流程

   • 访问控制

   • 事件管理流程

   • 证书管理流程

5. 设计物理架构，包括使用的平台、网络、操作系统和数据存储等。物理架构还应包括云平台和服务，如 PaaS 和 SaaS，以及 DevOps 实践，如 CI/CD。

6. 验证业务和物理架构是否符合企业必须遵守的合规性和安全标准与协议。

7. 定义并实施操作架构，例如：

   • 配置管理

   • 监控

   • 日志记录

   • 变更管理

   注意

   上述提供的列表并不意味着穷尽。在进一步阅读部分，我们包含了一个关于企业安全架构的 ISACA 期刊的链接。在该期刊中，你将找到更多关于使用 SABSA 和 COBIT 描述的步骤的详细信息。

在定义安全架构中一个重要的主题是理解风险。哪些系统面临风险，对企业及其业务的影响是什么？DevOps 带来了自己的风险。我们将在下一节讨论这个问题。

理解 DevOps 中的安全风险

互联网上有一个经典的卡通。它展示了一个拳击比赛场地。发言人在拳台左角宣布了一套庞大的安全工具和规则。然后，在右角，他宣布了戴夫：一个穿着写着人为错误的衬衫、看起来呆萌的家伙。这则卡通传达的信息是：你可以拥有世界上所有的安全系统，但这并不能阻止人为错误。而开发仍然主要是人类的工作。人类会犯错。这是否是 DevOps 中最大的风险，或者还有其他需要关注的特定风险？我们将在本节讨论这个问题。

对于是否 DevOps 意味着特定风险的问题，答案是肯定的。在不关注安全性的情况下实施 DevOps 将明显增加攻击的风险，仅仅是通过增加系统的攻击面。有三个主要的主题需要解决：

• 访问管理：DevOps 团队可能使用开发者或工具手动访问的代码仓库。即使在开源模式下操作，代码也需要保护，并且共享代码以便更多开发者能够贡献代码。即使如此，公司也希望规范对代码的访问，以防止泄露，甚至更糟糕的是注入恶意代码。

  你需要一个基于角色的访问模型来管理代码仓库：谁有读取权限和写入权限，以及谁有完全访问权限——出于什么原因？

  跟踪账户。例如，GitHub 公司可以拥有只有分配给该公司的员工或工具才能访问的内部仓库。在该内部仓库中，管理员委派角色。凭据根据公司的安全政策设置。保持访问控制的推荐方法是实施特权访问管理（PAM）。

  由于 DevOps，团队将不得不创建更多特权账户，这些账户会在开发者和工具之间手动或自动共享。这些账户还涉及服务账户、加密密钥、SSH 密钥和 API 证书，所有这些都保存在仓库中。对这些仓库的未经授权访问是灾难性的。

  PAM 解决方案提供了一种授权和审计 DevOps 周期中任何活动的方式。大多数这些解决方案使用密钥保管库来保护访问细节，并在用户能够实际访问仓库之前对其进行身份验证和授权。

• 缺乏 DevOps 工作方式和工具的护栏与指导方针：访问代码是一回事，接下来我们该如何处理这些代码？企业通常不会允许 DevOps 团队直接提交并将新代码推送到生产环境。首先，企业或首席架构师——在大多数大公司中会有一群主导架构师——需要仔细思考选择的工具集。

  每个 DevOps 团队都应使用统一的工具集，而不是根据个人喜好选择自己的工具，尽管这可能很诱人。问题在于，DevOps 工具集没有统一的安全策略标准，例如访问控制。这是企业自身需要建立和实施的内容，如果选择统一的工具集会更容易做到这一点。

  同样适用于工作方式：整个企业的工作方式必须保持一致，我们无法过度强调这一点。所有这些必须在首选技术列表和 DevOps 护栏及原则中定义。通常，会有一个主分支。新代码会首先推送到一个独立的分支——通常称为特性分支——并在该分支上进行测试。经过验证的正面测试结果后，代码会合并到主分支。主代码或主分支随后会存储在代码仓库中。这个原则在下图中展示：

图 11.2 – 合并新代码的原则

护栏定义了何时从代码仓库中提取代码，如何将其提交到特性分支，如何进行测试，最终如何发布并合并到主分支。

• 专注于开发过程和速度，而忽视安全：DevOps 主要是为了提升开发速度。绝不能以此为借口忽视安全。在接下来的章节中，我们将通过一个实际案例来说明这一点。

总结来说，DevOps 安全包括三个主题：

• 可追溯性：跟踪 DevOps 循环和管道中的每一个操作。

• 可审计性：确保在 DevOps 中开发的系统符合企业的安全标准以及企业所遵循的行业框架。第十三章，使用行业安全框架与 DevSecOps 协作，对此进行了更详细的讨论。

• 可见性：建立可靠的监控系统。

现在我们已经很好地理解了 DevOps 中的安全风险。在下一节中，我们将讨论如何开始实施 DevSecOps。

成为 DevSecOps 专家

安全从对代码仓库的访问开始，代码仓库是 DevOps 循环开始的源头。正如我们到目前为止所学的，我们希望尽可能地自动化开发、测试和部署。接下来，通过采用 DevOps，企业希望加快新应用和功能的开发与部署。速度和敏捷性可能会导致安全风险，因为代码未经过充分测试，或者更糟糕的是，它在没有应用适当的安全策略的情况下被推送到生产环境，以节省时间。让我们通过一个实际例子来说明这一点。

开发人员从仓库中分叉代码并开始在该代码上工作。在某个阶段，代码需要推送到指定的基础设施上以运行。在开发阶段，代码运行正常，因为它尚未与生产系统进行交互。一旦代码准备好发布到生产环境，它将需要建立这些连接。通常，在企业中，需要打开特定的路由和防火墙端口，以便实现连接和流量传输。

防火墙规则，特别是开放端口和分配防火墙规则，通常不会自动执行；安全工程师需要评估请求，然后批准实施设置。在很多情况下，这实际上会减缓整个 DevOps 和敏捷流程。但几乎在每个企业中，做法都是：安全是最终部署前的最后一道关卡，而不是嵌入到 DevOps 循环中。然而，绕过这一环节是一个糟糕的主意。这将增加代码和系统的攻击面。

最终结论：安全必须嵌入到 DevOps 中——它使得开发和部署成为开发人员、运维人员和安全工程师的共同责任。安全不仅是安全团队的责任，而是整个 DevOps 团队的责任。

DevSecOps 的起点

安全扫描从代码从仓库中拉取的那一刻就开始。第一步是对仓库应用基于角色的访问控制（RBAC）模型。RBAC 定义了谁可以访问以及访问的级别。身份是否只允许查看代码，还是授予完全访问权限，能够拉取代码、修改代码和向仓库添加代码？请注意，这不一定是指一个人。DevOps 工具也是身份，你需要考虑这些工具所需的访问权限。

在整个 DevOps 循环中，代码会不断地被审查、扫描和测试漏洞。一个非常简单的例子是，如果某个应用禁止访问互联网，而代码中指向了端口 80，它可能会被标记为风险。如果应用依赖于一个通过互联网连接的服务，可能会被允许，但这需要根据安全策略进行验证。扫描、测试和验证需要尽早在开发过程中进行。此外，这里也适用“左移”原则。

在 DevOps 中嵌入安全性最大的好处是，我们还可以实现自动化检查，甚至在发现或确认漏洞时立即应用补丁和修复。例如，如果代码库的新版本包含针对常见漏洞和暴露（CVEs）的补丁，这可以被注入到安全基线中，并与安全测试程序集成。代码会自动根据这个新基线进行检查。软件可以执行测试，验证代码是否符合要求，如果代码未通过，则标记出问题或触发自动修复程序来安装补丁。这不仅适用于应用程序代码，还适用于所使用的基础设施、操作系统和中间件。

使用容器的 DevSecOps

另一个例子：越来越多的企业使用容器进行代码分发。就像虚拟机一样，容器也需要符合安全政策。企业很可能会使用强化的容器，为以下内容设置策略：

• 强化的主机操作系统：通常，这些是 Linux 操作系统，通过防止被感染的容器侵入来保护主机。例如，应用于 Linux 主机的安全包，如 SELinux 和 seccomp；这些 Linux 发行版允许对内核设置实施强制访问控制（MAC）。企业可以选择开发自己的Linux 安全模块（LSMs）。

• 容器运行时安全策略：为挂载容器、特权容器、禁用容器中的 SSH、端口绑定设置以及暴露端口等设置特定权限。

下图展示了基于 CVE 的容器安全扫描原理：

图 11.3 – Docker 安全扫描概念

扫描是使用来自 CVE 数据库的数据进行的。这些数据可以来自例如国家标准与技术研究院（NIST）、MITRE 或像微软这样的供应商，后者也为其产品和服务发布 CVE 通知。扫描完成后，Docker 签名 从仓库中拉取的镜像。为此，Docker 使用 Docker Notary，它验证镜像并防止开发人员使用未签名的镜像。

现在，我们已经拥有了强化、验证过的容器，并设置了特定的权限。接下来最重要的是控制这些设置；一旦为容器设置了权限，就不应有任何方式更改这些权限。容器不应能够获得新权限，否则就不是强化过的容器了。在 Docker 中，有一种简单的方法来检查和设置这个。使用以下命令，你可以列出所有容器的安全设置：

docker ps --quiet --all | xargs docker inspect --format 'SecurityOpt={{ .HostConfig.SecurityOpt }}' SecurityOpt=[label=disable]

它将返回有关容器强化、为容器创建独立分区以及 Docker 文件和目录审计配置的消息。

接下来，设置不授予新特权选项：

docker run <run-options> --security-opt=no-new-privileges <image> <cmd>

显然，这些设置需要不断评估。DevSecOps 与 DevOps 一样，是一个可重复的、持续的过程，旨在实现持续改进。这意味着在企业采用 DevSecOps 时，目标、需求、 newly identified risks（新识别的风险）以及减轻这些风险的控制措施需要进行评估和处理。我们将在本章的最后一部分讨论这一点。

定义需求和指标

在本章的第一部分，我们讨论了架构师必须采取的步骤来定义企业安全。在本部分，我们将解释如何收集、验证需求和指标，并将其转化为控制措施和关键绩效指标（KPIs）。

业务目标

我们在第一章中讨论过这个内容，定义企业 DevOps 的参考架构，但显然，了解一个企业想要实现的目标是很重要的。它们所在的市场是什么？它们如何在这些市场中服务客户？产品组合是什么？如果一个企业运营的是金融产品或医疗保健领域，差别是非常巨大的。它们的市场决定了风险水平。银行或投资公司面临的风险可能主要是财务风险，而医疗保健行业的最大风险可能涉及到患者的生命。目标也会不同：投资公司可能有支持尽可能多的企业获得资金的目标，而医疗保健公司则有通过具体解决方案治愈患者的目标。因此，企业及其目标将决定企业属性。

业务属性

属性可以是系统的可用性、数据的准确性和客户的隐私。除了业务类型和目标外，法规将规定这些属性的级别。金融机构必须遵守如 萨班斯-奥克斯利法案（SOx）和医疗保健提供商必须遵守的 健康保险流通与问责法案（HIPAA）等国内和国际金融法规。请注意，这些法规会接受审计。我们将在第十三章中讨论这个问题，使用行业安全框架与 DevSecOps 协作。

风险

基于业务目标和属性，我们可以定义风险。如果某些事件发生，什么将对企业构成重大威胁？如果考虑到可用性，可能会遇到这种情况：企业在关键系统停止运行时没有执行故障转移的手段。企业如何从重大故障中恢复？没有冗余系统可能是一个风险，正如应用程序中的漏洞可能被犯罪分子利用一样。MITRE ATT&CK 框架可以帮助识别风险；这一内容将在第十三章中讨论，使用行业安全框架与 DevSecOps 协作。

控制措施

下一步是定义风险控制。以下是一些示例：

• 制定一个适应灾难恢复的业务连续性计划。

• 实施公钥基础设施（PKI），并配备身份存储和保管库，以确保用户隐私。

• 实施应用防火墙，并设置具体的防火墙规则以保护关键系统。

• 设置控制措施来管理、更新和升级前述内容：维护业务连续性计划、管理安全策略，并定期评估防火墙设置。

验证这些控制措施是否与属性和应用的安全框架关联，以便进行审计。对于每个控制措施，必须有一个可以在审计中验证的理由。

好消息是，企业不必独自思考这些控制措施。互联网安全中心（CIS）为许多 IT 领域定义了控制措施：CIS 控制框架。基本的 CIS 控制措施包括对特权访问的受控使用、所有 IT 系统资产（包括容器）的安全配置，以及对网络端口、协议和服务的控制。对于 Azure、AWS、GCP，以及像 Kubernetes 这样的容器平台，CIS 已经定义了具体的控制措施。

CIS、MITRE 和其他框架以及它们如何影响 DevOps 将在后续章节中进一步讨论，但首先，我们将了解 DevSecOps 架构应包括哪些内容。这个话题将在下一章讨论。

总结

本章介绍了如何将安全集成到 DevOps 中，讨论了 DevSecOps 的概念。我们探讨了安全性在企业架构中的重要性，以及它如何推动企业 DevOps 中的安全性。我们了解了采用 DevOps 中涉及的主要安全风险，并深入研究了作为 DevOps 实践中最常用技术之一的容器安全性。通过这些内容，我们为采纳 DevSecOps 确定了一些关键的起点。

在最后一部分中，我们学习了如何从业务目标和业务属性中收集和评估风险，介绍了 CIS 等常用的安全控制框架。通过一些示例，我们探索了架构师需要采取的各个步骤，以便拥有一个也能应用于 DevOps 的安全标准。

在下一章中，我们将更详细地探讨 DevSecOps 的架构，然后开始将安全策略和行业框架与 DevOps 工作方式进行集成。

问题

1. 列出企业安全的四个传统原则。

2. Docker 使用什么来验证签名的容器？

3. 判断正误：安全性不应该妨碍 DevOps 中的速度和敏捷性。

进一步阅读

• 关于使用 SABSA 和 COBIT 的企业安全架构的 ISACA 期刊：www.isaca.org/resources/isaca-journal/issues/2017/volume-4/enterprise-security-architecturea-top-down-approach

• CIS 官网：cissecurity.org

第十二章：为 DevSecOps 架构设计

和企业 IT 领域的所有内容一样，DevSecOps 需要一个架构基础。在本章中，您将学习如何为 DevSecOps 实践构建参考架构，并设计 DevSecOps 管道。我们还将讨论主要公共云服务提供商的最佳 DevSecOps 实践；即 AWS、Azure 和 GCP。为此，我们将详细阐述市场上一些领先的工具。在最后一节中，您将了解企业应采取哪些步骤来实施 DevSecOps。

完成本章后，您将能够列出 DevSecOps 架构中的不同组件，以及如何将这些组件纳入 DevSecOps 管道。您还将学习如何保护容器以及在各种公共云中最佳的做法。最重要的是，您将能够解释为什么在 DevOps 中融入安全对企业至关重要。

在本章中，我们将涵盖以下主要主题：

• 理解 DevSecOps 生态系统

• 创建参考架构

• 构建 DevSecOps 管道

• 将 DevSecOps 应用于 AWS、Azure 和 GCP

• 部署规划

理解 DevSecOps 生态系统

在上一章中，我们讨论了安全原则以及这些原则如何影响 DevOps 的工作方式。我们得出结论，安全必须贯穿开发和部署周期的每一步，从代码从代码库拉取的那一刻起，到实际的代码提交和推送到生产环境。在本章中，我们将看看DevSecOps的基础，即嵌入安全的 DevOps。

DevSecOps 由三层组成：

• 文化：这不是一个技术层面，但经常被忽视的是，DevOps 远不止应用工具和创建 CI/CD 管道。显然，DevSecOps 也是如此。在 DevSecOps 中，每个团队成员都对安全负责并采取相应行动，拥有安全的责任。这并不意味着安全专家变得过时。最好在团队中有一名安全工程师或专业人士，通常称为安全冠军。此人必须主导所有应用安全标准和政策的流程，确保合规性。

• 设计即安全：安全被嵌入到系统的每一层。这通常意味着企业有一个明确的架构，涵盖每个安全方面并将安全策略强制应用于系统：身份验证、授权、保密性、数据完整性、隐私、问责制和可用性，包括在系统受到攻击时的修复和纠正措施。软件开发人员在设计和构建新应用或功能时不需要每次都考虑安全——安全姿态一旦开发开始就会应用。安全架构、框架、规则和标准都是集中管理的。

• 自动化：在 DevSecOps 中，我们希望尽可能实现自动化，其中包括安全性。自动化安全的理由是我们可以防止人为错误，并且有自动化的门槛，在那里代码会被扫描以发现可能的漏洞或不合规的组件，比如未授权的代码。安全负责人也负责自动化安全，但他们与团队一起进行。自动化还意味着在发生攻击或数据泄露时会进行自动化审计并收集证据。接下来，自动化流程确保收集安全指标并反馈到 DevSecOps 实践中。例如，如果在扫描时发现代码中的漏洞或许可证被违反，证据将被收集并发送反馈。

DevSecOps 管理这些层次时依赖以下组件：

• 利用仓库

• 应用程序（代码）安全

• 云平台安全

• 漏洞评估和测试

DevSecOps 不应与 安全即服务 (SECaaS) 混淆。SECaaS 可以是 DevSecOps 实践中的一个组成部分，但 SECaaS 的概念主要是将安全责任转交给服务提供商。这是一种外包模型，允许企业通过订阅模式从服务提供商处获得网络安全服务。实施 SECaaS 有充分的理由，其中之一是服务提供商负责所有安全更新，基于最新的见解。企业可以定义服务水平协议，以确保及时响应事件并应用安全实践。如前所述，SECaaS 可以集成到 DevSecOps 中，但它也意味着企业必须依赖第三方来实施和管理安全基准。

在接下来的部分中，我们将讨论 DevSecOps 组件并定义参考架构。

创建参考架构

在我们讨论 DevSecOps 的参考架构之前，我们需要了解 DevOps 的角色及其如何融入安全性。DevOps 涉及软件开发生命周期。我们必须注意的一点是，开发人员越来越多地使用开源组件。这是合理的，因为它在开发新代码时提供了极大的灵活性。

开源是由社区推动的，因此开发者可以互相贡献代码并加快开发进程。项目可以共享在公开的 Git 和 GitHub 仓库中，也可以在企业内部共享。InnerSource 类型的项目就是一个很好的例子。InnerSource 在组织的边界内使用开源最佳实践进行软件开发。通常，InnerSource 项目会利用 GitHub 等平台中受保护的、访问受限的仓库。

然而，开源软件存在一些需要从安全角度解决的风险。由于开源具有其开放的社区特性——即开源的优势——这增加了将漏洞引入代码库的风险。第二个风险是许可证合规性。在开源中，许可证通常不为人们所关注，但请注意，即使是开源软件和工具也需要许可证。

让我们首先看看流程。软件开发生命周期是一个重复的过程。开发人员从仓库中拉取源代码并触发构建。代码编写完成后，代码被打包并启用以部署到下一个阶段，即测试、验收，最终是生产阶段。整个过程通过 CI/CD 流水线进行促进和监控。正如我们在前几章中总结的那样，测试代码是整个过程中的关键。我们还扫描代码以确保安全性和合规性。这应该在过程中的每一个步骤中进行。

事实上，我们从 DevOps 流程开始就需要关注安全。实际上，这意味着从代码从仓库拉取的那一刻起，我们就开始扫描安全问题。仓库也是软件开发生命周期的一部分，因此这些仓库必须防止未经授权的访问。这就需要在仓库上实施 基于角色的访问控制（RBAC）和 身份与访问管理（IAM）。

考虑到这一点，我们可以使用以下组件创建 DevSecOps 的参考架构：

• 使用 RBAC 进行仓库访问

• 静态应用程序安全测试（SAST）：这将检测源代码中的错误

• 软件组成分析（SCA）：这将检测代码中的依赖关系

• 动态应用程序安全测试（DAST）：这将动态扫描代码

这些组件被嵌入到 DevSecOps 流水线中，我们将在下一节中讨论。

组成 DevSecOps 流水线

让我们首先看一下一个常见的 DevOps 流水线。基本的流水线如以下图所示：

图 12.1 – DevOps 流水线

流水线的基本步骤如下：

• 从仓库拉取代码

• 构建

• 测试

• 部署

在 DevSecOps 中，我们将安全嵌入到流水线中，使安全标准和政策成为其集成的一部分。安全是应用于流水线每个步骤的一个层次，但它确实包括几个步骤。如下图所示：

图 12.2 – DevSecOps 流水线

这些步骤如下：

1. pipenv 用于 Python 代码，npm 用于 Node.js。用于检查的命令分别是 pipenv check 和 npm audit。

   提示

   查看 pipenv 网站，了解更多脚本和教程：pipenv.pypa.io/en/latest/。也可以查看 docs.npmjs.com/cli/v6/commands/npm-audit 了解 npm 代码检查。

2. 静态分析：这会检查不良的编码实践，比如配置错误。几乎每种编程语言都有开源工具。以下是一些工具示例：

   • C# 的 ArchUnitNet 和 Puma Scan

   • Go 的 Go vet

   • Java 的 Checkstyle 和 开放 Web 应用程序安全项目（OWASP）依赖检查

   • JavaScript 的 Flow

   • PHP 的 Parse

   • Python 的 Bandit

   提示

   这份清单并不详尽。在 github.com/analysis-tools-dev/static-analysis 上，您将找到当前使用最广泛的工具列表。

3. 扫描：开发人员很可能会使用容器，进而使用容器镜像来构建和打包他们的应用程序。这些镜像需要扫描以查找已使用的二进制文件和库中的漏洞。扫描是通过已知漏洞的基础列表来进行的；这些列表由如美国国家标准与技术研究院（NIST）等机构提供，也有软件供应商以常见漏洞和曝光（CVE）通知的形式提供。一旦报告了新的 CVE，列表会被更新，扫描工具会自动更新并触发重新扫描。Clair（github.com/quay/clair）是一个开源工具，它会执行这些扫描，也适用于 Docker 镜像。扫描过程包括代码检查，我们将在下一节关于容器加固时详细解释。

4. 动态分析：对于 Web 应用程序，开发人员可以运行自动化 Web 应用程序扫描，以检查错误的头部或缺失的令牌，用于跨站请求伪造（CSRF 或 XSRF）。这些令牌可以防止来自受信任用户的未经授权的命令被利用——这也可以是来自其他网站的功能。这些自动化的动态扫描可以集成到流水线中。OWASP Zed Attack Proxy 是一个免费的 Web 安全工具（owasp.org/www-project-zap/）。

现在，我们已经拥有一个嵌入安全的 CI/CD 流水线，它将自动涵盖大多数常见的代码漏洞。不过，这一节中我们没有涉及到的一个特定项是容器的使用，以及我们如何保护这些容器。我们将在下一节中研究如何构建安全的容器。

在流水线中使用安全容器

大多数开发人员会使用容器来打包和部署他们的代码，通常是 Docker 容器。在使用和保护容器时，有一些最佳实践。为了保持容器的一致性和安全性，它们应该定期扫描，即使应用程序已经达到了稳定状态，更新变得不那么频繁，或者主动开发已停止。如果应用程序仍然在使用其底层容器托管不同的应用组件，这些容器必须进行扫描，因为总是有可能某个依赖项会产生新的漏洞。

由容器组成的应用程序由 Dockerfiles 定义。Linting——分析代码中使用的错误或不良语法——可以用于对 Dockerfiles 进行 静态代码分析 (SCA)，并确保这些文件保持安全。一个常用的代码检查工具是 Haskell Dockerfile Linter (Hadolint)，它作为 Docker 镜像提供，可以通过以下命令轻松执行：

docker run --rm -i hadolint/hadolint

Hadolint 会扫描代码，如果一切正常，它将返回退出代码 0。当发现错误或不良实践时，它会呈现 Hadolint 错误 (DL) 或 SellCheck 错误 (SC) 键。

提示

常见错误的概述已汇总在 github.com/hadolint/hadolint#rules。

除了代码检查，Docker 还推荐了一些保持容器安全的最佳实践。Docker 已经处理了命名空间和网络栈，以提供隔离，从而确保容器无法获得对其他容器的特权访问，除非在配置中明确指定。接下来，有一些重要事项需要考虑：

• Docker 使用 Docker 守护进程。这个守护进程需要根权限，这意味着存在安全风险。首先，只有受信任的用户应被允许设置守护进程的控制权限。接下来，你需要采取行动，通过设置对 Docker 主机和客户容器的访问权限，尤其是当容器可以通过 Web 服务器的 API 来配置时，来限制守护进程的攻击面。

• 强烈建议使用 Docker 内容信任签名验证。这是一个从 dockerd 二进制文件开始提供的功能，允许你设置 Docker 引擎仅运行已签名的镜像。对于签名本身，你可以使用 Notary。

• 使用加强版模板来用于 Linux 托管系统，如 AppArmor 和 SELinux。

如果我们遵循 Docker 的所有建议，我们将拥有经过测试的、不可变的镜像，可以用于在 Kubernetes 上部署容器。例如，Kubernetes 将使用可信的镜像仓库，并负责容器的供应、扩展和负载均衡。Kubernetes 的一项安全功能是支持滚动更新：如果镜像仓库更新了补丁或增强功能，Kubernetes 将部署新版本并销毁旧版本。通过这一功能，开发人员可以始终确保只有最新的、经过强化的镜像版本被使用。

应用机密管理

数据库凭证、API 密钥、证书和访问令牌必须始终存储在安全的地方。使用 CI/CD 和容器并不会改变这一点。强烈建议使用一个位于管道访问的 CI/CD 仓库之外的保管库。机密管理的最佳实践如下：

• 静态和传输加密。建议使用 AES-256 加密密钥。

• 机密，如密钥，绝不能存储在 Git/GitHub 仓库中。

• 建议通过将机密作为环境变量注入应用程序中的安全字符串。

Hashicorp（Terraform）提供了 Vault 作为一个开源解决方案，用于安全地访问机密。该服务使我们能够轻松旋转、管理和检索数据库凭证、API 密钥以及其他机密，并贯穿其生命周期。

CyberArk 提供了一个更强大的解决方案。CyberArk Conjur 是一个平台无关的机密管理解决方案，专门设计用于保护容器和微服务。该解决方案是平台无关的，意味着它可以部署到任何云环境或本地系统。

这两个工具与本地环境中的密钥管理集成，例如，Azure 和 AWS，分别使用 Azure Key Vault 和 AWS Secrets Manager。

将 DevSecOps 应用于 AWS、Azure 和 GCP

在前面的部分中，我们讨论了 DevSecOps 原则以及如何构建嵌入安全性的管道。在本节中，我们将探讨如何将 DevSecOps 应用于主要公共云平台的最佳实践，即 AWS、Azure 和Google Cloud Platform（GCP）。

在 AWS CodePipeline 中使用 DevSecOps

在我们开始探索 AWS 中的 DevSecOps 之前，需要理解 AWS 中的部署应该基于云采用框架（CAF）的原则。该框架涵盖了特定的安全任务和责任，分为我们在第十一章《理解 DevOps 中的安全性》讨论的四个类别或原则，即企业安全性：

• 防范

• 检测

• 更正

• 方向

  注意

  AWS 使用不同的术语来表示这些原则，以进行更正和方向。在 CAF 中，这些原则随后被称为侦测和响应。

AWS 提供了本地解决方案来管理 CI/CD 管道中的安全态势：Amazon CloudWatch Alarms、AWS CloudTrail、Amazon CloudWatch Events、AWS Lambda 和 AWS Config。下图展示了使用这些解决方案的 DevSecOps CI/CD 管道：

图 12.3 – 在 AWS 中使用 CodePipeline 和安全组

AWS CodePipeline 用于协调管道中的不同步骤。一个重要的产物是安全组：这些是定义管道中所有开发和部署组件的安全态势的 容器。它包含必须应用于这些组件的模板、保护措施和策略。我们可以在管道中定义三个阶段：

1. 来源或提交：对从 S3 桶中拉取的代码进行静态代码分析。如果发生安全组违规，构建过程将被停止。

2. 测试：在此阶段，使用 CloudFormation 创建一个包含 AWS 中 虚拟私有云（VPC）的堆栈来运行测试。接下来，使用 AWS Lambda 在堆栈中运行代码并验证构建。AWS 称此为堆栈验证：Lambda 函数将根据安全组验证堆栈。如果检测到违规，Lambda 函数会删除堆栈并发送错误消息。这是为了防止堆栈和代码进入下一个阶段。

3. 生产：在成功的堆栈验证后，触发 Lambda 函数使用 CloudFormation 模板准备生产环境。这个 变更集——将测试堆栈转化为生产环境堆栈并使用生产模板——随后会执行。

   提示

   AWS 提供了 CloudFormation 模板和管道的示例，访问地址：github.com/awslabs/automating-governance-sample/tree/master/DevSecOps-Blog-Code。

检查安全组中的项目示例包括验证用户访问权限、S3 桶的访问控制、以及使用 EC2 计算资源创建实例的策略等。CloudWatch 和 CloudTrail 用于监控组件、访问级别及其使用情况，并收集在管道各个步骤执行过程中触发的事件日志。

使用 GitHub 和 Azure 服务与 DevSecOps 一起工作

Microsoft Azure 使用不同的 DevSecOps 方法：它利用 GitHub 的扫描功能和 Azure Kubernetes 服务（AKS）的特性，除了 Azure Pipelines，它集成于 Azure DevOps 和 Azure Security Center 中，用于存储安全态势。下图展示了使用 GitHub 和 Azure 服务的嵌入式安全 CI/CD 管道的高级架构：

图 12.4 – 使用 GitHub 和 Azure 服务的 DevSecOps

上述图中的数字表示步骤的执行顺序。容器一旦推送到 Azure 容器注册表（ACR），就会根据存储在 Azure 策略中的政策进行扫描。接下来，适当的安全密钥将被获取，以验证容器是否能通过 Azure Kubernetes Service（AKS）进行认证。只有在所有检查通过后，代码才会被推送到应用网关。

让我们更详细地看一下这个过程：

1. 来源：该解决方案从 GitHub 中的代码分析开始，包括使用 CodeQL 和 Dependabot 来检测源代码和依赖项中的漏洞。

2. 测试：一旦代码经过验证，它就被打包成 Docker 容器，并通过 Azure Dev Spaces 部署到测试环境中。这一协调工作是通过 Azure Pipelines 完成的。Azure Dev Spaces 将使用 AKS 构建一个隔离的测试环境。这类似于 AWS 中 CloudFormation 构建堆栈的方式。

3. 扫描：容器存储在 ACR 中，在这里它们会根据安全状态进行扫描。为此，Azure 使用 Azure Security Center，它是一个庞大的库，存储了所有已注册环境的安全策略。

4. 生产：扫描后的容器通过 AKS 推送到 Kubernetes 集群。Azure 策略用于验证已配置集群和容器的合规性。

与 AWS 一样，Azure 使用多种不同的解决方案来提供一个端到端的解决方案，这些解决方案将安全规则、策略和状态嵌入整个 CI/CD 流程中。然而，所有这些解决方案都从一个存储并管理这些安全防护和指南的仓库开始：通过 AWS Security Hub 管理的安全组，或者在 Azure 中是 Azure Security Center。

在 Google Cloud 中使用 Anthos 和 JFrog 与 DevSecOps 合作

GCP 提供了一个有趣的最佳实践解决方案，用于通过 Anthos 和 JFrog 实现 DevSecOps 流水线。通过这个方案，它不仅提供了一个云原生流水线，还为混合环境提供了解决方案，能够同时使用 GCP 和本地系统进行开发和部署。

这对企业来说很有意思，因为很多企业不会将其 IT 系统完全迁移到公有云。预计大多数企业将会把越来越多的系统迁移到云端，但一些系统仍会保留在私有堆栈中。针对云端和本地解决方案的 CI/CD 流水线是比较受欢迎的，使用 Kubernetes 时，它们相对容易搭建。

架构如以下图所示：

图 12.5 – 使用 JFrog Artifactory 和 Google Anthos 的高层架构

GCP 提倡使用 JFrog Artifactory 和 JFrog Xray：

• JFrog Artifactory 负责存储在构建应用程序时使用的构件。在本章中，我们看到一个管道通过从源代码库中拉取代码开始。开发人员需要依赖能够全面且安全地存储和排序构件——即代码构建块——的工具，以便将软件交付到管道中并实现自动化。

• JFrog XRay 通过 Artifactory 扫描构件——即代码构建块——以检测已知漏洞和许可证合规性。XRay 倡导通过提前扫描源构件来实现“向左移动”的思维模式。

解决方案如以下图所示：

图 12.6 – 使用 JFrog XRay 的 Google Cloud 中的 DevSecOps

在这个解决方案中，JFrog XRay 是嵌入在管道中的安全解决方案。构建随后使用 GCP 中的 Kubernetes 和 Anthos 推送到生产环境。然而，Anthos 确保在本地云和 Google Kubernetes Engine（GKE）以及本地环境中，部署和管理 Kubernetes 集群的一致性层。这个解决方案不仅在 GCP 上可行，还可以在本地的 VMWare 堆栈以及 AWS 上使用。

部署规划

到目前为止，我们已经讨论了 DevSecOps 管道的参考架构以及 AWS、Azure 和 GCP 的最佳实践。如果我们有了架构，下一步就是规划在企业中部署 DevSecOps 和管道。这是最后一节的主题。

企业需要遵循三个主要步骤来实施 DevSecOps：

1. 评估企业安全性：企业可能已经采纳了安全策略并采取了措施来保护其系统。他们还需要遵守安全标准和框架，因为政府或行业的法规要求。安全专家将进行风险评估并分析可能的威胁。这些专家理解并管理安全控制。这是将安全性融合到 DevOps 实践中的默认起点。强烈建议 DevOps 团队在没有包括开发和部署新代码的安全策略和标准的情况下，不应开始任何项目，即使是试点项目或概念验证。安全性必须从第一天开始就是优先事项。

2. 将安全性嵌入 DevOps：安全政策和标准被集成到开发过程中。DevOps 工作流程与安全指南和防护措施相匹配。这包括漏洞测试和代码扫描，我们在本章中已做了广泛讨论。如果没有相应的流程和工具，DevOps 团队无法开始开发新代码。增加系统攻击面、最终给企业带来巨大损失的风险太大。无论大小企业，都在黑客和安全威胁的持续威胁之下。这就引出了第三步。

3. 培训，培训，再培训：DevOps 和 DevSecOps 不仅仅是技术问题——它是一种工作方式，甚至是一种思维方式。或许更准确地说，它是一种文化，员工需要经过培训来适应这种文化。这种培训不是一次性的。员工、开发人员和运维人员需要不断和一致地接受培训。开发人员、运维人员和安全工程师需要全身心地致力于在工作中应用安全控制，这意味着他们始终需要意识到企业面临的安全漏洞和黑客攻击的风险。

当然，适当的工具至关重要。建议企业至少包括以下工具：

• 测试：这是 DevSecOps 中至关重要的环节。市场上提供了大量用于执行测试的工具。例如 Chef Inspec、Haikiri 和 Infer。

• 警报：当检测到安全威胁时，需要发出警报并进行通知。Elastalert 是一个警报工具的例子。

• 自动化修复：像 StackStorm 这样的工具可以在安全问题被检测到时，立即提供修复措施。

• 可视化：开发人员和运维人员需要能够看到系统中发生了什么。Grafana 和 Kibana 是帮助可视化和共享安全信息的流行工具。

这份清单绝不打算是详尽无遗的。所提到的工具是与 DevOps 工具以及 AWS、Azure 和 Google Cloud 的原生工具兼容的第三方工具。当然，公有云平台本身也提供了广泛的安全工具。例如，Azure 中的 Sentinel 和 Azure Security Center，AWS 中的 Security Hub，GCP 中的 Security Command Center。

阅读完本章后，DevSecOps 的好处应该已经很清晰，但我们将通过总结来概括这一点：通过 DevSecOps，企业能够实现开发人员、运维人员和安全工程师之间的更好协作，从而确保在开发初期就能发现安全威胁和漏洞，最大限度地降低企业风险。

我们将在第十四章《将 DevSecOps 与 DevOps 集成》中详细阐述在 DevOps 中实现安全性，我们也会讨论 DevSecOps 的治理。但首先，我们将在下一章学习如何在 DevOps 中使用和集成行业安全标准。

总结

在本章中，我们学习了 DevSecOps 的不同组成部分。我们了解到，DevSecOps 不仅仅是工具和自动化的问题，它更是关于文化：DevOps 团队必须与企业中的安全专家协作，共同致力于将安全指南融入开发和部署新代码的过程。工具无疑可以帮助在 DevOps 中实现最大程度的安全性。本章的一个重要部分是关于架构 DevSecOps 实践。

然后，我们讨论了主要公共云提供商中 DevSecOps 的最佳实践；即 AWS、Azure 和 Google Cloud。这些实践通常包括使用 Docker 容器和 Kubernetes 作为容器编排平台。我们还学习了如何扫描代码并在将容器部署到生产平台之前确保其安全。重要的活动包括静态代码分析和动态扫描。

在本章的最后部分，我们讨论了企业必须采取的实施 DevSecOps 实践的步骤，并提供了一些关于所需工具的建议。

企业通常必须遵守政府和行业的安全标准和框架。下一章将专门讲解在 DevSecOps 中如何使用这些标准。

问题

1. 软件组成分析（SCA）的功能是什么？

2. 用于保持容器安全的技术是什么？

3. AWS 中用于创建堆栈的本地工具是什么？

4. AWS、Azure 和 GCP 等公共云服务提供商提供了各自的 Kubernetes 服务来运行容器。请列举它们的相关服务。

进一步阅读

• 使用 AWS CodePipeline 实现 DevSecOps 的博客：aws.amazon.com/blogs/devops/implementing-devsecops-using-aws-codepipeline/#:~:text=%20Implementing%20DevSecOps%20Using%20AWS%20CodePipeline%20%201,%206%20Create%20change%20set%3A.%20%20More%20

• 在 Azure 中应用 DevSecOps 实践的文档：azure.microsoft.com/en-us/solutions/devsecops/

• 使用 GCP、Anthos 和 JFrog 实现 DevSecOps CI/CD 的文档：cloud.google.com/architecture/partners/a-hybrid-cloud-native-devsecops-pipeline-with-jfrog-artifactory-and-gke-on-prem#best_practices

• Docker 中的安全性文档：docs.docker.com/engine/security/trust/

第十三章：使用行业安全框架与 DevSecOps 合作

安全性和 DevSecOps 中一个重要的工具是安全框架。存在通用框架，例如互联网安全中心（CIS），但通常行业必须根据特定的行业安全标准遵守并报告合规性。这些框架影响了企业内部安全处理的方式，因此也影响了 DevSecOps 的实施。

本章将解释框架的功能和影响，以及如何将它们融入到 DevSecOps 中。本章包括关于 MITRE ATT&CK 框架使用和价值的单独段落，因为它正变得越来越知名并被广泛接受，成为基础框架。

完成本章后，您将对最常用的安全框架有一个清晰的了解，并知道如何将这些框架的控制措施应用于 DevOps。

在本章中，我们将覆盖以下主要内容：

• 理解行业安全框架

• 使用 MITRE ATT&CK 框架

• 将框架应用于 DevSecOps

• 创建合规报告并指导审计

理解行业安全框架

随着时间的推移，IT 变得越来越复杂，IT 安全也是如此，两者之间存在关联。企业 IT 环境不再是位于公司地下室的数据中心的单一系统。如今，IT 环境由不同的组件组成，并通过互联网连接与外部世界互联。因此，系统默认是可以通过互联网访问的。然而，只有授权用户才能访问这些系统。因此，我们需要一些强有力的防御措施来保护系统免受安全漏洞的侵害。

所需的安全级别因行业而异。首先，金融机构需要确保银行账户无法被入侵，且资金不会被非法转移。医疗机构需要保护患者的个人和健康数据。制造商希望保护其知识产权和专利。最重要的是，安全方面有几个总体原则，即保护数据、身份，以及加强系统防范外部攻击。要跟踪这些几乎是不可能的，这时安全框架就派上了用场：它们为企业实施正确的安全政策提供了指导。

在学习安全框架如何影响 CI/CD 和 DevOps 之前，我们需要理解这些框架的概念。简而言之，框架是一套实施和管理这些政策的政策和文档化指南。政策本身专注于识别风险、减轻风险以及在发现漏洞时减少系统和程序的攻击面。这是一种通用方法，但行业框架会根据行业的具体需求对这种方法进行调整。

通用的 IT 安全框架包括 ISO IEC 27001/ISO 2700212、美国国家标准与技术研究院（NIST）的网络安全框架、互联网安全中心（CIS）和信息与相关技术控制目标（COBIT）。让我们先详细了解这些框架：

• ISO IEC 27001/ISO 2700212/27017：ISO 27001 制定了国际系统安全控制标准，重点关注能检测出会严重影响系统可用性和完整性的威胁的控制。ISO 27002 则设立了额外的标准，用以管理这些控制措施，如用户访问管理和资产清单维护。ISO 27017 专门针对云计算，涉及在平台即服务（PaaS）和软件即服务（SaaS）环境中的共享责任，确保云服务的部署与移除，并监控云服务等。

• NIST：NIST 网络安全框架并未指定具体的控制措施，但它提供了五个功能来增强安全性：识别、保护、检测、响应和恢复。这些功能允许组织设定控制措施以管理数据泄露风险。控制措施包括访问控制、保护数据的措施，以及员工的安全意识。响应要求控制措施描述组织应如何应对威胁和攻击，包括缓解和沟通指南。恢复是最后的手段：组织需要有明确的战略来恢复攻击后的系统和数据。NIST 的五个领域如下图所示：

图 13.1 – NIST 网络安全框架

• CIS：CIS 提供了针对平台、操作系统、数据库和容器的广泛框架，并提供具体的控制措施。一些 CIS 框架嵌入在平台中，如 CIS for Azure 和 AWS。在这些场景中，可以通过 Azure 安全中心和 AWS 安全中心访问 CIS 基准。CIS 基准确保所使用的组件是强化的。与 NIST 相比，主要的区别在于，NIST 侧重于评估风险的指南，而 CIS 提供了大量的安全控制措施和最佳实践。

• COBIT：COBIT 由信息系统审计与控制协会（ISACA）推出，ISACA 是一个国际 IT 安全与审计组织。最初，COBIT 是关于识别和缓解 IT 系统中的技术风险，但随着最近发布的框架——COBIT 5，它还涵盖了与 IT 相关的业务风险。COBIT 的实施和管理较为复杂，因为它涵盖了整个企业，包括所有 IT 管理流程，如事件管理、问题管理、配置管理和变更管理。

这些都是控制框架。所有这些框架可能有涵盖特定行业需求的版本，但通常情况下，行业需要遵守它们自己的标准，并且完全合规。这在行业进行审计时非常重要。在本章的最后一节，我们将更详细地讨论审计问题。

主要的行业框架——实际上，这些是监管认证——包括医疗保健领域的健康保险流通与责任法案（HIPAA），美国政府机构的联邦风险与授权管理计划（FedRAMP），欧盟的通用数据保护条例（GDPR），以及金融机构的支付卡行业数据安全标准（PCI-DSS）。

这些框架都在全球范围内或至少在区域内实施，但也可能有公司需要遵守的特定国家安全法规。例如，纽约金融服务部（NYDFS）的网络安全法规。该框架于 2017 年发布，对美国所有金融机构提出了安全要求。然而，这一框架中的规则与 NIST 一致，并应用了 ISO 27001 标准。然而，NYDFS 确实有一些规则，优先于这些通用框架。在 NYDFS 的规定下，数据加密和增强的多因素身份验证是所有入站连接的强制性安全控制措施。

还有一个框架我们还没有讨论，那就是 MITRE ATT&CK。MITRE ATT&CK 并不是一个真实的框架，比如我们在本节中讨论的那些框架。它是一个知识库，涵盖了系统可能遭受的攻击和突破的策略。然而，它可以作为定义风险策略和威胁模型的输入，来保护系统。在下一节中，我们将学习如何使用 MITRE ATT&CK。

使用 MITRE ATT&CK 框架

也许这不是一个完全公平的说法，但我们会在这里发布它：MITRE ATT&CK 在涉及安全时让您从攻击者的角度思考。该框架的强大之处在于任何人都可以为其做出贡献。它实际上并没有描述系统中的实际漏洞，而是描述攻击者可能利用这些漏洞的技术。MITRE ATT&CK 使用一个包含 14 个攻击策略的矩阵。接下来，它将这些策略分配给主要平台或技术，包括云和容器。在云中，有 Azure、AWS 和 GCP 的细分。

提示

完整的 MITRE ATT&CK 框架可以在 attack.mitre.org/ 找到。但是，建议还关注 MITRE 的 Twitter 帐号 @MITREattack。该矩阵是开源的，因此活跃的社区正在为收集在框架中的策略和技术做出贡献。MITRE 鼓励人们加入社区并积极贡献他们的发现。

在本节中，我们将简要介绍 14 种策略，然后专门讨论容器中的策略，因为这些在持续集成/持续部署（CI/CD）中被广泛使用。

• 侦察：这些技术旨在收集尽可能多的信息以准备攻击。这包括扫描系统，还包括社会工程，即利用组织的员工获取信息。

• 资源开发：这些技术涉及创建、购买或窃取黑客可以用来执行攻击的资源。

• 初始访问：这是首次尝试访问系统。包括滥用有效（服务）账户和钓鱼。

• 执行：这项技术涉及运行恶意代码。

• 持久性：这种技术通过后门获取访问权限。它利用容器注入恶意代码，引导并登录初始化脚本。

• 权限升级：这种技术涉及利用漏洞在系统上提升权限，最终获取更多控制权。在使用容器时，这是一种常用的策略。容器应始终加固，以防止它们获取额外的权限。

• 防御规避：这包括使用代码绕过入侵检测、日志记录和其他预防措施的策略。在云环境中，此策略用于操纵云（编码）防火墙，例如通过未使用的不同区域中的环境或未受保护的沙盒环境进入。

• 凭证访问：通常涉及暴力破解以获取用户名和密码。

• 发现：此策略用于查找用户数据、设备、应用程序、数据和服务，以尽可能多地了解可用系统的信息。

• 横向移动：此战术用于将系统和数据从一个主机移动到另一个主机，有时是移动到一个不在企业控制下的环境中。常用的技术包括散列传递和远程管理员访问。

• 收集：此战术用于收集数据，例如键盘输入或屏幕截图等。在云环境中，收集 API 密钥以访问存储和密钥保管库是常见的技术。

• 命令与控制：使用此技术时，黑客尝试与系统通信，试图获得对系统的控制。

• 数据外泄：此战术涉及通过例如将数据发送到不同的存储环境并加密数据，来控制数据和数据流。

• 影响：这是一个广泛的类别，包括拒绝服务技术和资源劫持。

MITRE ATT&CK 并不是一个魔法棒：它并不能解决所有的安全问题。它应被视为另一种可以帮助你以更好的方式保护 IT 环境的资源，通过提供不同的见解。它展示了潜在的攻击模式和路径，安全工程师可以将其纳入安全策略中。MITRE ATT&CK 提供了来自特定平台和技术的见解，这使得它非常独特。常见的攻击战术在不同平台上可能有不同的路径和模式，而这正是 MITRE ATT&CK 成为一个良好护栏的地方。

注意

在 DevOps 中，扫描代码至关重要。静态和动态扫描必须是 CI/CD 中的默认操作。扫描通常是针对基线进行的。在 DevOps 中常用的基线之一是OWASP，即开放网页应用程序安全项目。OWASP 是开源的，每年列出应用程序中的十大漏洞。我们将在 第十四章 将 DevSecOps 与 DevOps 集成 中更详细地讨论 OWASP。

在接下来的章节中，我们将向你展示如何使用矩阵来更好地保护容器。

使用 MITRE ATT&CK 战术保护容器

那么，MITRE ATT&CK 在实践中是如何工作的呢？我们以容器矩阵为例，因为容器在 CI/CD 流水线中被频繁使用。首先，我们必须访问 attack.mitre.org/matrices/enterprise/containers/ 上的特定矩阵。你将会认识到我们在上一节中讨论的 14 个战术中的一些。并非所有战术都适用；对于容器，有八个战术被证明是相关的：

• 初始访问

• 执行

• 持久性

• 权限提升

• 防御规避

• 凭证访问

• 发现

• 影响

接下来，我们可以看一下这些战术中的一个。我们将以执行为例，如下图所示：

图 13.2 – MITRE ATT&CK 中容器的标签

执行中的前两项如下：

• 容器管理命令

• 部署容器

如果我们点击第一个，容器管理命令，矩阵将为我们提供有关如何在容器管理中利用特定漏洞的信息。漏洞本身可能出现在使用例如 Docker 守护进程或 Kubernetes API 管理容器时。这些可能允许在容器启动时使用远程访问和管理。MITRE 给出了两个已经使用的技术例子。第一个技术是 Hildegard，它使得可以使用 kubelet API 运行命令在运行中的容器上执行命令。MITRE 提到的第二个技术是 Kinsing，它利用 Ubuntu 入口点运行 shell 脚本来接管容器管理进程。

接下来，矩阵提供了缓解措施。在给定的例子中，缓解措施包括使用只读容器并限制通过 SSH 的远程访问来与容器服务、守护进程或 Kubernetes 进行通信。

你会发现 Kinsing 也出现在部署容器标签下，紧挨着 Doki 漏洞，后者是一种在 2020 年春季被发现的恶意软件，专门针对 Docker 容器。

矩阵将引导你了解各种漏洞并帮助你减轻它们。

在这方面，我们已经讨论了各种框架的内容。在接下来的章节中，我们将学习如何在 DevSecOps 中使用这些框架，以及如何创建合规性报告来展示框架的应用。

将框架应用于 DevSecOps

在本节中，我们将学习如何将框架的控制措施融入到 DevOps 中，并将它们嵌入为 DevSecOps。好消息是：这并不像听起来那么困难。下图展示了这个过程：

图 13.3 – 从安全框架到 DevOps 的控制应用过程

通常，我们首先评估企业需要应用到其 IT 环境中的框架。从这个评估中，衍生出不同的控制措施，并将其设置为应用和基础设施的开发和部署周期。一旦代码从仓库拉取，扫描就会针对这些控制措施开始。

我们在这里以 CIS 基准为例，因为 CIS 是最常用的安全控制框架。应用控制始于认识到，在 DevOps 中，IT 环境默认是高度动态的。一切，包括基础设施，都转化为代码，因此应用程序将运行在容器中或无服务器模式下。这需要一些特定的控制措施。

必须应用一些通用控制措施。这些包括以下内容：

• 漏洞管理：这必须作为一个控制措施在代码推送到生产环境之前实现，但考虑到左移原则，漏洞扫描应该从代码从仓库拉取的那一刻就开始。

• 访问控制：通过此控制，你可以限制和管理所有资源的权限，包括容器。

• 日志记录：这包括在构建和测试代码时的日志。有时，在生产环境中只收集日志，但如果你想掌控 DevOps 循环，这样是不足够的。

这些是通用的。CIS 开发了一个专门用于保护容器的框架，如下图所示：

图 13.4 – CIS Docker 基准测试

这个基准测试，CIS 称之为基准，包含以下控制项：

• Linux 主机配置；例如，确保容器使用独立分区，并确保只有可信用户可以控制 Docker 守护进程。

• Docker 守护进程配置；例如，如果可能的话，作为非 root 用户运行守护进程，并确保容器在获取新权限时受到限制。

• 容器镜像和构建文件配置；例如，确保容器只使用可信的基础镜像。

• 容器运行时配置；例如，限制容器中的 Linux 内核功能，并确保容器中不会映射特权端口。

CIS 还有一些通用的建议，比如确保容器经过加固，并确保 Docker 版本是最新的。

提示

所有 CIS 基准测试都可以在 www.cisecurity.org/ 上免费下载。

这个基准不仅告诉你应该实施哪些控制项，还提供了如何实施这些控制项的建议，以及为什么这些控制项必须存在的理由。看一下 CIS 推荐为容器设置独立分区的例子——这是 CIS v1.3.1 (2021) 中的控制项 1.1.1。

这从配置文件适用性开始。在控制项 1.1.1 中，这个设置为 Level 1-Linux 主机。这意味着这些设置仅适用于 Linux 主机，在不妨碍组件预期功能的情况下，提供明确的安全性好处——在这个例子中，是 Linux 主机。

接下来，描述了控制项本身及其背后的理由。在这个例子中，它描述了 Docker 如何使用 /var/lib/docker 作为默认路径来存储所有组件。该目录与 Linux 主机共享，这意味着它可能会很容易被完全填满，导致 Docker 和主机都无法使用。因此，推荐使用独立分区。最后，CIS 提供了一个手动指南，说明如何通过为 /var/lib/docker 挂载点创建独立分区来实现这一点。

是否必须按照这些建议执行？不一定。CIS 明确区分了关键控制和重要控制。显然，关键控制在所有情况下都应当执行，但你需要评估每个控制措施，无论它是否对你的 DevOps 实践有意义。这里的黄金法则是，如果你实施了某个控制，你需要持续遵守它，并进行合规报告。企业将根据他们已实施的规则和政策接受审计。在本章的最后一节中，我们将讨论报告和审计。

创建合规性报告并指导审计

DevOps 在企业中正在迅速发展，将安全嵌入 DevOps 是一个合乎逻辑的下一步。但是，企业如何确保其 DevOps 和 DevSecOps 符合我们在本章讨论的框架呢？这个问题的答案是：通过审计。IT 系统会定期审计，DevOps 实践也应如此。尽管如此，审计 DevOps 仍然是未知领域，尽管像 KPMG 和德勤这样的主要会计公司已就此发布了白皮书。

DevOps 审计应至少涵盖以下主题：

• 评估 DevSecOps 策略：策略是否清晰？治理是如何安排的？可以根据业务单元或全公司范围制定 DevOps 策略。两者都可以，只要策略始终如一地贯彻执行。目标应当清晰，并且被每个团队采纳。同样，所有团队的工作方式也应一致。测试流程和验收标准等流程必须透明并且严格遵守，没有例外。

• 评估 DevSecOps 培训水平：培训不仅仅是做一个幻灯片，展示规模化敏捷框架（SAFe）并说明 DevOps 循环。DevOps 强调的是文化，但有时组织会因突然改变工作方式而感到不知所措。例如，实施 DevOps 还意味着创建具备正确技能的团队。这需要组织安排，并且远不止于在组织中推出Spotify 模型。员工不会仅仅通过告诉他们必须这样做就自动在公会和小组中组织起来。企业需要对员工进行 DevOps 培训，并确保团队拥有所需的技能。培训还包括组织管理。

  注意

  Spotify 模型在组织中已成为一种非常流行的扩展敏捷工作方式的方案，而 DevOps 就是其中的一部分。Spotify 模型以音频流媒体服务实施的敏捷工作方式命名，提倡团队自主性，团队被组织成小组。每个小组可以选择自己的工具集和敏捷框架，如 Scrum 或 Kanban。

• 审查 DevSecOps 工具链：是否有架构来指定 DevOps 工具，并且它是否连贯？它是否服务于战略，并且与企业的 IT 战略一致？例如，如果企业有开源战略，那么工具必须遵循这一战略。最后，就像任何在企业中使用的工具一样，它需要受到架构变更控制。

• 审查 DevSecOps 流程：DevOps 并不意味着流程不再有效。企业仍然需要有基本的 IT 流程，如事件管理、问题管理和变更管理。这些流程必须有文档记录，包括它们的升级流程。同时，必须清晰地描述这些流程中的角色，并在实施 DevSecOps 时遵循这些描述。安全管理在这里占据特殊位置，因为它必须描述安全政策是如何定义的，如何在企业中实施和管理的，以及如何在 DevOps 流程中嵌入安全措施。

这样，我们已经学习了 DevOps 中安全的基本原则以及行业安全框架。现在，我们需要将安全整合，或者更确切地说，融入到我们的 DevOps 实践中。这就是 第十四章的主题，将 DevSecOps 与 DevOps 整合。

总结

在本章中，我们讨论了各种安全框架。这些框架是为企业的 IT 环境设置安全控制的指南。这些控制适用于系统和应用程序，也适用于 DevOps 实践。从开发人员从代码库拉取代码并开始构建，到部署和生产，IT 环境，包括 CI/CD 管道，都需要遵循安全控制。框架种类繁多，其中一些被企业广泛接受，如 NIST、CIS 和 COBIT。

我们还讨论了 MITRE ATT&CK 框架，它通过与其他安全控制框架进行对比，采用了不同的角度。MITRE ATT&CK 列出了黑客可能使用或曾经使用过的战术和技术，来利用漏洞。就像 CIS 一样，MITRE ATT&CK 列出了适用于不同平台和技术的具体内容，包括 CI/CD 中常用的容器。

在最后一节中，我们讨论了 DevSecOps 的审计。建议复审诸如工具的持续使用、流程和 DevOps 团队的技能等话题。

在下一章中，我们将把安全实践融入 DevOps，并学习企业如何采纳真正的 DevSecOps 战略。

问题

1. 哪项 ISO 标准专门针对云？

2. MITRE ATT&CK 在执行战术下提到的两种容器技术是什么？

3. 判断对错：CIS 没有提到 Docker 的版本控制作为一种控制措施。

进一步阅读

• KPMG，2020 年 1 月：advisory.kpmg.us/articles/2020/role-of-internal-audit-devops.html

• 发现 Spotify 模型，这是 Mark Cruth 在 Atlassian 上的一篇博客文章：www.atlassian.com/agile/agile-at-scale/spotify#:~:text=It%20is%20now%20known%20as%20the%20Spotify%20model.,by%20focusing%20on%20autonomy%2C%20communication%2C%20accountability%2C%20and%20quality

• CIS 网站：www.cisecurity.org/

• ISACA 网站，您可以在这里找到 COBIT 5 框架：www.isaca.org/

• NIST 网站：www.nist.gov/

• ISO 网站：www.iso.org/standards.html

第十四章：将 DevSecOps 与 DevOps 集成

本章标题可能听起来有点奇怪，但 DevSecOps 和 DevOps 并不是分开的东西。它应该是一种工作方式：安全性应与 DevOps 实践集成，而不是将安全原则加到 DevOps 之上。这意味着架构师必须定义一个总体的治理模型，将威胁建模集成到 DevOps 中，并实现一个集成的工具集。最后，集成监控需要覆盖 DevSecOps 周期的每个方面。我们将学习到，集成监控接近我们在本书早些时候讨论的内容：AIOps。在本章中，我们将把一切整合在一起。

完成本章后，您将学会如何实现治理，理解威胁建模，并理解它在安全软件开发生命周期（SDLC）中的重要性。您还将学会如何将安全性嵌入到持续集成中，并如何监控这一过程，以及该领域的一些主要工具。

本章中，我们将涵盖以下主要主题：

• 定义 DevSecOps 中的治理

• 理解并使用威胁建模

• 集成工具和自动化

• 实现监控

定义 DevSecOps 中的治理

到目前为止，我们已经草拟了一个 DevSecOps 架构，确定了流程，并将其与企业的业务目标对齐。下一步是管理这一切，这就是治理的主题。DevSecOps 不仅仅是一个 PowerPoint 演示文稿和一个显示 CI/CD 管道的 Visio 图表。企业需要有技能的员工来使用它，并且需要一个治理模型来描述安全的数字化运营模式。在本节中，我们将通过使用 The Open Group 的 IT4IT 框架作为最佳实践来讨论这一点。

在第六章《架构中的定义操作》中，我们介绍了产品的价值流，并描述了 IT 如何创造价值。该模型可在下图中看到：

图 14.1 – IT4IT 价值流

在 IT4IT 中，治理、风险和合规性（GRC）是四个价值流的支持活动。这意味着 GRC 完全嵌入到每个价值流中。GRC 做什么呢？

简单来说，GRC 是通过应用已达成一致的行业商业政策来管理不确定性，从而实现目标。每个企业都需要遵守一定的政策。这些政策可以是国际贸易规定、国家法律，也可以是行业特定的标准。包括安全性和数据隐私规定。实施 GRC 并不是一次性的努力：企业需要定期调整。这就是 GRC 能力模型的作用。该模型如下图所示：

图 14.2 – 治理、风险和合规模型

该模型由四个元素组成：

• 学习：企业的目标必须清晰定义，但这些目标是在企业运营的背景下设定的。例如，医院的目标是让人们变得更健康；而其背景则更为广泛，包括与制药公司和健康保险公司等的关系。目标和背景共同定义了公司的战略。

• 对齐：评估企业的目标和可能威胁，分析这些威胁对企业战略的危害。这将导致需求和对策，以确保企业实现目标，抓住新机遇的同时减轻威胁。

• 执行：这是检测到不期望事件并采取行动的阶段。

• 回顾：企业需要不断回顾是否及时识别了威胁，是否进行了适当评级，并且缓解措施是否成功。这反馈到学习中，因为背景可能会发生变化，战略也需要进行调整。

实施和管理这些能力需要治理。企业必须为这些能力的控制分配人员，并在企业不同级别上确定这些能力的采纳程度。这包括将 GRC 能力集成到 DevSecOps 中。我们如何安排最佳实践治理模型？

我们需要查看企业中的不同级别，这正是 IT4IT 所做的。下图展示了该模型的高层原则：

图 14.3 – 企业中不同安全治理级别的模型

让我们更详细地看看这些级别：

• 企业级：在企业级别，关键角色是企业架构师，负责企业架构。在这个层级，企业架构师将与首席信息官（CIO）合作。在现代企业中，我们看到 CIO 的角色在变化，并且有其他角色逐渐加入。首席数字官（CDO）和首席数据官或首席隐私官在组织架构中越来越常见。CDO 是实施数字化转型战略的重要职位，包括采用 DevSecOps。需要注意的是，DevSecOps 本身从来不是战略目标：它是一种引导数字化转型的方法论。

• 价值流：企业级是战略层；价值流则是战术层。在这一层级，关键角色是领域架构师和 SecOps 工程师。他们需要监督在各个 DevOps 团队中实施的全局 DevOps 架构和安全措施。

• DevOps 团队：DevOps 中的黄金法则是你构建它，你运行它，你破坏它，你修复它。这并不意味着 DevOps 中没有其他规则——或者更确切地说，是指导方针。企业寻求在 DevOps 中跨不同团队保持一致性。这些团队将独立运作，但仍需要遵循企业层面设定的集中化指导方针，并在价值流层面加以实施和管理。为什么这很重要？企业服务或产品可能由不同 DevOps 团队负责的构建模块组成。如果工作方式、指导方针和安全防护没有对齐，最终产品或服务很可能无法达到企业的质量标准。

• @robakershoek)，他为 IT4IT 框架做出了广泛贡献。他的其中一本书列在进一步阅读部分。

本节内容是关于 DevSecOps 中治理和控制流程的。在下一节中，我们将讨论安全团队和专家如何识别可能影响代码开发和部署的事件。深入理解并掌握如何使用威胁建模是必需的。

理解和使用威胁建模

在上一节中，我们讨论了企业安全治理以及它如何作为 DevSecOps 的一部分进行集成。在本节中，我们将学习安全问题如何影响软件开发生命周期（SDLC）。当涉及到在 DevOps 中集成安全性时，你需要对威胁建模有充分的理解，威胁建模为我们提供了关于安全威胁如何影响软件代码开发和部署的信息。我们将通过解释开放 Web 应用程序安全项目（OWASP）的定义来开始了解什么是威胁建模。OWASP 是一个提供安全威胁、工具和技术见解的在线社区。

本质上，威胁模型展示了安全威胁如何影响应用程序的完整性。该模型汇集并分析安全数据，帮助做出如何保护应用程序的决策，从而通过评估需求、重新审视设计并实施改进的安全政策来提升代码和托管环境的安全性。

什么是威胁？任何负面影响应用程序并导致失败或不希望事件的东西，如数据泄露。威胁建模识别可能的漏洞，然后定义缓解措施。在识别阶段，它可以使用我们在上一章中讨论过的 MITRE ATT&CK 框架。威胁建模不仅仅是检测安全问题，甚至不只是防止或修复它们。

建模是一项结构化、计划性强且重复进行的活动，用于持续评估环境和可能的漏洞，并帮助实施结构化的方法来减轻这些漏洞。因此，威胁建模需要贯穿整个 SDL（软件开发生命周期），其中模型以及由模型触发的后续行动需要不断审查和完善。原因在于，在开发过程中，可能会增加新的功能，甚至是新的技术。这样就有可能引入新的漏洞——威胁——因此，模型需要不断修订。

威胁建模通常包括以下步骤：

1. 范围分析：我们的威胁模型和分析的范围是什么？可以考虑应用代码、编程语言（例如 C#、Python 或 Java）、API、虚拟机、平台（比如 AWS 或 Azure 等云平台）、数据库引擎（例如 SQL、Postgres 或 Cassandra）和数据库。

2. 识别威胁代理：在 MITRE ATT&CK 框架中，我们关注的是漏洞和这些漏洞被利用的技术。在威胁建模中，我们还需要识别可能对攻击感兴趣的人。OWASP 称这些人为威胁代理：这些代理既可以是内部的，也可以是外部的。做出这一明确区分的原因是为了识别环境是否对内部人员具有容错性，或者是否容易从外部突破。

3. 评估缓解措施：OWASP 称之为对策。已知的缓解措施——例如，能够注册补丁——必须包含在模型中。

4. 评估漏洞：如果你已经知道了范围、可能的攻击者，并识别了可能的对策，那么我们就可以开始分析漏洞。这些漏洞是否在范围内，可能被谁利用，以及可以采取哪些具体的缓解措施来防止或最小化影响？

5. 优先考虑风险：分析漏洞被利用的可能性以及实际损害的程度。这定义了威胁的优先级。

6. 执行缓解措施：根据优先级，必须采取缓解行动，以降低已识别的风险。

   提示

   OWASP 社区管理着自己的 GitHub 页面，专门用于威胁建模。这些页面可以在github.com/OWASP/www-community/blob/master/pages/Threat_Modeling.md找到。

还有更多定义威胁建模的模型，但从本质上讲，它们都归结为相同的原则：评估、识别威胁、评估威胁，并识别减少风险的行动。

我们已经在治理下管理安全，并且知道如何评估我们环境中的可能威胁。下一步是将这一过程自动化，并集成到 DevOps 工具中。如果我们完成了这一点，那么我们就可以说我们已经实现了 DevSecOps。

集成工具和自动化

在本书中，我们已经多次讨论了测试的重要性。DevOps 提倡在生命周期的每个阶段进行测试，从开发到部署。这也包括安全测试。但是我们如何实现这种持续集成呢？目标是在开发人员提交代码时运行测试，在拉取代码时运行测试，在构建过程中运行测试，并在实际部署时（包括预发布阶段）进行测试。

首先，我们来看一下持续集成（CI）。开发人员会频繁地提交代码；在某些情况下，每天的提交次数可能达到多个。这就是 CI 的目标，以及 DevOps 中的敏捷工作方式：开发人员不再处理庞大的程序；相反，他们应用小规模的代码构建，每次添加一个功能。通过这种方式，更容易跟踪代码的变化，重要的是，如果添加的功能导致失败，能够轻松回滚。

CI 的核心是将这些变化和新增内容整合到代码中。开发人员提交代码，修改代码，并将其发布到功能分支。然后，代码被推送到生产环境并返回到仓库，源代码在极短的时间内更新了这一小块新代码。由于这些只是小规模的代码迭代，整合代码并在生产环境中实施要比处理大型发布更容易。然而，前提是代码在整个过程中都必须经过测试。每个新的构建和每个修改都必须进行测试。

在 DevOps 管道中，我们以自动化方式运行这些测试。这需要集成工具来打包代码，运行脚本以启动适当的基础设施，应用安全策略，启动监控并执行测试。

总之，测试贯穿整个开发和部署周期。下图展示了我们所说的内容，同时应用了 Shift Left 的原则：

图 14.4 – 在安全测试中应用 Shift Left

这包括安全测试。毕竟，目标是将其与 DevOps 工具集成，并自动化 CI/CD 管道。我们在以下实例中运行安全测试：

• 代码仓库：提交和拉取源代码

• 构建：编写、修改和编译代码

• 发布前或预发布：在实际部署到生产环境和主分支之前进行类似生产环境的测试

在第十二章《为 DevSecOps 架构》中，我们讨论了可以应用于管道的各种扫描类型，如静态应用安全测试（SAST）和动态应用安全测试（DAST）。

所有这些测试都可以并且应该自动化。对于许多企业来说，这是一次真正的范式转变。许多安全工程师和经理会坚持手动测试，而不是自动化安全测试。问题在于，安全测试将成为 DevOps 的瓶颈：部署会被安全测试停止，或者至少会被安全测试减慢。这就是为什么我们要将安全测试集成并自动化到我们的管道中，并在整个 SDLC 的每个阶段进行。

接下来，通过自动化和完全集成的安全测试，我们确保开发人员能即时收到关于代码中漏洞的反馈，这将有效地改进代码。

集成静态应用程序安全测试

SAST 至关重要。我们在第十二章《为 DevSecOps 设计架构》中简要讨论了这一点，现在我们将深入探讨。

首先，我们需要理解 SAST 有两种类型：

• 扫描原始源代码的 SAST 工具。

• 扫描库中反编译源代码的 SAST 工具，如动态链接库(DLL)或Java 归档(JAR)。

SAST 工具逐行扫描代码，报告在代码中发现的潜在漏洞，以便开发人员确切知道需要查看的位置。大多数工具还会对漏洞进行评级，甚至提供修复问题的建议。需要注意的是，SAST 工具需要具备语言感知能力。它们扫描源代码，因此必须理解代码所使用的语言。如果使用了多种语言，则可能需要多个 SAST 工具。

SAST 工具集成到 CI/CD 管道中，以便在整个开发过程中进行扫描。大多数工具识别常见的安全问题，这些问题通常会被报告并列出，比如 OWASP 提到的问题。每年，OWASP 都会发布十大 web 应用程序安全风险。目前，前十名的风险包括代码注入、敏感数据暴露和监控不足等。

提示

OWASP 前十可以在owasp.org/www-project-top-ten/找到。

我们将在本章的最后部分回到监控内容。

集成动态应用程序安全测试

DAST 不扫描代码。简而言之，DAST 工具模拟攻击。在第十三章《使用行业安全框架与 DevSecOps 协作》中，我们讨论了 MITRE ATT&CK 框架，它列出了有助于利用漏洞的技术。DAST 工具通过注入恶意代码字符串或暴力破解来执行这些技术。通过这样做，DAST 试图识别应用程序功能中的漏洞，而不是源代码中的漏洞。

DAST 是复杂的，这意味着它成本较高。它通过应用程序运行事务，并且依赖与应用程序交互的组件。例如，可以考虑前端应用程序和后端数据库。DAST 工具需要良好配置才能有效运行。

在这一点上，DAST 与渗透测试非常相似。大多数安全官员和工程师会依赖手动渗透测试来检测不同应用堆栈和服务之间的漏洞，特别是当这些堆栈和服务由不同的平台和提供商使用时。在现代 IT 中，系统通常由基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）组成，托管在 AWS、Azure 或私有数据中心等各种平台上，集成和测试集成点变得越来越重要。

请注意，公共云平台对于渗透测试有严格的政策。例如，AWS 仅支持对少数几个服务进行渗透测试，如其计算平台 EC2。违反这些政策可能会导致处罚，最坏情况下甚至禁止使用服务。

使用 CircleCI orbs 进行集成

在 DevSecOps 集成的世界中，有一个相对较新的现象值得一提，那就是 orbs —— 可重用的 YAML 代码片段，用于处理可重复的操作，如安全扫描。Orbs 允许直接与流行的安全扫描工具进行集成。这是 CircleCI 提出的概念，CircleCI 是一家位于旧金山的公司，提供自动化 CI 工具。

它声称可以将这些工具直接集成到 CI/CD 管道中。例如，Probely（一个网页漏洞扫描器）和 SonarCloud（代码分析）的 orbs 可用，但开发人员也可以创建自己的 orbs 并将其推送到开源 Orb 注册表中。

现在我们已经涵盖了集成的安全框架和工具，我们必须确保跟踪结果。在最后一节中，我们将更详细地讨论监控。

实施监控

安全的关键要素之一是确保必要的安全策略已到位，并且环境得到了有效保护。听起来简单，但实际上需要正确配置监控。开发人员需要信息来帮助他们修复错误，同时也要改进代码，从而改进应用程序。这不仅适用于客户体验和性能，也适用于确保应用程序保持安全。黑客并非坐以待毙：他们不断寻找新的攻击系统的方法。因此，我们需要持续监控应用程序的运行情况。

安全监控不仅仅是检测意外行为，还包括分析所有行为。这为开发人员提供了洞察，帮助他们改进代码。为了做到这一点，监控需要提供三项主要服务：

• 收集

• 分析

• 警报

有时，存储和可视化也会被加入到这些服务中。然而，存储监控数据更侧重于日志记录，而可视化则侧重于全面呈现监控数据。这些是重要的服务，但它们并不是监控本身的核心服务。当然，你仍然需要方法来接收和查看警报。例如，Grafana 是一个流行的工具，它提供跨平台的仪表盘，允许我们查询和可视化存储的监控数据。

在我们开始实施监控之前，架构师需要评估以下四个 W 问题：

• 我们在监控什么？

• 我们为什么监控这个（而不是其他任何东西）？

• 我们何时监控这个？

• 谁在关注（谁需要被通知）？

什么是收集数据，为什么是触发分析，谁是指向企业中正确的人员或实体发送警报。正如我们之前提到的，正确的监控对于我们在 DevOps 中所进行的反馈循环至关重要，包括关于可能影响系统的安全事件的警报。一个常见的误解是，只有代码的系统并且托管在云平台上的系统默认就会被监控和保护。其实并非如此。像 AWS、Azure 和 Google Cloud 这样的平台仅仅提供了巨大的工具箱，供你用来保护在这些平台上运行的代码。工程师需要自己配置监控。这包括监控基础设施，如云中使用的虚拟机（VMs）的健康状态。虚拟机的使用量增加——虚拟机的 CPU 或内存出现无法解释的峰值——可能表明出现了问题。

接下来，为了对 DevOps 有用，监控必须从应用程序本身收集指标。通过这种方式，监控可以提供应用程序运行状态的信息。应用程序必须能够向监控系统提供这些信息。这些信息通常在应用程序的代码中标记。例子包括诸如调试和警告之类的标签。监控将收集这些信息，并确保以易于理解的格式将其传递给工程师。

监控工具是如何做到这一点的呢？有几种方式可以做到这一点，但在大多数情况下，工具使用的是收集系统数据的代理，或者通过模拟——无代理——交易来实现。通过交易，工具会向应用程序发送一个交易，并在交易返回时分析响应。

注意

基于事务的监控并不意味着这些工具不能或不会使用代理。有代理和无代理的系统。一些企业有政策规定，禁止在其系统上使用代理，因为代理会增加系统的负载，或者因为企业担心代理的侵入性。

在监控代理的情况下，这些代理可以并且应该成为应用程序部署到平台时期望的状态配置的一部分。记住“左移”原则：这应当集成到整个 DevOps 链条中，以便监控从代码推送到开发、测试和预发布系统的那一刻就开始。换句话说，监控不仅仅是为了生产环境。

由于监控工具必须具备的能力，这些工具可能会变得非常庞大和复杂。代理可能会导致所谓的系统开销，即代理会增加系统资源的使用或触发更多的网络流量。这些方面应该在架构设计时加以考虑。同样，先从四个 W 问题开始。

最后，企业可能不会只使用一个监控工具，而是会形成一条工具链。他们可能使用 AWS CloudWatch 或 Azure Monitor 来监控云资源，使用 Prometheus 来收集如容器平台等高动态系统中的实时数据，使用 Sysdig 来监控云原生应用程序。具体到安全监控，企业可以使用 Splunk Security Essentials 或云原生的 Azure Sentinel。需要注意的是，许多安全工具侧重于网络和身份访问管理，而不太关注应用程序或应用代码。这就是为什么企业最终会拥有监控工具链的原因：这是有充分理由的。架构师在选择满足企业需求的工具方面有很大发言权。

注意

我们这里只提到几款工具，这绝不意味着要详尽列出所有工具，或推广特定工具。这里提到的工具在企业中广泛使用，但还有许多其他优秀的工具可供选择。

工程师们可能不希望使用多个控制台来查看这些不同工具的输出。像 ServiceNow 和 BMC Helix 这样的企业级套件提供了经纪平台，能够实现统一的“玻璃面板”视图：各种监控工具和数据收集过程可以在这个统一的套件中聚合。这些是复杂的系统，需要高技能的专业人员来实施和配置，但在 IT 日益复杂的今天，这笔投资是值得的。关于 DevOps 团队，记住他们对开发、部署和运营自己的代码负有完全责任。你可能不希望依赖这些“整体管理”类型的系统，但在拥有各种产品和服务的企业中，拥有所有资产、开发和部署状态的全面概览是至关重要的。

那么，我们已经遵守了安全框架，定义了政策，并将工具整合到我们的 DevOps 和 CI/CD 循环中，但我们真的可以开始了吗？IT 正在迅速变化，每天都变得更加具有挑战性。攻击和安全漏洞每天都在新闻中出现。这对我们如何保护系统产生了巨大影响。我们再也不能信任我们企业网络中的任何人了。另一方面，我们希望尽可能给开发人员更多的自由，以便在编码方面获得最佳结果。毕竟，DevOps 的第一条原则就是关于信任的：你构建，你运行——因为你可以。但是我们该如何处理信任问题呢？这正是本书的最后主题：零信任架构及其对 DevOps 的影响。

总结

DevOps 和 DevSecOps 不是分开的东西：安全必须完全与 DevOps 集成。在这一章中，我们讨论了如何在 DevOps 中集成安全性，不仅关注扫描工具，更主要的是治理、应用威胁建模并监控我们的 DevOps 环境。对于治理，我们研究了 GRC 原则，它允许企业管理不确定性——例如安全风险——同时定义实现业务目标的策略。这是将安全性整合到企业各个层面，并由此推动产品和服务发展的基础步骤。

为了检测、识别和伪造攻击，我们需要使用威胁建模。在本章中，我们讨论了 OWASP，它提供了有关安全事件如何影响业务的见解。接下来，我们将更详细地探讨安全扫描。SAST 和 DAST 是 DevSecOps 中的必需品。

在上一部分，我们了解了架构师在实施监控时需要采取的各个步骤。他们需要问自己四个基本问题：我们在监控什么？为什么要监控这些？什么时候监控？谁需要被通知？我们还查看了监控工具的特性。

安全就是信任，在现代 IT 中，随着攻击数量和种类的增加，基本规则是企业不能再信任任何人或任何事物。这导致了架构中的一个特定领域：零信任。这是本书最后一章的主题。

问题

1. 判断题：在 OWASP 中，威胁代理可以是内部和外部的。

2. 请列出两种 SAST 工具类型。

3. 监控的三个主要功能是什么？

进一步阅读

• IT4IT 管理 IT 业务，Rob Akershoek 等著，《The Open Group》。

• Mike Vizard 在 DevOps.com 上发布的关于私有 orb 引入的博客文章，2021 年：devops.com/circleci-adds-private-orbs-to-devops-toolchain/#:~:text=Constructing%20an%20orb%20gives%20DevOps%20teams%20a%20relatively,of%20the%20DevOps%20team%20can%20more%20easily%20consume。

• Adrian Lane 于 2019 年在 ITSecuroty.org 发表的文章，深入探讨安全测试与集成：itsecurity.org/enterprise-devsecops-security-test-integration-and-tooling/。

• 关于 DevOps 中流行安全工具的概述：dzone.com/articles/an-overview-of-security-testing-tools-in-devops。

• DevOps 中的实战安全，作者：Tony Hsiang-Chih Hsu，Packt 出版社，2018 年。

第十五章：实现零信任架构

数字化转型是企业的新范式。企业正在采用数据驱动的架构，并在云中使用越来越多的原生服务，通过这种方式加速其产品和服务的发展。在这种压力下，安全必须跟上，并确保环境，很多时候甚至是关键任务环境，保持弹性。这就是零信任的领域。

本章解释了零信任是什么，以及它对 DevOps 的重要性。零信任假设企业网络内部的所有事物都是安全的，这也包括 DevOps 流水线。在零信任环境中使用的一些技术是服务网格和微服务，这个话题我们将在本章最后部分讨论。

完成本章后，你将了解零信任的含义以及它对 DevOps 的影响。你将了解到微服务和安全的服务网格如何推动安全的数字化转型。在最后部分，我们将简要讨论云平台提供的一些解决方案。

在本章中，我们将涵盖以下主要内容：

• 理解零信任原则

• 为零信任安全架构设计

• 包括架构中的微服务

• 在流水线中集成零信任

理解零信任原则

零信任确实意味着零信任，首先。零信任的原则在过去几年里在 IT 安全领域获得了广泛关注，这是有充分理由的。攻击不仅来自外部，还可能来自企业内部网络。零信任提倡无论用户是处于企业网络内外，所有用户或每个身份都必须进行身份验证。通过身份验证后，用户必须根据安全策略进行验证，并在授权后才能访问应用程序。数据访问应仅通过经过验证的应用程序进行，且用户必须在应用程序中经过身份验证并授权。

在我们学习零信任如何在 DevSecOps 中运作，尤其是在持续集成/持续部署（CI/CD）流水线中运作之前，我们需要更深入地了解零信任的原则。

零信任始于了解谁在企业的网络中。这一点有一个重要的事项需要注意：在云环境中，一切都是身份。它可以是一个真实的用户，一个人，但也可以是被触发来执行特定操作的服务。同时，服务有一定的权限：它们被允许执行特定的操作或获取定义的数据集，并且禁止执行其他操作。因此，所有身份，或者更准确地说，所有账户，必须被识别，并且更重要的是，必须清楚它们拥有哪些权限。这意味着企业必须不断监控并验证所有账户及其凭证和权限。这必须实时进行。

现在，你可能认为零信任主要是监控帐户。但实际上，零信任还意味着企业已采取措施，防止经过认证的用户做超出授权的事情。你可能会想到为帐户设置最小权限，但你还需要考虑网络分段和限制网络上的特定协议。基本上，你需要考虑所有包含帐户的内容，以确保其只能在授权的地方执行被授权的任务。这必须通过强有力的身份和访问管理（IAM）政策、网络分段、外部和内部防火墙、网关以及严格的路由政策（如拒绝所有和仅允许白名单地址）来强制执行。

零信任中必须包含的原则如下：

• 帐户类型和凭据始终基于最小权限原则。

• 指定的特权权限及其应用规则。

• 为服务和应用程序定义的端点。

• 认证协议。

• 安全监控包括入侵检测、入侵防御和异常检测。

• 使用最新版本和最新补丁的操作系统加固。

• 使用最新版本和最新补丁的软件生命周期。

这如何影响 DevOps？这个问题的答案是：零信任对 DevOps 和敏捷工作方式有着巨大影响。DevOps 的核心是加速应用代码的开发和部署。这需要灵活性，并且要求 DevOps 团队承担极大的责任。虽然严格的安全规则确实会妨碍开发和部署的速度，但保护企业资产没有其他方法。DevOps 团队同样有责任保护这些资产。

其结果是，DevOps 团队也必须遵守零信任原则。团队只能使用被允许访问代码仓库的帐户，使用在云中企业网络特定区域内的构建，使用经过批准的操作系统、软件和工具，并应用通过路由和防火墙规则强制执行的安全政策。

然而，零信任并不意味着 DevOps 过程默认会变慢。只有在将零信任的责任放在团队之外时，才会发生这种情况。例如：团队已准备好部署代码，但现在必须等待特定的防火墙端口被打开。如果该端口已经被列入白名单，并且自动化安全扫描已验证代码符合防火墙规则，则可以迅速完成。如果批准过程必须通过一个安全部门手动验证所有内容，那么这一过程就会显著变慢。

因此，我们需要将零信任纳入 DevOps 流程。我们将在接下来的章节中讨论这个问题。

零信任安全架构

在充分理解零信任概念的基础上，我们可以定义应用零信任原则的架构。以下准则将帮助定义该架构。部分原则可能显而易见，其他原则可能会导致开发人员在开发和部署应用程序时的某些限制。但最终，我们需要确保企业资产的安全：

• 评估和分析所有访问控制。必须制定严格的身份和访问管理（IAM）策略。最小权限原则必须是这些策略的一部分。这是根据国家标准与技术研究院（NIST）的定义，零信任的核心。他们为零信任架构定义了一组原则，所有这些原则都涉及企业如何处理 IAM。关键原则是拥有一个单一的身份源。在大多数情况下，企业将使用Active Directory（AD）来实现这一点。简而言之，任何用户或身份必须被AD 所知。

• 接下来，必须进行强身份验证。身份是否确实如其所声称的那样？多因素认证（MFA）是强烈推荐的。NIST（美国国家标准与技术研究院）还强调了验证和验证用户授权和身份验证上下文的必要性。例如：是从哪台机器访问的仓库？该设备是否符合企业的标准？许多开发人员都有自己的机器，并使用自己偏好的工具。这必须经过评估，以明确这是否符合安全策略。

• 必须定义和控制特定应用程序的访问策略。一个在营销网站上工作的开发人员可能不需要访问控制企业供应链的应用程序。在这种情况下，应限制对该应用程序的访问。因此，零信任意味着每个应用程序都有自己的策略：谁有资格访问，访问到何种级别，以及在该应用程序中的权限是什么？

• 数据分类和数据安全是零信任架构的下一个关键组成部分。数据必须受到保护。现代基于云的 IT 面临的挑战是，数据可能存在于任何地方，并且跨平台、跨应用程序和跨服务共享。企业需要清楚地知道他们的数据在哪里，数据的类型是什么，谁或什么被允许在严格的条件下访问这些数据。数据必须被识别和分类：例如，它是机密的，还是可以公开访问的？严格的隐私法规，例如欧盟的通用数据保护条例（GDPR），是数据分类的指南；应用这些指南是企业的责任。

• 美国国家标准与技术研究院（NIST）和国家网络安全卓越中心（NCCoE）也将受信云定义为一个构建模块。这是因为云本身具有动态特性。现在我们真正进入了 DevOps 的核心，在这里我们遵循自主工作团队的规则，团队可以在需要时即时创建环境，修改它们，甚至删除它们。这些环境将使用数据，但其中一些环境可能只是短暂的，而其他的最终将推向生产环境。云技术，通过一切代码化，促进了这一点。这对安全性是一个巨大的挑战，特别是在保持环境与安全策略一致方面。因此，安全必须融入 DevOps 中。监控应该是实时的，并能够启用控制措施，以识别任何安全策略的违规行为，即使这意味着开发会因此暂停。

总结来说，我们可以说零信任主要是关于尽可能地将网络分段、应用、数据和服务分开，并且只允许经过身份验证和授权的用户，以最小权限访问这些不同的组件。微服务将帮助架构师实现这一点。然而，微服务也带来了一些挑战。这些挑战可以通过服务网格来克服。

在架构中加入微服务

DevOps 旨在通过更快速的代码发布来提高生产力。DevOps 团队可以专注于特定任务和只执行该任务的代码。他们独立于其他服务开发代码，以提高关注度、交付速度和客户体验。安全原则应用于这些服务，并通过自动扫描手段不断验证。DevOps 默认是分布式架构，与单体架构形成对比，后者是将系统设计和构建为一个整体。在 DevOps 中，架构将由微服务驱动：一个应用程序被定义为由独立服务组成的集合，这些服务通过指定的协议相互通信。下图展示了微服务的原理：

图 15.1 – 微服务原理

在安全性方面，我们可以假设微服务架构比单体系统更安全。如果某个服务被突破，并不意味着整个应用堆栈都会被突破，只要受影响的服务得到了足够的隔离。不幸的是，事情并不像想象的那么简单。原因在于微服务确实需要能够相互通信。下一个问题是：我们如何以安全的方式实现这一点？答案是服务网格。

首先，让我们来看看微服务架构的最佳实践：

• 防御策略：微服务允许多种防御层或安全层。例如，一个 web 门户需要公开访问，但应用程序和数据应该得到保护。一个很好的例子是移动银行应用。该应用可以在任何智能手机上访问：用户可以从应用商店下载并安装它。要访问检索和呈现账户信息的应用程序，用户需要具备几件事：一个特定银行的账户，以及一个允许他们使用移动应用的账户。这是两个不同的事情。显然，账户数据也会受到保护，例如通过加密。

• DevSecOps：正如我们在前几章中看到的，这一切都是将安全实践嵌入到 DevOps 中。在整个构建过程中，代码会自动扫描，遵循政策和行业安全合规框架。但这不仅仅是在构建过程中；在部署后，应用程序和代码应该持续监控以发现漏洞。

• MFA：每个应用程序都应仅通过多因素认证（MFA）进行访问。仅使用用户名和密码显然不足够；认证应通过第二因素进行，例如，使用与登录设备不同的设备上的认证应用进行认证。即使已经使用 MFA 访问应用程序，当访问特定的高度机密数据时，可能仍然需要重新认证。仅访问应用程序并不意味着用户默认可以访问该应用程序能够检索到的所有数据。应用程序和数据是分开的层次或级别。

• 依赖性：在云环境中，我们可能会使用云服务，例如平台即服务（PaaS）和软件即服务（SaaS）。我们需要应用程序编程接口（API）来实现这些服务之间的互动。这些是依赖项，如果没有经过验证和良好的配置，可能会导致漏洞和安全威胁。必须对源代码进行扫描，以查找易受攻击的依赖项。

依赖性可能是安全方面最大的挑战。在现代架构中，如何通过使用微服务来处理这个问题？

理解和应用服务网格

DevOps 在微服务中得到了很好的支持。这是开发和部署新功能的完美方式，可以在不影响其他正在运行的服务的情况下进行编码。由于微服务的粒度，开发和部署也可以在较低级别进行安全保护，从而降低了服务中断用户体验的风险。使用微服务意味着配置错误或程序不当的实现仅限于正在开发和部署的特定服务，也最小化了整个应用程序堆栈的攻击面。为了支持这种工作方式，容器发挥了重要作用。服务和功能被打包并作为容器进行部署。

下一个挑战是如何让这些容器化的服务和功能安全地互相作用。这正是服务网格的核心内容。为了建立这种互动，开发者需要在应用程序代码中进行配置。他们将集成能够与应用程序外部服务通信的库，例如服务发现、负载均衡，以及设置与其他服务之间的传输层安全性（TLS）流量。首先，配置字符串和它们在应用程序代码中调用的服务需要共享一种通用语言。但更重要的是，当一个服务发生变化时，应用程序代码也需要进行相应的调整。这使得应用程序代码变得复杂。

服务网格通过将复杂性从应用程序中移除，并将其转移到服务代理来解决这个问题。这个代理现在负责处理应用程序与其他功能组件交互时使用的许多第三方服务。比如流量管理，包括负载均衡、身份验证，当然，还有安全性和监控。服务现在从应用程序代码中抽象出来，成为一个独立的组件。

开发者只需要关注应用程序代码，因为所有其他服务都由服务代理来处理。通过这种方式，我们实现了严格的责任分离。

听起来是个不错的解决方案，但它在实践中是如何运作的呢？我们将在本章的最后一节学习这一点。

在流水线中集成零信任

在前面的章节中，我们讨论了零信任架构的原理以及微服务如何帮助实现零信任。接下来，我们了解了如何通过安全的服务网格让微服务互相作用。在这一节中，我们将学习如何通过容器化应用程序以及我们从 CI/CD 流水线中瞄准的云服务来实现这一目标。像 AWS 和 Azure 这样的平台提供了相应的解决方案，我们将讨论这些解决方案。

首先，我们需要了解如何为服务网格添加安全性。一种方法是使用边车（sidecar）。简单来说，边车是容器集群中的一个节点，用于插入安全策略。你可以把它想象成一条主路，汽车在上面行驶。一辆载有特定安全策略的汽车从一条侧路驶入，插入到主路上的车队中。然而，这个插入点是固定的。

有多种工具提供旁车服务网格。常见的有 Istio、Linkerd 和 Envoy。这些工具的共同点在于，它们将所需的功能放入一个单独的容器中，并将其插入到应用容器附近，就像我们描述的插入汽车一样。由于大多数使用容器的开发者都在使用 Kubernetes，因此了解旁车容器必须与应用容器放在同一个 Kubernetes pod 中是很重要的。因为 pod 的命名空间需要相同。应用容器和旁车容器可以通过 CI/CD 流水线进行集成。

服务网格和旁车代理的整体原理如图所示：

图 15.2 – 服务网格和旁车的原理

如前所述，云平台也提供服务网格。AWS 有 AWS App Mesh，它允许服务在不考虑底层基础设施的情况下相互交互，当它使用 Envoy 旁车代理时。原生 App Mesh 可以与 AWS Fargate 的无服务器基础设施服务、EC2 计算引擎以及 Elastic Container Services（ECS）和 Elastic Kubernetes Services（EKS）的容器编排服务一起使用。AWS App Mesh 的高级架构如图所示：

图 15.3 – AWS App Mesh 的架构

在 Azure 中，我们使用 Azure Service Fabric，这是微软的容器编排器，用于部署和管理微服务。微软于 2018 年推出的完全托管的网格服务 Azure Service Fabric Mesh 已于 2021 年 4 月退役。使用 Azure 的公司可以使用 Azure 容器服务、Azure Kubernetes 服务（AKS）或 Azure Service Fabric 托管集群来创建网格功能。Azure Service Fabric 的原理如图所示：

图 15.4 – Azure Service Fabric 的高级架构

这标志着我们对企业 DevOps、AIOps 和 DevSecOps 之旅的结束。在这个数字化转型的时代，架构师面临着一个重要任务，那就是理解这些方法论如何帮助企业现代化其 IT 环境，使软件开发更加敏捷，同时确保在开发和部署过程中实现最大安全性。本书仅是一个起点，关键在于实践，所以走出去，尝试将其落实。

总结

在这一章节中，我们首先学习了零信任架构的原则，并了解到 DevOps 团队也需要遵守这些原则。零信任从准确知道谁可以访问代码仓库开始，并且了解构建只能部署到严格隔离的网络段，以避免影响其他服务。接下来，我们了解到微服务架构对 DevOps 有很好的支持，它们允许独立开发和部署代码中的功能，而不影响其他服务。

我们了解到，微服务是一种安全的架构类型。然而，挑战在于如何建立这些微服务之间的互动。我们研究了服务网格作为解决方案，并了解了如何将安全策略作为容器化微服务集成，使用侧车代理技术。我们还学习了如何通过使用侧车代理在微服务旁插入安全服务和监控功能。

在最后一部分，我们介绍了一些云服务提供商（如 Azure 和 AWS）提供的网格服务。此部分总结了 DevOps、DevSecOps 和 AIOps 在企业架构中的应用，这些概念在数字化转型中变得越来越重要，理解并实施它们是成功推动企业数字化转型的关键。

问题

1. 在零信任环境中，我们应用哪些基本规则来管理账户权限？

2. 我们使用什么类型的服务来在应用容器旁插入具有安全策略的独立容器？

3. AWS 提供了什么服务来支持服务网格？

进一步阅读

• 国家网络安全卓越中心（NCCoE）关于零信任架构的网站：www.nccoe.nist.gov/projects/building-blocks/zero-trust-architecture

• Kubernetes 微服务实战，作者 Gigi Sayfan，Packt Publishing，2019

• 微软 Azure Service Fabric 的文档：docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview#:~:text=%20Overview%20of%20Azure%20Service%20Fabric%20%201,application%20lifecycle...%204%20Next%20steps.%20%20More%20

• AWS App Mesh 的博客文章：aws.amazon.com/app-mesh/?aws-app-mesh-blogs.sort-by=item.additionalFields.createdDate&aws-app-mesh-blogs.sort-order=desc&whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc

第十六章：评估

第一章

1. 正确

2. 集成、协作、配置管理

3. 持续集成、持续交付（有时也称为持续部署）

4. 部署失败检测时间

第二章

1. 错误。商业利益——以及随之而来的商业案例——是需求管理的重要资产。

2. 静态分析

3. 开发 – 测试 – 验收 – 生产

第三章

1. 测试独立组件

2. 边界值分析

3. 完成定义

4. 正确

第四章

1. 重构

2. AKS 和 EKS

3. BIA

第五章

1. 劳动

2. 检测时间和修复时间

3. 风险的后果被转移，例如转交给保险公司。

第六章

1. 这些组件必须是技术架构的一部分：

   • 生产调度/监控

   • 系统监控

   • 性能监控

   • 网络监控

   • 事件管理（事故、问题、变更）

2. IT4IT 定义的四个 IT 交付价值流如下：

   • 计划：从战略到投资组合

   • 构建：从需求到部署

   • 交付：完成需求

   • 运行：从检测到修正

3. 微服务

4. 第 3 级：主动

第七章

1. 同理心

2. CodeBuild、CodePipeline 和 CodeDeploy

3. 平均响应时间

第八章

1. 展示层有两个主要功能。首先，它帮助用户以易于理解的方式提交请求。一旦请求处理完成，响应将在此层中呈现。

2. 异常检测

3. 参与数据

4. 正确

第九章

1. 通过将系统和数据迁移到其他平台来降低 TCO/成本降低

2. Kubernetes

3. AI 驱动的 DevOps 可能的结果/成果，特别是在代码改进方面：

   • 识别缺失的代码

   • 检测写得差的代码

   • 检测不必要的代码

   • 检测预期和/或所需的缺失依赖项

第十章

1. 自动修复

2. 演绎

3. 正确

第十一章

1. 以下是四个原则：

   • 预防

   • 检测

   • 修正

   • 方向

2. Docker Notary

3. 错误

第十二章

1. SCA 将检测代码中的依赖关系。

2. Linting。

3. CloudFormation。

4. 弹性 Kubernetes 服务（EKS）在 AWS 中，Azure Kubernetes 服务（AKS）在 Azure 中，Google Kubernetes 引擎（GKE）在 GCP 中。

第十三章

1. ISO 27017。

2. 容器管理命令并部署容器。

3. 错误——这是一个通用控制，设置 Docker 的最新版本。

第十四章

1. 正确

2. 扫描原始源代码的 SAST 工具和扫描库中反编译源代码的工具

3. 收集、分析、警报

第十五章

1. 最小权限

2. 边车

3. AWS App Mesh