Критические баги в мобильном приложении: где ломается
Критические баги в мобильном приложении почти всегда живут на стыках, а не в середине экранов. Холодный запуск — самый частый сценарий отказа: падение приложения происходит до отрисовки первого экрана, и пользователь не понимает, что вообще случилось. Второй по частоте — обрыв сессии при возврате из фона: срок действия ключа доступа истёк, тихое продление не сработало, и вместо каталога человек видит пустой экран или форму повторного входа.
Дороже всего обходится сбой при оплате. Платёж уходит в шлюз, подтверждение не доходит до клиента, деньги списаны — заказ не оформлен. Это не просто потерянная покупка: пользователь пишет в поддержку и требует возврат, а разбор каждого такого случая идёт вручную и отнимает время у команды, которая могла бы заниматься продуктом.
Отдельная группа — сбои после обновления версии. Новая сборка меняет структуру локального хранилища, старая схема данных не мигрирует, и приложение падает у тех, кто поставил обновление поверх предыдущей версии. Рядом стоят сбои синхронизации после потери сети: накопленная очередь запросов уходит на сервер не в том порядке, расходятся статусы заказов.
Цена такого сбоя — не только несостоявшиеся заказы. Растёт поток обращений в поддержку, релиз приходится срывать, а вернуть предыдущую сборку через магазины приложений быстро не получится: на публикацию и проверку уходят дни. Разбираем, как это закрывается.
Что меняет налаженный разбор сбоев: эффект в цифрах
Метрики здесь описывают не «стало стабильнее», а конкретные величины: сколько времени проходит от первого сигнала о сбое до выпуска исправления, насколько широко расходятся последствия и как часто один и тот же отказ возвращается.
Время до исправления и окно обнаружения
Падение или зависание в мобильном приложении привязано к конкретной модели устройства, версии системы и участку сценария. Пока такие сбои ловятся отзывами в магазине приложений, окно обнаружения растягивается на дни, и к моменту подтверждения отказ затрагивает заметную долю активных пользователей. Автоматический сбор падений — Crashlytics и подобные платформы — сокращает это окно до часов: сигнал приходит с привязкой к сборке, устройству и цепочке действий пользователя.
Дальше работает приоритизация: сначала чиним то, что блокирует вход, оплату и оформление заказа, остальное уходит в плановый выпуск. Воспроизведение в тестовом контуре занимает часы, а не дни, поэтому время до исправления перестаёт измеряться неделями. Класс отказов, который раньше всплывал только у части аудитории, отсекается проверками до выпуска.
Доля повторных обращений по одному и тому же сбою
Повторный отказ — признак того, что причину заглушили, а не устранили. В разборе мы фиксируем первопричину и закрываем её проверкой: сценарий, который приводил к падению, попадает в набор автоматических тестов, а на ту же сигнатуру сбоя ставится оповещение.
На замерах реальных обращений доля повторных обращений по одному и тому же сбою заметно снижается, а стабильность выпуска становится измеримой величиной: каждое исправление сопровождается проверкой, что смежные сценарии не сломались.
Форматы реакции на критические баги: дежурство, окно исправлений
Критический баг в проде не решается вопросом «есть ли свободный разработчик» — режим реакции выбирают заранее. Рабочих режимов два, и они дополняют друг друга: постоянное дежурство с каналом оповещения и окно исправлений с правилами отката.
Дежурство и канал оповещения
Дежурный инженер получает сигнал от системы мониторинга и подтверждает его до того, как о падении напишут пользователи. Ротация и лестница эскалации фиксируют, к кому уходит сигнал, если первый дежурный молчит: общий чат для этого не годится, там сообщение тонет в переписке.
Окно исправлений и правила отката
Срочная правка идёт вне обычного регламента выпуска, но не вместо него: правило отката согласуют до начала работ, а не в момент, когда сборка уже готова. Не нашли причину за окно — возвращаемся на предыдущий выпуск и продолжаем разбор без давления.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Постоянное дежурство с эскалацией | Платежи, авторизация, поток заказов — простой заметен сразу | Требует ротации и лестницы оповещения, выше организационная нагрузка |
| Дежурство по расписанию | Нагрузка сосредоточена в рабочие часы | Ночь и выходные остаются без немедленной реакции |
| Окно исправлений с откатом на предыдущий выпуск | Инцидент затрагивает данные или платежи | Нужна обратная совместимость схемы данных |
| Плановый выпуск по регламенту | Тексты, косметика, некритичные сбои | Критический баг ждёт ближайшего выпуска |
Как мы ведём исправление: от сигнала до проверки
Критический сбой в рабочей среде каждый час приносит потерянные сессии и обращения в поддержку, поэтому исправление ведём как конвейер с фиксированными точками контроля. Порядок работ одинаков для любого сигнала — от приёма до передачи сопровождения.
- Приём и классификация. Сводим отчёты о падениях, аналитику и обращения поддержки в один поток и считаем долю затронутых сессий — она задаёт приоритет.
- Разбор сигнала. Сопоставляем сбой с версией сборки, моделью устройства и версией системы, восстанавливаем стек вызовов.
- Воспроизведение сбоя. На стенде и на парке устройств доводим сценарий до стабильного повторения — без этого правка превращается в угадывание.
- Правка и регресс. Минимальное изменение в затронутом пути плюс проверки вокруг: соседние сценарии не должны сломаться.
- Проверка в рабочей среде. Выпускаем волнами, на каждой контролируем долю сбоев.
- Передача сопровождения. Причину, правку и проверки фиксируем в регламенте, чтобы следующий похожий сигнал разбирался быстрее.
Как строится разбор сигнала
Одинаковые падения приходят десятками отчётов, поэтому их схлопывают в уникальные сбои и сортируют по доле затронутых сессий. Отдельно проверяют, воспроизводится ли сбой на конкретной модели устройства — это отсекает шум окружения. Стек вызовов восстанавливают по символам сборки: без этого в отчёте остаётся набор адресов.
Проверка на реальных пользователях
Правка готова не после тестов, а после подтверждения на живом трафике. Выкатка идёт волнами — сначала небольшая доля аудитории, затем остальные, с автоматическим возвратом на предыдущую сборку, если доля сбоев выходит за порог.
Регламенты, схемы и точки наблюдения, которые остаются у вас
Работы заканчиваются не отчётом, а набором артефактов, по которым ваша команда сама проведёт разбор инцидента и выпустит исправление. Всё, что мы выстраиваем в процессе, передаётся в рабочем виде — с заполненными полями, а не шаблонами «на будущее».
Состав передаваемых материалов
- Регламент исправлений: уровни критичности, время реакции по каждому, кто принимает решение о срочном выпуске и кто подтверждает откат.
- Схема оповещения: дежурный канал, порядок эскалации, в какой момент подключается руководитель направления.
- Матрица доступов и ролей: разграничение по репозиторию, конвейеру сборки, хранилищу релизов и панели наблюдения — с указанием ответственных.
- Документация по инциденту: шаблон разбора, куда пишутся причина, время обнаружения и время до исправления, и журнал уже разобранных случаев.
- Точки наблюдения: набор сигналов и порогов, по которым сбой виден раньше жалоб — доля падений, зависания на старте, рост ошибок после публикации новой версии.
- Карта отката: какие сборки остаются доступны в магазинах и реестрах, как вернуть предыдущую версию и что при этом происходит с локальными данными.
- Инструкция по воспроизведению: как снять логи с устройства, какие стенды и учётные записи для этого нужны.
Как поддерживать регламент без нас
Регламент живёт, пока его пересматривают. Пороги сигналов сверяем с реальным потоком обращений раз в квартал: часть метрик устаревает после смены версии системы или обновления сторонних модулей. После каждого крупного инцидента шаблон разбора дополняется новыми полями — так накапливается база типовых причин, и следующий похожий сбой закрывается быстрее. Дежурного стоит провести по схеме оповещения на учебном сценарии: имитируем падение и смотрим, уложились ли в заявленное время реакции.
Разбор инцидента: время до исправления до и после
После релиза приложение падало на подтверждении оплаты: сначала у отдельных пользователей, через сутки — у каждого пятого. Сигналы о падениях в Firebase Crashlytics росли, но не были привязаны к конкретному действию пользователя, а выпуск исправления занимал дни. Разобрали кейс, где сбой закрыли не разовой правкой, а сменой процесса.
Что было до и что стало
| Показатель | До | После |
|---|---|---|
| Время от первого сигнала до исправления в релизе | 4–6 дней | 6–10 часов |
| Доля повторных сбоев того же класса | 38% | 4% |
| Сбои, закрытые до обращения пользователя | 1 из 10 | 7 из 10 |
Существеннее скорости одного инженера оказался устранённый класс отказов: падения перестали возвращаться в следующих релизах, потому что причину фиксировали как воспроизводимый случай, а не как точечную заплатку.
Что сделали иначе
Каждый релиз получил метку, по которой отчёты о падениях разносятся по версиям, а не смешиваются в один поток. Добавили автоматический сбор контекста: экран, шаг сценария, состояние сессии — этого хватало, чтобы воспроизвести сбой без переписки с поддержкой. Настроили правило автоматического отката на предыдущую версию при всплеске падений в первые часы после выката и ввели обязательный проверочный сценарий на каждый закрытый инцидент. Время до исправления сократилось, а доля повторных сбоев упала почти в десять раз.
Чем отличается срочное исправление от планового релиза
Срочный выпуск — это изменение минимальным диффом от тега последнего стабильного релиза: в сборку попадает только правка причины сбоя, всё остальное остаётся прежним. Путь до устройства сокращается до часов, но проверяется лишь затронутый сценарий, без полного прогона автотестов. Отсюда ограничение: срочный выпуск оправдан, когда сбой роняет ключевой путь — запуск, авторизацию, оплату — или затрагивает заметную долю устройств.
Плановый релиз накапливает правки и проходит полную регрессию. Он предсказуем и не оставляет непроверенных участков, но цикл занимает дни, а то и недели: всё замеченное ждёт следующего окна выкатки. Если дефект не блокирует пользователя, лечить его здесь дешевле — меньше ручных проверок и ниже риск, что одна правка потянет за собой вторую.
Откат версии не лечит дефект, а возвращает приложение в последнее известное рабочее состояние. Он ограничен двумя условиями: предыдущая сборка действительно стабильна, а серверная часть не изменила формат обмена данными настолько, что старый клиент с ней не заговорит. Если схема данных уже мигрировала, откат превращает один сбой в два.
Выбор режима — это выбор класса риска, а не скорости. Мы смотрим на три признака: рушится ли ключевой сценарий, есть ли обход, остаётся ли прошлая версия совместимой с серверной частью. По этим ответам видно, нужен срочный выпуск, ожидание планового релиза или немедленный откат.
Доступы, сроки и повторяемость: частые сомнения
Сомнения на старте редко касаются технологии — чаще это организация: как быстро выдадут доступы, что делать с плавающим сбоем, кто на связи вне рабочих часов. Ниже — то, что обсуждаем до подписания плана работ.
Какие доступы к рабочей среде нужны и как быстро их выдают?
Минимальный набор — чтение репозитория, история сборок, журналы падений по релизам, метрики мониторинга и тестовый аккаунт. Права только на чтение, выдача через вашу систему управления доступами. Если часть источников закрыта, разбор идёт по копиям логов и сроки диагностики растут.
Сколько времени занимает вход в проект?
Первый день уходит на сбор картины: какие релизы затронуты, на каких устройствах сбой повторяется, что менялось перед первым случаем. Дальше — воспроизведение на стенде или на группе пользователей. Оценку и план фиксируем до начала правок.
Сбой плавающий и ловится один раз из десяти. Что тогда?
Диагностируем телеметрией: расширенный сбор событий в сборке для группы пользователей, кольцевой буфер логов, разметка сессии до падения. Если причина не поймана, ставим защиту от повторения сценария и продолжаем наблюдение — так закрывается класс отказов, а не один случай.
Как устроено дежурство и кто за что отвечает?
Фиксируем окно реакции на инцидент, состав дежурных и порядок эскалации. Наша сторона — диагностика, исправление и проверка на регресс, ваша — доступы, окна релизов и публикация сборки. Откат на предыдущую версию держим штатным сценарием, а не аварийным.
Обсудим задачу: что прислать и как начнём работу
Чем точнее входные данные, тем быстрее мы выходим на причину критического сбоя и на оценку работ. Ниже — то, что помогает начать разбор без долгой переписки: по этим материалам инженер сразу видит картину и называет, где искать узкое место.
- Симптомы и частота: на каких версиях системы и моделях устройств падает приложение, воспроизводится ли сбой стабильно и в каком сценарии.
- Логи и отчёты о падениях за период: стек вызовов, идентификаторы сессий, условия, при которых падение повторяется.
- Доступ к репозиторию и сборке: ветка, в которой ведётся разработка, и канал, через который выкладываются тестовые сборки.
- Схема релизов: как часто выходят обновления, кто подтверждает публикацию в магазинах приложений.
- Перечень связанных сервисов: серверная часть, уведомления, оплата, аналитика, карты.
- Ограничения: требования к защите данных, регламент доступов, окна, когда допустимо выпускать исправление.
Порядок дальше простой. Обсуждаем задачу, сопоставляем симптомы с логами и возвращаемся с оценкой и планом: что правим в первую очередь, как проверяем и как откатываем, если исправление не подтвердилось. После согласования стартуют работы. Формат сотрудничества — разовый разбор критичного сбоя или постоянное сопровождение с дежурством по аварийным ситуациям.
