Цифровые сервисы: практика

Как откатить обновление мобильного приложения после сбоя: бэкап, версии и доступы

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 08 ноября 2025 г.

Откат обновления мобильного приложения нужен, если сбой затрагивает платежи, авторизацию, сохранность данных или массово ломает основной сценарий пользователя. Перед откатом проверьте три вещи: есть ли стабильная

Когда откат действительно нужен, а когда достаточно hotfix

Откат — это не просто «вернуть старую версию». В мобильных продуктах он затрагивает приложение, backend API, базу данных, push-уведомления, платежные SDK, аналитику и пользовательские сессии. Ошибка в решении может дать второй инцидент: пользователи останутся на несовместимой версии, заказы задвоятся, подписки перестанут подтверждаться, а часть данных не восстановится.

Откат действительно нужен, если после релиза появились признаки массового сбоя:

• приложение не открывается или падает на старте у заметной доли пользователей;

• авторизация не проходит из-за несовместимости клиента и API;

• платежи списываются, но заказ, подписка или доступ не активируются;

• новая версия записывает данные в формате, который старая версия не читает;

• crash-free sessions упали ниже внутреннего порога, например с 99,6% до 96–98%;

• количество ошибок 5xx на backend выросло в 2–3 раза после публикации сборки;

• негативные отзывы и обращения в поддержку идут по одному и тому же сценарию;

• не работает ключевая функция: оформление заявки, оплата, запись, доставка, вход в личный кабинет.

Hotfix подходит, если дефект узкий и не разрушает данные. Например, в одной форме не проходит валидация телефона, не отображается баннер, некорректно работает фильтр, ломается второстепенный экран, но платежи, авторизация и личный кабинет стабильны. В таком случае команда может подготовить исправленную сборку, прогнать регрессию и выпустить обновление без возврата всей версии.

Есть промежуточный вариант — отключение функции без отката. Если новая возможность была заведена через feature flag, remote config или серверный параметр, её можно выключить за 5–15 минут без публикации новой сборки. Это лучший сценарий для рискованных функций: новый онбординг, экспериментальный экран, промо-механика, A/B-тест, обновлённая корзина, интеграция с внешним сервисом.

Решение принимают не по эмоциям, а по метрикам. Минимальный набор для оценки:

• доля пользователей на проблемной версии;

• количество crash-событий за последние 15, 30 и 60 минут;

• версии iOS и Android, на которых воспроизводится дефект;

• модели устройств и объём свободной памяти;

• ошибки backend по endpoint’ам;

• количество незавершённых платежей;

• обращения в поддержку с одинаковым текстом;

• наличие стабильной предыдущей сборки и совместимой схемы данных.

Если сбой затрагивает меньше 1–2% пользователей, не касается денег и данных, а исправление уже готово, откат часто избыточен. Если затронуты платежи, авторизация или сохранность записей, откат нужно рассматривать сразу, не дожидаясь «ещё пары часов наблюдения».

Подготовка к откату: бэкапы, версии сборок и данные пользователей

Без подготовки откат превращается в ручную аварию. Команда должна заранее знать, какая версия считается стабильной, где лежит артефакт сборки, какие миграции базы были применены и что произойдёт с пользователями, которые уже успели открыть новую версию.

Что должно быть сохранено до релиза

Для безопасного отката нужны не только файлы APK, AAB или IPA. Нужен полный релизный комплект:

• номер версии приложения, например 4.18.2, и номер сборки, например build 4180207;

• ссылка на артефакт сборки в CI/CD или хранилище релизов;

• changelog с перечислением изменений;

• список backend-релизов, которые были выведены вместе с мобильной сборкой;

• список миграций базы данных;

• схема feature flags и remote config;

• список затронутых API;

• тестовый отчёт по smoke и регрессии;

• релизный паспорт или release notes для внутренней команды;

• контакты ответственных: мобильная разработка, backend, QA, DevOps, продукт, поддержка.

В 2026 году для мобильного сервиса нормальной практикой считается хранить релизные артефакты минимум 6–12 месяцев, а критические бэкапы базы — по политике 7/30/90 дней: ежедневные за 7 дней, недельные за 30 дней, архивные за 90 дней или дольше, если этого требует бизнес-процесс. Конкретный срок зависит от продукта, но отсутствие понятной политики хранения — прямой риск.

Какие бэкапы нужны

Перед откатом проверьте не один «общий бэкап», а несколько уровней восстановления:

1. Бэкап базы данных до релиза. Нужен timestamp: например, 2026-04-28 10:00 UTC, за 30 минут до выката.

