Часть Google Cloud в американском регионе us-central1 оказалась недоступна после того, как инженер во время планового обслуживания за 13 минут физически отключил все оптоволоконные линии сразу у нескольких резервирующих друг друга маршрутизаторов. Сбой 1 сентября продолжался 4 часа 11 минут, а в пиковый момент затронутые ресурсы теряли до 100% сетевого трафика.
Google раскрыла необычную причину аварии в предварительном отчёте . Проблема затронула часть зоны us-central1-b в Айове и нарушила работу Compute Engine, Google Kubernetes Engine, Cloud SQL, BigQuery, Cloud Run, App Engine, Cloud Spanner, Bigtable, Filestore, VPC и ряда других сервисов. Клиенты не могли подключиться к виртуальным машинам, а сами виртуальные машины потеряли связь с ресурсами за пределами своей зоны.
Самое примечательное в аварии заключается в том, что инфраструктура была специально спроектирована для подобных отказов. Google распределяет сетевые соединения между несколькими маршрутизаторами, физически разводит оптоволоконные трассы и подключает оборудование к разным источникам питания. По расчётам компании, система должна безболезненно переживать отказ любого одного устройства или оптического пути, а большинство комбинаций из двух и даже трёх одновременных отказов не должны влиять на клиентский трафик.
Однако резервирование работает, пока резервные линии не отключают одну за другой. Инженер проводил плановое увеличение ёмкости маршрутизаторов дата-центра и из-за ошибки в процедуре последовательно разъединил 100% оптоволоконных путей на всех задействованных устройствах. На всю операцию ушло всего 13 минут. Google объясняет, что действия выполнялись настолько быстро, что предупреждения о неправильной последовательности не успели остановить специалиста до полного обрыва связности.
Автоматические системы мониторинга сразу обнаружили потерю сети и подняли инженеров и команду реагирования. Google начала переводить совместимые нагрузки на исправные мощности в других частях региона, а сотрудники дата-центра нашли отключённые оптические линии и физически подключили кабели обратно. После восстановления соединений трафик постепенно вернули на исходную инфраструктуру.
Остальные зоны региона us-central1 продолжали работать. Google сама рекомендует размещать критичные приложения в нескольких зонах или даже регионах, поскольку отдельная зона считается самостоятельным доменом отказа. Поэтому клиенты с резервными ресурсами за пределами us-central1-b могли переключить нагрузку, тогда как системы, жёстко привязанные к пострадавшей инфраструктуре, оставались недоступными.
Авария затронула не только виртуальные машины. У баз данных Cloud SQL, AlloyDB, Spanner и Bigtable возникали проблемы с доступом к данным и связностью, GKE терял доступ к отдельным кластерам и узлам, Cloud Run и App Engine фиксировали задержки и ошибки очередей. Google SecOps также столкнулся с перебоями в работе интерфейса и API для части клиентов региона.
После восстановления Google остановила плановые работы в регионе и начала дополнительные проверки процедур обслуживания. Компания пока называет опубликованный разбор предварительным и обещает выпустить окончательный отчёт с мерами, которые должны исключить повторение аварии.
История хорошо показывает неприятное ограничение аппаратного резервирования. Можно разнести маршрутизаторы, кабели и питание так, чтобы инфраструктура выдерживала несколько независимых поломок, но общая процедура обслуживания превращает независимые компоненты в один домен отказа. В данном случае Google построила сеть, способную пережить почти любую случайную поломку, а затем один человек методично отключил все запасные пути быстрее, чем система успела его остановить.