事件报告：2026年5月19日 – GCP账户暂停

# 事件报告：2026年5月19日——GCP账户暂停 来源：https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage ## 目录 1. 影响范围 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#impact) 2. 事件时间线 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#incident-timeline) 3. 发生了什么？ (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#what-happened) 4. 预防措施 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#preventative-measures) 🚅 本报告反映了我们在发布时所知的信息，并可能根据 Google Cloud 的内部审查进行更新。 由于 Google Cloud 错误地将我们的账户置于暂停状态，Railway 经历了平台范围的服务中断。这导致所有 GCP 托管基础设施暂时失去服务能力。这些基础设施支撑着我们的控制台、API 以及部分网络基础设施。随着缓存的网络路由过期，中断范围从 GCP 扩展到所有 Railway 工作负载。 以下，我们将详细说明事件经过、我们的应对方式以及我们为防止类似事件再次发生所采取的措施。 https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#impact ## 影响范围 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#impact) 2026年5月19日 22:20 UTC 至 5月20日约 06:14 UTC（约8小时）期间，在 Google Cloud 暂停了我们生产账户上的服务后，Railway 经历了平台范围的中断。这导致我们的 API、控制平面和数据库以及托管在 Google Cloud 上的计算基础设施离线。 用户立即在控制台和 API 上遇到 503 错误，包括“无健康上游”和“无条件丢弃过载”消息，并且无法登录。所有托管在 Google Cloud 计算上的工作负载均已离线。 虽然我们自己的 Railway Metal 和 AWS 突发云环境中的工作负载保持在线，但 Railway 的边缘代理依赖一个托管在 Google Cloud 中的控制平面 API 来填充其路由表，导致中断级联到 Google Cloud 之外。随着路由缓存过期，这些其他工作负载变得不可达，导致返回 404 错误，因为网络控制平面无法再解析到活动实例的路由。在影响高峰期，所有区域中的所有 Railway 工作负载均变得不可达。 在我们恢复 Google Cloud 环境的过程中，构建和部署在整个平台上被阻塞，同时我们逐个恢复各个服务。一旦整个基础设施恢复，大量积压的排队部署被逐步消化，以避免压倒平台。与此同时，GitHub 开始对 Railway 的 OAuth 和 webhook 集成进行速率限制，暂时阻止了登录和构建。由于 Google Cloud 中断导致我们的缓存被清除，这些调用的数量增加了。作为副作用，服务条款接受记录也被重置，提示用户在下次访问控制台时重新接受。 我们对导致单一上游供应商行为级联成平台范围中断的架构决策承担全部责任，并在下面详细说明事件经过、恢复方式以及我们为防止再次发生而进行的更改。 https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#incident-timeline ## 事件时间线 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#incident-timeline) - 5月19日 22:10 UTC - 我们的自动监控检测到 API 健康检查失败，并呼叫了值班人员，他们开始调查问题。 - 5月19日 22:11 UTC - 控制台返回 503 错误。用户无法登录。 - 5月19日 22:19 UTC - 根本原因确定：Google Cloud Platform 已暂停 Railway 的生产账户。 - 5月19日 22:22 UTC - 向 Google Cloud 提交了 P0 工单。Railway 的 GCP 客户经理直接介入。 - 5月19日 22:29 UTC - 宣布事件。 - 5月19日 22:29 UTC - GCP 账户访问恢复。所有计算实例仍处于停止状态，持久磁盘不可访问。 - 5月19日 22:35 UTC - 缓存的网络路由开始过期；由于网络无法再解析路由，Railway Metal 和 AWS 上的工作负载开始返回 404 错误。 - 5月19日 23:09 UTC - 第一个持久磁盘重新上线。 - 5月19日 23:54 UTC - 所有持久磁盘恢复到就绪状态。网络仍然不可用。 - 5月20日 00:39 UTC - 磁盘确认就绪。恢复受阻于 Google Cloud 网络恢复。 - 5月20日 01:30 UTC - 计算实例开始恢复。 - 5月20日 01:38 UTC - 边缘流量再次提供服务。网络恢复。 - 5月20日 01:57 UTC - 编排和构建基础设施恢复。部署暂时暂停，以防止在排队的作业试图同时执行时压倒系统。 - 5月20日 02:04 UTC - 计算主机开始逐步恢复上线。 - 5月20日 02:47 UTC - GitHub 开始对 Railway 的 OAuth 和 webhook 集成进行速率限制；部分用户无法登录，构建被阻止。 - 5月20日 02:55 UTC - 控制台再次可访问。 - 5月20日 03:59 UTC - 所有层级的部署开始再次处理。 - 5月20日 04:00 UTC - API、控制台和 OAuth 端点确认运行正常。其余工作负载继续恢复。 - 5月20日 06:14 UTC - 事件转为监控状态。 - 5月20日 07:58 UTC - 事件已解决。 https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#what-happened ## 发生了什么？ (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#what-happened) 5月19日 22:20 UTC，Google Cloud 作为一项自动化操作的一部分，错误地将 Railway 的生产账户置于暂停状态。该操作影响了 Google Cloud 中的许多账户。由于这是平台范围的操作，在限制之前并未主动联系单个客户。 此暂停状态禁用了我们与 GCP 相关的基础设施，这些基础设施支撑着 Railway 控制台、API 和部分网络基础设施，以及托管在 Google Cloud 上的额外突发计算基础设施。 Railway 的控制平面是一组核心依赖项，为控制台提供服务、处理构建和部署，并填充我们边缘所使用的路由表。对于 Google Cloud 上的所有工作负载，影响是立竿见影的。 Railway 的边缘代理维护一个来自网络控制平面（托管在 Google Cloud 内）的路由表缓存。当该缓存有效时，Railway Metal 和 AWS 上的工作负载继续提供流量。一旦缓存过期，边缘便无法再解析活动实例的路由，包括 Metal 和 AWS 在内的所有区域的工作负载开始返回 404 错误。这导致网络中断影响从 Google Cloud 级联到这些区域，尽管这些区域的工作负载本身仍在线。 Railway 的基础设施旨在实现高可用性。我们的数据库跨多个可用区运行，网络在 AWS、GCP 和 Railway Metal 之间使用冗余连接。然而，恢复账户访问并没有恢复这些单独的服务。持久磁盘、计算实例和网络都需要单独恢复。由于此恢复过程的特性，中断时间延长了几个小时。磁盘在 23:54 UTC 恢复到就绪状态，但核心网络和边缘路由直到 5月20日约 01:30 UTC 才完全恢复。（我们正在等待确认，以查看此延迟和相关错误是否来自 Google 方面。） 随着网络恢复，Railway 核心服务的恢复和终端用户工作负载的验证逐层进行。为了防止压倒我们的构建系统，我们暂时暂停了部署，并逐步允许它们恢复。与核心系统恢复同时，GitHub 开始对 Railway 的 OAuth 和 webhook 集成进行速率限制，这是由于所有重试请求的数量和突发性质，暂时阻止了用户登录和构建。 到 5月20日约 04:00 UTC，API、控制台和 OAuth 端点确认运行正常，其余工作负载继续恢复。 https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#preventative-measures ## 预防措施 (https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage#preventative-measures) Railway 的网络控制平面旨在实现弹性。它是一个多 AZ、多区域的控制平面，可以容忍多台机器和组件的丢失，同时仍能正常运作且对用户无影响。这一点已在预发环境和实际流量中（在几个月前推出之前）经过测试。 我们已根据之前的事件对弹性进行了投入，这帮助我们应对了本次影响。之前的教训之一是 Railway 能够优雅地恢复用户 GitHub 安装，而不会触发二次速率限制。 然而，许多人在多个论坛上提出疑问：Railway 怎么会有一个影响所有客户工作负载的单一依赖项？ Railway 的网络是一个网状环，由 Metal <-> GCP <-> AWS 之间的高可用光纤互连构成。然而，在这个环中，仍然存在一个硬性依赖：工作负载的可发现性依赖于托管在 Google Cloud 机器上运行的控制平面 API。这意味着尽管网状结构在起初一小时内仍能运，但当路由缓存过期时，网状结构无法重新填充路由表。 我们正立即着手消除这一依赖，使其成为一个真正的网格。这意味着，如果任何互连出现故障，云之间始终存在一条路径。 因此，我们将把高可用数据库分片扩展到 AWS 和 Metal。将来，如果特定云中的所有实例瞬间消失，数据库仲裁将使一切保持运行，并立即故障转移任何不再运行的工作负载。 最后，我们正计划从数据平面的热路径中移除 Google Cloud 服务，仅将其保留用于辅助/故障转移场景。与此同时，我们正在为数据平面（实现与主机的连接）和控制平面（为用于访问和管理 Railway 的控制台提供动力）实施新架构。这些架构升级将确保我们的核心服务，尤其是面向用户的组件，不依赖于任何一个供应商或平台。 --- Railway 对我们选择的供应商负责，我们最终对此选择负责。您的客户不关心故障是 Google 还是 Railway 造成的；他们看到的是您的产品。您的正常运行时间是我们的责任，我们将持续履行这一责任。