你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 可靠性文档

项目
10/25/2023

可靠性包含两个原则：复原能力和可用性。复原能力的目标是避免出现故障，如果故障仍然发生，则将应用程序恢复到可完全正常运行的状态。可用性的目标是提供对应用程序或工作负载的一致访问。请务必根据应用程序要求规划主动可靠性。

Azure 包括内置可靠性服务，你可以根据业务需求使用和管理这些服务。无论是单硬件节点故障、机架级故障、数据中心中断还是大规模区域性中断，Azure 都提供了提高可靠性的解决方案。例如，可用性集确保 Azure 上部署的虚拟机分布跨群集中的多个隔离硬件节点。可用性区域可保护客户的应用程序和数据，避免数据中心跨一个区域中的多个物理位置发生故障。区域和可用性区域是应用程序设计和复原能力策略的核心，本文稍后将进行更详细的讨论。

Azure 可靠性文档提供了 Azure 服务的可靠性指南。本指南包括有关可用性区域支持、灾难恢复指南和服务可用性的信息。

有关特定于服务的详细可靠性指南（包括可用性区域、灾难恢复或高可用性），请参阅特定于 Azure 服务的可靠性指南概述。

有关 Microsoft Azure 服务中的可靠性和可靠性原则和体系结构的信息，请参阅 Microsoft Azure 架构良好的框架：可靠性。

可靠性要求

任何 Azure 解决方案所需的可靠性级别都取决于几个注意事项。可用性和延迟 SLA 和其他业务要求推动了体系结构选择和复原能力级别，应首先考虑。可用性要求的范围从可接受停机时间（以及业务成本）到实际投入的使应用程序高度可用的资金和时间。

在 Azure 上构建可靠性系统是一项共担责任。 Microsoft 负责提供云平台（包括其全球网络和数据中心）的可靠性。 Azure 客户和合作伙伴负责根据每个工作负载的要求，使用体系结构最佳做法来构建其云应用程序的复原能力。虽然 Azure 持续致力于为云平台在 SLA 中实现最高复原能力，但你必须在解决方案中为每个工作负载定义你自己的目标 SLA。通过 SLA 可以评估体系结构是否满足业务要求。随着你努力提高 SLA 保证的运行时间的百分比，实现该可用性级别的成本和复杂性也会增加。 99.99% 运行时间相当于每月的总停机时间大约为 5 分钟。为了达到该比例而提高复杂性和成本是否值得？答案取决于单个业务要求。在决定最终 SLA 承诺时，请了解 Microsoft 支持的 SLA。每项 Azure 服务都有自己的 SLA。

Diagram showing the shared responsibility model for Azure business continuity.

在传统的本地模型中，你需负责整个管理工作，范围包括有关计算、存储和网络方面的硬件以及应用程序等。你必须规划各种类型的故障，以及如何通过创建灾难恢复策略来处理故障。借助 IaaS，云服务提供商负责核心基础结构复原能力，包括存储、网络和计算。从 IaaS 迁移到 PaaS，然后再迁移到 SaaS 后，你会发现你负责的工作会更少，而云服务提供商负责的工作会更多。  

有关可靠性原则的详细信息，请参阅架构良好的框架可靠性文档。  

构建可靠性

应在规划开始时定义应用程序的可靠性要求。如果知道哪些应用程序在某些时间段内不需要 100% 的高可用性，那么就可以在这些非关键时间段内优化成本。确定应用程序可能经历的故障类型以及每个故障的潜在影响。恢复计划应涵盖所有关键服务，具体方法为在单个组件和整个应用程序级别最终确定恢复策略。设计恢复策略，防范局部区域、区域性和应用程序级故障。测试端到端应用程序环境，以衡量应用程序可靠性和针对意外故障的恢复。

以下清单涵盖了可靠性规划的范围。

可靠性规划
定义可用性和恢复目标以满足业务要求。
根据可用性要求设计应用程序的可靠性功能。
对齐应用程序和数据平台，以满足可靠性要求。
配置连接路径以提升可用性。
使用可用性区域和灾难恢复规划（如果适用）来提高可靠性并优化成本。
确保应用程序体系结构能抵御故障。
了解如果不满足 SLA 要求会发生的情况。
识别系统中可能的故障点；应用程序设计应该通过部署断路来容许依赖项故障。
构建在无依赖项情况下运行的应用程序。

RTO 和 RPO

要考虑的两个重要指标是恢复时间目标和恢复点目标，因为它们与灾难恢复有关。  有关功能性和非功能性设计要求的详细信息，请参阅架构良好的框架功能和非功能要求。

恢复时间目标 (RTO) 是指发生某个事件后，可接受应用程序不可用的最长时间。
恢复点目标 (RPO) 是指发生灾难期间，可接受数据丢失的最大持续时间。

RTO 和 RPO 是系统的非功能性要求，应符合业务要求。若要派生这些值，最好是进行风险评估，清楚地了解停机或数据丢失造成的后果。  

区域和可用性区域

区域和可用性区域是可靠性公式的重要组成部分。区域具有多个物理上独立的可用性区域。这些可用性区域通过高性能网络连接，物理区域之间的延迟少于 2 毫秒。低延迟有助于在出现故障时保持数据同步且可访问。在构建应用程序和数据基础结构时，可以战略性地使用此基础结构，以在区域之间和跨区域自动复制和交付不间断的服务。

Microsoft Azure 服务支持可用性区域，并能够以最佳高可用性推动云操作，同时支持跨区域恢复和业务连续性策略需求。

对于灾难恢复规划，与其他区域配对的区域提供跨区域复制，并通过跨其他 Azure 区域异步复制数据来提供保护。没有配对的区域遵循数据驻留准则并提供可用性区域和本地冗余或区域冗余存储的高可用性。客户需要根据 RTO/RPO 需求规划跨区域灾难恢复。

可根据服务功能、数据驻留、合规性要求和延迟等技术和监管方面的注意事项选择最符合需求的区域，并开始推进可靠性策略。有关详细信息，请参阅 Azure 区域和可用性区域。

Azure 服务依赖关系

Microsoft Azure 服务遍布全球各地，可推动云操作实现最佳水平。

部署到 Azure 区域的 Azure 服务列在 Azure 全球基础结构产品页上。若要更好地了解 Azure 中的区域和可用性区域，请参阅 Azure 中的区域和可用性区域。

Azure 服务专为可靠性（包括高可用性和灾难恢复）而构建。没有依赖于单个逻辑数据中心的服务（以避免单一故障点）。 Azure 全球基础结构产品上列出的非区域性服务是不依赖于特定 Azure 区域的服务。非区域服务将部署到两个或多个区域，如果出现区域性故障，另一个区域中的服务实例将继续为客户提供服务。某些非区域性服务使客户能够指定将在其上部署服务运行的基础虚拟机 (VM) 的区域。例如，Azure 虚拟桌面使客户能够指定 VM 所在的区域位置。用于存储客户数据的所有 Azure 服务都使客户能够指定其数据将存储到的特定区域。 Microsoft Entra ID 例外，它包含异地位置（如欧洲或北美）。有关数据存储驻留的详细信息，请参阅数据驻留地图。

如果需要了解 Azure 服务之间的依赖关系以帮助更好地构建应用程序和服务，可以通过联系 Microsoft 销售或客户代表来请求“Azure 服务依赖项文档”。本文档列出了 Azure 服务的依赖项，包括对任何常见主要内部服务（如控制平面服务）的依赖项。若要获取此文档，必须是 Microsoft 客户，并与 Microsoft 签订了相应的保密协议 (NDA)。

通过