Крупнейший облачный провайдер опубликовал официальный отчёт о причинах массового отказа сервисов 13 июня. Расследование показало, что корень проблемы крылся в незаметной на первый взгляд ошибке системы квотирования ресурсов. Инцидент начался с рутинного обновления компонента Service Control 29 мая. Разработчики добавили новую логику контроля ресурсов, которая прошла все этапы тестирования без замечаний. Однако критическая уязвимость осталась незамеченной: проблемный код активировался только при определённой конфигурации политик, не использовавшейся в тестовой среде.
12 июня введение пустых значений в одну из рабочих политик стало триггером катастрофы. Система столкнулась с ошибкой null pointer, вызвавшей лавинообразный крах экземпляров Service Control по всем регионам. Несмотря на оперативное реагирование SRE-команды, которая установила причину сбоя за 10 минут, масштабы сбоя оказались беспрецедентными. Массовые одновременные запросы перегрузили инфраструктуру, а каскадные отказы затронули взаимосвязанные сервисы. Свою роль сыграл тот факт, что критические системы мониторинга оказались в той же среде, что и основные сервисы.
Компания анонсировала структурные изменения для предотвращения подобных инцидентов. Планируется создание изолированной инфраструктуры для мониторинга и пересмотр процессов тестирования и развёртывания изменений. Этот случай вновь продемонстрировал уязвимость современной цифровой экосистемы, где отказ одного ключевого компонента может парализовать сотни зависимых сервисов по всему миру. Google обещает сделать свои облачные решения более устойчивыми, но вопрос глобальной надёжности интернет-инфраструктуры остаётся открытым.
Ранее сбой системы в кроссовере Lixiang L9 из-за рекламы спровоцировал аварию.