摘要
2026-05-19 22:20 UTC 至 05-20 06:14 UTC，Railway 因 Google Cloud 自动化动作将其生产账号错误置为 suspended 状态，导致 GCP 托管的 API、控制面与数据库离线，约 8 小时平台级全中断。边缘路由缓存过期后，连同 Railway Metal 与 AWS 上的 workload 也返回 404，峰值期全区域 workload 均不可达。
时间线
2026-05-19 22:10 UTC自动监控检测到 API 健康检查失败，on-call 被呼叫
2026-05-19 22:11 UTC仪表盘返回 503，用户无法登录
2026-05-19 22:19 UTC定位根因：Google Cloud 将 Railway 生产账号置为 suspended
2026-05-19 22:22 UTC向 Google Cloud 提交 P0 工单，GCP 客户经理直接介入
2026-05-19 22:29 UTC事件宣告；GCP 账号访问恢复，但计算实例停止、持久盘不可访问
2026-05-19 22:35 UTC边缘网络路由缓存开始过期，Railway Metal / AWS 上的 workload 开始返回 404
2026-05-19 23:09 UTC首块持久盘上线
2026-05-19 23:54 UTC全部持久盘恢复 ready，网络仍中断
2026-05-20 00:39 UTC磁盘确认 ready，恢复卡在 GCP 网络恢复
2026-05-20 01:30 UTC计算实例开始恢复
2026-05-20 01:38 UTC边缘流量恢复，网络恢复
2026-05-20 01:57 UTC编排与构建基础设施恢复，暂时暂停部署以防系统过载
2026-05-20 02:04 UTC计算主机增量上线
2026-05-20 06:14 UTC全部服务恢复
根因
Google Cloud 的自动化执行系统将 Railway 的生产账号错误地置于受限（suspended）状态，瞬间拉下 GCP 托管的 API、控制面、CloudSQL 与计算实例。Railway 虽在自有 Metal 与 AWS 上运行部分负载，但其网络控制面（负责向全球边缘代理分发路由表）仍托管于 GCP；账号被暂停后 API 下线，边缘路由缓存一旦过期，所有区域的代理均无法解析路由，导致全平台 workload（含非 GCP 负载）返回 404。Railway 承认对「单一上游供应商动作可级联为全平台中断」的架构负有责任。
放大因素
- 网络控制面单点托管于 GCP：路由表分发依赖 GCP 托管 API，缓存过期即全局失联。
- 路由缓存 TTL 有限：缓存失效时间集中在暂停后约 15 分钟，形成全区域同时不可达的高峰。
- 恢复期间 GitHub 因调用量激增对 Railway 的 OAuth / webhook 集成限流，二次阻断登录与构建。
- 排队部署积压：恢复后需分批排空队列，避免构建系统被瞬时压垮。
缓解措施
- GCP 账号访问在 9 分钟内恢复，随后逐层恢复持久盘→网络→计算→编排→部署。
- 恢复阶段临时节流非企业构建，分批排空队列。
- 后续将 GCP 降为备份/故障转移角色，核心用户通信路由不再依赖单一供应商。
- 高可用数据库分片扩展至 AWS 与 Railway Metal，使网络控制面实现供应商独立。
- 为依赖云连接的设备引入本地降级控制能力，断云时仍可操作核心功能。
经验教训
- 多 AZ / 多区域防护只挡得住「供应商内部」故障，挡不住「账号级」暂停。
- 控制面与数据面必须分离：把路由/控制表从单一云供应商的热路径中迁出。
- 不要把关键 API / DB 放在单一托管账号上，即便该供应商日常可靠。
- 边缘代理应持有长期有效的本地路由副本，缓存过期不应导致全局 404。
- 供应商自动化封禁需有人类复核与事前通知，否则大客户也会无预警离线。
检查清单
- 控制面是否依赖单一云账号？若是，列出解耦路径与时限。
- 边缘/代理层是否持有可独立服务的本地路由副本（不依赖中心 API 实时可用）？
- 账号级暂停（非资源故障）是否在灾备演练覆盖面内？
- 上游供应商是否提供账号动作的事前通知与人工复核通道？
- 恢复后排队任务是否有节流与分批排空机制，避免二次雪崩？
- 高可用分片是否跨供应商分布，而非同账号多 AZ？