Railway 发布事故报告：GCP 账户误停致全平台级联宕机

2026年5月19日，应用部署平台 Railway 遭遇了一场长达约8小时的全平台服务中断。事故起因是 Google Cloud Platform (GCP) 的自动化系统错误地将 Railway 的生产账户标记为暂停状态。尽管 Railway 采用了多云架构，结合了 GCP、AWS 及自研的 Railway Metal 基础设施，但由于其网络控制平面 API 托管在 GCP 上，此次单点故障引发了严重的级联效应。事故初期，所有托管在 GCP 上的计算实例、API 和数据库立即下线，用户遭遇 503 错误。更关键的是，虽然其他区域的边缘代理在路由缓存有效时仍能维持服务，但随着缓存陆续过期，由于无法连接至位于 GCP 的控制平面以刷新路由表，导致包括 AWS 和 Metal 在内的全网工作负载最终全部不可达，返回 404 错误。此外，恢复过程中积压的大量请求触发了 GitHub 的 OAuth 和 Webhook 速率限制，进一步阻碍了用户登录和构建流程。Railway 承担了架构设计上的全部责任，承认过度依赖单一上游供应商的控制平面。作为补救措施，Railway 计划实施架构升级，移除对 GCP 的硬依赖，构建真正的网状网络，并将高可用数据库分片扩展至 AWS 和 Metal，以确保任何单一云服务商的故障都不会导致全平台瘫痪。

事件分析

💡 核心观点：真正的多云容灾不仅要分散数据层，更必须解耦控制平面，避免单一供应商的账户风控或网络故障引发全平台级联雪崩。