Как отслеживать сбои мобильного приложения после запуска

Приложение может быть «стабильным», а билет не откроется

Человек подходит к турникету и открывает билет. Вместо QR-кода видит главный экран телефона: приложение закрылось. В тестировании всё работало, релиз прошел проверку магазина, но сейчас это мало утешает пассажира. Сцена на фотографии иллюстрирует возможную ситуацию, а не историю клиента Appfyl.

После запуска команде нужны ответы на три вопроса: кто не смог выполнить какое действие, в какой версии возникла проблема и кто займётся ею сейчас? Поэтому мониторинг начинается с проверки отчетов из рабочей сборки. Далее смотрят, как ведет себя новая версия по сравнению с предыдущей, и не пропадают ли покупки, записи, билеты или входы в аккаунт. Общая подготовка описана в чек-листе запуска; здесь речь о том, что делать после выхода приложения к пользователям.

Вылет, зависание и невыполненное действие: это разные сигналы

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

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

Проверьте сбор отчетов до того, как начнете доверять нулю

Попросите разработчика вызвать контролируемый сбой в сборке, максимально близкой к рабочей, и показать полученный отчет. В нем должны читаться версия приложения, платформа, устройство и место ошибки. Если для iOS не загружены файлы символов, а для Android потеряны файлы сопоставления имен, отчет может прийти, но причину будет трудно найти. Повторяйте проверку после изменения процесса сборки, а не только при первом подключении сервиса.

У уведомлений должен быть получатель и запасной ответственный. Согласно справке Firebase, часть уведомлений доступна сразу, а для новых критических ошибок и зависаний нужно настроить канал доставки. Иконка с цифрой в кабинете, который никто не открывает, не поможет остановить неудачный выпуск. Проверьте путь уведомления до человека, который вправе принять решение.

Собирайте ровно столько контекста, сколько нужно для диагностики: версия, обезличенный идентификатор ошибки, последнее безопасное действие. Не записывайте пароли, токены, платежные реквизиты, медицинские сведения и переписки. После добавления нового сервиса проверьте политику конфиденциальности и сведения для магазинов.

Не ждите, что один кабинет расскажет всю историю

Android vitals показывает сбои и зависания, которые видит Google Play. Crashlytics помогает группировать ошибки и сравнивать выпуски. Sentry может быть альтернативой для команды, которой нужны также сведения о производительности. Но ни один из этих кабинетов сам по себе не объяснит, прошла ли оплата на сервере или помог ли оператор человеку у стойки.

Руководителю продукта не обязательно читать техническую трассировку. Ему нужны версия, число затронутых людей, новая или повторная ошибка, нарушенный пользовательский сценарий и имя ответственного. Мониторинг выпусков Firebase показывает сравнение версий и новые проблемы при использовании Crashlytics. Дополните его событиями из плана аналитики приложения, чтобы заметить падение числа успешных записей, даже если вылетов не стало больше.

Решение об остановке зависит от последствий, а не от красивой цифры

Представим фитнес-клуб перед вечерним занятием. Приложение открывается, отчет о вылетах чистый, но отметка о приходе не сохраняется. Сотрудникам приходится впускать людей вручную. В такой ситуации важнее сохранить доступ и учет посещений, чем ждать предупреждения о техническом сбое.

До выпуска договоритесь, что требует немедленного решения: массовый новый вылет, сломанный вход или платеж, потеря данных, нарушение безопасности. Мелкую визуальную ошибку обычно можно исправить следующим обновлением. Смотрите одновременно на масштаб, важность действия и то, ограничена ли проблема одним устройством или новой версией. Единого «разрешенного процента сбоев» для приложения с билетами и приложения с необязательным контентом нет.

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

Первые сутки после релиза лучше расписать заранее

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

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

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

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

Частые вопросы