Google наконец рассказала, как случайная строка в коде парализовала половину интернета
NewsMakerВсе ждали объяснений сбоя. Теперь ясно: он был не случайностью, а закономерностью.
На прошлой неделе интернет по всему миру оказался в нестабильном состоянии — сервисы Cloudflare, Spotify, Discord, Snapchat, Twitch и множество других приложений начали массово сбоить. В центре событий оказалась инфраструктура Google Cloud : 13 июня в течение почти трёх часов клиенты по всему миру лишились доступа к арендуемым облачным ресурсам. Инцидент вызвал резонанс не только из-за масштаба, но и из-за того, что проблемы распространились каскадно — от самой Google до сервисов, которые на ней завязаны.
Теперь Google официально представила техническое объяснение случившегося. Как и в ряде других крупных инцидентов последних лет, корнем проблемы оказался не злонамеренный взлом и не внешняя атака, а ошибка внутри самой компании — ошибка в коде, который Google внедрила в систему управления квотами. Причём сбой оказался настолько «элегантно» закольцованным, что его последствия захлестнули сразу несколько уровней инфраструктуры, включая коммуникационные и мониторинговые.
На первый взгляд, всё началось с незначительного обновления: 29 мая в компонент Service Control — ключевой модуль, отвечающий за проверку квот и политик API в облаке — добавили поддержку дополнительной логики для контроля ресурсов. Этот компонент играет важную роль в архитектуре Google Cloud, обслуживая запросы через распределённые региональные экземпляры и обеспечивая соблюдение ограничений по квотам, авторизации и политике доступа.
Нововведение прошло стандартный поэтапный процесс развертывания по регионам, и на этапе выката всё выглядело благополучно. Однако была одна тонкость: изменённый код активировался только при определённых условиях — когда вступала в силу новая политика с конкретной структурой данных. И вот именно такая политика не была активирована на этапе тестирования. Поэтому проблемный участок кода не проявил себя ни в staging-среде, ни при региональном выкате. Он просто "дремал" внутри системы, ожидая триггера.
Критический момент наступил 12 июня, когда в одну из политик были внесены поля с пустыми значениями. Это стало тем самым триггером, который запустил неисследованный ранее путь выполнения кода. Новый фрагмент попытался обратиться к отсутствующим данным — и столкнулся с ошибкой null pointer. Результатом стала мгновенная авария бинарника, отвечающего за Service Control, и зацикленная перезагрузка. Причём проблема повторилась синхронно по всем регионам, потому что каждый из них читал одинаковые политики и запускал одну и ту же цепочку действий.
Google подтвердила, что этот код не был защищён фича-флагом (feature flag) — механизмом, который обычно позволяет в любой момент отключить спорное поведение до начала массового распространения. Если бы флаг использовался, инженеры смогли бы идентифицировать и изолировать проблему ещё до продакшн-этапа. Однако в данном случае его просто не предусмотрели. А обработка ошибок в коде также отсутствовала — что сделало сбой неустранимым без ручного вмешательства.
Site Reliability Engineering-команда Google отреагировала быстро: инцидент был зафиксирован спустя две минуты, причина установлена примерно за 10 минут, и уже через 40 инженеры начали восстановление. Но проблемы на этом не закончились. В крупных регионах, таких как us-central1, перезапуск Service Control привёл к перегрузке сопутствующей инфраструктуры. Механизм, рассчитанный на плановую работу, оказался не готов к лавинообразному количеству повторных запросов, вызвав эффект «стада» (herd effect) — когда однотипные процессы начинают одновременно обращаться к общей зависимости и перегружают её.
Поскольку Service Control — распределённая система, перегрузка в крупных точках распространилась каскадно, усложнив восстановление. В некоторых регионах восстановление длилось почти три часа. Одновременно с этим продукты Google, завязанные на Service Control, начали «падать» один за другим: Gmail, Drive, Meet, Calendar, Voice — все они испытали сбои различной степени. А клиенты Cloudflare, чей сервис Workers KV зависит от Google Cloud, столкнулись с отказом 90% запросов.
И хотя к вечеру 13 июня большинство систем вернулись в рабочее состояние, последствия инцидента продолжают разбираться до сих пор. Google пообещала не только не повторять те же ошибки, но и провести структурные изменения в процессе работы с инфраструктурным кодом. В частности, компания пообещала улучшить как автоматическую, так и ручную коммуникацию с клиентами — чтобы информация о критических сбоях доходила до них быстрее и точнее.
Также был сделан важный вывод: инфраструктура уведомлений и мониторинга должна быть изолирована от остальной части облака, чтобы продолжать функционировать даже в случае глобального сбоя. Таким образом, Google косвенно признала, что в ходе инцидента клиенты не получали достаточной информации в реальном времени именно из-за того, что инструменты оповещения сами были завязаны на упавшую инфраструктуру.
Финальное резюме, предложенное компанией, звучит почти как признание: несмотря на вложенные усилия и уровень зрелости, полностью устранить вероятность масштабных сбоев в такой архитектуре невозможно. Вопрос лишь в том, насколько оперативно удаётся реагировать — и насколько эффективно выстроена система страховок и каналов связи.
На прошлой неделе интернет по всему миру оказался в нестабильном состоянии — сервисы Cloudflare, Spotify, Discord, Snapchat, Twitch и множество других приложений начали массово сбоить. В центре событий оказалась инфраструктура Google Cloud : 13 июня в течение почти трёх часов клиенты по всему миру лишились доступа к арендуемым облачным ресурсам. Инцидент вызвал резонанс не только из-за масштаба, но и из-за того, что проблемы распространились каскадно — от самой Google до сервисов, которые на ней завязаны.
Теперь Google официально представила техническое объяснение случившегося. Как и в ряде других крупных инцидентов последних лет, корнем проблемы оказался не злонамеренный взлом и не внешняя атака, а ошибка внутри самой компании — ошибка в коде, который Google внедрила в систему управления квотами. Причём сбой оказался настолько «элегантно» закольцованным, что его последствия захлестнули сразу несколько уровней инфраструктуры, включая коммуникационные и мониторинговые.
На первый взгляд, всё началось с незначительного обновления: 29 мая в компонент Service Control — ключевой модуль, отвечающий за проверку квот и политик API в облаке — добавили поддержку дополнительной логики для контроля ресурсов. Этот компонент играет важную роль в архитектуре Google Cloud, обслуживая запросы через распределённые региональные экземпляры и обеспечивая соблюдение ограничений по квотам, авторизации и политике доступа.
Нововведение прошло стандартный поэтапный процесс развертывания по регионам, и на этапе выката всё выглядело благополучно. Однако была одна тонкость: изменённый код активировался только при определённых условиях — когда вступала в силу новая политика с конкретной структурой данных. И вот именно такая политика не была активирована на этапе тестирования. Поэтому проблемный участок кода не проявил себя ни в staging-среде, ни при региональном выкате. Он просто "дремал" внутри системы, ожидая триггера.
Критический момент наступил 12 июня, когда в одну из политик были внесены поля с пустыми значениями. Это стало тем самым триггером, который запустил неисследованный ранее путь выполнения кода. Новый фрагмент попытался обратиться к отсутствующим данным — и столкнулся с ошибкой null pointer. Результатом стала мгновенная авария бинарника, отвечающего за Service Control, и зацикленная перезагрузка. Причём проблема повторилась синхронно по всем регионам, потому что каждый из них читал одинаковые политики и запускал одну и ту же цепочку действий.
Google подтвердила, что этот код не был защищён фича-флагом (feature flag) — механизмом, который обычно позволяет в любой момент отключить спорное поведение до начала массового распространения. Если бы флаг использовался, инженеры смогли бы идентифицировать и изолировать проблему ещё до продакшн-этапа. Однако в данном случае его просто не предусмотрели. А обработка ошибок в коде также отсутствовала — что сделало сбой неустранимым без ручного вмешательства.
Site Reliability Engineering-команда Google отреагировала быстро: инцидент был зафиксирован спустя две минуты, причина установлена примерно за 10 минут, и уже через 40 инженеры начали восстановление. Но проблемы на этом не закончились. В крупных регионах, таких как us-central1, перезапуск Service Control привёл к перегрузке сопутствующей инфраструктуры. Механизм, рассчитанный на плановую работу, оказался не готов к лавинообразному количеству повторных запросов, вызвав эффект «стада» (herd effect) — когда однотипные процессы начинают одновременно обращаться к общей зависимости и перегружают её.
Поскольку Service Control — распределённая система, перегрузка в крупных точках распространилась каскадно, усложнив восстановление. В некоторых регионах восстановление длилось почти три часа. Одновременно с этим продукты Google, завязанные на Service Control, начали «падать» один за другим: Gmail, Drive, Meet, Calendar, Voice — все они испытали сбои различной степени. А клиенты Cloudflare, чей сервис Workers KV зависит от Google Cloud, столкнулись с отказом 90% запросов.
И хотя к вечеру 13 июня большинство систем вернулись в рабочее состояние, последствия инцидента продолжают разбираться до сих пор. Google пообещала не только не повторять те же ошибки, но и провести структурные изменения в процессе работы с инфраструктурным кодом. В частности, компания пообещала улучшить как автоматическую, так и ручную коммуникацию с клиентами — чтобы информация о критических сбоях доходила до них быстрее и точнее.
Также был сделан важный вывод: инфраструктура уведомлений и мониторинга должна быть изолирована от остальной части облака, чтобы продолжать функционировать даже в случае глобального сбоя. Таким образом, Google косвенно признала, что в ходе инцидента клиенты не получали достаточной информации в реальном времени именно из-за того, что инструменты оповещения сами были завязаны на упавшую инфраструктуру.
Финальное резюме, предложенное компанией, звучит почти как признание: несмотря на вложенные усилия и уровень зрелости, полностью устранить вероятность масштабных сбоев в такой архитектуре невозможно. Вопрос лишь в том, насколько оперативно удаётся реагировать — и насколько эффективно выстроена система страховок и каналов связи.