Built to bounce back: How Azure resiliency evolved

云环境中的弹性通常用可用性来描述，例如系统切换故障的速度、副本数量或服务等级协议的保证。但对当今大多数组织而言，尤其是那些在受监管、主权或地缘政治敏感环境中运营的组织，弹性是更基础的能力。它意味着在压力下持续运行、保护最关键的内容，并在意外发生时安全恢复。

一个有用的思考方式不是从系统层面，而是从城市层面来看。现代城市不依赖单一电源、单一道路或单一控制系统。它被设计为能够抵御各种中断，无论是基础设施故障、自然灾害还是安全事件。它具备冗余性——但更重要的是——它具备反映本地实际情况的治理、控制和恢复机制。云弹性的运作方式与此类似。它不仅关乎避免停机，更关乎确保系统能够在现实约束条件下适应、恢复并持续运行。

在Azure上，弹性不是微软交付给客户的能力，而是微软与客户共同构建的能力。平台提供深度弹性的基础设施和日益智能化的功能，但只有当这些能力被有意设计、与主权约束对齐，并持续针对现实条件进行验证时，弹性成果才会显现。去年，我们解释了Azure如何通过三个相互关联的支柱实现弹性：基础设施弹性、数据弹性和网络恢复。

• 基础设施弹性：确保应用在故障条件下保持可用。
• 数据弹性：确保数据受到保护、持久化且可恢复。
• 网络恢复：确保组织能够从被入侵的状态中安全恢复。

这些支柱共同确保系统不仅保持可用性，更在故障模式不可预测时依然保持可恢复性和可信性。这些支柱通过生命周期方法实现，帮助组织设计、改进并持续验证其弹性态势。

Azure的独特之处在于这些要素如何协同作用。Azure不仅提供弹性基础设施，更提供一个统一的方法，涵盖平台能力、可观测性、验证和智能修复，使组织能够从设计弹性转向持续运行和改进弹性。

在任何城市中，基础设施提供商确保道路、公用事业和基础系统可靠。但建筑物的设计方式、应急计划的执行方式以及关键服务的保护方式，这些始终是城市及其运营者的责任。

