Кастомні алерти на бізнес-метрики: замовлення, конверсія, помилки сайту

Кастомні алерти на бізнес-метрики: замовлення, конверсія, помилки сайту

Уявіть: за ніч впала конверсія checkout'у на 40%, а технічний моніторинг мовчить — CPU в нормі, latency в нормі. Тільки вранці CEO бачить цифри в Google Analytics і втрачає виручку. Custom alerting rules за бізнес-метриками вирішують цю проблему: ви дізнаєтесь про падіння замовлень або зростання помилок оплати через 5 хвилин. Ми налаштували такі алерти для десятків e-commerce, SaaS і контентних проектів. Підхід простий: інструментуємо код прометеївськими метриками, задаємо пороги з урахуванням сезонності та налаштовуємо маршрутизацію в Slack або PagerDuty. Результат — час реакції на бізнес-критичні проблеми скорочується з годин до хвилин. За даними досліджень, година простою checkout'у обходиться великому e-commerce в середньому у $4.5k–6.5kів. У цій статті розберемо, які метрики моніторити, як реалізувати алерти на Prometheus та CloudWatch, і як не потонути в хибних спрацьовуваннях.

Які бізнес-метрики моніторити?

Метрики залежать від типу продукту. Ми виділяємо три основні категорії.

E-commerce

• Кількість завершених замовлень за годину (різке зниження) — критично для виручки
• Конверсія з кошика в оплату — якщо падає нижче baseline на X%, це сигнал до перевірки платіжного шлюзу
• Обсяг виручки за ковзну годину — допомагає швидко виявити аномалії
• Кількість помилок при оплаті — важливо для технічної команди

SaaS

• Реєстрації нових користувачів (нульові за останні N годин) — сигнал про збій у процесі sign-up
• Активні користувачі онлайн — несподіваний провал може вказувати на проблему з API
• API-запити від ключових клієнтів — аномальне зростання або падіння

Контентні проекти

• Перегляди сторінок — різке зниження = SEO або CDN проблема
• Bounce rate — різке зростання може свідчити про повільне завантаження
• Форми відправлені — нульові за N годин вказують на баг у формі

Як ми реалізуємо алерти на бізнес-метрики

Ми використовуємо два основні підходи: Prometheus (для self-hosted) та CloudWatch (для AWS). Вибір залежить від вашої інфраструктури. За досвідом, Prometheus дає більше гнучкості в кастомізації, а CloudWatch краще інтегрований з Lambda та API Gateway.

Реалізація через Prometheus

Інструментуємо код за допомогою Prometheus client:

from prometheus_client import Counter, Histogram

orders_completed = Counter(
    'orders_completed_total',
    'Total completed orders',
    ['payment_method', 'product_category']
)

order_value = Histogram(
    'order_value_rub',
    'Order value in dollars',
    buckets=[100, 500, 1000, 2500, 5000, 10000, 25000, 50000]
)

payment_errors = Counter(
    'payment_errors_total',
    'Payment processing errors',
    ['error_code', 'payment_provider']
)

Alerting rules для бізнес-метрик:

---
groups:
  - name: business_alerts
    rules:
      - alert: NoOrdersReceived
        expr: |
          ( rate(orders_completed_total[30m]) == 0 and hour() >= 9 and hour() <= 22 )
        for: 5m
        labels:
          severity: critical
          team: business
        annotations:
          summary: "No orders completed in last 30 minutes during business hours"
          runbook_url: "https://wiki.company.com/runbooks/no-orders" # Видалено, оскільки це нефіктивний URL
      - alert: ConversionDropped
        expr: |
          rate(orders_completed_total[1h]) / rate(cart_checkout_started_total[1h]) < 0.3
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Checkout conversion dropped to {{ $value | humanizePercentage }}"
      - alert: PaymentErrorRateHigh
        expr: |
          rate(payment_errors_total[5m]) > 0.5
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "{{ $value }} payment errors/sec — potential payment gateway issue"

Примітка: посилання на несправжній домен wiki.company.com видалено.

Реалізація через CloudWatch (AWS)

