Azure Reliability、Resiliency 与 Recoverability 设计指南

Introduction: why this matters

在许多事故复盘中，团队会发现自己优化错了方向——例如在应用真正需要更好的故障隔离时，却把大量投入放在 disaster recovery runbook；或误以为“冗余”的基础架构就能自动带来可靠的用户体验。Microsoft 的最新指导在 Azure 中清晰划分 reliability、resiliency 与 recoverability，并说明如何通过设计来构建连续性，而不是依赖假设。

Key concepts (and the anchor principle)

Microsoft 将它们定义为彼此不同但互补的概念：

• Reliability：服务/工作负载在已定义的业务约束内，以预期服务水平持续运行的程度。这是客户最终感知到的目标。
• Resiliency：在发生故障与中断（可用区/区域级故障、基础设施故障、网络攻击、负载激增）时，能够承受冲击并持续运行，且不对客户产生可见影响的能力。
• Recoverability：当中断超出 resiliency 的设计上限后，能够恢复正常运行的能力。

Anchor principle: Reliability 是目标。Resiliency 让你在中断期间保持运行。Recoverability 在中断超出设计上限时恢复服务。

What’s new / what Microsoft is emphasizing

1) Align operating model with architecture

文章将组织层面的意图与技术设计连接起来：

• Microsoft Cloud Adoption Framework (CAF) 用于定义治理、责任划分与连续性期望。
• Azure Well-Architected Framework (WAF) 将这些期望落地为架构模式与权衡取舍。

2) Make reliability measurable and operational

reliability 只有在你能够持续证明它时才有意义：

• 为关键用户路径定义可接受的服务水平。
• 使用 Azure Monitor 与 Application Insights 对稳态与客户体验进行监测与度量。
• 通过可控的故障测试验证假设（例如 Azure Chaos Studio）。
• 使用 Azure Policy、Azure landing zones 与 Azure Verified Modules 扩展治理能力。
• 使用 Reliability Maturity Model 评估 reliability 实践的一致性与成熟度。

3) Treat resiliency as a lifecycle (not a checklist)

resiliency 被定位为持续性的实践，而非一次性清单：

• Start resilient（设计阶段的模式、secure-by-default 配置、平台防护）
• Get resilient（评估现有应用、聚焦任务关键工作负载、补齐差距）
• Stay resilient（监控、识别漂移，并持续验证）

4) Shift to application-centric resiliency posture

Microsoft 强调，用户感知到的是应用不可用，而不是 VM/磁盘事件。Azure 的 zone resiliency experience 支持将资源按逻辑应用服务组进行分组，评估风险、跟踪漂移，并在可见成本的前提下提供修复指引。

Impact for IT administrators and platform teams

• 更清晰的 shared responsibility 边界：通过 Azure Reliability 指南，服务的内建行为与需要你自行配置的内容会更明确。
• 更好的设计决策：可区分何时应投资于可用区/多区域设计（resiliency），以及何时应侧重备份/故障切换流程（recoverability）。
• 更强的事故准备度：可度量的 SLO、可观测性与混沌演练可减少真实故障期间的“未知的未知”。

Action items / next steps

1. 在团队间统一术语（reliability vs. resiliency vs. recoverability），并相应更新架构标准。
2. 针对你运行的每项核心服务，审阅 Azure Reliability guides，确认故障行为与配置要求。
3. 基于故障域与业务影响，将工作负载映射到 zonal、zone-resilient 或 multi-region 模式。
4. 落地 SLOs + monitoring（Azure Monitor / App Insights），并安排 fault injection drills（Chaos Studio）。
5. 使用 Policy / landing zones 防止配置漂移，并在规模化场景下标准化 resiliency 控制。