В июне 2025 года одна из крупнейших технологических компаний мира — Google — столкнулась с масштабным сбоем, парализовавшим многие популярные сервисы общей аудиторией сотен миллионов пользователей. О том, как банальная ошибка программирования вызвала глобальный крах и чем это грозит для индустрии в целом, пойдет речь далее. Сбой, начавшийся 12 июня, затронул Google Cloud Platform (GCP) и многочисленные сервисы, включая Spotify, Discord, Snapchat, а также приложения Google Workspace — Gmail, Meet, Drive и другие. Всего на пике инцидента сотни тысяч пользователей зафиксировали ошибки и перерывы в работе. Длительность простой составила свыше семи часов, что для такой компании и инфраструктуры колоссально.
Причина оказалась столь простая, сколько и трагичная — Null Pointer Exception, возникшая в компоненте Service Control, который отвечает за контроль доступа и управление API запросами в облаке Google. Service Control выполняет критические функции: проверку подлинности пользователей, авторизацию, учет квот и ведение журналов всех обращений. Очередное обновление кода, внедренное 29 мая, включало новую возможность для более гибких политик квотирования, однако в коде отсутствовала надежная обработка ошибок, а сама функциональность была активирована без механизма безопасного этапного запуска. К моменту 12 июня в базу данных Spanner, которая синхронизирует данные по всему миру в режиме реального времени, попала неожиданно пустая или нулевая запись для политики доступа. Это незаметное, на первый взгляд, изменение вызвало разрыв цепочки в логике Service Control.
Попытка обработать эту пустую запись привела к Null Pointer Exception — ситуации, при которой программа пытается обратиться к неинициализированной области памяти. Поскольку в коде отсутствовали проверки на пустые значения, все инстансы сервиса по всему миру начали аварийно завершать работу в бесконечном цикле сбоев. В результате критически важный компонент инфраструктуры рухнул глобально. Так называемое «проклятие NULL» в современной программной инженерии — одна из самых распространенных и опасных ошибок. Отсутствие элементарных проверок и защитных механизмов вызвало цепную реакцию с влиянием на сотни тысяч пользователей и тысячи сервисов.
Отмечается, что в нормальной практике даже в инфраструктурных модулях всегда присутствуют гарантии устойчивости к недопустимым значениям. Однако именно отсутствие данной меры в данном случае стало причиной катастрофы. Восстановление функционирования сервиса заняло значительное время. Команда надежности Google (SRE), известная своим профессионализмом и опытом, оперативно определила источник неисправности в первые десять минут после начала сбоев. Был задействован «красный переключатель» — аварийный механизм отключения проблемного кода по всему миру.
Тем не менее, полное возвращение к стабильной работе в некоторых регионах, особенно в us-central1 (штат Айова), заняло более двух с половиной часов. При перезапуске множества инстансов одновременно возник эффект «стада», когда все сервисы стали интенсивно обращаться к одной и той же базе данных, создавая дополнительную нагрузку и замедляя восстановление. Сложности усугубляло отсутствие доступа к собственным средствам мониторинга и статусным страницам Google, которые работали на базе сервисов, пострадавших при сбое. Первое официальное публичное сообщение о ситуации появилось спустя почти час после инцидента. Пользователи были вынуждены самостоятельно искать информацию и сталкивались с ошибками типа 503 и 401, либо с продолжительными тайм-аутами.
Анализ инцидента выявил ряд фундаментальных ошибок в инженерных процессах и управлении жизненным циклом ПО. Прежде всего, новое сложное функциональное изменение было запущено повсеместно без ограничения области действия и без возможности быстрого отключения. Ключевой компонент был реализован без базовой проверки входных данных на наличие пустых или некорректных значений. Все обновления конфигурации распространялись мгновенно без этапов тестирования и валидации в песочнице. Механизмы повторных попыток не включали алгоритмы рандомизированного экспоненциального тайм-аута, что привело к лавине запросов к базе.
Кроме того, архитектура системы оказалась монолитной и не позволяла справиться с частичным отказом, а инструменты коммуникации полностью были зависимы от основной системы и не могли предоставить своевременную обратную связь. Все перечисленные отклонения от лучших практик превратили небольшую ошибку в катастрофу с масштабом, которого Google ранее избегал. Это серьезный знак тревоги, свидетельствующий о том, что даже лидеры индустрии не застрахованы от ошибок элементарного уровня. Впрочем, обсуждение инцидента породило новые стандарты и подходы к созданию надежных сервисов. Ключевыми уроками стали необходимость использования флажков функциональности (feature flags) для всех изменений, что позволяет ограничивать и быстро отключать опасные обновления.
Валидация и строгие схемы данных, исключающие возможность внесения некорректной информации, должны стать обязательными элементами. Изоляция и децентрализация критических компонентов помогают ограничить радиус поражения. Ввод механизмов плавного восстановления с использованием экспоненциальных тайм-аутов и случайного разброса загрузки минимизирует эффект «стада» при массовых перезапусках. Обеспечение независимой системы мониторинга и оповещений гарантирует наличие надежной связи с пользователями даже при серьезных проблемах. Особое внимание после инцидента уделяется практике защитного программирования (defensive programming), где каждый ввод и изменение проверяются и контролируются до попадания в производственную среду.
Простой пример исправления можно описать добавлением проверки на пустое значение до основного вызова, что убережет от сбоев даже при неожиданных данных. Интересен и растущий тренд использования искусственного интеллекта для поддержки процесса ревью кода. AI способен выявлять трудноуловимые ошибки, включая незащищенный доступ к нулевым значениям и отсутствие ключевых проверок, что значительно снижает вероятность подобных инцидентов. Такие инструменты не заменяют опытных разработчиков, но являются дополнительным уровнем защиты и повышения качества. Инцидент от июня 2025 года стал серьезным уроком не только для Google, но и для всей индустрии облачных технологий и разработки ПО.
