由于 Google Cloud 错误地暂停了其生产账户，Railway 平台经历了一场持续约 8 小时的全面服务中断。该事件最初导致其在 GCP 上的仪表盘和 API 等核心服务下线，随后因路由缓存失效，问题蔓延至 Metal 和 AWS 上的工作负载，造成全平台服务不可达。作为回应，Railway 宣布将调整其系统架构，移除对 Google Cloud 的单点依赖，以增强跨云端的高可用性和故障切换能力，防止未来发生类似事件。
事件影响
在 2026 年 5 月 19 日至 20 日期间，因 Google Cloud 暂停了 Railway 的生产账户，平台经历了全面的服务中断。这次中断造成了连锁反应，具体影响如下：
- 直接中断: 托管在 Google Cloud 上的 API、控制平面、数据库和计算基础设施立即下线。用户在访问仪表盘和 API 时遇到 503 错误，并且无法登录。
- 级联故障: Railway 的边缘代理依赖一个托管在 Google Cloud 上的控制平面 API 来获取路由信息。当这些路由的缓存过期后，即使是在 Railway Metal 和 AWS 上运行的工作负载也变得无法访问，开始返回 404 错误。
- 恢复缓慢: 恢复 GCP 账户访问权限后，计算实例和持久盘等服务仍需单独恢复，这延长了中断时间。
- 次生问题: 在恢复过程中，由于缓存被清除后产生大量请求，GitHub 开始对 Railway 的 OAuth 和 Webhook 集成进行速率限制，暂时阻止了部分用户登录和构建。
我们对导致单一上游供应商行为演变成全平台中断的架构决策承担全部责任。
事故原因分析
事件的根本原因是 Google Cloud 的一个自动化操作错误地暂停了 Railway 的生产账户。此操作影响了多个 GCP 账户，且在执行前没有向客户发出任何预警。
这次暂停立即禁用了 Railway 托管在 GCP 上的所有基础设施。虽然 Railway 的网络设计（包括在 AWS、GCP 和 Metal 之间的冗余连接）具有一定的弹性，但存在一个致命的架构缺陷：
- 单点依赖: 平台的工作负载可发现性（即路由）完全依赖于托管在 Google Cloud 内部的网络控制平面 API。
- 缓存失效导致崩溃: 尽管网络在出事后依靠缓存继续运行了一段时间，但一旦缓存过期，边缘代理就无法重新获取路由表，导致整个网络瘫痪，即使其他云上的工作负载本身仍在运行。
预防措施
为了防止此类事件再次发生，Railway 正在立即采取行动，以消除对单一供应商的硬性依赖，并建立一个真正弹性的系统。
- 构建真正的网状网络: 移除对 GCP 托管的控制平面 API 的依赖，确保即使任何云之间的互连中断，网络中总有备用路径。
- 跨云扩展数据库: 将高可用性数据库分片扩展到 AWS 和 Railway Metal。这样，即使某个云中的所有实例瞬间消失，数据库仍能保持运行并立即进行故障切换。
- 降低 GCP 的重要性: 计划将 Google Cloud 服务从数据平面的“热路径”（关键实时路径）中移除，仅将其用于次要或故障转移目的。
- 升级核心架构: 实施新的数据平面和控制平面架构，确保核心服务（尤其是面向用户的组件）不依赖于任何单一供应商或平台。