Триаж мобильных сбоев: как исправить самый важный сбой приложения

Почему небольшие мобильные команды пропускают настоящий сбой

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

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

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

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

Ложная срочность обычно появляется из-за нескольких паттернов:

• несимволицированные стек-трейсы
• дубликаты, разбросанные по версиям приложения
• одно шумное устройство или версия ОС
• сбои, которые происходят уже после завершения задачи
• ранжирование по числу событий, а не по числу затронутых пользователей

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

Какие данные нужны, прежде чем что-то ранжировать

Сырые цифры по сбоям легко вводят небольшие команды в заблуждение. Один сбой может один раз затронуть 2000 пользователей, а другой — загнать 50 человек в цикл каждый раз при открытии приложения. Если ранжировать проблемы до сбора базовой информации, обычно исправляют самый громкий сбой, а не тот, который сильнее всего бьет по релизу.

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

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

Собирайте небольшой набор фактов по каждой проблеме:

• версия приложения и номер сборки
• символицированный стек-трейс
• затронутые пользователи, общее число сессий и как часто один и тот же пользователь сталкивается со сбоем снова
• модель устройства, версия ОС и состояние сети
• последние действия пользователя перед сбоем

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

Данные об устройстве и ОС помогают быстро находить узкие проблемы. Сбой, который появляется только на одной версии Android или на одной старой модели iPhone, — это совсем не то же самое, что сбой, разбросанный по всей базе установок. Состояние сети тоже помогает. Оффлайн, слабый сигнал и переключение между Wi-Fi могут запускать баги, которые никогда не всплывают на офисных устройствах.

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

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

Сначала символицируйте сбой

Сырой отчет о сбое — это гадание. Если стек-трейс показывает адреса памяти, смещения или «unknown», вы еще не знаете, что именно сломалось. Хороший триаж мобильных сбоев начинается тогда, когда в отчете видны реальные имена методов и, по возможности, номера строк.

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

Такая ошибка случается часто. Если упала сборка 241, а вы загрузили символы от сборки 240, метод вроде LoginViewModel.submit() может выглядеть как случайный адрес вместо понятного фрейма. Отчет выглядит технически, но не дает ничего полезного.

На iOS загрузите правильный dSYM для этой сборки. На Android загрузите mapping-файл из ProGuard или R8 и добавьте нативные debug symbols, если сбой затрагивает код на C или C++. После этого обработайте отчет заново, пока в стеке не появятся имена методов. Частично символицированные отчеты все еще скрывают настоящую причину.

Когда отчет становится читаемым, проверьте верхние фреймы по простой схеме:

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

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

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

Читайте подсказки сессии вокруг сбоя

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

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

Ищите простую цепочку событий: пользователь нажал кнопку, приложение отправило запрос, локальное состояние изменилось, а потом приложение закрылось. Мелочи тоже важны. Двойное нажатие, медленный API-запрос, запрос разрешения или draft-объект, который изменился дважды, могут превратить случайный сбой в баг, который можно воспроизвести.

Обычно достаточно короткой проверки:

• последний видимый экран
• финальные действия пользователя
• запросы, повторы или тайм-ауты
• изменения состояния приложения, например сворачивание или возврат на передний план
• признаки нагрузки на устройство, например нехватка памяти

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

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

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

Группируйте проблемы, но не прячьте реальные различия

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

Одного текста сообщения мало. Два отчета могут оба говорить о «null reference» или «index out of range» и при этом приходить с разных экранов, с разным вводом или из разных состояний приложения. Прежде чем доверять группе, посмотрите несколько примеров. Обычно трех-пяти отчетов достаточно, чтобы понять, один это баг с шумными симптомами или несколько багов под одной меткой.

Разделяйте отчеты, когда путь меняется

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

• iOS и Android ломаются по разным путям кода, даже если текст ошибки похож
• ANR зависает приложение, а в другом отчете виден настоящий крэш
• фатальная нативная ошибка начинается на нижнем уровне и не совпадает с исключением на уровне приложения
• одна модель устройства или версия ОС образует крошечный кластер, а больше нигде этот сбой не встречается

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

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

Аккуратная группировка делает ранжирование проще. Она еще и не позволяет одной шумной метке скрыть меньшую группу, которая падает при каждом открытии приложения. Если объединить слишком рано, самая большая корзина легко введет в заблуждение.

Что исправлять в первую очередь

