Отчёт об инциденте: 19 мая 2026 года — приостановка аккаунта GCP
Railway пережил общесистемный сбой из-за того, что Google Cloud ошибочно перевёл наш аккаунт в статус заблокированного. Это повлекло временную потерю доступа ко всей инфраструктуре, размещённой на GCP. Данная инфраструктура обслуживает наш дашборд, API и часть сетевых компонентов. По мере истечения кэшированных сетевых маршрутов сбой вышел за пределы GCP и затронул все рабочие нагрузки Railway.
Ниже мы подробно разбираем, что произошло, как мы реагировали и что меняем, чтобы исключить подобное в будущем.
19 мая 2026 года в период с 22:20 UTC до приблизительно 06:14 UTC 20 мая (~8 часов) Railway испытывал общесистемный сбой после того, как Google Cloud заблокировал сервисы на нашем производственном аккаунте. В результате отключились наш API, управляющий уровень (control plane), базы данных и вычислительная инфраструктура, размещённая на Google Cloud.
Пользователи сразу начали получать ошибки 503 на дашборде и в API, в том числе сообщения «no healthy upstream» и «unconditional drop overload», и не могли войти в систему. Все рабочие нагрузки на вычислительных мощностях Google Cloud были остановлены.
Рабочие нагрузки на наших собственных серверах Railway Metal и в AWS burst-cloud оставались доступны, однако граничные прокси (edge proxies) Railway полагаются на API управляющего уровня, размещённый на Google Cloud, для формирования таблиц маршрутизации. Из-за этого сбой каскадно распространился за пределы Google Cloud: по истечении кэша маршрутов остальные рабочие нагрузки тоже стали недоступны и начали возвращать ошибки 404 — управляющий уровень сети больше не мог разрешать маршруты к активным инстансам. В пиковый момент все рабочие нагрузки Railway во всех регионах оказались недостижимы.
В процессе восстановления среды Google Cloud сборки и деплои были заблокированы на всей платформе, пока мы поочерёдно восстанавливали отдельные сервисы. После полного восстановления инфраструктуры накопившаяся очередь деплоев постепенно обрабатывалась, чтобы не перегружать платформу. Параллельно GitHub начал ограничивать (rate-limiting) OAuth- и webhook-интеграции Railway, временно блокируя входы в систему и сборки — объём этих запросов вырос из-за сброса кэша в ходе сбоя на Google Cloud. Побочным эффектом также стал сброс записей о принятии пользовательского соглашения (Terms of Service): пользователям пришлось заново принять его при следующем визите на дашборд.
Мы полностью принимаем ответственность за архитектурные решения, которые позволили единственному действию стороннего провайдера перерасти в общесистемный сбой. Ниже подробно описано, что произошло, как мы восстанавливались и какие изменения вносим.
-
19 мая, 22:10 UTC — Автоматический мониторинг зафиксировал сбои в health-check API и уведомил дежурных инженеров, которые немедленно приступили к расследованию.
-
19 мая, 22:11 UTC — Дашборд возвращает ошибки 503. Пользователи не могут войти в систему.
-
19 мая, 22:19 UTC — Установлена первопричина: Google Cloud Platform заблокировал производственный аккаунт Railway.
-
19 мая, 22:22 UTC — Подан приоритетный тикет P0 в Google Cloud. К решению вопроса напрямую подключён менеджер аккаунта Railway в GCP.
-
19 мая, 22:29 UTC — Инцидент официально объявлен.
-
19 мая, 22:29 UTC — Доступ к аккаунту GCP восстановлен. Все вычислительные инстансы остаются остановленными, постоянные диски (persistent disks) недоступны.
-
19 мая, 22:35 UTC — Кэшированные сетевые маршруты начали истекать; рабочие нагрузки на Railway Metal и AWS начали возвращать ошибки 404, так как сеть больше не может разрешать маршруты.
-
19 мая, 23:09 UTC — Первый постоянный диск вернулся в рабочее состояние.
-
19 мая, 23:54 UTC — Все постоянные диски переведены в состояние готовности. Сеть по-прежнему недоступна.
-
20 мая, 00:39 UTC — Диски подтверждены как готовые. Восстановление заблокировано ожиданием восстановления сети Google Cloud.
-
20 мая, 01:30 UTC — Вычислительные инстансы начали восстанавливаться.
-
20 мая, 01:38 UTC — Граничный трафик снова обслуживается. Сеть восстановлена.
-
20 мая, 01:57 UTC — Инфраструктура оркестрации и сборок восстановлена. Деплои временно приостановлены, чтобы предотвратить перегрузку систем при одновременном запуске накопившейся очереди.
-
20 мая, 02:04 UTC — Вычислительные хосты постепенно вводятся в строй.
-
20 мая, 02:47 UTC — GitHub начал применять rate-limiting к OAuth- и webhook-интеграциям Railway; часть пользователей не может войти в систему, сборки заблокированы.
-
20 мая, 02:55 UTC — Дашборд снова доступен.
-
20 мая, 03:59 UTC — Деплои начинают обрабатываться снова на всех уровнях.
-
20 мая, 04:00 UTC — API, дашборд и OAuth-эндпоинты подтверждены работоспособными. Восстановление оставшихся рабочих нагрузок продолжается.
-
20 мая, 06:14 UTC — Инцидент переведён в режим мониторинга.
-
20 мая, 07:58 UTC — Инцидент закрыт.
Что произошло
В 22:20 UTC 19 мая 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 спроектирована с прицелом на высокую доступность: базы данных работают в нескольких зонах доступности (availability zones), а сеть использует резервные соединения между AWS, GCP и Railway Metal. Однако восстановление доступа к аккаунту не означало автоматического восстановления отдельных сервисов. Постоянные диски, вычислительные инстансы и сетевые компоненты требовали раздельного восстановления, что в совокупности затянуло простой на несколько часов. Диски вернулись в состояние готовности к 23:54 UTC, однако основная сеть и граничная маршрутизация полностью восстановились лишь около 01:30 UTC 20 мая. (Мы ждём подтверждения от Google, была ли эта задержка и сопутствующие ошибки на их стороне.)
По мере восстановления сети ключевые сервисы Railway и рабочие нагрузки пользователей возвращались в строй последовательно, слой за слоем. Чтобы не перегрузить системы сборки, мы временно приостановили деплои и постепенно возобновляли их. Параллельно с восстановлением основных систем GitHub начал ограничивать OAuth- и webhook-интеграции Railway из-за высокого объёма и всплескового характера повторных запросов, временно блокируя вход пользователей и сборки.
К приблизительно 04:00 UTC 20 мая API, дашборд и OAuth-эндпоинты были подтверждены работоспособными, восстановление оставшихся рабочих нагрузок продолжалось.
Как мы предотвратим повторение
Управляющий уровень сети Railway спроектирован с расчётом на устойчивость: это мультизонный (multi-AZ, multi-zone) управляющий уровень, способный выдержать отказ нескольких машин и компонентов без какого-либо воздействия на пользователей. Это было проверено как на стейджинге, так и на реальном трафике (до его полноценного запуска несколько месяцев назад).
Благодаря урокам прошлых инцидентов мы вложили значительные усилия в повышение отказоустойчивости. Один из примеров таких решений — возможность Railway корректно восстанавливать GitHub-инсталляции пользователей без возникновения вторичных rate-limit’ов.
Тем не менее многие спрашивают на различных площадках: как у Railway вообще могла оказаться единственная зависимость, способная затронуть все рабочие нагрузки клиентов?
Сеть Railway — это кольцевая mesh-сеть (mesh ring), построенная на высокодоступных оптоволоконных соединениях между Metal, GCP и AWS. Однако в этом кольце по-прежнему существовала жёсткая зависимость: обнаружение рабочих нагрузок (workload discoverability) было привязано к API сетевого управляющего уровня, работающему на машинах в Google Cloud. Это означало, что, несмотря на то что сама mesh-сеть продолжала функционировать около часа, по истечении кэша маршрутов она не смогла заново заполнить таблицы маршрутизации.
Мы немедленно приступаем к устранению этой зависимости, чтобы сделать сеть по-настоящему распределённой (true mesh). В результате при отказе любого из межоблачных соединений путь между облаками всегда будет сохраняться.
Кроме того, мы распределим высокодоступные шарды баз данных между AWS и Metal. В будущем, если все инстансы в каком-либо облаке внезапно пропадут, кворум базы данных обеспечит непрерывную работу и немедленный перенос (failover) остановившихся рабочих нагрузок.
Наконец, мы планируем вывести сервисы Google Cloud из «горячего» пути (hot path) нашего уровня данных (data plane), оставив их лишь в качестве вторичного или резервного варианта. Это происходит параллельно с внедрением новой архитектуры для уровня данных (обеспечивающего подключение к хостам) и управляющего уровня (на котором работает дашборд для доступа к Railway и управления им). Эти архитектурные изменения обеспечат независимость наших ключевых сервисов, и прежде всего компонентов, с которыми взаимодействуют пользователи, от какого-либо одного вендора или платформы.
Заключение
Railway сам выбирал своих вендоров — и сам несёт за это ответственность. Вашим пользователям безразлично, на чьей стороне произошёл сбой — Google или Railway: они видят только ваш продукт. Ваш аптайм — наша ответственность, и мы продолжим её нести.