所需客户活动
事件前
对于 Azure 服务
- 熟悉 Azure 门户中的 Azure 服务运行状况。 此页面将在事件期间充当“一站式商店”。
- 请考虑使用 服务运行状况警报，该警报可配置为在发生 Azure 事件时自动生成通知。
对于 Power BI
- 熟悉 Microsoft 365 管理中心的服务运行状况。 此页面将在事件期间充当“一站式商店”。
- 请考虑使用 Microsoft 365 管理 移动应用来获取自动服务事件警报通知。
事件期间
对于 Azure 服务
- Azure 管理门户中的 Azure 服务运行状况 将提供最新的更新。
- 如果访问服务运行状况时遇到问题，请参阅 “Azure 状态”页。
- 如果访问“状态”页面时遇到问题，请转到 @AzureSupport X（前 Twitter）。
- 如果影响/问题与事件不匹配（或缓解后仍然存在），请联系 支持 人员提出服务支持票证。
对于 Power BI
- Microsoft 365 管理中心内的服务运行状况页会提供最新更新
- 如果在访问服务运行状况时出现问题，请参阅 Microsoft 365 状态页
- 如果影响/问题与事件不匹配（或在缓解后问题仍然存在），应提出服务支持票证。
Microsoft 恢复后
有关详细信息，请参阅以下部分。
事件后
对于 Azure 服务
- Microsoft会将 PIR 发布到 Azure 门户 - 服务运行状况以供评审。
对于 Power BI
- Microsoft会将 PIR 发布到 Microsoft 365 管理 - 服务运行状况以供评审。
“等待 Microsoft”过程
“等待 Microsoft”过程只是等待 Microsoft 恢复受影响主要区域中的所有组件和服务。 恢复后，验证数据平台与企业共享服务或其他服务的绑定、数据集的日期，然后执行使系统达到当前日期的过程。
完成此过程后，就可以完成技术和业务行业专家 (SME) 验证，使利益干系人能够批准服务恢复。
灾难发生时重新部署
对于“在灾难时重新部署”策略，可以描述以下高级流程。
恢复 Contoso 的企业共享服务和源系统
- 此步骤是恢复数据平台的先决条件。
- 此步骤将由负责企业共享服务和运营源系统的各种 Contoso 运营支持组完成。
恢复 Azure 服务 - Azure 服务是指构成 Azure 云产品/服务的应用程序和服务，可在次要区域内进行部署。
Azure 服务是指构成 Azure 云产品/服务的应用程序和服务，可在次要区域内进行部署。
- 此步骤是恢复数据平台的先决条件。
- 此步骤将由Microsoft和其他平台即服务（PaaS）/软件即服务（SaaS）合作伙伴完成。
恢复数据平台基础
- 此步骤是平台恢复活动的入口点。
- 对于重新部署策略，将采购每个必需的组件/服务并将其部署到次要区域。
- 此过程还应包括与企业共享服务的绑定、确保访问/身份验证的连接以及验证日志卸载是否正常工作的活动，同时确保与上游和下游进程建立连接。
- 应确认数据/处理。 例如，验证已恢复平台的时间戳。
- 如果存在有关数据完整性的问题，可以在执行新处理之前做出进一步回退以使平台保持最新状态的决定。
- 对流程（基于业务影响）的优先顺序有助于协调恢复。
- 除非业务用户直接与服务交互，否则应通过技术验证完成此步骤。 如果有直接访问权限，则需要执行业务验证步骤。
- 完成验证后，将移交给各个解决方案团队，开始自己的灾难恢复（DR）恢复过程。
- 此移交应包括确认数据和进程的当前时间戳。
- 如果要执行核心企业数据进程，则应注意各个解决方案 - 例如入站/出站流。
恢复平台托管的各个解决方案
- 每个解决方案都应有自己的 DR Runbook。 Runbook 应至少包含提名的业务利益干系人，他们将测试和确认服务恢复已完成。
- 例如，根据资源争用或优先级，关键解决方案/工作负载可能优先于其他解决方案/工作负荷 - 核心企业流程（例如，临时实验室）。
- 完成验证步骤后，将移交下游解决方案以启动其 DR 恢复过程。
移交给下游依赖系统
- 恢复依赖服务后，E2E DR 恢复过程将完成。
注意
虽然从理论上讲，可以完全自动化 E2E DR 过程，但不太可能考虑到事件的风险与涵盖 E2E 过程所需的 SDLC 活动成本。
回退到主要区域 - 回退是将数据平台服务及其数据在其可用于 BAU 后移回主区域的过程。
根据源系统和各种数据过程的性质，数据平台的回退可以独立于数据生态系统的其他部分进行。
建议客户查看自己的数据平台依赖项（包括上游和下游），以做出适当的决定。 以下部分假定独立恢复数据平台。
- 在主要区域中提供所有必需的组件/服务后，客户将完成冒烟测试以验证Microsoft恢复。
- 将验证组件/服务配置。 增量将通过从源代码管理重新部署来解决。
- 主要区域中的系统日期将跨有状态组件建立。 应通过重新执行或重播来自该点的数据引入过程来解决次要区域中已建立的日期/时间戳之间的增量。
- 获得业务和技术利益干系人批准后，将选择回退窗口。 理想情况下，这应在系统活动和处理过程中发生。
- 在回退期间，主要区域将在系统切换之前与次要区域同步。
- 在并行运行一段时间后，次要区域将从系统脱机。
- 次要区域中的组件将被删除或剥离，具体取决于选择的 DR 策略。
暖备用进程
对于“暖备份”策略，高级过程流与“发生灾难时重新部署”的过程流密切相关，主要区别在于已在次要区域中采购组件。 此策略消除了其他组织在该区域完成自己的 DR 时发生资源争用的风险。
热备用进程
“热备份”策略意味着，尽管发生灾难事件，平台服务（包括 PaaS 和基础结构即服务 (IaaS) 系统）仍会持续存在，因为辅助系统与主要系统一起运行。 借助“暖备用”策略，此策略消除了其他组织希望在该区域完成自己的 DR 时发生资源争用的风险。
热备份客户将监视 Microsoft 在主要区域中对组件/服务的恢复。 完成后，客户将验证主要区域系统并完成向主要区域的回退。 此过程类似于 DR 故障转移过程，即检查可用的代码库和数据，并根据需要重新部署。
注意
这里应特别注意，要确保两个区域之间的任何系统元数据保持一致。
- 完成向主区域的回退后，就可以更新系统负载均衡器，使主要区域重新进入系统拓扑。 如果可以，可以使用 Canary 发布方法以增量方式为系统打开主要区域。
DR 计划结构
有效的 DR 计划提供了可由 Azure 技术资源执行的服务恢复分步指南。 因此，下面列出了 DR 计划的建议 MVP 结构。
- 流程要求
- 任何特定于客户 DR 流程的详细信息（例如启动 DR 所需的正确授权），并根据需要（包括“已完成的定义”），服务支持 DR 票证参考和战室详细信息做出有关恢复的关键决策。
- 资源确认，包括 DR 负责人和执行人的备份。 所有资源都应记录有主要和次要联系人、升级路径和休假日历。 在严重 DR 情况下，可能需要考虑名单系统。
- 适用于 DR 执行程序、DR 备份和任何升级点的笔记本电脑、电源包或备份电源、网络连接和移动电话详细信息。
- 如果未满足任何流程要求，则遵循该过程。
- 联系人列表
- DR 领导和支持组。
- 将完成技术恢复的测试/审查周期的企业中小企业。
- 受影响的业务所有者，包括服务恢复审批者。
- 受影响的技术所有者，包括技术恢复审批者。
- 所有受影响领域的 SME 支持，包括平台托管的关键解决方案。
- 受影响的下游系统 - 操作支持。
- 上游源系统 - 操作支持。
- 企业共享服务联系人。 例如，访问和身份验证支持、安全监视和网关支持
- 任何外部或第三方供应商，包括云提供商的支持联系人。
- 体系结构设计
- 描述端到端（E2E）方案详细信息，并附加所有相关支持文档。
- 依赖项
- 列出所有组件的关系和依赖项。
- DR 先决条件
- 确认上游源系统根据需要可用。
- 已向 DR 执行程序资源授予跨堆栈的提升访问权限。
- Azure 服务可根据需要使用。
- 如果尚未满足任何先决条件，则遵循该过程。
- 技术恢复 - 分步说明
- 运行顺序。
- 步骤说明。
- 步骤先决条件。
- 每个离散操作的详细过程步骤，包括 URL。
- 验证说明，包括所需的证据。
- 完成每个步骤的预期时间，包括应变。
- 如果步骤失败，则要遵循的过程。
- 故障或 SME 支持时的升级点。
- 技术恢复 - 先决条件
- 跨关键组件确认系统的当前日期时间戳。
- 确认 DR 系统 URL 和 IP。
- 准备业务利益干系人评审过程，包括确认系统访问以及完成验证和审批的业务中小企业。
- 业务利益干系人评审和批准
- 业务资源联系人详细信息。
- 根据上述技术恢复执行业务验证步骤。
- 业务审批者签署恢复所需的证据线索。
- 恢复后先决条件
- 移交运营支持以执行数据进程以使系统更新。
- 移交下游流程和解决方案 - 确认 DR 系统的日期和连接详细信息。
- 使用 DR 潜在顾客确认恢复过程完成 – 确认证据线索和已完成 Runbook。
- 通知安全团队，可以从 DR 团队中删除提升的访问特权。
标注
- 建议包含每个步骤过程的系统屏幕截图。 这些屏幕截图有助于解决系统 SM 的依赖项以完成任务。
- 若要跟上快速发展的云服务，应定期重新访问、测试 DR 计划，并通过 Azure 及其服务的当前知识的资源执行。
- 技术恢复步骤应反映组件和解决方案对组织的优先级。 例如，核心企业数据流在临时数据分析实验室之前恢复。
- 一旦恢复基础组件或服务（例如密钥库）恢复，技术恢复步骤应遵循工作流的顺序（通常从左到右）。 此策略将确保上游依赖项可用，并且可以适当测试组件。
- 完成分步计划后，应获取有应变时间的活动的总时间。 如果总时间超过商定的恢复时间目标 (RTO)，则有几个选项可用：
- 自动执行选定的恢复过程（尽可能）。
- 寻找并行运行所选恢复步骤的机会（尽可能） 但是，请注意，此策略可能需要额外的 DR 执行人资源。
- 将关键组件提升到更高级别的服务层级，例如 PaaS，其中Microsoft对服务恢复活动承担更大的责任。
- 使用利益干系人扩展 RTO。
DR 测试
Azure 云服务产品的性质会导致任何 DR 测试方案受到限制。 因此，指导原则是使用数据平台组件支持 DR 订阅，因为它们将在次要区域中提供。
根据此基线，可以有选择地执行 DR 计划 Runbook，特别注意可部署和验证的服务和组件。 此过程需要一个特选的测试数据集，以便根据计划确认技术和业务验证检查。
应定期测试 DR 计划，不仅要确保它是最新的，还要为执行故障转移和恢复活动的团队建立“肌肉记忆”。
- 还应定期测试数据和配置备份，以确保其“适用”，能够支持任何恢复活动。
在 DR 测试期间，需要关注的关键领域是确保规定的步骤仍然正确，并且估计的计时仍然相关。
- 如果说明反映的是门户屏幕而不是代码，则应根据云中的更改节奏至少每 12 个月验证一次说明。
虽然希望实现完全自动化的 DR 过程，但由于事件的罕见性，不太可能实现完全自动化。 因此，建议使用用于交付平台的所需状态配置 (DSC) 基础结构即代码 (IaC) 建立恢复基线，然后随着新项目基于基线构建而提升。
- 随着组件和服务的扩展，应强制实施 NFR，要求重构生产部署管道以提供 DR 的覆盖。
如果 Runbook 计时超过 RTO，有以下几种选项：
- 使用利益干系人扩展 RTO。
- 通过自动化、并行运行任务或迁移到更高的云服务器层来降低恢复活动所需的时间。
Azure Chaos Studio
Azure Chaos Studio 是一个托管服务，可以通过将故障注入 Azure 应用程序来提高复原能力。 Chaos Studio 使你能够使用实验，以安全且受控的方式在 Azure 资源上编排故障注入。 有关当前支持的故障类型的说明，请参阅产品文档。
Chaos Studio 的当前迭代仅覆盖 Azure 组件和服务的子集。 在添加更多故障库之前，建议使用 Chaos Studio 进行隔离复原测试，而不是进行完整的系统 DR 测试。
有关 Chaos Studio 的详细信息，请参阅 Azure Chaos Studio 文档。
Azure Site Recovery
对于 IaaS 组件，Azure Site Recovery 将保护在受支持的 VM 或物理服务器上运行的大多数工作负载
针对以下方面提供强有力的指导：
相关资源
后续步骤
了解如何部署方案后，可以阅读适用于 Azure 数据平台的 DR 系列的 摘要。