Моніторинг стабільності мобільного додатку в продакшені
Crash-free rate 99,2% звучить добре, поки не посчитаєте: при 100 000 DAU це 800 крешів на день. Без інструментів моніторингу команда дізнається про проблему з відзивів у App Store — то есть з затримкою в кілька годин після того, як сотні користувачів уже стикнулись з помилкою.
Що моніторимо
Крешн й помилки
Основний інструмент — Firebase Crashlytics. Автоматично перехоплює fatal й non-fatal винятки, групує по стектрейсу, показує затронутих користувачів та сесії. Ключові метрики для щоденного контролю:
- Crash-free users (не sessions) — реальна картина по користувачам
- Velocity alerts — Crashlytics вміє присилати уведомлення, коли нова крешу торкається N% сесій за годину
- Regression tracking — була крешу, закрили, з'явилась знову в новій версії
Для NDK/C++ компонентів потрібна окрема настройка nativeSymbolUploadEnabled = true й завантаження .so символів через Crashlytics CLI.
ANR й зависання (Android)
Google Play Console → Android Vitals → ANR rate. Пороговое значення Google — 0,47% ANR-rate, вище нього додаток помічається як проблемний й знижується у пошуку. ANR на головному потоці частіше за все означає блокуючий IO або синхронний запит до бази даних у onCreate.
StrictMode у Debug-збірках помагає поймати такі місця до продакшена:
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(
StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectNetwork()
.penaltyLog()
.build()
)
}
Продуктивність (iOS MetricKit)
MetricKit з iOS 14 доставляє агреговані дані по діагностиці: hang rate, crash rate, disk writes, launch time. Дані приходять раз на суть у didReceive(_ payloads: [MXMetricPayload]). Для моніторингу launch time критично стежити applicationLaunchMetrics.histogrammedTimeToFirstDraw — деградація на 200ms уже впливає на утримання.
Нестандартні события
Firebase Crashlytics дозволяє логувати non-fatal помилки вручну — це важливо для бізнес-критичних флоу:
// iOS: логуємо помилку оплати як non-fatal
Crashlytics.crashlytics().record(error: paymentError)
Crashlytics.crashlytics().log("Payment failed at step: \(step)")
// Android
FirebaseCrashlytics.getInstance().recordException(exception)
FirebaseCrashlytics.getInstance().log("Checkout step: $step")
Так у Crashlytics з'являються «м'які» помилки — користувач не побачив крешу, але транзакція не пройшла.
Алертинг
Налаштовуємо уведомлення в Slack або Telegram через Crashlytics webhooks або Firebase Extensions. Мінімальний набір алертів:
| Подія | Поріг | Канал |
|---|---|---|
| Нова крешу в release-збірці | Будь-яка | #crashes-mobile |
| Crash-free rate упав | < 99,5% за годину | #incidents |
| ANR rate (Android) | > 0,3% | #android-ops |
| Velocity alert | > 0,1% сесій за 30 хв | #incidents (pager) |
Процес роботи
Первинна настройка: інтеграція Crashlytics, налаштування velocity alerts, підключення до Slack.
Щоденний моніторинг: перегляд нових крешів, звірка з Android Vitals і App Store Connect.
Регулярні звіти: щотижневий зріз crash-free rate у розрізі версій ОС й пристроїв.
Орієнтири по строкам
Первинна настройка повного моніторингу — 1–3 дні залежно від складності проекту. Ongoing-моніторинг — обговорюється індивідуально.