2. Снапшот конфигураций. Remote config, feature flags, лимиты, ключи интеграций, настройки платежей.

3. Бэкап файлового хранилища. Аватары, вложения, документы, медиа, если приложение с ними работает.

4. Логи операций. Платежи, заказы, заявки, изменения профилей, подписки.

5. Экспорт критических сущностей. Пользователи, транзакции, статусы заказов, записи, бронирования.

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

Как проверить предыдущую версию

Стабильная сборка — это не «та, что была вчера». Её нужно проверить против текущего сервера и текущих данных. Минимальная проверка занимает 30–90 минут, если процесс готов заранее.

Проверьте:

• установка предыдущей версии поверх новой;

• вход существующего пользователя;

• регистрация нового пользователя;

• восстановление пароля или вход по SMS/e-mail;

• загрузка профиля;

• основной пользовательский сценарий;

• оплата или тестовая покупка в sandbox;

• push-уведомление;

• deep link;

• работа без сети и после восстановления связи;

• обновление с предыдущей версии на будущую hotfix-сборку.

Отдельно проверьте, не изменилась ли локальная база на устройстве. Если новая версия обновила SQLite/Room/Core Data/Realm-схему, старая сборка может не запуститься. В этом случае откат через приложение становится опасным: пользователь уже имеет локальные данные нового формата, а старый клиент их не понимает.

Что делать с пользователями на новой версии

В мобильных продуктах нельзя мгновенно «забрать» установленную версию у всех пользователей. Часть уже обновилась, часть обновится позже, часть отключила автообновление, часть сидит на старой версии. Поэтому план должен учитывать смешанную аудиторию.

Рабочая схема:

• остановить поэтапный rollout, если он ещё не дошёл до 100%;

• отключить проблемные feature flags;

• вернуть backend к совместимому поведению;

• подготовить hotfix для тех, кто уже обновился;

• через поддержку дать пользователям понятную инструкцию: обновить приложение, перезапустить, повторить операцию, обратиться с номером заказа;

• не просить удалять приложение, если это может стереть локальные данные без синхронизации.

Если продукт разрабатывается подрядчиком, до начала работ зафиксируйте не только цену сборки, но и аварийные условия. Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную; отдельно отметьте сроки 3–7 дней, гарантию и стоимость переделки. В смете должны быть прописаны релиз, поддержка после публикации, регрессия, исправление критических дефектов и доступность команды в первые 24–72 часа после выката.

Доступы и роли: кто выпускает, кто подтверждает, кто контролирует инцидент

Главная ошибка при откате — все имеют мнение, но никто не имеет полномочий. При сбое нужен заранее назначенный инцидент-менеджер и понятная матрица доступов.

Кто принимает решение

Решение об откате не должен принимать один разработчик в чате. Минимальная группа:

• инцидент-менеджер — ведёт таймлайн, фиксирует решения, назначает ответственных;

• технический лидер — оценивает совместимость сборок, API, миграций и бэкапов;

• мобильный разработчик — проверяет сборку, публикацию, crash-логи;

• backend-разработчик или DevOps — контролирует сервер, базу, конфиги, логи;

• QA — выполняет smoke-проверку и подтверждает воспроизведение;

• продуктовый ответственный — оценивает влияние на пользователей и бизнес-сценарии;

• поддержка — собирает обращения и готовит текст для пользователей;

• владелец доступа к сторам — выполняет действия в консолях публикации.

У каждого должен быть резервный исполнитель. Если доступ к консоли мобильного магазина есть только у одного сотрудника, который недоступен ночью или в отпуске, откат может задержаться на часы.

Какие доступы проверить заранее

Минимальный набор доступов:

• консоль публикации Android-приложения;

• консоль публикации iOS-приложения;

• CI/CD: сборка, подпись, релизные артефакты;

• хранилище сертификатов и keystore;

• crash-аналитика: Firebase Crashlytics, Sentry, AppMetrica или аналог;

• продуктовая аналитика;

• backend-логи и мониторинг;

• база данных или панель управления миграциями;

• feature flag / remote config;

• push-платформа;

• платежный кабинет или агрегатор;

• система поддержки;

• репозиторий и доска задач.

Доступы должны быть ролевыми, а не «логин на всех». Для критичных систем включают двухфакторную аутентификацию, журнал действий и принцип минимальных прав. Разработчику не обязательно иметь право удалять production-базу, а менеджеру не нужен доступ к приватным ключам подписи.

Какие документы нужны

Чтобы откат не спорили на словах, держите комплект документов:

