本文档介绍了在持续集成和持续交付 (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 流程的 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 以及他们在执行 BCP 中的作用。
为 CI/CD 构建业务连续性流程
本部分提供了有关制定专门用于恢复 CI/CD 操作的 BCP 的具体指南。规划 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 中，该工具不属于工具链的一部分，但应用在部署时需要凭据才能启动。因此，应用凭据会作为 GKE 的依赖项包含在内。同样重要的是，请将 deploy.yaml 和 cloudbuild.yaml 文件作为依赖项添加到源代码控制中，即使它们与应用代码一起存储在源代码控制中也是如此，因为它们定义了该应用的 CI/CD 流水线。
示例 Java 应用的 BCP 应考虑对 deploy.yaml 和 cloudbuild.yaml 文件的这些依赖项，因为它们会在恢复过程中工具就位后重新创建 CI/CD 流水线。此外，如果这些依赖项遭到破坏，即使工具本身仍在运行，流水线的整体功能也会受到影响。
外部依赖项
外部依赖项是您的工具链运行所依赖的外部系统，不受您的直接控制。外部依赖项是指您选择的工具和编程框架。您可以将外部依赖项视为位于内部依赖项之下的另一层。外部依赖项示例包括 npm 或 Maven 仓库以及监控服务。
虽然外部依赖项不在您的控制范围内，但您可以将其纳入您的 BCP。下图除了内部依赖项之外，还添加了外部依赖项（Maven Central 中的 Java 库和 Docker Hub 中的 Docker 映像），从而更新了示例 Java 应用。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 目标的优先级。例如，与通过 CD 阶段部署应用相比，通过 CI 阶段构建新版本的应用可能影响较小。因此，部署工具的 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 流水线是镜像。不过，被动流水线实际上并未处理客户工作负载以及任何 build 或部署，因此处于缩减状态。此策略最适合可容忍少量停机时间的关键业务应用。
下图显示了本文档中使用的 Java 应用示例的活动/被动配置。被动流水线会在其他区域完全复制应用工具链。
在此示例中，region1 托管主动 CI/CD 流水线，而 region2 托管被动 CI/CD 流水线。代码托管在外部 Git 服务提供商（例如 GitHub 或 GitLab）上。代码库事件（例如拉取请求的合并）可以触发 region1 中的 CI/CD 流水线，以便构建、测试并部署到多区域生产环境。
如果 region1 流水线发生严重问题（例如产品在某个区域出现服务中断），则可能会导致部署或构建失败。如需快速解决此问题，您可以更新 Git 代码库的触发器，然后切换到 region2 流水线，该流水线将成为有效流水线。在 region1 中解决问题后，您可以将 region1 中的流水线保持为被动状态。
主动/被动策略的优势包括：
- 停机时间短：由于被动流水线已部署但已缩减，因此停机时间仅限于扩容流水线所需的时间。
- 可配置的数据丢失容忍度：使用此策略时，必须定期同步配置和制品。不过，您可以根据自己的要求配置数量，从而降低复杂性。
此策略的缺点包括：
- 费用：由于基础架构重复，此策略会增加 CI/CD 基础架构的总体费用。
备份/恢复
使用备份/恢复策略时，您只需在突发事件恢复期间根据需要创建故障切换流水线。此策略最适用于优先级较低的用例。下图显示了示例 Java 应用的备份/恢复配置。备份配置仅会在其他区域复制应用的 CI/CD 流水线的一部分。
与上例类似，region1 托管主动 CI/CD 流水线。region2 中没有被动流水线，而是仅包含必要区域数据（例如 Maven 软件包和容器映像）的备份。如果您在 region1 中托管源代码库，则还应将数据同步到您的 DR 位置。
同样，如果 region1 流水线发生严重问题（例如区域性产品服务中断），您可以在 region2 中恢复 CI/CD 实现。如果基础架构代码存储在基础架构代码库中，您可以从该代码库运行自动化脚本，并在 region2 中重新构建 CI/CD 流水线。
如果服务中断是一次大规模事件，您可能需要与其他客户竞争云资源。若要缓解这种情况，一种方法是为灾难恢复位置提供多个选项。例如，如果您的 region1 流水线位于 us-east1，则您的故障切换区域可以是 us-east4、us-central1 或 us-west1。
备份/恢复策略的优势包括：
- 费用：此策略的费用最低，因为您仅在灾难恢复场景中部署备份流水线。
此策略的缺点包括：
- 停机时间：此策略的实现时间较长，因为您需要在需要时创建故障切换流水线。您需要在突发事件恢复期间创建和配置服务，而不是使用预构建的流水线。制品构建时间和检索外部依赖项所需的时间也可能会显著延长。
记录您的 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 的 DR，而非特定工具。无论您采用何种实现方式，都应定期测试 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 可帮助团队按照您希望的速度和频率构建和发布应用。
紧急访问流程
在灾难发生时，运维团队可能需要采取超出标准流程的措施，并获得对系统和工具的紧急访问权限。此类紧急操作有时也称为“紧急措施”。首先，您应实现以下三项最佳实践：
- 制定明确的上报计划和流程。明确的计划有助于运维团队了解何时需要使用紧急访问权限流程。
- 确保多名人员可以访问配置和 Secret 等重要信息。
- 开发自动审核方法，以便跟踪何时使用了紧急访问权限流程以及使用者是谁。
后续步骤
- 详细了解本文档中使用的 Google Cloud 产品：
- 请参阅灾难恢复规划指南。
- 完成我们的教程，试用其他 Google Cloud 功能。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。
贡献者
作者：
- Ben Good | 解决方案架构师
- Xiang Shen | 解决方案架构师
其他贡献者：
- Marco Ferrari | 云解决方案架构师
- Anuradha Bajpai | 解决方案架构师
- Rodd Zurcher | 解决方案架构师