Google Cloud 中断影响欧洲几乎所有银行及其他业务

用户影响与 neobank 可靠性

• 许多评论者报告称，neobank 和 fintech（例如 Revolut）发生了中断，卡支付、ATM 取款和应用访问都失败了。
• 一些用户指出，在事故期间缺乏电话支持或人工联系，是纯 App 银行的一个主要缺点。
• 另一些人则将此与那些投资于位于不同提供商上的独立、简化“stand-in”系统的 neobank 作对比；这些系统在过去的中断中保住了核心银行功能。
• 少数用户因为对监管、账户冻结或事故处理不佳的担忧而避开或离开了某些 neobank，更倾向于拥有可靠电话支持的传统银行。

中断的原因与范围

• Google 的状态页面将问题归因于 europe-west2-b 区域的“power event”，约 30 分钟内部分恢复，之后进一步缓解。
• 评论者对大型银行和金融服务似乎把关键工作负载集中在单一可用区/区域而不是多可用区或多区域架构感到惊讶。
• 有人报告其他可用区或区域的服务也出现了问题，但跨区影响的范围和根本原因尚不明确。

云架构、韧性与测试

• 几条评论强调，多 AZ 或多区域架构只有在定期测试时才有意义；许多组织从未模拟过整个 AZ 失效。
• 从业者指出，在严格一致性和遗留依赖的情况下，多云和真正的地理冗余都很难实现，而且成本高昂。
• 有人批评超大规模云厂商可能存在可用区/区域间依赖和容量限制，导致某个区域故障时出现“thundering herd”问题。
• 也有人认为，如果每个人都把自己的硬件放在同一个数据中心，同样会发生中断；真正的问题是没有正确实现冗余。

主权、监管与 DORA

• 关于“AI sovereignty”与“compute/data sovereignty”的讨论：一些人认为依赖单一超大规模云厂商区域，与主权目标相矛盾。
• 也有人区分主权（数据存放在哪里）与冗余（有多少地点），认为监管机构和企业都必须同时考虑这两者。
• 讨论中提出了欧盟/英国监管影响（例如 DORA）的问题，有观点认为机构可能面临审查和改进计划，但如果这是首次重大问题，大额罚款不太可能。
• 法律/地理居住要求以及 Brexit 被认为是一些银行将英国工作负载严格保留在英国区域的原因，这限制了冗余选项。

云提供商比较与更广泛的情绪

• 对提供商的看法不一：有些人把 AWS 和 Azure 排在“其他一切”之上，另一些人则称 GCP 通常中断更少且安全性强。
• Azure 被描述为在控制平面层面设计得很好，但在实现和文档上显得笨拙。
• 对“cloud 会更便宜、更有韧性”的说法普遍持怀疑态度；很多人认为云只是改变了故障发生的位置，而不是消除了故障。