Половина интернета зависла: пользователи со всего мира пожаловались на сбои в Google и других сервисах
Почему 12 июня рухнул интернет: честный разбор глобального сбоя Google, AWS и Cloudflare
12 июня 2024 года, ближе к вечеру по Москве, половина интернета просто перестала отвечать. Gmail, YouTube, Google Карты, Spotify, Discord — всё легло. И это не локальная проблема одного дата-центра. Сбой задел сразу трёх гигантов: Google, Amazon Web Services (AWS) и Cloudflare. Давайте разбираться, что произошло на самом деле, почему такое случается и как от этого защититься.
Картина маслом: что и когда ломалось
Первые сигналы пошли около 20:30 мск. К 21:25 количество жалоб зашкалило. В зоне поражения оказались умные колонки Nest, облачные платформы Google Cloud и Firebase, а также сервисы, работающие на AWS и защищённые Cloudflare. Пользователи не могли зайти в почту, запустить стрим, вызвать такси. Даже банковские системы, завязанные на облачную инфраструктуру, давали сбои.
Интересная деталь: официальные панели статуса Google Workspace и Cloud при этом показывали зелёную галочку. А в соцсетях — ад. Это характерная черта современных распределённых систем — реальная картина доступности часто запаздывает на 10–20 минут.
Три кита, которые упали одновременно
Сбой задел три ключевых звена интернет-инфраструктуры. AWS обеспечивает вычислительные мощности. Cloudflare — CDN и защиту от DDoS. Google — облачные сервисы и DNS. Когда они ложатся одновременно, возникает эффект домино. Сайты, которые используют все три, полностью теряют связь с пользователем.
Cloudflare признала проблему через час после начала. Google — только в 22:41 мск, когда сервисы уже начали восстанавливаться. AWS до сих пор молчала (на момент обновления статьи). Это говорит о разном уровне прозрачности и внутренних регламентах. Моё личное наблюдение: компании с публичным SLA обычно быстрее признают сбой — боятся судебных исков. Молчуны же надеются, что «само рассосётся».
Сбой в инфраструктуре — не вопрос «если», а вопрос «когда». Отличаются только масштабы и скорость реакции.
Как это работает: типичная анатомия глобального даунтайма
- Триггер — ошибка конфигурации маршрутизации (BGP), сбой в DNS или отказ системы управления кластером.
- Каскад — один отказ перегружает соседние узлы, они тоже падают. За 5–10 минут проблема распространяется на континенты.
- Обнаружение — внутренние мониторинги часто настроены с лагом в 10–15 минут, поэтому внешние агрегаторы (вроде DownDetector) быстрее показывают реальность.
- Митигация — инженеры вручную отключают проблемные сегменты, переключают трафик на резервные мощности.
- Восстановление — постепенное включение сервисов по мере стабилизации. Полное возвращение к норме — от 40 минут до нескольких часов.
В этом случае всё уложилось в 2–2,5 часа. Для масштаба трёх гигантов — достойно, хотя нервов вымотало много.
Сравнительная таблица: кто как реагировал
| Сервис | Пик сбоя (мск) | Статус признания | Время восстановления | Особенности |
|---|---|---|---|---|
| Google (Gmail, YouTube, Cloud) | 21:25 | Признан в 22:41 | ~22:45 – частично, Meet ещё проблемы | Долго молчали, панель статуса врала |
| AWS | ~21:30 | Не признан (на момент обновления) | Не указано | Частичная недоступность облачных ресурсов |
| Cloudflare | ~20:30 | Подтверждён | ~22:00 – начали восстанавливаться | Быстрое признание, открытая коммуникация |
Что делать обычному пользователю и бизнесу
Никто не застрахован. Но можно снизить риски.
- Не кладите все яйца в одну корзину. Используйте мультиоблачные архитектуры: часть в AWS, часть в Azure, резервный DNS у другого провайдера.
- Мониторинг внешней доступности. Нанять сервис вроде Pingdom или UptimeRobot — дёшево и позволяет узнать о сбое раньше, чем от пользователей.
- Автоматическое переключение. Настройте failover: если основной DNS не отвечает 2 минуты — трафик идёт на запасной IP.
- Соглашение об уровне обслуживания (SLA). Выбирайте облачных провайдеров с SLA минимум 99.99% и штрафами за даунтайм. Это дисциплинирует их инженеров.
Лично я держу копию критичных писем локально. После вчерашнего — убедился, что правильно делаю.
Резюме от автора
Глобальный сбой 12 июня — не случайность, а симптом. Интернет стал слишком централизован: три компании держат львиную долю инфраструктуры. Пока рынок не созреет для децентрализованных решений, такие «чёрные часы» будут повторяться. Единственный способ выжить — готовиться. Резервирование, мониторинг, трезвая оценка SLA. И ничего не принимать как должное. Даже Gmail может упасть.
