29 сентября сбой Firebase iOS на несколько часов превратил обычный запуск приложений Apple в массовую лотерею: у тысяч программ по всему миру начались падения, чаще всего сразу после открытия. Проблема оказалась не в самих приложениях, а в Google Analytics для Firebase, который передавал SDK некорректные данные. Для разработчиков и бизнеса это неприятное напоминание: зависимость от облачного SDK может положить продакшен даже без новой версии приложения.
О массовом инциденте сообщает Habr / Новости. По данным из обсуждения в трекере задач Google Firebase на GitHub, ошибка в Google Analytics для Firebase приводила к аварийному завершению iOS-приложений при запуске. Масштаб быстро стал заметен: сервис используется для аналитики и бэкенд-сценариев во множестве мобильных продуктов, поэтому сбои проявились почти синхронно у разных команд и в разных странах.
Самый неприятный сценарий для мобильной команды — приложение падает на старте, а релиза в App Store никто не выкатывал. Именно это и произошло: пользователи открывали привычные приложения, те закрывались, а разработчики сначала искали ошибку у себя. Один из участников обсуждения признался, что потратил огромное количество токенов на отладку, решив, что сломался его собственный код. В эпоху AI-помощников это уже почти новая метрика ущерба: не только часы инженеров, но и сожжённый лимит на автоматическую диагностику.
Google исправила проблему через пару часов, но эффект исчез не мгновенно. Компания предупредила, что из-за кеширования часть приложений могла продолжать падать ещё до четырёх часов. Для пользователя разницы мало: если банковское, рабочее или сервисное приложение закрывается при запуске, виноватым выглядит бренд на иконке, а не сторонний SDK глубоко внутри сборки. Репутационный удар получает владелец продукта, даже если причина лежит за пределами его инфраструктуры.
Причины сбоя Google пока не раскрыла. Известно только, что некорректные данные пришли со стороны Google Analytics для Firebase и ломали работу SDK. Это важная деталь: речь не о классическом падении дата-центра, отключении сети или ошибке в конкретном приложении. Сбой Firebase iOS показал более тонкий риск — удалённый конфиг, аналитический компонент или зависимость, которую команда привыкла считать вспомогательной, внезапно становится критической точкой отказа.
Для мобильных разработчиков практический вывод довольно приземлённый. SDK аналитики, crash reporting, push-уведомлений и A/B-тестов давно живут внутри клиентских приложений на правах инфраструктуры. Но если такой компонент способен уронить приложение до отображения первого экрана, его нужно рассматривать как часть критического пути. Значит, нужны проверки инициализации, защитные обёртки, возможность деградации без аналитики и сценарии быстрого отключения проблемной зависимости там, где это технически возможно.
Для продактов и IT-директоров история ещё проще: SLA стороннего сервиса не спасает, когда пользователь уже поставил одну звезду в магазине приложений. Если продукт зависит от Firebase, полезно заранее понимать, какие модули используются, какие из них обязательны на старте и что произойдёт при некорректном ответе от внешнего сервиса. Инцидент особенно болезненный для iOS: цикл публикации исправлений через App Store не располагает к мгновенным клиентским патчам, поэтому архитектурная устойчивость важнее героической ночной сборки.
У Google это не первый заметный сбой за месяц. Ранее в сентябре сетевой инженер Google Cloud случайно отключил от сети обслуживаемое оборудование, после чего несколько часов работали с перебоями Compute Engine, Kubernetes Engine, Cloud Run, Google App Engine, AlloyDB для PostgreSQL и другие сервисы. Эти эпизоды разные по природе, но тренд один: чем глубже облачные платформы и SDK вшиты в продукты, тем чаще чужая ошибка выглядит для пользователя как ваша. Следующий раунд зрелости мобильной разработки, похоже, будет не про ещё одну метрику в дашборде, а про умение пережить сбой этой самой метрики.