Azure 服务中断期间要执行的操作
Microsoft 的同仁兢兢业业，只为确保在任何时候都能提供需要的服务。 然而，确实会发生计划外的服务中断。 本文介绍了发生计划外的服务中断时会发生什么情况。
Azure 为其多个服务提供服务级别协议 (SLA)，作为运行时间和连接承诺。 可以在 Azure 服务级别协议中找到各种 Azure 服务的 SLA。
发生事件时，如果了解该事件的范围，就可以确定最佳的操作过程。
若要了解事件的范围，请执行以下步骤：
转到 Azure 服务运行状况，其提供：
有关可能影响服务的问题或事件的信息。
自动事件更新警报，以便可以自动收到任何事件状态更新的通知。 当 Azure 了解事件的范围时，我们将更新事件状态。 可以将这些状态更新配置为转到 Azure Monitor 操作组，该操作组可将警报发送到电子邮件地址或你自己的事件管理系统等各种位置。
如果访问 Azure 门户时遇到问题，请转到 Azure 状态。
许多问题仅限于单个可用性区域。 可用性区域表示与同一区域中其他可用性区域隔离的数据中心或数据中心组。 当某可用性区域遇到问题时，你看到的影响取决于服务的部署方式：
- 固定到受影响的可用性区域的局部区域服务可能会受到影响。
- 区域冗余服务不太可能受到影响。 无需对区域冗余资源执行任何修正操作。
- 区域（非局部区域）服务可能会受到影响，因为它们可能会使用受影响的可用性区域。
若要详细了解 Azure 服务中的可用性区域支持以及局部区域、区域冗余和区域（非局部区域）服务之间的差异，请参阅包含可用性区域支持的 Azure 服务。
如果对受影响可用性区域中部署的局部区域或区域资源有任何顾虑，请考虑启动业务连续性和灾难恢复 (BC/DR) 计划。
每个 Azure 订阅都会看到不同的可用性区域列表。 每个订阅使用的逻辑区域可能与不同的物理区域对应。 可以在逻辑区域和物理区域之间映射，以确认哪些资源在受影响的物理可用性区域中运行。 有关详细信息，请参阅物理和逻辑可用性区域。
有时，问题会影响整个区域。 当某个区域没有可用性区域时，可能会出现区域范围的问题。 发生区域范围的事件时，可能需要考虑启动灾难恢复计划。 计划可能包括故障转移到另一个区域。
当遇到事件时，首要任务是保持业务正常运转。 过于注重隔离或修复问题原因可能会分散你对恢复解决方案运作和维持业务连续性的注意力。
根据以下因素，你不一定需要执行任何操作来保持业务连续性：
问题对生产资源以及用户或工作负载的实际影响。 例如，在标准营业时间之外发生的问题可能不需要你立即执行任何操作。
事件的范围。 对于隔离到单个可用性区域的问题，如果使用的是区域冗余资源，或者所使用的资源位于不受影响的物理可用性区域中，则无需执行任何操作。
估计的解决时间（如果可用）。 Azure 努力尽快提供明确的恢复时间表。 如果恢复过程运行需要很长时间，请考虑问题是否会在该过程完成时得到解决。
与受影响的工作负载的用户（如果有）共同制定的服务级别目标 (SLO)。 在这种情况下，SLO 可以指导决策。 例如，在某些情况下，你或许能够切换到手动操作，直到服务正常运行，并且此决定可能会反映在系统的 SLO 中。 若要详细了解 SLO 以及如何定义它们，请参阅 Azure 架构良好的框架中的定义可靠性目标的建议。
但是，如果业务连续性需要某种形式的操作，并且你已确实制定了灾难恢复计划，则下一步是考虑是否启动该计划。
灾难恢复计划说明了在发生重大事件时预期执行的操作。 灾难恢复计划通常包括如下操作：
- 对于可用性区域中的隔离中断，如果可以，则横向扩展资源。
- 对于使用区域性服务时的可用性区域中断，请部署到另一个可用性区域并故障转移到另一个可用性区域。
- 对于使用区域冗余服务时的可用性区域中断，可能不需要执行任何操作。 如果观察到性能问题，请考虑横向扩展资源，以便剩余区域中的实例可以处理其收到的流量涌入。
- 对于区域性中断，请部署到另一个区域并进行故障转移。
重要
不要未经深思熟虑就采取任何行动。 仓促做出的决定有时会让事情变得更糟。 如果已经制定了涵盖该应用场景的灾难恢复计划，通常最好使用它而不是立即制定计划。
故障转移可能是一个复杂的过程。 仅当可以证明成本和风险合理时，才应触发故障转移。 在某些情况下，它可能会导致数据丢失，例如如果在任何故障时间开始之前未在区域之间复制最近更改。 还可能会遇到故障时间，尤其是在需要将流量重定向到不同区域中的部署时。 根据解决方案的设计方式，可能需要更新 DNS 记录并等待它们传播。
某些 Azure 服务在事件期间会自动故障转移到备用区域。 Azure 管理这些服务的故障转移过程。 但是，Microsoft 启动的故障转移通常是作为最后手段并且在花费了大量时间进行恢复尝试之后才执行的。 通常，Azure 的策略是尽量减少数据丢失，即使这意味着恢复时间更长。 对于你自己的解决方案，不应仅依赖 Microsoft 启动的故障转移，尤其是在需要最大程度地减少恢复时间时。 如果可以，请对 Azure 存储等服务使用客户启动的故障转移。
如果服务事件已在 Azure 服务运行状况中传达，则所有最新信息都会在此处提供，无需创建支持请求。
但是，在以下情况下，可以考虑创建支持案例：
看到 Azure 服务运行状况事件说明中未涵盖的问题。
在恢复过程中需要 Azure 的帮助。
提示
如果受到服务中断的影响，则可以在问题缓解后最多 72 小时内提交免费支持票证，以协助你执行恢复所需的任何步骤。
在创建支持案例时，请清楚地说明受影响的资源以及问题的影响。 指定 Azure 订阅 ID 和遇到问题的区域。 根据对业务的影响设置支持案例的严重性。 请注意，在上述条件之外的 Azure 服务中断期间，许多客户可能会主动联系 Azure 支持人员。 不幸的是，这会额外增加 Azure 支持资源的负担，从而可能会延迟满足你的支持需求。
若要了解 Azure 从该事件中学到的内容，请从 Azure 服务运行状况的“运行状况历史记录”窗格或通过客户配置的服务运行状况警报了解事后回顾 (PIR)。 不同的事件可能会获得不同类型的 PIR。 初步 PIR 通常在事件发生后的几天内发布，而更全面的 PIR 将在几周后发布。
对于我们的公共状态页上列出的重大事件，请加入 Azure 事件回顾直播以解答任何问题，或观看录制内容。
如果认为你可能有资格获得 SLA 额度，请创建问题类型为“退款请求”的新支持请求，并包括事件跟踪 ID。
考虑你从该事件中学到的内容以提高自己的复原能力和流程。 考虑以下类似问题：
灾难恢复计划的效果如何？ 是否可以做出任何改进？ 有关详细信息，请参阅有关灾难恢复策略的 Azure 架构良好的框架指导。
你对事件的响应是否与其严重性相称？ 如果不相称，你是否有办法可以更好地了解情况并就采取的措施做出更好的决定？
你使用的服务是否有 Azure 服务可靠性指南？ 可靠性指南提供有关可配置多少 Azure 服务来满足复原能力要求的信息。
是否有一种设计权衡来在未来提高此类问题的复原能力？ 有关详细信息，请参阅 Azure 架构良好的框架的可靠性支柱。
如果遇到此计划外中断，为用户提供的 SLO 或 SLA 是否仍然合适？ 现在应重新审视你对用户群做出的承诺，以使期望与你从此事件中学到的内容保持一致。
是否应该配置 Azure 服务运行状况警报，以便自动接收未来任何事件的通知？
如果有有关如何改进事件响应的反馈，请联系为你分配的 Azure 代表或通过 Azure 反馈站点告知我们。