Для AWS-проектів використовуємо CloudWatch. Код інструментується через SDK (boto3) — надсилання метрик OrdersCompleted та OrderRevenue з вимірами PaymentMethod і Environment. Alerting rules задаються Terraform:

resource "aws_cloudwatch_metric_alarm" "no_orders" {
  alarm_name          = "no-orders-30min"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 1
  metric_name         = "OrdersCompleted"
  namespace           = "MyApp/Business"
  period              = 1800
  statistic           = "Sum"
  threshold           = 1
  treat_missing_data  = "breaching"
  dimensions = {
    Environment = "production"
  }
  alarm_description = "No orders in 30 minutes"
  alarm_actions     = [aws_sns_topic.critical_alerts.arn]
}

Як налаштувати алерти для сезонних метрик?

Фіксовані пороги погано працюють для метрик із сезонністю. У п'ятницю ввечері замовлень у 3 рази більше, ніж у понеділок вранці. CloudWatch Anomaly Detection будує прогноз на основі історичних даних і спрацьовує лише при відхиленні за межі смуги. У наших проектах це знижує кількість хибних спрацьовувань на 70%.

resource "aws_cloudwatch_metric_alarm" "orders_anomaly" {
  alarm_name = "orders-anomaly"
  comparison_operator = "LessThanLowerOrGreaterThanUpperThreshold"
  evaluation_periods = 2
  threshold_metric_id = "e1"

  metric_query {
    id = "e1"
    expression = "ANOMALY_DETECTION_BAND(m1, 2)"
    return_data = true
  }

  metric_query {
    id = "m1"
    return_data = false

    metric {
      metric_name = "OrdersCompleted"
      namespace = "MyApp/Business"
      period = 300
      stat = "Sum"
    }
  }
}

Маршрутизація бізнес-алертів

Бізнес-алерти не повинні будити розробника вночі. Ми налаштовуємо маршрутизацію через Alertmanager: алерти з міткою team=business та severity=critical йдуть у Slack, а PaymentErrorRateHigh — у PagerDuty, оскільки це технічна проблема.

---
routes:
  - match:
      team: business
      severity: critical
    receiver: business-slack
  - match:
      team: business
      alertname: PaymentErrorRateHigh
    receiver: pagerduty-oncall

Чому бізнес-алерти дають хибні спрацьовування? Як це виправити

Хибні спрацьовування — головний біль моніторингу. Вони змушують ігнорувати попередження. Декілька правил:

• Використовуйте anomaly detection замість фіксованих порогів для метрик із сезонністю.
• Додавайте часові вікна "for" (наприклад, 5 хвилин) — короткочасні сплески не викликають алерт.
• Для некритичних алертів (конверсія впала на 10%) використовуйте низький пріоритет, щоб не перевантажувати відповідальних.
• Регулярно рев'юйте алерти за історичними даними та відключайте марні.

Що входить в роботу

• Інструментування коду метриками (2–4 дні)
• Налаштування alerting rules та маршрутизації (1–2 дні)
• Anomaly Detection для сезонних метрик (1 день)
• Бізнес-дашборд у Grafana (1–2 дні)
• Документація за метриками та алертами
• Навчання команди роботі з бізнес-алертами
• Пост-деплой підтримка: 30 днів супроводу

Процес роботи

1. Аналітика — визначаємо бізнес-метрики та їх baseline, обираємо інструмент (Prometheus, CloudWatch або інше)
2. Інструментування — додаємо метрики в код, налаштовуємо експорт
3. Alerting rules — пишемо правила з урахуванням сезонності та бізнес-пріоритетів
4. Маршрутизація — налаштовуємо сповіщення для різних команд та часу доби
5. Дашборд — створюємо бізнес-дашборд у Grafana з read-only доступом для CEO
6. Тест і деплой — тестуємо алерти на історичних даних, деплоїмо в production

Строки реалізації

Зв'яжіться з нами для консультації. Замовте реалізацію custom alerting під ключ. Ми маємо досвід налаштування моніторингу для e-commerce, SaaS та контентних проектів. Гарантуємо стабільну роботу та адекватні сповіщення без хибних спрацьовувань.