TGViewer
Java Portal | Программирование Java Portal | Программирование @java_iibrary · 11.7K subscribers
Post #2519 1.37K
Как один баг в Google Cloud уронил весь Интернет

12 июня Google Cloud упал, и вместе с ним перестали работать Spotify, Fitbit, Gmail, Google Drive, Vertex AI и десятки других сервисов. Причиной оказался всего один null pointer баг в Service Control — сервисе, через который проходит почти каждый запрос к Google Cloud API.

Все запросы проходят через Service Control, он как вышибала, решающий, есть ли у тебя доступ. Если он падает, то рушится всё.
В конце мая Google добавил туда новый код для проверки квот, где не было обработки ошибок на пустые поля. На тестах этот код не активировался, потому что требовалась специфичная политика. Не было ни feature flag, ни постепенного раската — просто мёртвый код, ждавший своего часа.

12 июня утром в базы попала политика с пустыми полями. Service Control попытался её обработать, наткнулся на null pointer и упал.

Spanner почти мгновенно разнёс некорректные данные по всему миру, и каждая инстанция, которая к ним обратилась, падала следом. Двух минут хватило, чтобы Google Cloud лег глобально.

Начались таймауты, 503 от перегруженных систем и 401, когда пустые политики интерпретировались как отсутствие прав.

Пользователи Spotify массово получали 401, Fitbit выдавал разные ошибки в зависимости от региона, сервисы не могли пройти аутентификацию к своим бэкендам.

У Google был kill switch — красная кнопка, чтобы отключить проблемный код. Её нажали через сорок минут, и большая часть регионов восстановилась. Но us-central1 оставался недоступен ещё три часа. Когда тысячи инстансов Service Control перезапустились одновременно, они одновременно пошли в базу и устроили эффект стада, который уронил даже сам фикс.

Хуже всего то, что статус-дэшборд Google тоже крутился на Google Cloud. Когда облако упало, он умер вместе с ним, и мониторинг ослеп. Команды поддержки почти час работали вслепую.

Инцидент случился потому, что не было feature flag на новом коде, не было проверки на null в критическом пути, данные с багом мгновенно разлетелись по всему миру, восстановление не имело задержек и мониторинг был привязан к той же инфраструктуре, которую он должен был отслеживать.

После этого Google заморозил изменения в Service Control, начал переделывать систему так, чтобы компоненты могли падать независимо, добавляет задержки в репликацию, чтобы отлавливать некорректные данные, и строит отдельный мониторинг, который будет жить вне основной системы.

В итоге вся история показала, что один пропущенный if может уронить одну из самых сложных платформ в мире. Не атака и не катастрофа, а просто null pointer.

В распределённых системах локальный сбой превращается в глобальную аварию быстрее, чем человек успевает отреагировать. Инфраструктура, которая даёт масштаб, так же усиливает и ошибки.

Любой запрос к API всегда на расстоянии одного непроверенного значения от фатала. Это и есть реальность современной облачной архитектуры.

Полный отчет о происшествии: ссылка

👉 Java Portal
  • 🔥 6
  • ❤ 2
  • 😁 1
More from @java_iibrary
  1. Sep 22, 2026Прогрев от Java-бабули 🙂 👉 Java Portal
  2. Sep 21, 2026Шпаргалка по проектированию веб систем System Design 101 Подробное руководство по архитект…
  3. Sep 21, 2026Псс, хочешь перестать мониторить Telegram в поисках работы? 👀 Ты листаешь каналы, видишь…
  4. Sep 21, 2026💡 Java/Spring: отдавайте предпочтение constructor injection вместо @Autowired для полей.…
  5. Sep 20, 2026Если бы пришлось заново начинать свой путь в Java в 2026 году, я бы придерживался такого r…
  6. Sep 20, 2026Вайбкодим «Полный путь разработки AI-агентов: от MCP до Agentic RAG» Образовательная прогр…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →