Обнаружение аномалий в операциях

1) Зачем

Аномалии — ранние маркеры инцидентов и финансовых потерь. В iGaming это падения успешных авторизаций, всплески таймаутов, рост очередей, провалы в конверсии KYC, скачки отклонений ставок, ошибки провайдеров игр. Цель — обнаружить раньше пользователя, локализовать причину и запустить автоматические/операторские реакции.

2) Сигналы и домены наблюдения

Платежи/финансы: success-rate авторизаций по PSP/банкам/GEO, soft/hard declines, время клиринга, chargeback-ранние индикаторы.
Игровое ядро: p95/p99 ставок и сеттлов, error-rate, расхождение балансов, outliers в коэффициентах/линии.
Инфраструктура: latency/5xx API, saturation (CPU/RAM/IO), replication lag БД, consumer-lag очередей, cache-hit/eviction.
KYC/AML: очереди верификаций, TAT (turnaround time), доля ручной проверки.
Фронт/RUM: TTFB/LCP, JS-ошибки, гео-специфичные деградации.
Безопасность/мошенничество: всплески входов/регистраций/выводов, velocity-аномалии, нетипичные паттерны.

3) Типы аномалий

Точечные (point): разовый всплеск/провал (например, падение auth-success в EU на 20%).
Контекстные (contextual): “аномально для этого часа/дня/события” (ночной пик — ок, дневной — нет).
Коллективные (collective): последовательность небольших отклонений, формирующая инцидент (ползучий рост p99).
Смена режима (change-point): новый уровень ряда (после релиза/конфигурации/провайдера).

4) Методы детектирования (от простого к сложному)

1. Пороговые правила: статические или динамические (перцентиль по скользящему окну, медиана ± k·MAD).
2. Сезонная декомпозиция (STL): тренд/сезонность → анализ остатка (residual) и IQR/MAD.
3. Контрольные карты (CUSUM/EWMA): чувствительны к небольшим сдвигам среднего/дисперсии.
4. Обнаружение изменений (Change Point Detection): BOCPD, ruptures/PELT; фиксируем моменты смены режима.
5. Многомерные аномалии: Mahalanobis, Isolation Forest/LOF по наборам фич (latency, error-rate, lag, hit-ratio).
6. Потоковые методы (stream): ADWIN, SSD, sketch-статистика; low-latency и с ограниченной памятью.
7. Прогноз+дельта: ARIMA/ETS/Prophet/GBM → сравнение факта с доверительным интервалом (особенно для бизнес-рядов).
8. Полу-контролируемые ML: обучение на “норме” (One-Class SVM/Autoencoder), полезно при скудной разметке.

Практика: комбинируем 2–3 метода и агрегируем голосованием или по приоритету (rule-of-thumb: сезонная STL + CUSUM + прогнозная лента).

5) Пайплайн аномалий: от данных к действию

1. Сбор → нормализация: унифицированные ряды (OTel/метрики), единая гранулярность (10–60 сек).
2. Фичи и контекст: GEO/PSP/банк/канал, “рабочий час?”, “матч/турнир?”, релизы/фичефлаги, плановые работы.
3. Сезонность и календарь: модели aware о выходных/прайм-тайме/матчах/праздниках.
4. Детектор: выбранные методы (порог/статистика/ML/stream) с параметрами per-сегмент.
5. Подавление шума: гистерезис и подтверждение несколькими окнами (N-of-M), дедуп инцидентов.
6. Сведéние и приоритизация: оценка импакта (SLO, деньги/мин, доля аудитории), присвоение P1–P4.
7. Реакция: авто-действия (фейловер PSP, деградация фич, autoscaling по lag), создание инцидента и вар-рума, обновление статус-страницы.
8. Логирование и аудит: что сработало/почему, пороги/версии моделей, коммуникация.

6) Калибровка порогов и качества

Precision/Recall/F1 для “аномалия ↔ инцидент”.
Time-to-Detect (TTD): цель — раньше MTTA пользователей/саппорта.
False Alarm Rate: целевой ≤ 5–10% для P1/P2.
Lead Time: окно между детектом и нарушением SLO — дает шанс на авто-действия.
Drift мониторинг: переобучение/перекалибровка по расписанию и при смене сезона/архитектуры.

7) Каталог аномалий (iGaming-примеры)

7.1 Платежи

Провал auth-success у PSP-X в TR/EU: контекст — конкретный банк BIN, окно 5–10 мин.
Рост soft-decline при нормальном трафике: возможная 3DS/issuer проблема.
Задержки клиринга: риск кассовых разрывов.
Реакции: роутинг на альтернативного PSP (health×fee×conversion), ретраи с джиттером, включение упрощенного 3DS, комм-пакет партнерам.

7.2 Ставки/игры

Скачок p99 сеттла ставок: реплика/кэш/очередь.
Отрыв ожидаемого GGR от нормы: контекстные аномалии по турнирам/спорт-событиям.
Реакции: кэш-warmup, перераспределение нагрузки, удержание части non-critical фич.

7.3 Инфра/данные

