22 октября Google опубликовала предварительный отчёт о сбое в лондонском регионе europe-west2, который 20 октября на 6 часов 10 минут нарушил работу десятков сервисов и, по данным прессы, задел клиентов среди британских банков и ретейлеров.
Что произошло
- Перебой городского питания на площадке зоны europe-west2-b перевёл нагрузку на ИБП.
- Основная и резервная системы автоматики (PLC) не смогли запустить аварийные дизель-генераторы.
- Через несколько минут батареи ИБП разрядились, и серверы, сетевое оборудование и локальные хранилища зоны отключились.
- Мониторинг заметил рост ошибок через 8 минут; основная часть сервисов восстановилась примерно через 5,5 часа, ещё дольше тянулся «хвост» отдельных VM.
Масштаб
В списке затронутых — Compute Engine, GKE, Cloud Run, Cloud SQL, AlloyDB, Spanner, BigQuery, Pub/Sub, Cloud Storage, Persistent Disk, Load Balancing, Cloud NAT, Memorystore и многие другие.
Важная деталь: проблемы были и в «здоровых» зонах a и c. Причины — резкий рост нагрузки на оставшиеся мощности при переезде и вызовы control plane, зависевшие от отключённой зоны. Сервисы с поддержкой failover (Cloud SQL, AlloyDB, Memorystore for Redis, Bigtable) переключились, но с задержками, ошибками 500/503 и очередями.
Выводы для инженеров
- Мультизональность не равна устойчивости: при потере зоны нужно иметь запас мощности в остальных и заранее зарезервированные ресурсы — Google в ходе восстановления в первую очередь обслуживала активные резервации.
- Стоит проверить, не зависят ли ваши деплои и автоскейлинг от операций control plane, которые могут встать при сбое зоны.
- Для критичных систем — рассмотреть мультирегиональную схему.
Финальный отчёт с мерами по предотвращению Google обещает после завершения расследования.
On October 22 Google published a preliminary incident report for the outage in its London region europe-west2, which on October 20 disrupted dozens of services for 6 hours 10 minutes and, according to press reports, hit customers including UK banks and retailers.
What happened
- A grid power disruption at the facility hosting zone europe-west2-b moved the load to UPS.
- Both the primary and backup PLC automation systems failed to start the emergency diesel generators.
- Within minutes the UPS batteries drained, and the zone’s servers, network gear and local storage went offline.
- Monitoring flagged rising errors after 8 minutes; most services recovered after about 5.5 hours, with a longer tail for individual VMs.
Scope
Affected products include Compute Engine, GKE, Cloud Run, Cloud SQL, AlloyDB, Spanner, BigQuery, Pub/Sub, Cloud Storage, Persistent Disk, Load Balancing, Cloud NAT, Memorystore and many more.
A key detail: the “healthy” zones a and c had problems too. The causes were demand surges on the remaining capacity during failover and control-plane calls that depended on the offline zone. Failover-capable services (Cloud SQL, AlloyDB, Memorystore for Redis, Bigtable) switched over, but with latency, 500/503 errors and queuing.
Takeaways for engineers
- Multi-zone is not the same as resilient: losing a zone requires spare capacity elsewhere and pre-reserved resources — during recovery Google prioritized active reservations.
- Check whether your deploys and autoscaling depend on control-plane operations that can stall during a zone failure.
- For critical systems, consider a multi-region setup.
Google says a final report with preventive actions will follow once the investigation is complete.