Your architecture diagram is not your resilience

_本系列文章的第一篇基于与Mark Russinovich的对话，探讨AI时代弹性如何演变，以及如何在大规模场景下持续验证弹性。_

最令我惊讶的是弹性故障中"漂移"的普通性。工作负载部署在多个可用性区域，但健康探测仍指向单一依赖项。数据库支持故障转移，但应用程序的连接字符串固定在一个区域。看起来一切正常。架构图仍然显示弹性设计，而实际运行环境下的现实却在悄然改变。

多年来，弹性一直被视为一次性设置的事项：配置灾难恢复方案、编写操作手册、偶尔执行故障转移测试。这虽然能维持系统运行，但将弹性视为有明确结束日期的项目，而非需要持续维护的属性。

因此，当某个可用性区域或区域遭遇故障时，问题的关键不在于是否有书面的恢复计划。而在于今天的弹性是否依然成立，团队是否能够证明这一点。

导致工作负载失效的依赖项也在发生变化。在微软FY26第四季度财报电话会议上，Satya Nadella直言："无论出于何种原因，如果某个模型失效，您不能陷入困境。您必须能够继续进行网络作战。"

传统的灾难恢复规划假设关键依赖项是基础设施。但如今，这个关键依赖项越来越可能是AI模型、推理端点、检索流水线，或因容量限制而运行的服务。从基础设施角度看工作负载可能完全健康，但若该依赖项不可用、被限流或经济上难以运行，仍会导致用户请求失败。这种依赖项通常在架构图中根本不会出现。

在第一个变化之下还存在第二个转变。架构图假设由人类绘制并由人类阅读。这两个假设正在消失，它所描述的依赖项也不再完全确定。这改变了"了解您的环境是否具备弹性"的含义。

这是系列文章的第一篇，介绍我们如何帮助客户实现"内建弹性、随环境变化而测量、随时间持续改进"的弹性体系。我们之前曾讨论过如何设计弹性工作负载。现在的问题不同：如何确认数百个工作负载是否仍符合其设计，并能够证明这一点。这是我们当前路线图投资的重点领域。

**为什么弹性会发生漂移**

弹性始终是共同责任。我们提供可用性区域、可选的次要区域、支持弹性的复制原语，这些不会发生漂移。发生漂移的是责任的另一半：经过一年的变更后，某个工作负载是否仍按设计方式使用这些功能。变更正是问题集中之处。在全行业范围内，约70%的云服务中断都与变更有关——不是戏剧性的故障，而是那些未被重新评估影响范围的普通修改。

这就是为什么变更管理与设计同样重要。在内部，变更会首先在金丝雀区域推出，然后在试点区域推出，在进一步推进之前会设置烘焙时间以监控健康信号。这种实践源于我们自身的一次事件，它与Well-Architected Framework所描述的安全部署实践一致。

灾难恢复本质上是被动的。团队在项目上线时设定恢复目标，建立复制机制，然后继续推进，对工作负载变化后这些目标是否仍然适用缺乏持续的可见性。弹性设计一次后很少被重新审视。随着可用性区域和区域数量的增加，设计的弹性与实际存在的弹性之间的差距悄然扩大，通常只有在发生事件时才会显现。

_我们是通过艰难的方式学到这一点的。Mark讲述了那次差点导致Azure瘫痪的存储变更事件，以及它永久改变了我们的部署方式。_

**图表无法告诉你的事**

图表是对系统的一次性声明，由某人基于他们认为系统的样子进行推理后创建。它很有用，但它不是证据。它在结构上无法告诉你以下四点：

1. 当前目标是否正在实现。图表没有时间戳。健康建模则有：在Well-Architected Framework中已有描述，现在通过Azure Monitor的健康模型实现，它将应用程序表示为组件及其底层信号的层次结构，使健康状态以业务可识别的方式表达，而非资源级别的指标墙。结合服务级别指标，它能回答事件期间唯一重要的问题：这个应用程序现在是否满足其目标？重要的标准不是我们自己的。只有客户认为服务是健康的，服务才是健康的——我们可能认为它没问题，但如果客户看不到健康的服务，我们就存在问题。

1. “弹性”对这个应用程序意味着什么。在图表中，“弹性”是一个形容词。弹性目标将其转化为一个你必须达到或未达到的阈值，而以应用程序级别而非资源级别来定义它，使答案变得有意义。

1. 故障转移路径是否真的有效。每个图表都会画出箭头。只有测试才能证明它是否有效。

1. 那些无人绘制的资源。图表显示的是某人记得的内容。通过生成的基础设施即代码，可以覆盖应用程序中的所有资源。这两组之间的差异是漂移开始的地方——而且越来越多的读者是代理而非人类，它们根据你要求的结果而非你绘制的图片来工作。

