Настройка алертов по метрикам стабильности мобильного приложения

Настройка алертов по метрикам стабильности мобильного приложения

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

Ключевые метрики стабильности

Crash-Free Users Rate — процент пользователей, у которых за период не было ни одного крэша. Сторонние ориентиры: Google Play считает «плохим» приложение с > 1.09% crashes per session. Apple рекомендует > 99% Crash-Free Users. Важный нюанс: считать нужно по уникальным пользователям, а не по сессиям — иначе один пользователь с 10 крэшами завышает значение.

ANR Rate (Android) — количество ANR-событий на 1000 пользователей в день. Порог плохого поведения в Google Play Vitals: > 0.47% ANR Rate.

Watchdog Termination Rate (iOS) — соотношение сессий с Watchdog Termination к общему числу сессий. Нет официального бенчмарка от Apple, но хороший ориентир — < 0.1%.

App Hang Rate (iOS) — процент сессий с зависанием UI > 250ms. Xcode Organizer показывает эту метрику в Hang Rate.

Настройка алертов в Firebase Crashlytics

// Firebase Alert Webhook (настраивается в консоли Firebase)
// При velocity alert — POST на ваш endpoint

// Пример payload от Firebase:
{
  "type": "crashlytics.velocityAlert",
  "data": {
    "issue": {
      "id": "issue_id",
      "title": "Fatal Exception: java.lang.NullPointerException",
      "crashPercentage": 2.3,
      "firstVersion": "2.1.0",
      "latestVersion": "2.3.1"
    }
  }
}

Velocity Alert в Crashlytics срабатывает, когда процент затронутых сессий резко растёт. Настройка порога — в Firebase Console → Crashlytics → Alerts.

Алерты в Sentry с CRON-проверкой

# Sentry API — создание Monitor через REST
import requests

response = requests.post(
    "https://sentry.io/api/0/organizations/YOUR_ORG/monitors/",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json={
        "name": "Crash-Free Rate Drop",
        "type": "cron_job",
        "config": {
            "schedule_type": "interval",
            "schedule": [1, "hour"]
        }
    }
)

Но удобнее использовать Sentry Alerts через UI: Issues → Alerts → New Alert Rule:

• Условие: Number of users affected > 50 за 1 час
• Действие: Notify Slack channel #mobile-incidents

Алерты в Datadog на основе RUM-метрик

# Datadog Monitor query (Metric Alert)
rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600)

# Условие: > 100 крэшей в час → CRITICAL
# > 50 крэшей в час → WARNING

Для Crash-Free Rate:

# Вычисляемая метрика в Datadog
(1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100

# Алерт: если < 99% → WARNING, < 98% → CRITICAL

Маршрутизация алертов

# PagerDuty + Alertmanager (для Prometheus-based мониторинга)
route:
  group_by: ['service', 'platform']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
        service: mobile
      receiver: pagerduty-mobile-oncall
    - match:
        severity: warning
        service: mobile
      receiver: slack-mobile-channel

receivers:
  - name: pagerduty-mobile-oncall
    pagerduty_configs:
      - service_key: YOUR_PD_SERVICE_KEY
  - name: slack-mobile-channel
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK
        channel: '#mobile-stability'

Что не работает: типичные ошибки конфигурации

Алерт на абсолютное число крэшей без нормировки. При росте аудитории число крэшей растёт, даже если Crash-Free Rate стабильный. Алерт постоянно срабатывает, команда перестаёт реагировать.

Единый порог для всех версий. Новая версия только вышла — у неё маленькая аудитория, но высокий крэш-рейт может быть статистически незначимым. Добавляйте условие sessions > 1000 перед проверкой порогов.

Нет алерта на улучшение. Если Crash-Free Rate резко вырос с 97% до 99.9% — это тоже интересно: может быть, сработал hotfix. Bi-directional алерты помогают понять эффект релизов.

Что делаем

• Определяем baseline метрик стабильности для текущей версии
• Настраиваем velocity alerts в Crashlytics/Sentry под реальный трафик
• Конфигурируем Datadog/New Relic Monitors с нормировкой по сессиям
• Маршрутизируем CRITICAL → PagerDuty, WARNING → Slack
• Документируем runbook для каждого типа алерта

Сроки

Базовая настройка алертов: 4 часа – 1 день. Полная система с маршрутизацией и runbook: 2 дня. Стоимость рассчитывается индивидуально.