早上七点一刻，你站在地铁口，手机攥在手里，这个月的房租该转了。

点开银行 App，密码输完，转账页面开始转圈。两秒、五秒、十秒。你以为是信号不好，退出去重进一次。还是转圈。旁边的人擦肩而过，谁也没抬头——只有你一个人卡在这一屏上，因为今天全城有太多人卡在这一屏上。

然后你看到新闻：不是你的手机，也不是你的密码。是伦敦那边，一整层机房停了电。

一个可用区，三十七项服务

这次故障的起点非常小、非常物理。

谷歌云的状态页写得很清楚：事件开始于 2026 年 10 月 19 日 23:08（美国太平洋时间），也就是伦敦当地 10 月 20 日早上 7 点多。原因是 一次供电事件（power event），导致欧洲西部 2 区域（europe-west2）下面的 europe-west2-b 这一个可用区整体宕机。

europe-west2 就是伦敦。谷歌云在伦敦部署了三个可用区，b 是其中之一。官方在 04:12 PDT 的更新里说，供电事件已经被缓解，基础设施服务会在 30 分钟内逐步部分恢复，但剩下的服务会更晚一些。它同时给出了一条听起来很平淡、其实很残酷的建议：如果可行，请把受影响的工作负载迁移到其他可用位置。

被这次事件同时打中的服务，官方列了长长一串：Google App Engine、BigQuery、Cloud Run、Google Kubernetes Engine、Cloud SQL、Cloud Storage、Cloud NAT、VPC、Filestore、Pub/Sub、Spanner、Kafka、Dataflow、Dataproc、Apigee、Cloud Load Balancing、Redis / Memorystore、Speech-to-Text、VMware Engine、Looker（Google Cloud core）……

官方状态页列出的受影响服务清单有 38 项，其中包括 Google App Engine、BigQuery、Cloud Run、Kubernetes Engine 在内的十余项被媒体逐一点名。这是一个值得记住的数字：你以为云计算是一个"云"，其实它是几十个彼此独立、又被彼此依赖的具体服务叠在一起，共享着同一层楼的地板、同一套配电、同一路市电。

The Register 记录下的一句业内评论很直白："单可用区一打盹儿，你那个没做高可用的服务就跟着躺下了。"下面另一条更朴素："感觉啥都挂了，DNS 好像也不对。"

早上七点，谁在替你数钱

真正让普通人感觉被"点到"的，是下游那份名单。

英国《卫报》的实时报道里，DownDetector 的曲线上依次弹起的名字是：Lloyds Bank（劳埃德银行）、HSBC（汇丰）、Royal Mail（英国皇家邮政）、Rightmove、DPD、BT、Screwfix，以及 Revolut。财经媒体 Business Insider 还提到了 Halifax。w.media 的汇总里还出现了 NHS 和连锁超市 Asda，不过他们也写明了——是不是同一个原因，目前还不能确定。

被点名最多、也最扎眼的是 Revolut。这家英国数字银行那天早上几乎全线飘红：注册、登录、刷卡支付、转账、ATM 取款、账户充值、股票交易、加密货币相关服务全部受影响。它的官方声明是这样的：

"我们目前正在经历影响多项服务的服务中断。我们可以确认，我们所有客户的资金和数据都是安全的。我们从今天早上发现该问题起就在着手修复，对给各位造成的影响和不便深表歉意。"

"资金和数据是安全的"——这句话恰恰是这条新闻最扎人的地方。

钱当然安全。钱一直都在 AWS 和 GCS 的数据库里，一个字节都没丢。问题在于：你的钱安全，和你能动用自己的钱，是两件完全不同的事。 前者是存储，后者是一条依赖链上的几十次握手。当这条链在伦敦的一个可用区断掉，你的钱就从"我的"变成了"暂时够不着的"。

那天早上英国时间 10 点 24 分，谷歌云首次在状态页确认问题；The Register 报道说，当时尚无预计恢复时间，谷歌明确表示"暂无绕行方案（no workarounds for now）"。而在地球另一边，Revolut 新加坡站的状态页显示，27 项服务全部处于部分不可用状态，其中一部分是在当地下午 3 点 47 分被检测到的。也就是说，伦敦一个楼层的供电问题，通过跨区的架构依赖，在十几个小时之后仍然在东南亚的支付界面上留下痕迹。

据 DownDetector，当天英国时间上午有超过 1500 人报告 Revolut 异常。

你的钱到底存在谁的机房里