Replication lag↑ и lock-waits: БД перегруз.
Consumer-lag скачет: недоразметка партиций или горячий ключ.
Реакции: autoscaling, переразбиение, лимиты на producer’ов.

7.4 KYC/AML

Время верификации↑: провайдер деградирует.
Реакции: fallback-провайдер/ручная очередь, уведомление Compliance.

7.5 Фронт/RUM

LCP/JS-ошибки в конкретном браузере/версии: регресс релиза.
Реакции: rollback канареек, feature-flag off, сообщение на статус-странице.

8) SLO-aware алертинг

Сигнал аномалии становится алертом, если затрагивает бюджет ошибок или прогнозирует его выгорание (burn-rate).
Два окна: быстрое (1 ч) и медленное (6–24 ч); “немедленный пейджер” только для P1 с высоким импактом.
Любой алерт привязан к runbook и роли владельца.

9) Архитектура решения

Инжест: OTel/метрики → Kafka/стрим → фреймворк обработки (Flink/Spark/Kafka Streams).
Фиче-инжиниринг: агрегаты, сезонные индикаторы, one-hot по PSP/банкам/GEO.
Детекторы: библиотеки статистики + модели (on-line/mini-batch) с версионированием.
Хранилище результатов: “анома-линия” (events) с контекстом, связка с инцидент-менеджментом.
Сервис принятия решений: приоритизация, авто-реакции, публикация на статус-страницу/в каналы.
Наблюдаемость: графики качества моделей, тревоги о drift, стоимость инжеста.

10) Стоимость и приватность

Cost-aware: семплинг входных рядов, downsampling истории, агрегации; отдельные классы QoS.
PII: не логировать userId в метриках; для анализа — токенизация/маски и доступ по SoD; экспорт — через workflow с TTL/шифрованием.

11) Процессы и роли

Responsible: SRE/Observability/Payments Risk в своих доменах.
Accountable: Head of Ops/SRE.
Consulted: Data Science, Product, Compliance, Security.
Informed: Support, Partner Management, Finance.
Ритуалы: еженедельная калибровка порогов/правил, ежемесячные ретро по ложным/пропущенным сигналам.

12) Дашборды

Exec: карта аномалий по доменам, тренды false/true alarms, TTD и lead time, влияние на выручку/SLO.
Ops/SRE: ленты детектов с контекстом (релизы/флаги/плановые работы), распределения остатков STL, карты change-points.
Payments/Risk: теплокарты PSP×банк×GEO, воронки отказов, авто-роутинг и эффект мер.
Front/RUM: браузер×версия×GEO, регрессии релизов, опыт VIP.

13) KPI/KRI функции

TTD (мин) и Lead Time (мин) до SLO-нарушения.
Precision/Recall/F1 по привязке к инцидентам.
False Alarm Rate и квота пейджеров (усталость on-call).
Доля авто-реакций, закрывших проблему без ручного вмешательства.
Снижение MTTR после внедрения.
Стоимость/ценность: $/алерт и экономия от предотвращенных потерь.

14) Дорожная карта внедрения (8–12 недель)

Нед. 1–2: инвентаризация SLI/KPI, выбор приоритетных рядов (платежи/ставки/очереди/БД), базовые пороги и STL.
Нед. 3–4: потоковая обработка (Kafka + Flink/Streams), контекст (GEO/PSP/релизы), гистерезис и дедуп.
Нед. 5–6: change-point + CUSUM, прогнозные ленты для бизнес-рядов, связь с инцидент-платформой, runbooks.
Нед. 7–8: авто-реакции (PSP-фейловер, деградация фич, autoscaling по lag), дашборды и метрики качества.
Нед. 9–10: мультивариантные модели (Isolation Forest/IForest/AE) в пилотных доменах, drift-мониторинг.
Нед. 11–12: оптимизация стоимости, A/B калибровка порогов, регламент ежемесячного review и обучение команд.

15) Шаблоны артефактов

Anomaly Spec: сигнал, сегментация (GEO/PSP/банк), метод, пороги, окна, гистерезис, владелец, runbook, авто-реакции.
Change-Point Report: время, компонент, до/после уровни, корреляции (релизы/фичфлаги/работы).
Quality Dashboard Definition: метрики качества, целевые границы, период пересмотра.
Auto-Action Policy: условия и лимиты авто-действий, критерии возврата, аудит.

16) Антипаттерны

Универсальные статические пороги без сезонности и сегментации.
Отсутствие гистерезиса → флаппинг и “pager fatigue”.
Алерты вне контекста SLO/денег → много шума, мало пользы.
“Черный ящик” ML без объяснимости и журналирования.
Нет связи с релизами/фичефлагами/плановыми работами.
Игнор стоимости инжеста/хранения для вспомогательных рядов.

Итог

Обнаружение аномалий — это процесс и платформа, а не только модель: правильные сигналы и контекст → устойчивые методы (STL/CUSUM/CPD/прогноз) → подавление шума и приоритизация по SLO/выручке → авто-реакции и понятные runbooks → замкнутый цикл качества и стоимости. Такой контур ловит проблемы раньше пользователей, сокращает MTTR и защищает бизнес-потоки iGaming-платформы.