级联故障：从 Railway 的 GCP 账号停用事件中汲取的教训

2026 年 5 月 19 日，Railway 经历了持续约八小时的灾难性全平台服务中断。起初这只是 Google Cloud Platform (GCP) 的一次自动化账号停用，但很快演变成了一场全面的停机，不仅影响了托管在 GCP 上的基础设施，还波及了运行在 AWS 和 Railway 自身裸金属服务器上的工作负载。

这次事件是云架构领域的一个关键案例研究，它展示了即使是“具有韧性”的多云策略，如果存在单一故障点，仍可能引发跨不同环境的级联崩溃。

故障分析

在 UTC 时间 22:20，Google Cloud 通过自动化操作错误地将 Railway 的生产账号置于停用状态。影响是立竿见影的：托管在 GCP 上的 Railway Dashboard、API 以及核心网络基础设施组件全部下线。

虽然 Railway 使用的是混合基础设施（Metal、AWS 和 GCP），但其架构中包含了一个隐藏的关键依赖项。负责将流量路由到各种工作负载的边缘代理（edge proxies）依赖于托管在 GCP 上的网络控制平面 API 来填充其路由表。

级联效应

故障分三个阶段展开：

  1. 即时损失： 所有托管在 GCP 上的计算、数据库和控制平面 API 瞬间消失，向用户返回 503 错误。
  2. 缓存窗口期： 在短时间内，运行在 Railway Metal 和 AWS 上的工作负载仍可访问，因为边缘代理正在使用缓存的路由表。
  3. 全线崩溃： 一旦这些缓存过期，边缘代理便无法再解析到活动实例的路由。由于控制平面 API（事实来源）在 GCP 上处于离线状态，网络无法重新填充数据。这导致所有区域的所有工作负载都出现了 404 错误，无论它们物理上托管在哪里。

恢复挑战与次生故障

恢复账号访问并不意味着服务能立即恢复。Railway 指出，持久化磁盘、计算实例和网络都需要分别进行顺序恢复流程。这延长了停机时间，核心网络直到次日 UTC 时间 01:30 左右才完全恢复。

随着系统重新上线，出现了“惊群效应”（thundering herd）。大量积压的部署任务和重试请求同时涌入系统。这触发了次生故障：GitHub 开始对 Railway 的 OAuth 和 webhook 集成进行速率限制，从而暂时阻碍了用户登录和新构建任务。

技术分析与社区批评

这次事件在 Hacker News 上引发了技术社区的激烈辩论，主要集中在两个主题：GCP 的可靠性以及“平台即服务”（PaaS）抽象层的风险。

GCP 的“信任”差距

许多工程师分享了关于 GCP 自动化账号停用的类似恐怖故事。批评者的共识是，Google 的自动化执行机制过于激进，且对于 B2B 客户缺乏足够的的人工监督。

"Google 有一种文化问题……在我的同行 C-suite 高管中，大家的讨论是，除非经过数年时间且没有发生此类事件，否则 GCP 根本无法进入考虑范围。"

泄露的抽象层

一些观察者质疑使用像 Railway 这样构建在其他基础设施提供商之上的提供商的价值。其论点是，这增加了一层成本和风险，却未能消除云提供商的服务条款或自动化机器人带来的底层脆弱性。

预防措施：迈向真正的网格化

Railway 承认，虽然其控制平面是多可用区（multi-AZ）的，但并非多提供商（multi-provider）。为了防止再次发生，他们正在实施以下架构转变：

  • 真正的网格化网络 (True Mesh Networking)： 消除对 GCP 托管的控制平面在工作负载可发现性方面的硬性依赖。这确保了如果一个云提供商发生故障，网格仍能通过其他路径解析路由。
  • 跨云数据库仲裁 (Cross-Cloud Database Quorum)： 将高可用数据库分片扩展到 AWS 和 Metal。这确保了如果整个云提供商消失，数据库仲裁仍能维持，从而实现即时故障转移。
  • 将 GCP 从热路径中移除 (Removing GCP from the Hot Path)： 计划将 Google Cloud 服务移出主要数据平面，将其降级为次要或故障转移角色。

最终启示

Railway 的事件报告展现了极高的透明度，承认了其架构决策允许单一的上游动作引发了全平台的停机。对于任何平台工程师来说，核心教训是：冗余并不等同于独立性。如果寻找数据的“地图”仅存储在一个地方，那么将数据存储在三个云中也是徒劳的。

Sources