我们就是这样运行Azure的。我们没有要求每个团队声明其服务的健康定义，而是标准化了服务级别指标，然后应用机器学习来分析观察到的行为，使“健康”由服务实际执行的操作定义，而非某人假设它应该执行的操作。

这正是我最感兴趣的部分。我们编写文档、模式和模板的初衷是为人服务。但如今越来越多地是智能体在读取这些内容，它们根据你设定的目标而非你描绘的图像进行工作，并自行生成所需资源。当作者和读者都成为机器时，图表甚至不再是决策的媒介。

_马克关于为何故意破坏自身服务、游戏日实际测试的内容以及为何模拟的每个故障模式都曾真实发生。_

**当依赖关系具有概率性时**

模型消失是显而易见的风险。更微妙的风险是模型每次给出的答案都不同。这是新型的漂移来源，其行为方式与旧模型不同。向同一模型提出相同问题，可能会得到两个不同的答案。这使得正确性更难定义，也使变更更难分析：如果你修改提示词、更换模型或调整相关工具和技能，就相当于改变了软件，这种变更应与其他变更一样受到严格管控。

大多数团队只是进行简单的烟雾测试。看起来没问题就上线。评估环节往往被跳过，而这恰恰是最重要的步骤：将系统与你真正认为有价值的标准进行衡量，而非仅仅看它是否做出了响应。

第一个问题是系统是否必须具备概率性。尽可能保持确定性，在AI能发挥价值的地方使用它，而非无处不在。在可能的情况下，将非确定性系统封装在确定性检查中。如果代理仅负责更新依赖项版本，可以设置第二个系统验证是否只有版本发生了变化。当无法进行确定性检查时，使用对抗性评审：由第二个代理专门负责找出第一个代理工作中的问题。

问责机制不会自动转移。当某人部署一个代理时，仍有人要对它的行为负责。

这对我们同样适用。我们自己的事件分类系统使用语言模型来判断哪个服务对事件负责——这项工作过去意味着要叫醒人们争论日志。这种方法确实更快，但依然遵循“信任但验证”的原则。

_马克关于为何AI的防护措施应尽可能确定性，以及为何代理永远不是问责主体的说明。_

**实际应用中的表现**

这种严谨性必须贯穿所有工作负载的运行环境，其基础概念也十分熟悉。Well-Architected Framework中的可靠性指南早已建议从一开始就设计弹性，而Cloud Adoption Framework则描述了运营层面：将这种意图落实到实际运行和每月的审查中。当资产跨越全球、国家、主权或受监管环境时，“弹性”这个词在每个环境中必须含义一致，而非在每个边界处重新定义；我们关于可靠性和主权的指导原则涵盖了这些约束条件的交叉点。

• 您的图表显示了三个区域，但没有显示负载均衡器后面的健康探测会解析到其中一个区域。 可用性区域可以保护工作负载免受同一区域内数据中心级别的故障影响，但前提是计算、存储和数据层级确实分布在这些区域中。
• 为灾难恢复规划区域弹性。 为每个工作负载设定明确的恢复目标，包括恢复时间目标（RTO）和恢复点目标（RPO）。可用性区域在区域内提供高可用性，而选择的次要区域则在整个区域受到影响时提供故障转移位置。它们应对的是不同的风险，一个弹性的设计需要同时考虑两者。在受监管的环境中，选择范围会进一步缩小，因为恢复区域必须位于与所保护工作负载相同的司法管辖区内。
• 决定投入多少资源来购买弹性。 弹性不仅是一个设计问题，更是一个成本决策。一个在单日承载1亿美元收入的应用程序，当天可能需要跨区域的主动-主动拓扑结构；而其余时间，该应用程序可能只需在一个区域内运行并采用主动-被动故障转移。正确的答案是经过深思熟虑的，而不是追求极致。
• 了解你的影响范围。 理解每个工作负载所依赖的内容及其隐藏的单点故障，然后随着应用程序的变化持续更新这一认知。在内部，我们通过可靠性威胁建模来实现这一点：与安全威胁建模采用相同的纪律，对每个组件提出问题：如果它失败了会发生什么？我们又将如何应对？
• 检查你的恢复路径本身所依赖的依赖项。 一个工作负载可能被正确复制，但仍可能无法恢复：如果其加密密钥仅存在于主区域，当区域故障导致需要这些密钥时，它们恰好会消失。恢复路径也有依赖项，而这些依赖项很少在图表中体现。
• 你的图表可能没有为你的应用程序现在依赖的AI依赖项添加一个框。 为你的应用程序、工作负载、AI模型和服务依赖项进行设计，而不仅仅是基础设施。规划优雅降级和回退方案，以便当关键依赖项被弃用、限流、不可用或容量受限时，工作负载可以通过替代路径继续运行，而不是直接失败。

