多可用区架构最值得追问的是：一个区退出以后，剩下的系统能否完成同一项业务？这要求应用同时具有可用副本、可执行的控制路径和足够容量。伦敦云故障提供了一个具体入口，让我们把“部署在多个区”拆成可以分别检查的恢复条件。
Google Cloud · 事故初步分析与工程解读
一手来源：Multiple services were experiencing issues in the europe-west2 region. · 事故发生于 2026-10-20；本文纳入 2026-10-22 发布的 Preliminary Incident Report。新闻线索：Google Cloud’s London zones takes a nap, multiple services disrupted，Paul Kunert，2026-10-20。
初步报告揭示了什么
Google 将故障归于 europe-west2-b 的供电中断：主、备 PLC 未完成发电机启动／切换，UPS 耗尽后设备离线。跨区控制调用等待失效区，转移负载又挤压其他区容量。官方记录影响持续 6 小时 10 分钟，截至 10 月 20 日 13:10 BST，超过 99% 的 Compute Engine 虚拟机恢复健康。处置包括隔离失效端点、调整资源分配及逐步恢复流量。这是初步调查，最终预防措施尚待发布。初步事故报告
接下来的模型是对故障转移条件的工程推导；其中的容量数字和示例并非 Google 的实际配置。
副本存在，为什么请求仍然可能失败
考虑一个假设的查询服务：工作节点部署在多个区，但每次接收新任务都必须读取一个目录服务。即使健康区的工作节点、数据副本都可用，只要目录查询仍同步等待故障区，任务就不能进入执行阶段。架构图上“有另一个副本”，并没有回答请求在何处被卡住。
可以沿一项业务列出三条路径：正在执行的任务依赖什么；新任务进入时要验证什么；故障后重建实例又需要什么。三条路径可能并不相同。已有任务继续运行，不代表新任务能够提交；数据能够读取，也不代表调度器能够重新分配资源。
这种分解还影响监控。仅探测工作节点是否存活，可能漏掉任务接纳失败；只看 API 返回成功，也可能遗漏长时间排队。一个有辨识力的探针应走完最小业务闭环，并记录在哪个阶段停止推进，帮助区分服务不可达、控制调用阻塞和资源不足。
用一个容量算式理解切换压力
假设三个区容量相同，每区可持续处理容量为 C，正常负载均匀，总负载为 L。丢失一个区后，在没有额外开销的理想情况下，需要满足：
若正常单区利用率为 u，则 L = 3uC；于是剩余两区的平均利用率为：
正常利用率为 60% 时，切换后变成 90%；正常为 70% 时，则需要 105% 的容量，已经超出这个模型的稳定处理能力。这里的阈值只适用于容量相同、均匀分流的简化条件，不能直接成为生产配置建议。
这个推导忽略了恢复本身的工作量。副本追赶、连接重建和重试都可能消耗资源；缓存命中率变化也会改变每个请求的成本。容量规划因此需要同时问“业务负载能否放下”和“切换过程是否还留有余量”。反过来，长期保留余量需要付费，系统应明确哪些业务必须保持完整服务，哪些可以排队、限流或暂时降低功能。
故障恢复也是一次流量调度
在一个假设的恢复阶段，若积压任务数为 B，系统每秒可处理 μ 个任务，新任务每秒到达 λ 个，且 μ 大于 λ，忽略任务差异时，清空积压所需时间约为：
当处理能力仅略高于新增流量时，即使系统已重新接通，队列仍可能需要很久才能消退。若 μ 不大于 λ，积压不会自行清空。这解释了为何“恢复供电”“服务开始响应”和“用户等待回到正常水平”应分别观测。
恢复控制也有取舍。一次放回全部流量，可以更快利用新恢复的容量，却可能同时触发缓存预热和连接风暴；缓慢放量更容易观察异常，却延长了部分请求的等待。一个可验证的恢复策略应给出阶段性接纳条件，例如完成健康验证后先放少量任务，再依据错误率和积压变化扩大，而不是只看进程启动成功。
对重试也应提出同样的问题：它是在等资源恢复，还是不断把额外请求压进已经拥塞的系统？退避和限额的价值，要通过恢复期总工作量与业务完成时间评估，不能只看单次调用最终是否成功。
还有一种容易遗漏的恢复条件是状态一致性。对一个假设的订单服务，请求超时只表示调用者没有及时拿到结果，不能直接证明订单没有创建。如果恢复脚本重新提交所有超时请求，却没有稳定的业务标识，就可能把可用性问题变成重复操作问题。因此，恢复任务需要知道哪些工作可以安全重试，哪些必须先查询结果，再决定后续动作。
这也解释了恢复演练为什么需要观察应用层状态，而不只是网络连通性。关闭故障区流量之后，如果客户端仍持有旧连接、缓存旧位置，或者后台任务仍引用旧资源，用户路径可能尚未真正切走。演练应把入口切换与残余依赖清理分别记录，才能看出恢复时间究竟耗在资源重建、状态确认还是客户端重新发现服务上。
如何把这次阅读变成有效的演练
可以把一次故障演练拆成三个可比较场景：移走一个区的执行资源；保留执行资源，但让关键控制调用超时；同时移走资源并施加积压。它们分别检查放置冗余、依赖隔离和剩余容量，避免一个“切换成功”的指标掩盖不同瓶颈。
每个场景都需要明确业务成功条件。例如，已有任务是否保留进度，新任务是否在目标时间内接纳，重复请求是否造成重复执行，以及恢复后是否仍有一小部分任务长期停滞。这些是本文提出的评估维度，不是对 Google 客户损失或内部实现的推测。
阅读价值在于重新检查故障边界。 初步报告给出了值得追踪的传播链，但没有公开各服务的容量余量、重试策略或控制组件完整拓扑，不能从一次事故推导某种部署方式的通用恢复时间。后续最值得读的是最终报告如何解释备份控制为何同时失效，以及修复是否覆盖了控制依赖和切换容量，而不只是恢复电力。