Хороший триаж мобильных сбоев начинается с влияния на пользователя, а не с шума. Сбой с 40 событиями может заслуживать внимания раньше, чем сбой с 400, если он останавливает людей прямо у входа.

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

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

Помогает простое правило ранжирования:

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

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

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

Простой пример все проясняет. Допустим, у сбоя A 250 событий от 12 пользователей на экране профиля. А у сбоя B — 35 событий от 31 пользователя во время входа после последнего релиза. Сначала исправляйте сбой B. Он блокирует больше людей и происходит раньше.

Список приоритетов держите коротким. Трех пунктов обычно достаточно для одного спринта или окна релиза. Все, что длиннее, превращается в парковку, и команда начинает спорить вместо того, чтобы чинить.

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

Версия 4.2 выходит в 10:00. К 10:45 объем сбоев уже заметно выше обычного. Маленькая команда в этот момент легко может запаниковать, особенно если дашборд сразу показывает целую пачку новых отчетов.

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

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

Когда сбой символицирован, стек-трейс становится куда полезнее. Вместо расплывчатого адреса памяти команда видит null в парсинге формы после того, как autofill вставляет данные, которые не совпадают с ожидаемой структурой. Теперь баг конкретен: парсер предполагает, что есть каждое поле, но autofill иногда сначала отправляет неполные данные.

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

Разумная реакция в день релиза выглядит так:

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

Только после выхода хотфикса команде стоит вернуться к меньшим отчетам. Редкий сбой в настройках может подождать пару часов. Сбой входа обычно не может.

Ошибки, из-за которых триаж замедляется

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

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

Группировка тоже может навредить по-своему. Если объединять только похожие на вид сбои, можно скрыть реальный паттерн. Null pointer в checkout и null pointer при запуске приложения могут иметь одну-две похожие строки в стеке, но источники у них часто разные: разные пользовательские потоки, устройства или релизы. Если корзина слишком широкая, никто не поймет, какое исправление действительно помогло.

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

Команды тоже слишком быстро назначают исправление. Кто-то видит сбой в сетевом классе, ставит его на backend или mobile infra, и проблема лежит день. Сначала воспроизведите пользовательский путь вокруг сбоя. Он случился после входа, после неудачного запроса разрешения или при возврате приложения из фона? Подсказки по сессии часто показывают настоящий триггер.

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

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

Быстрые проверки перед назначением исправления

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

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

Перед передачей задачи проверьте пять вещей:

• Назовите действие пользователя, которое запускает сбой. «Приложение упало при запуске» — слишком размыто, если в сессии видно, что пользователь нажал «Оплатить», переключился на другое приложение, а потом вернулся.
• Подтвердите точную сборку, версию ОС и платформу. Сбой на Android 14 в сборке 2.8.1 может вообще не иметь отношения к iOS 17 в сборке 2.8.0.
• Проверьте, что для этой сборки загрузились символы. Если символикация сбоев приложения не удалась, стек-трейс может указывать на шум, а не на настоящий метод.
• Посмотрите на группу проблем критическим взглядом. Похожие стек-трейсы не всегда означают одну и ту же причину, особенно если сбои происходят на разных экранах или после разных действий.
• Оцените влияние на ключевой путь пользователя. Редкий сбой в настройках может подождать. Сбой в оплате, регистрации, входе или подписке обычно уходит в начало очереди.

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

Простой пример: в одну и ту же группу попадают два отчета. Один приходит с iOS после нажатия «Start free trial». Второй — с Android после поворота устройства на экране профиля. Верхние фреймы выглядят похоже, но триггер, платформа и бизнес-ущерб — нет. Разделите их.

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

Постройте легкую рутину сбоев, которую команда сможет поддерживать

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

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

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

• номер сборки или версия приложения
• вероятный триггер
• влияние на пользователя
• следующий шаг и ответственный

Такая заметка убирает обычный хаос, когда один человек помнит устройство, другой — стек-трейс, а никто не записал, что делать дальше. Она также облегчает передачу задачи, если лидер Android или iOS недоступен.

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

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

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

Если вашей команде нужна помощь с настройкой, внешняя консультация может пригодиться. Консультации Fractional CTO от Oleg Sotnikov хорошо подходят для такой работы: легкая рутина триажа сбоев, четкая ответственность и процесс, который достаточно мал для стартапа или команды среднего размера, чтобы продолжать им пользоваться.