Оперативное исправление критических багов мобильного приложения
Оплата перестала работать у 15% пользователей после обновления до iOS 17.4. Или на Android 14 приложение падает при открытии уведомления — а вчера ещё работало. Это критические баги: они блокируют ключевые пользовательские сценарии, и каждый час без исправления — это потери конверсии и рост негативных отзывов.
Что считать критическим
Не каждый баг требует hotfix. Критерии для экстренного исправления:
- Крэш затрагивает >1% сессий за последние 6 часов
- Заблокированы оплата, авторизация или core-функционал приложения
- Уязвимость безопасности с возможностью утечки данных
- ANR rate превысил 1% на Android (риск предупреждения от Google)
Баг с неправильным отображением даты в профиле — не критический. Падение при попытке сделать заказ — критический.
Как работает hotfix-процесс
Диагностика (первые 30–60 минут)
Смотрим Crashlytics: версия затронутых устройств, ОС, конкретный стектрейс. Если крэш начался после конкретного релиза — git diff между версиями сужает поиск. Если началось без релиза — ищем изменения на backend (API-ответ, формат данных, новый endpoint).
Типичный сценарий: бэкенд вернул null в поле, которое мобильный клиент не ожидал получить null — NullPointerException или force-unwrap в Swift (Fatal error: Unexpectedly found nil). Фикс на стороне клиента — defensive parsing:
// Было — падает при null
val price = response.price.toDouble()
// Стало — graceful handling
val price = response.price?.toDoubleOrNull() ?: 0.0
Разработка и тестирование
Hotfix-ветка от текущего production-тега, не от main. Только минимальное изменение — никаких «заодно рефакторингов». Тестирование на реальном устройстве с версией ОС, на которой воспроизводится крэш.
Для Android: можно выпустить hotfix через staged rollout — сначала 10%, смотреть на crash-rate в Play Console в реальном времени, затем расширять.
Публикация
App Store: экстренный review занимает 24–48 часов при стандартной очереди. При реальной критической ситуации Apple принимает запрос на Expedited Review через Resolution Center — решение в течение нескольких часов. Обоснование должно быть конкретным: «crashes for 100% of users on iOS 17.4 during payment».
Google Play: staged rollout 10% → 50% → 100% с шагом 1–2 часа при стабильных метриках. Полный rollout на всех пользователей — в течение дня.
Remote kill switch
Для критических ситуаций, когда фикс не готов быстро — можно заранее реализовать feature flags через Firebase Remote Config. Отключить проблемную фичу без релиза:
// iOS: проверка флага перед показом функции
let config = RemoteConfig.remoteConfig()
let isPaymentEnabled = config["payment_enabled"].boolValue
Если флаг не был реализован заранее — это аргумент в пользу его добавления после разрешения инцидента.
После фикса
Post-mortem: что именно сломалось, почему тест не поймал, что добавить в регрессионный набор. Не для поиска виноватых — для того, чтобы следующий аналогичный баг поймать на staging, а не в продакшене.
Ориентиры по срокам
Диагностика и минимальный фикс стандартного крэша — 2–8 часов. Проблема, связанная с изменением поведения ОС или стороннего SDK (например, изменения в AVFoundation после обновления iOS) — до 2 рабочих дней. Стоимость рассчитывается индивидуально после анализа ситуации.