«Мы глубоко сожалеем»: Google выпустила мини-отчёт об инциденте, сломавшем половину интернета

Google Cloud рухнул на три часа: что пошло не так и как не потерять бизнес на облачных сбоях

12 июня 2024 года в 21:49 по Москве инженеры по всему миру увидели ошибку 503. Discord, Spotify, Snapchat, OpenAI — десятки сервисов перестали отвечать. Причина? Автоматическое обновление квоты в системе управления API Google Cloud. Этот случай — не единичный. Давайте разберемся, что произошло под капотом.

Анатомия сбоя: как одна квота положила пол-интернета

Google опубликовал мини-отчет об инциденте. Официально: в 10:49 по тихоокеанскому времени система управления API начала рассылать недопустимые обновления квот. Эти данные распространились по всем регионам. Результат — внешние запросы API начали получать отказ (503) практически мгновенно. Восстановление заняло три часа — до 13:39.

Но самое интересное — почему так долго. База данных политики квот в регионе us-central1 оказалась перегружена. Она не справилась с лавиной поврежденных метаданных. В других регионах проблему решили за два часа, включив обход проверки квоты. А центральный дата-центр восстанавливали отдельно. У нескольких продуктов остаточные эффекты (невыполненные задания) тянулись еще час.

Симптом: резкий рост ошибок 503 при вызовах API. Диагноз: глобальная рассылка битых квот из-за сбоя в автоматическом обновлении.

Почему это касается вас (даже если вы не сидите на Google Cloud)

Многие компании используют облачные API как базовую инфраструктуру. Spotify полагается на Google Cloud для хостинга. OpenAI — тоже. Если вы используете ChatGPT или Discord, вы косвенно зависите от стабильности этой платформы. А если вы сами разработчик — ваш сервис мог упасть вместе с провайдером.
Урок прост: не кладите все яйца в одну корзину. Даже самый надежный облачный гигант может рухнуть из-за банального автоматического обновления квоты. И ваши пользователи не будут разбираться, кто виноват — они просто перестанут пользоваться вашим продуктом.

Пошаговый совет: как защититься от повторения сценария

1. Используйте мультиоблачную архитектуру. Разделите критичные компоненты между AWS, Azure и GCP. Да, это дороже. Но стоимость простоя часто выше.
2. Внедрите резервирование на уровне API. Если ваш сервис вызывает внешние API — предусмотрите fallback-провайдера. Например, для переводов — второй движок.
3. Настройте мониторинг ошибок 5xx. Ловите резкий рост 503/502 сразу. Сделайте алерт в Telegram или Slack. Это даст вам время среагировать до масштабных жалоб.
4. Разработайте план ручного переключения. Автоматика может сломаться. Подготовьте сценарий, как вручную перенаправить трафик на здоровый регион или другого провайдера.
5. Регулярно тестируйте аварийное восстановление. Раз в квартал симулируйте отказ основного облака. Смотрите, как система держит удар.

Мое мнение: облачные гиганты слишком самоуверенны

Google Cloud обещает 99,99% доступности. Но такая поломка из-за простого обновления квоты — показатель хрупкости. Недавно я заметил, что в официальных отчетах о сбоях часто маскируют суть: «автоматическое обновление» звучит как случайность. На деле — недостаток тестирования распределенных изменений в глобальном масштабе.
Я считаю, что индустрии пора серьезнее относиться к постепенному развертыванию (canary deployment) и изоляции регионов. Один регион (us-central1) не должен тащить весь мир на себе. Google пообещал исправить три вещи: не допускать поврежденных данных в системе управления API, внедрить защиту при глобальном развертывании метаданных и улучшить обработку системных ошибок. Посмотрим.

Один сбой — не катастрофа. Но он — напоминание: ваша надежность не должна целиком зависеть от чужой инфраструктуры. Пока облачные гиганты чинят свои квоты, вы можете спать спокойно, только если у вас есть план Б.