Сбой Google Cloud оставил без доступа пользователей Revolut и банков

Google указала, что проблема началась в регионе europe-west2 в 23:08 PDT 19 октября 2026 года, однако закрытие инцидента на статусной странице Cloud не означало мгновенного восстановления всех приложений. Для аудитории цифровых сервисов это конкретный пример разрыва между доступностью облачной инфраструктуры и готовностью прикладного продукта.

Инфраструктура восстановилась раньше приложений

Около 10:00 ET 20 октября Google закрыла заявленный инцидент. В обновлении на статусной странице Cloud говорилось, что большинство затронутых продуктов уже работают нормально, а предполагаемое влияние ограничено небольшим числом клиентов. Инженерная команда продолжала работать с оставшимися проблемами.

Банковские сервисы восстанавливались медленнее. Revolut и HSBC по-прежнему показывали ошибки на своих статусных страницах, а пользователи Revolut сообщали о сбоях вплоть до 11:30 ET. Источник CNN, на который ссылается Mashable, связал сбой Google Cloud непосредственно с проблемами Revolut.

Изначально ситуация выглядела локализованной в Европе. Позднее на американской статусной странице Revolut появились те же типы ошибок, но оставалось неясным, действительно ли пострадали клиенты в США или это был сбой самой страницы. Соответственно, преждевременно считать клиентский эффект полностью устранённым можно было только при совпадении сигналов Google, банка и реальных обращений пользователей.

Что проверять пользователю

Если приложение банка или другого критичного сервиса недоступно, полезно разделить проблему на три уровня. Первый, инфраструктурный, показывает статус облачного провайдера. Второй, прикладной, отражает состояние конкретного сервиса банка или разработчика. Третий, пользовательский, включает реальные сценарии: вход в аккаунт, историю операций, платежи и обращения в поддержку.

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

Что учитывать при выборе цифрового стека

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

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

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