这件事最让人后背发凉的地方，不是它影响了多少人，而是它暴露了我们对"钱在银行里"这件事的默认误解。

我们这一代人几乎已经不再把银行理解成一栋有保险柜、有柜台、有人的地方。我们理解它是一串服务接口。刷信用卡，是一次 HTTP 请求加一次风控打分；转账，是两个账户之间的一条流水；取现，是一台机器去某个网络里完成一次授权。每一次，你都在信任背后有一串机器正亮着绿灯。

而这次故障问了一个很朴素的问题：那串绿灯，是谁点亮的？

不是你。不是汇丰，不是 Revolut，甚至也不是这些公司自己的机房。是谷歌云伦敦区域的一个可用区。它今天早上 7 点因为一次供电事件倒了，然后一万公里外的一台手机，它的支付按钮就按不下去了。

这里我不想简单地把矛头指向某一家公司——一次供电事件在任何基础设施里都可能发生，谷歌在事件确认后两小时内就给了成因说明和恢复计划，这种透明度本身是合格的。真正值得停留的是那个更大的结构：

过去十年，我们把越来越多的东西，从"自己维护"交给了"有人维护"。 存储、计算、身份、支付、风控、日志、消息队列。企业省下了机房和运维团队，代价是把自己的连续性，变成了别人的一个可用区。这笔交易在绝大多数日子里是划算的——直到某一天早上七点。

我们把多少东西押在了一个名字上

这次故障的另一个细节，被讨论得反而比事故本身更多：多可用区架构（multi-AZ）到底有没有用。

europe-west2-b 倒了，"正常情况下"同区域的其他可用区应该顶上，客户感觉不到任何事。这正是可用区设计要解决的问题——它本来就是为单点故障准备的。

但那条 Reddit 评论说得对：如果你把服务、数据、或者一个关键的 DNS 解析，都放在了这一个可用区里，那你买的就不是高可用，你买的是一张单程票。 三层高可用设计（三个可用区 × 每个区三台机器），看上去很美，但只要有一层偷懒往下塌，上面两层就是纯装饰。这次事件里还出现了一个副产物——"感觉啥都挂了，DNS 好像也不对"，这句大白话，恰好是所有架构师最怕听到的那种现场描述。

对我们的个人日常来说，这一天真正值得带走的判断有三层：

第一层：如果你是开发者或者运维，今天应该去看一眼自己服务的高可用配置。 不是看架构图上画的几个可用区，是去看真实的资源分布、真实的容灾预案。真正的问题不是"你做没做多可用"，而是"如果你的主区域整个没了，你多久能起来"——这个数字，架构图上从来不写。

第二层：如果你是创业公司的技术负责人，今天应该盘一下你的依赖清单。 你的登录、支付、短信、邮件、数据同步，有几个是单一供应商的？这不是要你今天就上多云——那不现实。而是让你知道，明天早上万一出事，你的第一件事是打电话给谁。

第三层：如果你是普通用户，这一天最好的收获是一个新的直觉。 我们习惯了把这些 App 当成"随时都在"的基础设施，就像水和电。这一天告诉我们，它们不是。它们是别人机房里的机器，机器会断电、会被误配、会有人在前一天晚上做一次改动然后忘记回滚。知道这一点不是要你焦虑，而是要你在下次转账转不动的时候——第一反应是"等一会儿再试"，而不是"我的钱是不是被冻结了"。 这两种反应，会让你的这一天少慌 30 分钟。

后来呢

截至本文发稿，谷歌云的状态页上这次事件仍没有给出明确的完全恢复时间。状态页上多行更新反复出现的是同一句话："我们的工程团队仍在调查这个问题。"

那个在状态页上等回复的人，其实就是你。那天早上在地铁口刷着转账页面的人，和慕尼黑、伦敦、新加坡某个运维工程师盯着的，是同一块发光的屏幕。

谷歌云这次在状态页上的处理其实是合格的——两小时内给了成因，两小时内给了缓解进度，反复更新，也给了迁移建议。但这次事故最值得记住的，不是它影响了谁，而是它证明了一件事：

你以为你把钱存在了银行，其实你把它存在了一个可用区。

下一次那屏转圈的时候，记住它只是一件暂时够不着的事。钱是安全的，你也是安全的。恢复之后你会发现，其实这一天真正被中断的，是那种"一切都理所当然"的错觉。

本文信息截至 2026 年 10 月 20 日 19:30（北京时间）。故障进展请以谷歌云官方状态页为准。