Anomaly detection для бизнес-метрик: пайплайн от детекции до RCA

Действуй как data reliability engineer. Спроектируй anomaly detection для метрики {{metric}}. Частота: {{frequency}}. Стек: {{stack}}.

Шаг 1. Выбор метода детекции

Static thresholds

• Когда: метрика стабильна, известны бизнес-границы (например, error_rate > 1% — это плохо всегда)
• Плюсы: понятно, predictable
• Минусы: ловит только грубые аномалии, нужно вручную обновлять

Rolling z-score / MAD

• z = (x - rolling_mean) / rolling_std. Аномалия при |z| > 3
• MAD устойчивее к выбросам, чем std (median absolute deviation)
• Окно: 14-30 точек для daily, 1-7 дней для hourly
• Когда: метрика без сильной сезонности

ESD (Extended Studentized Deviate)

• Грубо: итеративно убирает наибольшие отклонения и тестит остаток на normality
• Хорошо ловит несколько аномалий подряд (не маскируются друг другом)
• Когда: ожидаешь несколько spike подряд

Prophet / SARIMA / decomposition

• Раскладывает сигнал на trend + weekly + daily + residual; аномалия = residual выходит за CI
• Когда: явная сезонность (DAU с weekend dip, e-commerce — Black Friday)
• Минусы: дороже compute, нужно retrain regularly

Isolation Forest / Autoencoder

• ML-based, multivariate (учитывает несколько метрик одновременно)
• Когда: ловишь сложные корреляции между метриками
• Минусы: чёрный ящик, требует ML team

Решение

Стартуй просто: rolling z-score (или MAD) на residual после decomposition. Поднимайся в Prophet только если простое не работает.

Шаг 2. Контроль false positives

• Sensitivity: z=3 даёт ~0.3% FPR при нормальном распределении. z=4 — ~0.006%. Бери минимум z=3.5 для бизнес-метрик.
• Persistence requirement: не алерти на 1 точку, требуй ≥3 точки подряд (или ≥3 из 5). Снижает FPR на порядок.
• Cool-down: после алерта 1 час молчания по этой метрике. Чтобы не спамить одним инцидентом.
• Suppression rules: запланированные релизы / маркетинг кампании / праздники — flag-таблица, suppress на эти окна.
• Hysteresis: вошёл в anomaly при z>3.5, выйдёт при z<2.5. Иначе будет flapping.

Шаг 3. Сезонность

Если метрика имеет недельную сезонность (weekend dip):

• Сравнивай same-day-of-week baseline (среда vs предыдущие 4 среды), не предыдущий день
• Или: используй STL-decomposition, считай z-score на residual

Дневная сезонность (часовая):

• Same-hour-of-week baseline (понедельник 14:00 vs последние 4 понедельника в 14:00)

Holiday handling:

• Чёрный список дат (Black Friday, NYE) — suppress алерты
• Альтернатива: Prophet с holiday regressor

Шаг 4. Alert tiering

Правило: если в P0/P1 нет конкретного действия — это P2. Page = wake up. Без действия — не буди.

Шаг 5. Root cause investigation flow

При алерте бот должен сразу присоединить контекст:

ALERT P1: conversion_rate dropped (z=-4.2, persisted 15 min)
- Current: 1.8% (baseline 3.1%, expected 2.9-3.3%)
- Started: 2026-05-18 14:22 UTC
- Affected segments: web/Chrome (-65%), iOS unaffected
- Recent changes:
  - Deploy 14:18: web checkout v3.2 (5 min before)
  - Marketing: no campaign change in last 24h
- Correlated metrics:
  - JS errors on /checkout +340%
  - p95 latency normal
- Suggested next:
  - Rollback deploy v3.2
  - Check Sentry for new error signatures
- Runbook: <link>

Минимальный набор контекста: что упало, на сколько, с какого момента, в каком сегменте, какие deploys/changes в последние 30 минут, коррелированные метрики, рекомендуемое действие.

Шаг 6. Метрика самой системы

• True positive rate (real incidents caught / total real incidents) — цель >95%
• False positive rate (false alerts / total alerts) — цель <10%
• Mean time to detect (MTTD) — цель < окно × 2
• Alert fatigue score — # алертов / # actions taken

Если FPR > 30% — система мусорит, люди начнут игнорировать.

Output

## Detection spec
- Metric: {{metric}}
- Frequency: {{frequency}}
- Method: rolling MAD on STL residual, z=3.5
- Persistence: 3 consecutive points
- Cool-down: 1h
- Suppression: holiday calendar + deploy windows

## Alert routing
| Severity | Trigger | Channel | Runbook |

## RCA template
[как выше]

## SLOs of detection system
- TPR > 95%, FPR < 10%, MTTD < 10 min

Анти-паттерны

• ❌ Алерт на любое отклонение от mean — flapping, alert fatigue, никто не реагирует
• ❌ Static threshold на сезонную метрику — false positives каждый weekend
• ❌ Alert на одной точке — random noise будит on-call ночью
• ❌ Prophet без holiday calendar — Black Friday = алерт-storm
• ❌ Алерт без runbook — on-call просыпается, не знает что делать
• ❌ Игнор корреляций — алерт на 5 метрик одновременно из одной причины = 5 разных тикетов
• ❌ Не мерить FPR системы — постепенно деградирует, никто не замечает