这并非理论上的讨论。Carne Group是欧洲最大的独立第三方资产管理公司之一，管理着1万亿美元资产，他们通过在Azure上使用基础设施即代码的落地区，重新构建了自己的环境，目的是使弹性可重复实现，而非仅仅依赖记忆。由于定义存在于代码中，他们的团队可以在另一个区域快速搭建一个镜像站点，正如Carne Group全球技术负责人Stéphane Bebrone所说：“即使在最坏的情况下，我们也能在同一天内恢复运营。”他们正朝着跨区域的主动-被动拓扑结构发展，并计划使用Chaos Studio定期验证这些故障转移路径，而不是等到发生事故时才进行验证。根据DORA的要求，他们必须能够证明这一点，而不仅仅是声称这一点。

**弥合意图与现实之间的差距**

架构图是意图的表达，而非证明。它可能展示区域冗余、区域故障转移和受保护的依赖关系，但只有测试才能确定这些假设是否仍然成立。将底层数据整合为清晰的应用程序弹性视图需要真正的努力和专业知识。这是客户需要承担的共享责任的一部分，也是Azure Infrastructure Resiliency Manager旨在帮助弥补的差距。目前处于公开预览阶段，其以智能代理为核心体验帮助团队实现从一开始就具备弹性、持续提升弹性并始终保持弹性。

• 从一开始就具备弹性。 为应用程序定义弹性的含义，设定明确的弹性目标，并使用弹性代理提前生成具备弹性意识的基础设施即代码，使新工作负载从一开始就具备弹性，而非数月后才进行修正。服务组帮助团队在门户中将应用程序表示为Azure资源的逻辑组，使团队能够在应用层面而非逐个资源管理弹性状态，从而更高效地管理。
• 持续提升弹性。 了解当前环境与预期设计之间的差距，识别从未具备区域弹性或因变更而失去区域弹性的资源，并优先处理最关键的问题。团队无需在多个工具间关联分析结果，即可获得修复建议和生成的基础设施即代码，使修复工作通过拉取请求完成，而非成为独立项目。
• 始终保持弹性。 在真实故障发生前验证恢复路径背后的假设。对于客户管理计算资源的工作负载（如虚拟机），区域停机演练可模拟可用性区域丢失并展示应用程序实际受影响情况。对于其他服务，团队可通过故障转移验证、产品特定的恢复能力以及通过Azure Chaos Studio进行故障注入，测试正确的故障模式。

我们也将坦率地承认存在的差距。跨所有工作负载和环境的一致性自助恢复能力评估尚未完成，明确这一点至关重要。弹性的提升需要团队能够看到差距、衡量差距并随着时间推移系统性地弥补差距。这也是一项永无止境的工作。随着服务不断强化，故障率会下降，但剩余的故障会变得越来越罕见和难以预料；你将渐近式地接近完美，却永远无法真正抵达。

**结论：图表并非证明**

弹性不是一项可以完成的项目，而是需要持续维护的姿态。工作应从第一个架构决策开始就将其设计进去，然后随着环境变化持续验证，使偏差通过测试而非事件被发现。所有内容都基于Azure Essentials框架、Well-Architected框架和云采用框架，确保“弹性”和“主权”在所有环境中具有相同含义，而非由每个团队重复定义。

None of this is a new framework. A diagram tells you what you intended; only a test tells you what you have. That was true when people drew the diagrams and read them. It matters more now that neither is reliably the case, and that some of what you depend on answers differently every time you ask. If resilience cannot be tested, it cannot be trusted.

在本系列文章的下一部分中，我们将探讨如何在大规模场景下衡量这种状态。

_上述三个片段摘自一段更长的对话，内容涵盖2014年那次几乎导致Azure瘫痪的变更、我们如何从客户视角学习衡量系统健康状态、当依赖项是AI模型时会出现哪些不同类型的故障，以及为什么数据中心的硬件每天都会发生故障。_[查看完整采访](https://youtu.be/IQOki5wRGHI)（在Azure Essentials YouTube频道）。

**资源**

• 云弹性
• Azure Essentials
• Azure基础设施弹性管理器
• 可靠性设计原则—Azure Well-Architected Framework
• 工作负载健康建模—Azure Well-Architected Framework
• Azure Monitor中的健康模型（预览版）
• Azure云采用框架
• Azure架构中心
• Azure中的可靠性和主权
• 弹性服务新功能
• 为Azure工作负载启用区域弹性
• Azure Chaos Studio文档
• Azure Site Recovery文档
• Azure Backup文档
• Carne Group通过Azure Site Recovery和Backup提升基础设施和网络弹性
• 安全部署实践—Azure Well-Architected Framework
• 认识Brain：Azure可靠性的AI系统
• 使用Triangle系统通过AIOps优化事件管理
• 使用Chaos Studio在Azure上验证应用程序弹性
• 提升可靠性—Azure博客系列