Виявлення аномалій в операціях
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
Час verifikatsii↑: провайдер деградує.
Реакції: 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-платформи.