本文档介绍了在持续集成和持续交付 (CI/CD) 的背景下进行灾难恢复 (DR) 和业务连续性规划。它还提供了有关如何在制定全面的业务连续性计划 (BCP) 时识别和缓解依赖关系的指导。无论您使用哪些工具和流程，本文档都包含您可以应用于 BCP 的最佳实践。本文档假定您熟悉软件交付和运维周期、CI/CD 和灾难恢复的基础知识。
CI/CD 流水线负责构建和部署关键业务应用。因此，与应用基础架构一样，您的 CI/CD 流程也需要针对灾难恢复和业务连续性进行规划。在考虑 CI/CD 的灾难恢复和业务连续性时，请务必了解软件交付和运营周期的每个阶段，并了解它们如何作为一个整体流程协同运作。
下图简要说明了软件开发和运维周期，其中包含以下三个阶段：
- 开发内部循环：编码、尝试和提交
- 持续集成：构建、测试和安全
- 持续交付：升级、发布、回滚和指标
此图表还显示，Google Kubernetes Engine (GKE)、Cloud Run 和 Google Distributed Cloud 是软件开发和运维周期的可能部署目标。
在整个软件开发和运营周期中，您需要考虑灾难对团队运营和维护关键业务应用的能力的影响。这有助于您确定 CI/CD 工具链中工具的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
此外，大多数组织都有许多不同的 CI/CD 流水线，用于处理不同的应用和基础架构集，并且每个流水线对灾难恢复和业务连续性规划都有独特的要求。您为流水线选择的恢复策略因您的工具的 RTO 和 RPO 而异。例如，某些流水线比其他流水线更关键，因此对 RTO 和 RPO 的要求会更低。请务必在 BCP 中标识对业务至关重要的流水线，在实施测试和运行恢复程序的最佳实践时，也应对这些流水线给予更多关注。
由于每个 CI/CD 流程及其工具链都不同，因此本指南旨在帮助您找出 CI/CD 流程中的单点故障，并制定全面的 BCP。以下部分将帮助您执行以下操作：
- 了解如何从影响 CI/CD 流程的灾难恢复 (DR) 事件中恢复。
- 确定 CI/CD 流程中工具的 RTO 和 RPO。
- 了解 CI/CD 流程的失败模式和依赖项。
- 为您的工具链中的工具选择合适的恢复策略。
- 了解针对 CI/CD 流程实施灾难恢复计划的常规最佳实践。
了解业务连续性流程
制定 BCP 至关重要，有助于确保您的组织在发生中断和紧急情况时能够继续运营。它有助于贵组织快速恢复 CI/CD 流程的正常运行状态。
以下各部分概述了创建有效 BCP 所涉及的各个阶段，其中包括相应步骤。虽然其中许多步骤广泛适用于项目管理和灾难恢复，但某些步骤更适合为 CI/CD 流程规划业务连续性。以下各部分中突出显示的步骤与规划 CI/CD 的业务连续性密切相关，也是本文档其余部分的指导原则的基础。
启动和规划
在此初始阶段，技术团队和业务团队会共同为业务连续性规划流程及其持续维护奠定基础。此阶段的主要步骤包括：
- 领导层认可：确保高层管理人员支持并大力推动 BCP 的制定。分配一个专门的团队或个人来负责监督该计划。
- 资源分配：分配必要的预算、人员和资源，用于制定和实施 BCP。
- 范围和目标：定义 BCP 的范围及其目标。 确定哪些业务流程至关重要，需要在计划中加以解决。
- 风险评估：识别可能扰乱业务的潜在风险和威胁，例如自然灾害、网络安全漏洞或供应链中断。
- 影响分析：评估这些风险评估发现对您的业务运营、财务、声誉和客户满意度可能产生的影响。
业务影响分析
在此阶段，业务团队和技术团队会分析中断对客户和组织的业务影响，并优先恢复关键业务功能。这些业务功能在构建和部署流程的不同阶段由不同的工具执行。
业务影响分析是 CI/CD 业务连续性规划流程中的一个重要阶段，尤其是确定关键业务功能和工具依赖关系的步骤。此外，了解 CI/CD 工具链（包括其依赖项以及在 DevOps 生命周期中的作用）是针对 CI/CD 流程开发 BCP 的基础构建块。
业务影响分析阶段的主要步骤包括：
- 关键功能：确定必须优先恢复的关键业务功能和流程。例如，如果您确定部署应用比执行单元测试更重要，则应优先考虑应用部署流程和工具的恢复。
- 依赖项：确定可能影响关键功能恢复的内部和外部依赖项。依赖项对于确保 CI/CD 流程通过其工具链继续运行尤为重要。
- RTO 和 RPO：为每个关键功能定义可接受的停机时间和数据丢失限制。这些 RTO 和 RPO 目标与业务功能对持续运营的重要性相关，并且涉及业务功能顺畅运行所需的特定工具。
制定策略
在此阶段，技术团队会为关键业务功能制定恢复策略，例如恢复运营和数据，以及与供应商和利益相关方进行沟通。策略制定也是为 CI/CD 流程规划业务连续性的关键部分，尤其是为关键功能选择高级恢复策略的步骤。
策略制定阶段的主要步骤包括：
- 恢复策略：制定恢复关键功能的策略。这些策略可能涉及备用营业地点、远程工作或备用系统。这些策略与每个关键功能的 RTO 和 RPO 目标相关联。
- 供应商和供应商关系：与主要供应商建立沟通和协调计划，以便在发生中断时保持供应链正常运转。
- 数据和 IT 恢复：制定数据备份、IT 系统恢复和网络安全措施的计划。
- 沟通计划：在服务中断期间和中断发生后，为内部和外部利益相关方制定明确的沟通计划。
方案开发
在此阶段，主要步骤是记录 BCP。技术团队会记录每个关键功能的工具、流程、恢复策略、理由和程序。制定计划还包括编写员工在发生中断时应遵循的逐步说明。在实施和持续维护期间，可能需要对计划进行更改，并且应将计划视为活文档。
实现
在此阶段，您将使用技术团队创建的 BCP 为贵组织实施计划。实施包括员工培训和 BCP 的初始测试。实施还包括在发生中断时使用该计划来恢复常规操作。主要的实现步骤包括：
- 初始测试和培训：在记录 BPC 后，通过模拟和练习对其进行测试，以找出差距并提高效率。培训员工在中断期间的角色和职责。
- 启动：发生中断时，根据预定义的触发器和程序启动 BCP。
- 沟通：让利益相关方了解情况和恢复工作。
维护和审核
此阶段并非仅发生一次的定义流程，而是代表持续不断的努力，应成为 CI/CD 操作的常规环节。请务必定期审核、测试和更新贵组织的 BCP，以便在发生中断时，该计划仍然相关且可执行。维护和审核的主要步骤包括：
- 定期更新：定期审核和更新 BCP，以确保其保持最新状态并有效。每当人员、技术或业务流程发生变化时，请及时更新。
- 经验教训：每次发生中断或测试后，都要进行总结，找出经验教训和有待改进的方面。
- 合规性：使 BCP 与行业法规和标准保持一致。
- 员工意识：持续向员工宣传 BCP 以及他们在执行 BCP 过程中所扮演的角色。
为 CI/CD 构建业务连续性流程
本部分提供了有关构建 BCP 的具体指南，该 BCP 专注于恢复 CI/CD 操作。规划 CI/CD 业务连续性的过程首先要全面了解您的 CI/CD 工具链，以及它如何与软件交付和运营生命周期相关联。在此基础上，您可以规划组织如何在发生中断时恢复 CI/CD 操作。
如需为 CI/CD 流程构建强大的业务连续性流程，您需要执行以下主要步骤：
以下各部分将详细介绍其中的每一个步骤。
了解工具链
CI/CD 工具链由许多不同的单个工具组成，并且工具的可能组合似乎是无穷无尽的。不过，了解您的 CI/CD 工具链及其依赖项对于 CI/CD 业务连续性规划至关重要。CI/CD 流程的核心任务是将代码传送到生产系统，供最终用户使用。在整个过程中，系统会使用许多不同的系统和数据源；了解这些数据源和依赖项对于制定 BCP 至关重要。如需开始制定灾难恢复策略，您首先需要了解 CI/CD 流程中涉及的不同工具。
为了帮助您了解如何评估自己的工具链并制定 BCP，本文档使用了在 GKE 上运行的企业 Java 应用示例。下图显示了工具链中的第一层数据和系统。此第一层将由您直接控制，并包含以下内容：
- 应用的来源
- CI/CD 平台中的工具，例如 Cloud Build 或 Cloud Deploy
- 不同工具的基本互连
如图所示，示例应用的主要流程如下：
- 开发内部循环中的代码开发事件触发 Cloud Build。
- Cloud Build 从源代码控制库中提取应用源代码。
- Cloud Build 会识别构建配置文件中指定的所有必要依赖项，例如 Artifact Registry 中的 Java 代码库中的第三方 JAR 文件。然后，Cloud Build 会从其来源位置提取这些依赖项。
- Cloud Build 运行 build 并执行必要的验证，例如静态分析和单元测试。
- 如果构建成功，Cloud Build 会创建容器映像并将其推送到 Artifact Registry 中的容器代码库。
- 系统会触发 Cloud Deploy 流水线，该流水线会从代码库中提取容器映像，并将其部署到 GKE 环境。
为了了解 CI/CD 流程中所使用的工具，我们建议您创建一个图表，其中显示了您的 CI/CD 流程以及其中所使用的工具，类似于本文档中的示例。然后，您可以使用该图表创建一个表格，其中包含有关 CI/CD 工具链的关键信息，例如流程阶段、工具用途、工具本身以及受工具故障影响的团队。此表格提供了工具链中工具的映射，并标识了 CI/CD 流程的特定阶段所使用的工具。因此，该表格可以帮助您全面了解工具链及其运行方式。
下表将前面提到的企业应用示例映射到图表中的每种工具。为了提供一个更完整的工具链映射示例，这些表格还包含图表中未提及的其他工具，例如安全工具或测试工具。
第一个表格映射到 CI/CD 流程的 CI 阶段中使用的工具：
| 持续集成 | 源代码 | 使用的工具 | 主要用户 | 用量 |
|---|---|---|---|---|
| 阶段：源代码控制 |
|
|
|
|
| 阶段：构建 |
|
开发者 |
|
|
| 阶段：测试 |
|
开发者 |
在一致的按需平台中运行单元测试和集成测试。 |
|
| 阶段：安全 |
|
|
扫描代码以查找安全问题。 |
第二个表格侧重于 CI/CD 流程中的 CD 阶段所使用的工具：
| 持续部署 | 源代码 | 使用的工具 | 主要用户 | 用量 |
|---|---|---|---|---|
| 阶段：部署 | 部署配置文件 |
|
自动化部署，以便在安全且一致的平台中提升、批准和管理流量。 |
|
| 阶段：测试 |
|
|
开发者 |
测试集成和性能，以确保质量和可用性。 |
| 阶段：日志记录 |
|
|
保留日志以实现可观测性和问题排查。 |
|
| 阶段：监控 | 监控配置文件，包括以下内容：
|
|
|
随着您继续开展 BCP 工作，对 CI/CD 工具链的了解不断加深，您可以更新图表和映射表。
确定数据和依赖项
完成 CI/CD 工具链的基础清单和映射后，下一步是捕获与元数据或配置相关的所有依赖项。在实施 BCP 时，您必须清楚了解 CI/CD 工具链中的依赖项。依赖项通常分为两类：内部（一阶）依赖项和外部（二阶或三阶）依赖项。
内部依赖项
内部依赖项是您的工具链使用的系统，并且由您直接控制。内部依赖项也是由您的团队选择的。 这些系统包括您的 CI 工具、密钥管理存储区和源代码控制系统。您可以将这些系统视为位于工具链本身的下一层。
例如，下图展示了内部依赖项在工具链中的位置。此图扩展了示例 Java 应用的上层工具链图，还包含工具链的内部依赖项：应用凭据、deploy.yaml 文件和 cloudbuild.yaml 文件。
该图显示，为了在示例 Java 应用中成功运行，Cloud Build、Cloud Deploy 和 GKE 等工具需要访问 cloudbuild.yaml、deploy.yaml 和应用凭据等非工具链依赖项。在分析您自己的 CI/CD 工具链时，您需要评估某个工具是可以自行运行，还是需要调用其他资源。
请考虑示例 Java 应用的记录在案的内部依赖项。
凭据存储在 Secret Manager 中，Secret Manager 不属于工具链的一部分，但应用在部署时启动时需要使用凭据。因此，应用凭据作为 GKE 的依赖项包含在内。还要将 deploy.yaml 和 cloudbuild.yaml 文件作为依赖项添加进来，即使它们与应用代码一起存储在源代码控制中也是如此，因为它们定义了该应用的 CI/CD 流水线。
示例 Java 应用的 BCP 应考虑到对 deploy.yaml 和 cloudbuild.yaml 文件的这些依赖项，因为它们会在恢复过程中在工具就位后重新创建 CI/CD 流水线。此外，如果这些依赖项遭到破坏，即使工具本身仍在运行，流水线的整体功能也会受到影响。
外部依赖项
外部依赖项是指您的工具链在运行时所依赖的外部系统，这些系统不受您的直接控制。外部依赖项是由于您选择的工具和编程框架而产生的。您可以将外部依赖项视为比内部依赖项更低的层。外部依赖项的示例包括 npm 或 Maven 代码库以及监控服务。
虽然外部依赖项不在您的控制范围之内，但您可以将其纳入 BCP。下图更新了示例 Java 应用，除了内部依赖项之外，还添加了外部依赖项：Maven Central 中的 Java 库和 Docker Hub 中的 Docker 映像。Java 库由 Artifact Registry 使用，而 Docker 映像由 Cloud Build 使用。
该图显示，外部依赖项对于 CI/CD 流程非常重要：Cloud Build 和 GKE 都依赖于两个外部服务（Maven 和 Docker），才能正常运行。在评估自己的工具链时，请记录工具需要访问的外部依赖项以及处理依赖项中断的程序。
在示例 Java 应用中，无法直接控制 Java 库和 Docker 映像，但您仍然可以在 BCP 中添加这些库及其恢复程序。例如，请考虑 Maven 中的 Java 库。虽然库存储在外部来源中，但您可以建立一个流程，以便定期将 Java 库下载并刷新到本地 Maven 代码库或 Artifact Registry。这样一来，您的恢复流程就无需依赖第三方来源的可用性。
此外，请务必了解外部依赖项可能具有多个层。例如，您可以将内部依赖项所使用的系统视为二阶依赖项。这些二阶依赖项可能有自己的依赖项，您可以将其视为三阶依赖项。请注意，您可能需要在 BCP 中记录和考虑二阶和三阶外部依赖项，以便在中断期间恢复操作。
确定 RTO 和 RPO 目标
在了解工具链和依赖项后，您可以为工具定义 RTO 和 RPO 目标。CI/CD 流程中的每个工具都会执行不同的操作，这些操作可能会对业务产生不同的影响。因此，请务必根据业务功能对业务的影响，确定 RTO 和 RPO 目标的优先级。例如，通过 CI 阶段构建新版本的应用可能比通过 CD 阶段部署应用的影响更小。因此，部署工具的 RTO 和 RPO 目标可能比其他函数更长。
下图显示了四个象限图，它是一个一般示例，展示了如何为 CI/CD 工具链的每个组件确定 RTO 和 RPO 目标。此图表中映射的工具链包括 IaC 流水线和测试数据源等工具。在 Java 应用的上述示意图中未提及这些工具，但我们在此处添加了这些工具，以提供更完整的示例。
该图表显示了四个象限，它们是根据对开发者和操作的影响程度划分的。在该图表中，组件的位置如下所示：
- 开发者影响中等，操作影响低：测试数据源
- 开发者影响中等，操作影响中等：Cloud Key Management Service、Cloud KMS
- 开发者影响中等，操作影响高：部署流水线
- 对开发者的影响大，对运营的影响小：开发者内部循环
- 开发者影响较高，操作影响适中：CI 流水线、基础架构即代码 (IaC) 流水线
- 开发者影响高，操作影响高：源代码控制管理 (SCM)、Artifact Registry
源代码控制管理和 Artifact Registry 等对开发者影响和运营影响较大的组件对业务的影响最大。这些组件的 RTO 和 RPO 目标应尽可能低。其他象限中的组件优先级较低，这意味着 RTO 和 RPO 目标会更高。一般来说，应根据可容忍的数据或配置丢失量（与恢复该组件服务所需的时间相比）来设置工具链组件的 RTO 和 RPO 目标。
例如，请考虑图表中 Artifact Registry 和 IaC 流水线的不同位置。对这两种工具进行比较后发现，与 IaC 流水线中发生中断相比，Artifact Registry 中断对业务运营的影响更大。由于 Artifact Registry 中断会严重影响您部署或自动扩缩应用的能力，因此与其他工具相比，它具有更低的 RTO 和 RPO 目标。相比之下，该图表显示，与其他工具相比，IaC 流水线中断对业务运营的影响较小。然后，IaC 流水线的 RTO 和 RPO 目标会更高，因为您可以在停机期间使用其他方法来部署或更新基础架构。
选择业务连续性高级策略
生产应用的业务连续性流程通常依赖于三种常见的灾难恢复策略之一。不过，对于 CI/CD，您可以从以下两个业务连续性高级策略中进行选择：主动/被动或备份/恢复。您选择的策略取决于您的要求和预算。每种策略在复杂性和成本方面都有利弊，并且您需要针对 CI/CD 流程考虑不同的因素。以下部分将详细介绍每种策略及其权衡。
此外，当服务中断事件发生时，它们可能会影响到不仅仅是您的 CI/CD 实现。您还应考虑所需的所有基础架构，包括网络、计算和存储。您应该为这些组成部分制定灾难恢复计划，并定期进行测试，以确保该计划有效。
主动/被动
在主动/被动（或热备用）策略中，您的应用和被动 CI/CD 流水线是镜像。不过，被动流水线实际上并未处理客户工作负载和任何构建或部署，因此处于缩减状态。此策略最适合对业务至关重要的应用，因为这些应用可容忍少量停机时间。
下图显示了本文档中使用的示例 Java 应用的主动/被动配置。被动流水线会在其他区域完全复制应用工具链。
在此示例中，region1 托管活跃的 CI/CD 流水线，而 region2 托管被动 CI/CD 流水线。代码托管在外部 Git 服务提供商（例如 GitHub 或 GitLab）上。存储库事件（例如拉取请求中的合并）可以触发区域 1 中的 CI/CD 流水线，以便构建、测试和部署到多区域生产环境。
如果区域 1 流水线出现严重问题（例如产品在某个区域中断服务），则可能会导致部署失败或构建失败。如需快速解决问题，您可以更新 Git 代码库的触发器，并切换到 region2 流水线，该流水线随后会成为活跃流水线。在区域 1 中解决问题后，您可以将区域 1 中的流水线保持为被动状态。
主动/被动策略的优势包括：
- 停机时间短：由于被动流水线已部署但会缩减，因此停机时间仅限于扩容流水线所需的时间。
- 可配置的数据丢失容忍度：使用此策略时，必须定期同步配置和制品。不过，您可以根据自己的要求来配置数量，从而降低复杂性。
此策略的缺点包括：
- 成本：使用重复的基础架构，此策略会增加 CI/CD 基础架构的总体成本。
备份/恢复
使用备用/恢复策略时，您只需在事件恢复期间需要时创建故障转移流水线。此策略最适合优先级较低的用例。下图显示了示例 Java 应用的备份/恢复配置。备用配置仅在其他区域复制应用 CI/CD 流水线的一部分。
与上一个示例类似，region1 托管有效的 CI/CD 流水线。region2 中没有被动流水线，而是只有必要区域数据的备份，例如 Maven 软件包和容器映像。如果您在 region1 中托管源代码库，还应将数据同步到灾难恢复位置。
同样，如果区域 1 的流水线中发生严重问题（例如区域产品中断），您可以在区域 2 中恢复 CI/CD 实现。如果基础架构代码存储在基础架构代码库中，您可以从该代码库运行自动化脚本，并在 region2 中重新构建 CI/CD 流水线。
如果中断是大型事件，您可能会与其他客户争夺云资源。缓解这种情况的一种方法是为灾难恢复 (DR) 位置提供多个选项。例如，如果您的 region1 流水线位于 us-east1，则您的容灾区域可以是 us-east4、us-central1 或 us-west1。
备份/恢复策略的优势包括：
- 费用：此策略会产生最低的费用，因为您仅在灾难恢复场景中部署备用流水线。
此策略的缺点包括：
- 停机时间：此策略需要更长时间才能实现，因为您需要在需要时创建故障转移流水线。需要在事件恢复期间创建和配置服务，而不是使用预构建的流水线。制品构建时间和检索外部依赖项所需的时间也可能会显著延长。
编写业务连续性计划并实施最佳实践
在映射 CI/CD 工具链、确定其依赖项并确定关键函数的 RTO 和 RPO 目标后，下一步是在书面 BCP 中记录所有相关信息。在制定 BCP 时，请记录恢复每项关键功能的策略、流程和程序。此文档编写流程包括为特定角色的员工编写在中断期间要遵循的逐步操作步骤。
定义 BCP 后，您可以使用最佳实践来部署或更新 CI/CD 工具链，以实现 RTO 和 RPO 目标。虽然 CI/CD 工具链可能非常不同，但无论工具链如何，最佳实践的两个关键模式都是通用的：全面了解依赖项和实现自动化。
在依赖项方面，大多数 BCP 会直接处理您控制范围内的系统。不过，请记住，二阶或三阶外部依赖项也可能产生同样的影响，因此，针对这些关键依赖项也应实施最佳实践和冗余措施。示例应用中的外部 Java 库是三阶依赖项的示例。如果您没有这些库的本地存储库或备份，那么如果您拉取库的外部来源断开连接，您可能无法构建应用。
在自动化方面，应将最佳实践的实施纳入您的整体 Cloud IaC 策略。IaC 解决方案应使用 Terraform 等工具自动预配 CI/CD 实现所需的资源，并配置流程。IaC 实践是高效的恢复流程，因为它们已纳入 CI/CD 流水线的日常运作中。此外，IaC 还可促进将配置文件存储在源代码控制系统中，从而促进采用备份最佳实践。
在您根据 BCP 以及依赖项和自动化最佳实践实现工具链后，您的 CI/CD 流程和恢复策略可能会发生变化。请务必记录在审核 BCP 和实施最佳实践时对恢复策略、流程和程序所做的任何更改。
测试失败场景并维护方案
定期查看、测试和更新 BCP 至关重要。测试 BCP 和恢复程序可验证计划是否仍有效，以及记录的 RPO 和 RTO 目标是否可接受。不过，最重要的是，定期测试、更新和维护可确保 BCP 成为日常操作的一部分。使用 Google Cloud 可让您以最低费用测试恢复方案。为帮助进行测试，建议您实现以下内容：
- 使用 IaC 工具自动化基础架构预配：您可以使用 Terraform 等工具自动化 CI/CD 基础架构的预配。
- 使用 Cloud Logging 和 Cloud Monitoring 监控和调试测试：Google Cloud 可观测性提供日志记录和监控工具（您可以通过 API 调用访问这些工具），这意味着您可以通过对指标作出反应来自动部署恢复方案。在设计测试时，请确保设置可触发相应恢复操作的监控和警报功能。
- 在 BCP 中执行测试：例如，您可以测试权限和用户访问权限在 DR 环境中是否像在生产环境中一样正常运行。您可以对 DR 环境进行集成测试和功能测试。您还可以执行一项测试，在该测试中，您通常使用的 Google Cloud 访问路径不可用。
在 Google，我们会通过一个名为 DiRT（灾难恢复测试）的流程定期测试 BCP。此类测试有助于 Google 验证影响、自动化并揭示未考虑的风险。需要实现的自动化和 BCP 更改是 DiRT 的一个重要输出。
最佳做法
在本部分中，您将了解一些最佳实践，您可以实施这些最佳实践来实现 RTO 和 RPO 目标。这些最佳实践广泛适用于 CI/CD 的灾难恢复，而非特定工具。无论您采用何种实现方式，都应定期测试 BCP，以确保高可用性、RTO 和 RPO 符合您的要求。如果发生突发事件或灾难，您还应回顾并分析流程，以便改进流程。
高可用性
对于每种工具，您都应努力实现高可用性最佳实践。遵循高可用性最佳实践可让您的 CI/CD 流程更具前瞻性，因为这些最佳实践可让 CI/CD 流程更具抗故障能力。在恢复和备份方面，应将这些主动策略与更多被动控制和程序结合使用。
以下是一些实现高可用性的最佳实践。不过，如需了解更详细的最佳实践，请参阅 CI/CD 中每种工具的详细文档：
- 托管式服务：使用托管式服务会将运营责任转移给 Google Cloud。
- 自动扩缩：请尽可能使用自动扩缩。自动扩缩功能的一个关键方面是，工作器实例是动态创建的，因此失败节点的恢复是自动进行的。
- 全球部署和多区域部署：请尽可能使用全球部署和多区域部署，而不是区域部署。例如，您可以将 Artifact Registry 配置为多区域存储。
- 依赖项：了解工具的所有依赖项，并确保这些依赖项具有高可用性。例如，您可以缓存制品注册表中的所有第三方库。
备份流程
为 CI/CD 实现灾难恢复时，某些工具和流程更适合备份/恢复策略。全面的备份策略是有效的应急控制措施的第一步。借助备份，您可以在恶意行为者或灾难场景发生时以最小的中断恢复 CI/CD 流水线。
首先，您应实现以下三项最佳实践。 不过，如需了解更详细的备份最佳实践，请参阅 CI/CD 流程中每种工具的文档。
- 源代码控制：在源代码控制中存储配置文件和您编码的任何内容，例如自动化脚本和政策。例如
cloudbuild.yaml和 Kubernetes YAML 文件。 - 冗余性：确保在访问密码、证书和 API 密钥等机密时不会出现单点故障。需要避免的做法示例包括：只有一个人知道密码，或者仅将 API 密钥存储在特定区域的单个服务器上。
- 备份：经常验证备份的完整性和准确性。Backup for GKE 等托管服务有助于简化验证流程。
恢复流程
DR 还需要恢复过程来补充备份流程。恢复流程与完整备份相结合，将决定您能多快地应对灾难场景。
依赖项管理
您的 CI/CD 流水线可能包含许多依赖项，这些依赖项也可能是故障来源。应按照本文档中前面确定数据和依赖项部分的说明，确定依赖项的完整列表。不过，依赖项的两个最常见来源如下：
- 应用制品：例如软件包、库和映像
- 外部系统：例如工单和通知系统
缓解依赖项风险的一种方法是采用供应商实践。供应商应用软件包或映像是指在私有代码库中创建和存储这些软件包或映像的副本的过程。供应商可以消除对这些软件包或映像的依赖性，还可以帮助防止恶意软件插入软件供应链。
供应商应用软件包或映像的一些优势包括：
- 安全性：供应商模式可消除对应用软件包或映像的外部来源的依赖关系，从而有助于防止恶意软件插入攻击。
- 控制：通过供应自己的软件包或映像，组织可以更好地控制这些软件包和映像的来源。
- 合规性：供应商模式有助于组织遵守行业法规，例如网络安全成熟度模型认证。
如果您的团队决定使用供应商应用软件包或映像，请按照以下主要步骤操作：
- 确定需要供应商提供的应用软件包或映像。
- 创建一个专用代码库，用于存储供应商提供的软件包或映像。
- 从原始来源下载软件包或映像，并将其存储在专用存储库中。
- 验证软件包或映像的完整性。
- 根据需要更新供应商提供的软件包或映像。
CI/CD 流水线通常会调用外部系统来执行操作，例如运行扫描、记录工单或发送通知。在大多数情况下，这些第三方系统都有自己的 DR 策略，应予以实施。不过，在某些情况下，他们可能没有合适的灾难恢复计划，这些情况应在 BCP 中明确记录。然后，您必须决定是否可以出于可用性原因跳过流水线中的这些阶段，或者是否可以接受 CI/CD 流水线出现停机时间。
监控和通知
您的 CI/CD 就像应用生产系统一样，因此您还需要为 CI/CD 工具实现监控和通知技术。作为最佳实践，我们建议您实现信息中心和提醒通知。Cloud Monitoring 的 GitHub示例代码库包含许多信息中心和提醒政策示例。
您还可以实现其他级别的监控，例如服务等级指标 (SLI) 和服务等级目标 (SLO)。这些监控级别有助于跟踪 CI/CD 流水线的总体运行状况和性能。例如，可以实现 SLO 来跟踪构建和部署阶段的延迟时间。这些 SLO 可帮助团队以您想要的速度和频率构建和发布应用。
紧急访问流程
在灾难期间，运维团队可能需要在标准流程之外采取行动，并获得对系统和工具的紧急访问权限。此类紧急操作有时称为“破窗程序”。首先，您应遵循以下三项最佳实践：
- 制定明确的上报路径和程序。明确的计划有助于运营团队了解何时需要使用紧急访问程序。
- 确保多名人员可以访问关键信息，例如配置和密钥。
- 开发自动化审核方法，以便您能够跟踪紧急访问程序的使用时间和使用者。
后续步骤
- 详细了解本文档中使用的 Google Cloud 产品：
- 请参阅灾难恢复计划指南。
- 完成我们的教程，试用其他 Google Cloud 功能。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。
贡献者
作者：
- Ben Good | 解决方案架构师
- Xiang Shen | 解决方案架构师
其他贡献者：
- Marco Ferrari | 云解决方案架构师
- Anuradha Bajpai | 解决方案架构师
- Rodd Zurcher | 解决方案架构师