本文档介绍了持续集成和持续交付 (CI/CD) 背景下的灾难恢复 (DR) 和业务连续性规划。此外，它还提供了有关如何在制定全面的业务连续性计划 (BCP) 时识别和缓解依赖关系的指南。无论您使用何种工具和流程，都可以将本文档中包含的最佳实践应用于您的 BCP。本文档假定您熟悉软件交付和运营周期、CI/CD 和 DR 的基础知识。
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 流程的灾难恢复。
- 确定 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 会识别 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 流水线的不同位置。对这两种工具进行比较后发现，Artifact Registry 中断对业务运营的影响要大于 IaC 流水线中断。由于 Artifact Registry 发生中断会严重影响您部署或自动扩缩应用的能力，因此与其他工具相比，它具有较低的 RTO 和 RPO 目标。相比之下，该图表显示，与使用其他工具相比，IaC 流水线中断对业务运营的影响较小。这样一来，Iac 流水线将具有更高的 RTO 和 RPO 目标，因为您可以在中断期间使用其他方法来部署或更新基础设施。
选择业务连续性方面的高级策略
生产应用的业务连续性流程通常依赖于三种常见的灾难恢复策略之一。不过，对于 CI/CD，您可以选择两种高级业务连续性策略：主动/被动或备份/恢复。您选择的策略将取决于您的需求和预算。每种策略在复杂性和成本方面都有所权衡，并且您在 CI/CD 流程中需要考虑不同的因素。以下部分将详细介绍每种策略及其优缺点。
此外，当服务中断事件发生时，它们可能会影响您的 CI/CD 实现以外的其他方面。您还应考虑所需的所有基础设施，包括网络、计算和存储。您应该为这些构建块制定灾难恢复计划，并定期测试该计划，以确保其有效性。
主动/被动
借助主动/被动（或暖备）策略，您的应用和被动 CI/CD 流水线是镜像。不过，被动流水线实际上并不处理客户工作负载以及任何 build 或部署，因此处于缩减状态。此策略最适合可承受少量停机时间的关键业务应用。
下图展示了本文档中使用的示例 Java 应用的主动/被动配置。被动流水线在不同区域中完全复制应用工具链。
在此示例中，region1 托管活跃的 CI/CD 流水线，而 region2 托管被动对应的流水线。代码托管在外部 Git 服务提供商（例如 GitHub 或 GitLab）上。代码库事件（例如通过拉取请求进行的合并）可以触发 region1 中的 CI/CD 流水线，以构建、测试和部署到多区域生产环境。
如果 region1 流水线出现严重问题（例如产品区域性服务中断），则可能会导致部署失败或 build 失败。为了快速从问题中恢复，您可以更新 Git 代码库的触发器，并切换到区域 2 流水线，该流水线随后会成为活跃流水线。在 region1 中解决问题后，您可以将 region1 中的流水线保持为被动状态。
主动/被动策略的优势包括：
- 停机时间短：由于被动流水线已部署但已缩减，停机时间仅限于将流水线扩大的时间。
- 可配置的数据丢失容忍度：使用此策略时，必须定期同步配置和制品。不过，您可以根据自己的需求配置金额，从而降低复杂性。
此策略的缺点包括：
- 费用：由于基础架构重复，此策略会增加 CI/CD 基础架构的总费用。
备份/恢复
借助备份/恢复策略，您只需在突发事件恢复期间根据需要创建故障切换流水线。此策略最适合优先级较低的应用场景。下图显示了示例 Java 应用的备份/恢复配置。备份配置仅在其他区域中复制应用 CI/CD 流水线的一部分。
与上例类似，region1 托管着有效的 CI/CD 流水线。与在 region2 中设置被动流水线不同，region2 仅备份必要的区域数据，例如 Maven 软件包和容器映像。如果您在 region1 中托管源代码库，则还应将数据同步到灾难恢复位置。
同样，如果 region1 流水线中出现严重问题（例如区域产品中断），您可以在 region2 中恢复 CI/CD 实现。如果基础架构代码存储在基础架构代码库中，您可以从该代码库运行自动化脚本，并在 region2 中重建 CI/CD 流水线。
如果服务中断是大规模事件，您可能需要与其他客户竞争云资源。缓解这种情况的一种方法是为灾难恢复位置提供多种选择。例如，如果您的 region1 流水线位于 us-east1，则故障切换区域可以是 us-east4、us-central1 或 us-west1。
备份/恢复策略的优势包括：
- 费用：此策略产生的费用最低，因为您仅在发生灾难恢复 (DR) 场景时部署备份流水线。
此策略的缺点包括：
- 停机时间：此策略需要更多时间来实现，因为您是在需要时创建故障切换流水线的。在事件恢复期间，需要创建和配置服务，而不是使用预构建的流水线。制品构建时间和检索外部依赖项所需的时间也可能会显著延长。
记录您的 BCP 并实施最佳实践
在您映射 CI/CD 工具链、确定其依赖项并确定关键功能的 RTO 和 RPO 目标后，下一步是将所有相关信息记录在书面 BCP 中。制定 BCP 时，请记录恢复各项关键职能的策略、流程和程序。此文档编制流程包括为特定角色的员工编写在中断期间要遵循的分步程序。
定义 BCP 后，您可以使用最佳实践来部署或更新 CI/CD 工具链，以实现 RTO 和 RPO 目标。尽管 CI/CD 工具链可能大相径庭，但无论使用哪种工具链，都有两种关键的最佳实践模式：全面了解依赖项和实现自动化。
就依赖项而言，大多数 BCP 都直接针对您可控制的系统。不过，请注意，二阶或三阶外部依赖项的影响可能同样巨大，因此务必针对这些关键依赖项实施最佳实践和冗余措施。示例应用中的外部 Java 库是三阶依赖项的一个示例。如果您没有这些库的本地代码库或备份，那么当您从中提取库的外部来源断开连接时，您可能无法构建应用。
在自动化方面，最佳实践的实施应纳入您的整体云 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 Observability 提供日志记录和监控工具，您可以通过 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 密钥等 Secret 时，不会出现单点故障。应避免的做法包括：只有一个人知道密码，或者仅在特定区域的单个服务器上存储 API 密钥。
- 备份：经常验证备份的完整性和准确性。Backup for GKE 等托管服务将有助于简化验证流程。
恢复程序
灾难恢复还需要恢复程序来补充备份流程。您的恢复程序与完整备份相结合，将决定您能够以多快的速度应对灾难场景。
依赖项管理
您的 CI/CD 流水线可能具有许多依赖项，这些依赖项也可能成为故障来源。应按照本文档前面部分确定数据和依赖项中所述，确定完整的依赖项列表。不过，最常见的两种依赖项来源如下：
- 应用制品：例如软件包、库和映像
- 外部系统：例如，工单和通知系统
缓解依赖项风险的一种方法是采用供应商锁定实践。 供应商化应用软件包或映像是指在私有代码库中创建并存储它们的副本的过程。供应商化可消除对这些软件包或映像的外部来源的依赖，还有助于防止恶意软件插入到软件供应链中。
供应商提供应用软件包或映像的一些好处包括：
- 安全性：供应商化可消除对应用软件包或映像的外部来源的依赖，从而有助于防止恶意软件插入攻击。
- 控制：通过提供自己的软件包或映像，组织可以更好地控制这些软件包和映像的来源。
- 合规性：供应商可以帮助组织遵守行业法规，例如网络安全成熟度模型认证。
如果您的团队决定提供应用软件包或映像，请按以下主要步骤操作：
- 确定需要供应商提供的应用软件包或映像。
- 创建用于存储供应商提供的软件包或映像的私有代码库。
- 从原始来源下载软件包或映像，并将其存储在私有仓库中。
- 验证软件包或映像的完整性。
- 根据需要更新供应商提供的软件包或映像。
CI/CD 流水线通常会调用第三方系统来执行扫描、记录工单或发送通知等操作。在大多数情况下，这些外部方系统都有自己的灾难恢复策略，应予以实施。不过，在某些情况下，他们可能没有合适的灾难恢复计划，这些情况应在 BCP 中明确记录。然后，您必须决定是否可以出于可用性原因跳过流水线中的这些阶段，或者是否可以接受导致 CI/CD 流水线停机。
监控和通知
CI/CD 与应用生产系统一样，因此您还需要为 CI/CD 工具实现监控和通知技术。根据最佳实践，我们建议您实现信息中心和提醒通知。Cloud Monitoring 的 GitHub 示例代码库包含许多信息中心和提醒政策示例。
您还可以实现其他级别的监控，例如服务等级指标 (SLI) 和服务等级目标 (SLO)。这些监控级别有助于跟踪 CI/CD 流水线的总体健康状况和性能。例如，可以实现 SLO 来跟踪构建和部署阶段的延迟时间。这些 SLO 可帮助团队以您期望的速度和频率构建和发布应用。
紧急访问程序
在灾难期间，运营团队可能需要采取标准程序之外的行动，并获得对系统和工具的紧急访问权限。此类紧急措施有时称为“紧急情况处理流程”(breakglass procedures)。首先，您应实施以下三项最佳实践：
- 制定明确的上报计划和程序。清晰的计划有助于运营团队了解何时需要使用紧急访问程序。
- 确保多人可以访问关键信息，例如配置和密钥。
- 开发自动化审核方法，以便您跟踪紧急访问程序的使用时间和使用人员。
后续步骤
- 详细了解本文档中使用的 Google Cloud 产品：
- 请参阅灾难恢复规划指南。
- 完成我们的教程，试用其他 Google Cloud 功能。
- 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。
贡献者
作者：
- Ben Good | 解决方案架构师
- Xiang Shen | 解决方案架构师
其他贡献者：
- Marco Ferrari | 云解决方案架构师
- Anuradha Bajpai | 解决方案架构师
- Rodd Zurcher | 解决方案架构师