Azure 的共享责任模型遵循相同原则。微软负责提供一个具备弹性的云平台基础，包括区域、物理数据中心、网络、隔离边界以及能够减少爆炸半径并实现大规模持久性的工程系统。这包括可用性区域（Availability Zones）、区域隔离以及[Azure 备份](https://azure.microsoft.com/en-us/products/backup)和 [Azure 网站恢复](https://azure.microsoft.com/en-us/products/site-recovery) 等功能。客户则基于 Azure 提供的体验，配置合适的功能以实现预期的弹性目标。这包括应用程序架构设计、依赖项管理、恢复目标定义，以及备份和灾难恢复的配置与测试。在主权和受监管的环境中，这一责任变得更加关键，客户需要明确指定数据存储位置、数据传输方式，以及恢复如何符合合规性和司法管辖要求。

反映现实的平台基础：区域、区域划分与主权

现代 Azure 弹性 从以区域优先的设计方法开始，应用程序需具备容忍整个可用性区域失效的能力。这显著降低了本地化基础设施故障影响应用程序可用性的可能性。

然而，弹性并不仅限于区域。区域本身并非完全统一，假设区域统一性是导致设计脆弱性的最常见原因。

• 某些 Azure 区域是成对配置的，预定义的恢复区域与灾难恢复目标对齐。
• 其他区域是非成对配置的，通常由于主权、监管或地理限制。

这一区别从根本上塑造了弹性架构。

• 成对区域场景（可预测的恢复）： Azure 提供从本地冗余存储（LRS）到区域冗余（ZRS）和地理冗余存储（GRS）的持久性选项光谱，使客户能够根据可用性、合规性和数据主权需求对齐数据保护策略。例如，部署在西欧的金融服务应用可以利用其配对区域（北欧）进行灾难恢复。通过 Azure 网站恢复（ASR），工作负载会持续复制并编排，以在区域中断时实现应用级别的连续性。
• 预定义的区域配对提供了可预测的故障转移行为，以及明确的恢复点目标（RPO）和恢复时间目标（RTO）权衡。然而，现代 Azure 弹性指导原则已超越对区域配对的严格依赖。如 Mark Russinovich 的《现代 Azure 弹性》 博客所述，客户越来越多地采用灵活的多区域架构，包括基于服务可用性、容量、延迟和数据驻留需求等因素的非配对区域策略。这些模式强调灾难恢复不再局限于预定义配对，而是根据工作负载特定需求进行设计选择。

在这些场景中，Azure Site Recovery 通过在任意选定区域（无论是否为配对区域）提供一致且应用感知的复制和故障转移编排，发挥着关键作用。这使客户能够标准化其恢复策略，同时保留灵活性以满足不断变化的业务、监管和规模需求。

• 非配对区域场景（主权约束）：政府工作负载运行在没有预定义配对的主权区域。跨区域恢复受到限制。架构优先考虑区域内的高可用性，并通过备份到指定区域实现基于恢复的恢复，确保数据始终位于司法管辖范围内。恢复速度较慢，但完全合规。
• 非对称恢复场景（受监管企业）：跨国企业在受限制的地理区域部署，仅允许部分数据离开该区域。例如，Azure Site Recovery 可实现关键服务的故障转移，而敏感数据则依赖 Azure Backup 实现区域内恢复。结果是一个有意设计的非对称弹性模型，在合规性与业务连续性之间取得平衡。

这标志着从一刀切的架构转向以工作负载驱动的弹性设计，其中恢复策略有意与业务、监管和运营约束保持一致。

Azure 的功能和能力增强弹性结果

Azure 中的 弹性解决方案 并非由单一服务提供，而是通过 一系列功能和服务 实现。这些功能协同工作，确保应用保持可用、数据受到保护，并且即使在基础设施故障、区域中断或网络攻击的情况下系统也能恢复。它从 区域弹性基础架构 开始，减少对局部故障的暴露，然后通过 自动扩展、负载均衡和健康感知流量管理 保持应用在压力下的响应能力。

对于更广泛的基础设施或区域中断，Azure Site Recovery 通过复制和故障转移编排实现业务连续性。同样重要的是，Azure Backup 通过启用恢复到可信时间点来应对不同类别的风险（如数据损坏、意外删除、合规保留和网络攻击），当故障转移不足以解决问题时提供保障。这些功能在与 强大的可观测性和易于重新水合的设计 配合使用时效果最佳，系统能够早期检测问题、自动恢复并快速重建。结果是对弹性的更全面理解：不仅仅是保持运行时间，更是在现实世界故障条件下维持信任和可恢复性。

通过 Azure 上的体验将意图与执行连接起来

客户虽然拥有各种工具，但缺乏统一的衡量和提升其弹性态势的方法。在 Microsoft Build 2026 上发布并公开预览的 **Azure 基础设施弹性管理器** 解决了这一挑战。它提供了一种以应用为中心和资源为中心的弹性视图，将 Azure 弹性、Azure 顾问、Azure 混沌工作室 和 Azure 监视器 集成到统一的体验中。

关键的起点是 区域弹性态势。它帮助客户了解其工作负载是否真正具备区域弹性，识别隐藏的依赖关系，并发现预期架构与实际部署之间的差距。

它引入了一种生命周期的弹性方法：

• 从弹性起步：以正确的基础态势设计工作负载。
• 实现弹性：识别并弥补现有系统中的差距。
• 持续保持弹性：通过演练和监控持续验证和改进。

Azure 基础设施弹性管理器的核心是 [弹性代理](https://learn.microsoft.com/en-us/azure/copilot/resiliency-agent)，它将智能和自动化引入生命周期。该代理从整体角度评估工作负载，识别风险，揭示配置错误，并解释成本、可用性和合规性之间的权衡。但它的作用不仅限于分析。这标志着从被动指导向主动且日益自主的弹性管理的转变。

除了指导修复措施外，弹性代理还可以生成 基础设施即代码（Infrastructure-as-Code, IaC）模板，使团队能够直接在部署流程中实施推荐的更改。这是一个根本性的转变：弹性从建议性转变为可执行性。它被嵌入到 DevOps 工作流程中，实现标准化、可重复且一致的应用。

此外，通过 Azure 备份 MCP 服务器，这些功能变得可编程。组织可以将备份态势验证、恢复准备检查和基于策略的恢复工作流程集成到自动化系统中，同时在主权边界内保持完全控制。

如何在 Azure 上构建弹性

在 Azure 上，这一演进反映了从预定义结构向有意设计的架构转变，从碎片化工具向统一体验转变，以及从指导向执行的转变。随着组织面临日益复杂的环境、监管限制和不可预测的故障模式，前进的道路已经明确：将弹性构建到基础架构中，持续验证，并尽可能实现自动化。借助 Azure 的平台能力、以应用为中心的体验和智能代理，弹性不仅可实现，而且可以操作化，从而自信地交付服务。

通过 Azure Essentials 开始，您可以在应用程序和基础设施上获得统一的弹性体验。Azure Essentials、Microsoft Unified 和 Azure Accelerate 帮助组织从弹性设计过渡到整个生命周期中每个阶段的操作执行。

• 宣布Azure基础设施弹性管理器公开预览版
• 弹性文档
• 与Mark Russinovich一起探讨现代Azure弹性
• Azure服务可靠性指南
• 云弹性
• 使用Chaos Studio在Azure上验证应用程序弹性