• техническое задание или спецификация релиза;

• релизный паспорт;

• чек-лист smoke-тестирования;

• план отката;

• схема миграций базы;

• список API-контрактов;

• инструкция по включению и отключению feature flags;

• SLA на реакцию подрядчика;

• акт выполненных работ или релизный отчёт;

• журнал инцидента.

Проверьте портфолио, техническое задание, смету, сроки, гарантию, порядок правок, поддержку и документы на материалы или услугу. Для цифрового продукта это означает: кто отвечает за исправление дефектов после релиза, сколько часов поддержки включено, что считается гарантийным случаем, какие правки оплачиваются отдельно, как передаются исходники, ключи, доступы и документация.

Как вести инцидент

С момента обнаружения сбоя фиксируйте таймлайн:

• 10:05 — опубликована версия 4.18.2;

• 10:23 — рост crash rate на Android 14;

• 10:31 — поддержка получила первые 12 обращений;

• 10:40 — отключён feature flag нового экрана оплаты;

• 10:55 — подтверждён дефект на Samsung Galaxy S23 и Pixel 8;

• 11:10 — принято решение об откате backend-конфига;

• 11:35 — подготовлен hotfix build 4.18.3;

• 12:20 — smoke-тест пройден;

• 13:00 — начат релиз исправления.

Такой журнал нужен не для отчётности ради отчётности, а чтобы после инцидента понять, где потеряли время: в диагностике, доступах, сборке, тестировании, согласовании или публикации.

Таблица проверки

Практически таблица работает так: если красный флаг найден в базе, API или платежах, не делайте полный откат клиента до технического подтверждения. Сначала остановите распространение дефекта: отключите флаг, остановите rollout, временно заблокируйте проблемный сценарий, верните совместимый backend. Только после этого выбирайте: откат, hotfix или комбинированный план.

Риски отката: миграции базы, push-уведомления, платежи и совместимость API

Откат кажется простым, пока не выясняется, что новая версия уже изменила данные. Самый опасный тип сбоя — не падение интерфейса, а тихая порча состояния: неправильные статусы заказов, задвоенные заявки, неподтверждённые платежи, некорректные настройки профиля.

Миграции базы

Если релиз добавил новое поле, старый клиент обычно переживёт это спокойно. Если релиз переименовал поле, изменил тип данных, удалил колонку, объединил сущности или поменял статусную модель, откат становится сложным.

Пример: раньше заказ имел статусы `new`, `paid`, `done`, а новая версия добавила `reserved` и `awaiting_capture`. Старая сборка может не понимать эти статусы и показывать пользователю пустой экран или ошибку. В этом случае возврат старого клиента без адаптации backend только усилит проблему.

Перед откатом задайте три вопроса:

• какие миграции были применены после релиза;

• есть ли downgrade-скрипт;

• можно ли старому приложению показывать новые данные в совместимом формате.

Если downgrade-скрипта нет, не запускайте его на production под давлением. Сначала проверьте на копии базы. Даже 15 минут проверки лучше, чем потеря корректных пользовательских операций за весь день.

Push-уведомления и deep links

Push-кампания может продолжать вести пользователей в проблемный сценарий даже после того, как команда начала откат. Например, уведомление открывает новый экран акции, которого нет в старой версии, или передаёт параметры, которые старый клиент не обрабатывает.

Что сделать:

• остановить активные кампании;

• проверить отложенные уведомления;

• отключить deep links на сломанный экран;

• заменить маршрут на безопасный экран, например главный экран или список заказов;

• не отправлять массовое извинение до проверки сегментов, чтобы не привлечь к сбою тех, кого он не затронул.

Платежи и подписки

Платежи нельзя «откатить» как экран приложения. Деньги, авторизации, холды, возвраты, webhook-события и статусы заказов живут в отдельной цепочке. Если сбой затронул оплату, первым действием должно быть сохранение доказательной базы: transaction ID, user ID, время операции, сумма, статус у платежного провайдера, статус в вашей системе.

Минимальная сверка:

• выгрузка платежей за период инцидента, например с 10:00 до 13:00;

• список успешных списаний без выданного доступа;

• список неуспешных платежей, которые приложение показало как успешные;

• список повторных попыток одного пользователя;

• webhook-логи;

• ручное сопоставление 10–20 типовых кейсов перед массовым исправлением.

Если платежный сценарий нестабилен, временно отключите оплату в приложении или переведите пользователя на безопасный путь. Лучше потерять часть новых оплат за 30 минут, чем получить сотни спорных транзакций.

