У мобильного приложения есть два разных времени: момент, когда пользователь сталкивается со сбоем, и момент, когда команда ждёт очередную сборку. Crash-free и длительность сборки лежат по разные стороны релиза, однако вместе они хорошо описывают состояние продукта. Первая метрика показывает, сколько людей прошли период без аварийного завершения; вторая помогает увидеть, насколько предсказуемо команда доставляет изменения.

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

Crash-free измеряет опыт конкретных пользователей

Crash-free рассчитывают как долю уникальных активных пользователей, у которых за выбранный период не было краша. Показатель в 99,9% звучит убедительно, но сам по себе не отвечает на вопрос о приемлемом качестве. У финансового приложения сбой во время транзакции может затронуть деньги и доверие, поэтому ориентир часто лежит у 99,99% и выше. У небольшой товарной витрины попытка устранить каждый редкий краш способна стоить дороже потерь от него.

Цель надёжности стоит формулировать как SLO: заранее выбранный уровень, соответствующий сценарию использования и цене ошибки. В соглашениях SLA могут закрепляться внешние обязательства, а SLO помогает команде управлять ежедневной работой. Важно также зафиксировать период расчёта: суточный и месячный Crash-free одной версии различаются, поскольку меняется состав уникальных пользователей и частота их сессий.

Отчёт из Firebase, AppMetrica или Sentry — только исходные данные. Чтобы показатель работал, команде требуется цепочка из сбора события, агрегации, мониторинга, бюджета ошибок и процесса инцидента. Сервис сбора может передать стек вызовов, события перед сбоем и снимок экрана; на следующем этапе одинаковые ошибки группируют по версии, устройству, региону или платформе. Затем для группы можно автоматически создать задачу с ответственным и достаточным контекстом.

Бюджет ошибок задаёт приоритет исправлений

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

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

ANR — состояние Application Not Responding из-за долгой блокировки главного потока — удобно вести рядом с крашами. Причина у него часто сложнее, чем у конкретного исключения в коде, однако для пользователя результат похож: приложение перестаёт выполнять действие. Общий контур мониторинга избавляет от разрозненных очередей и даёт одну картину стабильности релиза.

Длительность сборки видна раньше, чем задержка релиза

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

Отдельного контроля требуют задачи минификации и shrink, кодогенерация через KSP или KAPT, загрузка зависимостей и includeBuild-библиотеки. Каждая из них способна превратить привычную горячую сборку в холодную. Ночной прогон Gradle-profiler позволяет воспроизводимо сравнить сценарии: например, задать число прогревочных запусков, отдельные задачи для debug и release, а для холодной сборки отключить build cache и configuration cache.

Результат профилирования полезно переносить из HTML- или CSV-отчёта в общую систему метрик. Тогда на одном дашборде видна динамика релизных сборок, а также эффект обновления Gradle, подключения библиотеки или смены DI-фреймворка. Для расследования скачка пригодятся измерения по каждой Gradle-задаче, времени конфигурации и потреблению памяти на CI.

Такой уровень детализации меняет разговор о производительности сборки. Рост времени release в четыре раза может оказаться следствием того, что новой библиотеке не хватает памяти на задаче Minify. Проблему удаётся локализовать по данным, вместо серии случайных оптимизаций. Для времени сборки тоже имеет смысл определить SLO — допустимую длительность конкретного сценария, после которой изменение требует разбора.

Одна система наблюдения связывает релиз и эксплуатацию

Crash-free отвечает на вопрос о стабильности уже выпущенного приложения. Время сборки показывает, насколько команда способна быстро и повторяемо подготовить следующее изменение. У этих метрик разная аудитория и разная цена отклонения, поэтому их нельзя сводить к единому «индексу здоровья».

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