В Лондоне у Google Cloud не запустились генераторы: зона легла на 6 часов и потянула соседние
Отказ автоматики запуска генераторов в одной зоне europe-west2 ударил и по клиентам из двух соседних, так что «мы в нескольких зонах» не стало страховкой.
С 19 на 20 октября 2026 года в регионе Google Cloud europe-west2 (Лондон) пропало питание в одном из дата-центров. По предварительному отчёту Google, опубликованному 22 октября, авария длилась 6 часов 10 минут. Прямо упала зона europe-west2-b, но проблемы возникли и у клиентов в зонах a и c. Зона здесь — отдельная площадка внутри региона, и облака продают именно её изолированность.
Отчёт пока предварительный: анализ причин ещё идёт, итоговый документ с мерами обещан позже. Всё ниже — по тому, что Google уже написал.
Резервное питание есть, но включиться не смогло
Сначала отказало внешнее электроснабжение дата-центра. Дальше сработала обычная схема: нагрузку взяли на себя батареи бесперебойного питания (UPS), а аварийные дизель-генераторы должны были запуститься и подхватить её. Не подхватили: по данным Google, и основной, и резервный контроллеры автоматики (PLC — промышленные контроллеры, которые командуют запуском и переключением) не смогли ни завести генераторы, ни перевести на них нагрузку.
Батареи продержались около семи минут, с 06:53 до 07:00. Когда заряд кончился, без питания остались серверы, сетевая фабрика и локальные хранилища зоны. По таймлайну Google: сбой питания в 06:53 по лондонскому времени 20 октября, отключение в 07:00, в 07:08 мониторинг зафиксировал рост ошибок.
Контроллер был зарезервирован, но отказали оба. Почему — Google пока не пояснил, число и мощность генераторов в отчёте тоже не приведены.
Падение одной зоны перетекло в соседние
Самое неприятное для тех, кто считал себя защищённым: пострадали и неповреждённые зоны. Google называет два механизма. Трафик и спрос на вычисления с упавшей зоны хлынули в оставшиеся. А межзональные вызовы управляющего слоя (control plane — часть облака, которая создаёт и перемещает ресурсы) к выключенной зоне упирались в таймауты.
В списке затронутых продуктов — Compute Engine, GKE, Cloud SQL, Cloud Run, Cloud Storage, BigQuery и ещё около 30 продуктов из шапки инцидента. Среди тех, у кого была межзональная деградация, отчёт называет BigQuery, Looker, Compute Engine, GKE, региональные Persistent Disk и Cloud SQL. Симптомы — повышенная доля ошибок, таймауты API, задержки обработки и ответы HTTP 500 и 503. Сколько клиентов пострадало, Google не сообщает.
Восстановление шло в пять шагов и заняло утро
- Маршрутизацию увели от europe-west2-b, чтобы межзональные запросы перестали висеть в таймаутах.
- Планировщик перенастроили так, чтобы в первую очередь обслуживались существующие резервации клиентов, и разгребли очереди.
- Вернули внешнее питание, а контроллеры генераторов сбросили и протестировали.
- Инфраструктуру и сервисы поднимали последовательно.
- Трафик возвращали постепенно, после проверок состояния и целостности хранилищ.
Основная фаза закончилась в 12:29 по Лондону, создание новых виртуальных машин возобновилось в 12:46, а к 13:10 больше 99% машин Compute Engine были в порядке. Клиентам на время аварии советовали по возможности переехать в другую зону или регион. Инцидент закрыли в 15:03, а тем, у кого остались проблемы с машинами, предложили обратиться в поддержку.
Что проверить у себя
- Выяснить, что на самом деле лежит в одной зоне: базы с одной репликой, диски без региональной репликации, единственный NAT или балансировщик.
- Проверить, выдержат ли оставшиеся зоны полную нагрузку: квоты и запас по мощности нужны заранее, в аварию ресурсов разом попросят все.
- Не рассчитывать на создание новых машин и перенос ресурсов во время аварии: управляющий слой может отвечать таймаутами, поэтому запас нужно держать уже запущенным.
- Посчитать цену часов простоя и сравнить с ценой второго региона: для критичных сервисов это может оказаться разумнее ещё одной зоны в том же регионе.
- Прогнать учения: выключить одну зону в тестовой среде и посмотреть, что не поднимется само.
- Для собственных серверных: регулярно проверять запуск генераторов под нагрузкой и автоматическое переключение, а не только заряд батарей.
Разборы аварий и практику для админов публикуем в Telegram-канале «Полный Ops».