Совместимость API

Старая версия приложения должна работать с текущим API. Поэтому backend обязан поддерживать хотя бы одну-две предыдущие мобильные версии, особенно если пользователи не обновляются мгновенно. Нормальная практика — не удалять поля и endpoint’ы без периода совместимости, а изменения проводить через версионирование API.

Опасные признаки:

• мобильный клиент жёстко зависит от нового поля;

• backend перестал отдавать поле, нужное старой версии;

• изменился формат даты, валюты, статуса или идентификатора;

• включена новая авторизация без поддержки старого токена;

• сервер стал требовать параметр, которого нет в предыдущей сборке.

Если совместимости нет, откат клиента невозможен без backend-исправления. В таком случае сначала возвращают API-контракт или добавляют адаптер, а уже потом принимают решение по мобильной версии.

Когда откат не подходит

Откат не подходит, если он создаёт больше риска, чем hotfix. Типовые случаи:

• новая версия уже записала данные в несовместимом формате;

• старая сборка не проходит авторизацию на текущем backend;

• ключи подписи, сертификаты или SDK изменены так, что старая сборка не может быть безопасно опубликована;

• дефект находится на сервере, а не в мобильном клиенте;

• проблема затрагивает только один экран и выключается через remote config;

• исправление уже готово и проверяется, а откат займёт дольше;

• пользователи на новой версии не смогут безопасно вернуться назад.

Что может пойти не так:

• часть пользователей останется на проблемной версии и продолжит получать ошибки;

• старая версия начнёт падать из-за локальных миграций;

• push-уведомления поведут на несуществующие экраны;

• аналитика смешает события старой и новой версии;

• платежи окажутся в разных статусах у приложения и провайдера;

• поддержка даст пользователям неверную инструкцию;

• подрядчик попросит доплату за срочное исправление, потому что гарантия и SLA не были прописаны.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. В мобильной разработке это проявляется как отсутствие релизного плана, неподготовленные доступы, неописанные правки после публикации, невнятная гарантия на исправление критических ошибок и передача сборки без исходников или документации.

Можно ли просто вернуть старую версию приложения?

Не всегда. Старая версия должна быть совместима с текущим API, базой данных, локальными миграциями и настройками сервера. Если новая версия уже изменила данные, простой возврат может вызвать новые падения.

Что быстрее: откат или hotfix?

Если проблема отключается через feature flag, это быстрее всего: обычно 5–15 минут. Hotfix может занять от нескольких часов до 1–2 дней с тестированием и публикацией. Откат быстрый только тогда, когда заранее подготовлены сборки, доступы и план восстановления.

Какие метрики смотреть первыми?

Crash-free sessions, crash rate по версии, ошибки backend 4xx/5xx, платежные ошибки, обращения в поддержку, долю пользователей на новой версии и успешность ключевого сценария: вход, заказ, оплата, запись или отправка заявки.

Нужен ли бэкап перед каждым релизом?

Для критичных мобильных сервисов — да. Минимум нужен бэкап базы перед релизом, снапшот конфигураций и журнал операций. Важно не только хранить бэкап, но и регулярно проверять восстановление.

Можно ли откатить только Android или только iOS?

Да, если сбой затрагивает одну платформу. Но backend и конфигурации всё равно нужно проверять общие: изменение API может ломать обе платформы, даже если жалобы пришли только от Android-пользователей.

Что делать, если пользователи уже обновились?

Остановите дальнейшее распространение, отключите проблемные функции, подготовьте hotfix и дайте поддержке понятную инструкцию. Не просите удалять приложение, если есть риск потери локальных данных.

Кто должен иметь доступ к публикации?

Минимум два ответственных человека с ролевыми доступами и двухфакторной аутентификацией. Один владелец доступа — риск задержки отката на часы.

Как понять, что откат опаснее исправления?

Если старая сборка не работает с текущей базой, не понимает новые статусы, падает после установки поверх новой версии или не проходит авторизацию, откат опасен. В таком случае лучше выпускать hotfix или восстанавливать совместимость backend.

Что включить в договор с подрядчиком на мобильную разработку?

ТЗ, смету, сроки, гарантию, порядок правок, поддержку после релиза, передачу исходников, доступов и документации. Отдельно пропишите реакцию на критический сбой: срок ответа, стоимость срочной работы и ответственность за дефекты.

Какой главный принцип безопасного отката?

Сначала остановить вред, потом восстанавливать стабильность. Не начинайте полный откат, пока не проверены данные, API, платежи, бэкапы и доступы.