Сбой Railway 19 мая: как ограничение аккаунта Google Cloud парализовало платформу

Какие сервисы исчезли

Ограничение аккаунта затронуло компоненты, на которых держалась как клиентская инфраструктура Railway, так и её собственная внутренняя логика управления.

По данным Railway, одновременно были потеряны несколько ключевых элементов:

• CloudSQL, где хранились данные платформы
• API Railway, центральная зависимость для большинства сервисов
• Overflow‑VM — дополнительные виртуальные машины для масштабирования вычислений

Особенно критичной оказалась потеря API платформы. Этот сервис был важной частью управляющего уровня (control plane), и его исчезновение мгновенно нарушило работу других систем, которые зависели от него.

Почему перестала работать почти вся платформа

После отключения этих сервисов Railway не могла корректно выполнять ключевые операции:

• вход пользователей и работу панели управления
• процессы деплоя приложений
• маршрутизацию трафика к запущенным сервисам
• сборку и развёртывание новых workloads

В результате одновременно пострадали и интерфейсы для разработчиков, и приложения, размещённые на платформе.

Почему сбой распространился дальше

Проблема не ограничилась удалёнными ресурсами Google Cloud. Сбой стал распространяться дальше, потому что слои оркестрации и маршрутизации Railway зависели от тех же отключённых сервисов.

Инженеры Railway сообщали, что для восстановления некоторых проектов пользователям приходилось повторно деплоить приложения, чтобы система могла перенаправить их код на здоровую машину после частичного восстановления инфраструктуры.

Это означает, что управляющая система, отвечающая за планирование задач, маршрутизацию и пересборку сервисов, не могла автоматически восстановить все workloads, пока ключевые ресурсы Google Cloud оставались недоступны.

Некоторые обсуждения в сообществе предполагали, что проблемы могли затронуть и workloads, работающие вне Google Cloud — например, на AWS или собственном железе Railway. Вероятная причина — невозможность обновить состояние маршрутизации платформы. Однако точный механизм каскадного сбоя пока не подтверждён полноценным публичным постмортемом.

Урок о «мультиоблачности»

Один из главных выводов, который активно обсуждали после инцидента, касается архитектуры облачных систем.

Railway использует несколько сред — включая AWS и собственные серверы — однако событие показало, что устойчивость системы определяется не только тем, где выполняются workloads, но и тем, где находится управляющий уровень.

Если такие элементы, как:

• оркестрация инфраструктуры
• базы данных платформы
• система идентификации
• конфигурация маршрутизации

зависят от одного облачного аккаунта, то этот аккаунт фактически становится единой точкой отказа.

В случае Railway потеря доступа означала потерю не только вычислительных ресурсов, но и систем, которые:

• отслеживают деплои
• управляют маршрутизацией
• создают инфраструктуру
• восстанавливают workloads

Именно эта зависимость позволила одному событию — ограничению аккаунта — повлиять на всю платформу.

Вопросы к автоматическим ограничениям облачных провайдеров

Инцидент также вызвал дискуссию о механизмах автоматического контроля аккаунтов в крупных облаках.

Облачные провайдеры могут автоматически ограничивать или блокировать аккаунты по различным причинам: например, из‑за подозрительной активности, нарушений политики или проблем с оплатой. В данном случае точная причина ограничения аккаунта Railway публично не раскрыта, поэтому неизвестно, было ли это автоматическое срабатывание системы, ошибка или другое событие.

Этот случай подчеркнул два операционных риска:

• автоматические действия провайдера могут мгновенно отключить критическую инфраструктуру
• даже крупные клиенты с корпоративной поддержкой могут ждать часы, пока выясняется причина ограничения

Что до сих пор неизвестно

Несмотря на обновления от Railway и обсуждения в сообществе, несколько ключевых деталей остаются неясными:

• точная причина, по которой Google Cloud ограничил аккаунт
• полная схема зависимостей между CloudSQL, API, системой маршрутизации и вычислительной инфраструктурой
• подтверждение некоторых каскадных эффектов, обсуждавшихся в сообществе

До публикации полноценного технического постмортема многие детали остаются реконструкцией на основе доступных сообщений и наблюдений.

Главный вывод для облачных платформ

Сбой Railway 19 мая показывает важную особенность современной инфраструктуры: решающую роль играет управляющий уровень (control plane).

Даже если вычисления распределены между несколькими облаками, платформа может полностью остановиться, если система, управляющая деплоями, маршрутизацией и оркестрацией, зависит от одного облачного аккаунта.

Когда такой уровень управления исчезает — пусть даже временно — вся платформа может оказаться офлайн.