День, когда «сломался» интернет: как и почему произошел глобальный сбой Google — и при чем тут дата-центры
12 июня 2025 года мир погрузился в цифровой «полумрак»: замолкла музыка в Spotify, замерли ключевые сервисы Google, отказали системы жизнеобеспечения тысяч других приложений, сервисов и интернет-магазинов с миллионами пользователей по всей планете. Причина — масштабный сбой в Google Cloud Platform (GCP). Специалисты дата-центра ESTT изучили хронику событий и попытались разобраться — что произошло, как это связано с дата-центрами и почему это важный сигнал для всей индустрии?
Первые проблемы с сервисами Google начались 12 июня около 10:49 PDT (~19:49 по Москве) — пользователи стали замечать недоступность Gmail, Docs, Calendar, Drive и остальных «гугловских» приложений, серьезно барахлить начали Spotify, Discord, Twitch, Snapchat, OpenAl, Shopify и многие другие сервисы.
Инженеры Google отреагировали на сбой мгновенно и выявили причину за десять минут, однако «пламя» уже охватило слишком большой сегмент интернета. «Потушить» его быстро не получилось: приложения восстановили работу спустя только пару часов.
Для точного понимания, что же произошло, кратко восстановим картину событий.
Одна ошибка программиста — и дата-центр не спасет
Критическая ситуация возникла после обновления компьютерного кода в Service Control — ключевого технического внутреннего сервиса Google, через который проходят все запросы к серверам дата-центров.
Программист (или заменившая его нейросеть — всей правды мы, вероятно, уже не узнаем) не предусмотрел достаточно элементарную защиту сервиса от ошибки, суть которой — обращение к несуществующей памяти.
Вместо того, чтобы обойти или исключить проблемный запрос, программа на нем «споткнулась» и «легла», перестав обрабатывать клиентские запросы к центрам обработки данных (ЦОД) Google.
Само по себе это еще не катастрофа — мало ли что случается в процессе разработки, тестирования и отладки. Но по неясной пока причине Service Control остановился глобально, миновав все системные «предохранители»: тесты, проверки кода, осторожные запуски в отдельных географических регионах и т.д.
Спасать критическое положение пришлось аварийным стартом так называемого «процесса отката» (red-button rollback) по всей инфраструктуре Google.
Постепенно сервисы начали восстанавливаться и возвращаться к работе в большинстве регионов, кроме наиболее загруженных (например, us-central1) — там из-за нагрузки на базы данных и синхронизацию любой «откат» идет медленнее. Позднее Google официально подтвердил, что большая часть сервисов восстановлена, и предоставил отчет об инциденте. Резюмировать его можно так:
произошли обычные ошибки, только в этот раз — на инфраструктуре планетарного масштаба.
Помимо сайтов, которые «арендуют» у Google инфраструктурные мощности напрямую, сбой также затронул Cloudflare — глобальный сервис с серверами по всему миру, поддерживающий региональную работу множества интернет-ресурсов.
По данным специализированного сервиса Downdetector, всего 12 июня было зафиксировано более 14 700 жалоб на работу сервисов в США и тысячи сообщений по всему миру. Убытки коммерческих сервисов и приложений из-за ~2,5 часов простоя еще только предстоит подсчитать.
При чем тут дата-центры?
На первый взгляд — случилась сугубо программная ошибка, никак не связанная с серверами, маршрутизаторами и прочим «железом». Но масштабы сбоя показали: в современном облаке код и дата-центр неразрывно связаны. Архитектура Google Cloud подразумевает сильную «спайку» регионов. Когда выходит из строя центральный сервис управления — это отражается на всех точках входа в систему.
Здесь же вступает в игру глобальная синхронность серверов: унифицированные политики доступа, распределенные базы данных и автоматическая маршрутизация трафика между дата-центрами усиливают зависимость — и отказ в одной логической точке блокирует всю сеть.
Нагрузочные эффекты дата-центров
Дата-центры не просто обрабатывают запросы — они синхронизируют, масштабируют, кэшируют, распределяют. При сбое возникает лавина запросов на восстановление и аутентификацию, что парализует даже здоровые кластеры. Это и произошло при масштабном сбое в Google Cloud Platform, повлекшем каскадное «падение» половины интернета.
Уроки для индустрии обработки данных
Облачная архитектура требует отказоустойчивости не только в «железе» — серверах, но и в логике — компьютерном коде. Сегментация в дата-центрах помогает локализовать сбои и минимизировать глобальный эффект, такая же сегментация необходима и при любых изменениях в системах вроде Service Control.
Если Service Control перестает работать — это сравнимо с поломкой систем контроля безопасности в аэропорту: никто никуда не сможет попасть, даже если все остальное будет работать.
Выводы дата-центра ESTT
Инцидент 12 июня — напоминание, что цифровая стабильность требует физической надежности. Все начинается с дата-центров — и тех, кто строит их с учетом резервирования, распределения, сегментации и устойчивости к программным ошибкам.
Мы в ESTT создаем дата-центры, где отказ одной системы не превращается в отказ целого мира. Инфраструктура будущего — это инфраструктура, которой можно доверять.
Если вы создаете IT-продукты, управляете цифровым бизнесом, готовитесь к запуску сервиса, желаете провести аудит вашей инфраструктуры или просто хотите знать больше обо всем, что связано с центрами обработки данных, их созданием и перспективами развития цифровых технологий в эпоху ИИ — подписывайтесь на соцсети и блоги ESTT: они обо всем вам расскажут!