Алерти з потоків даних
1) Навіщо і де застосовувати
У iGaming критичні події відбуваються в реальному часі: затрималися депозити, впав провайдер ігор, виріс RG-ризик у когорти, скакнув chargeback-рейт. Потокові алерти фіксують аномалії до того, як постраждають гроші, UX і комплаєнс.
Цілі:- Раннє виявлення інцидентів даних/платежів/ігор.
- Автоматичні реакції (зміна маршруту, деградації, фіч-прапори).
- Зниження MTTR і «алерт-втоми» через розумні пороги і консолідацію.
2) Архітектура (референс)
Event Bus/Log: Kafka/Pulsar/Kinesis - вихідні стріми (платежі, ігрові раунди, логістика ETL, RG-сигнали).
Stream Processing: Flink/Spark/Faust - вікна, агрегати, кореляції, CEP (Complex Event Processing).
Rules & Models: рушій правил (DSL/YAML), статпороги і online-моделі аномалій.
Alert Router: нормалізація і маршрутизація (PagerDuty/Slack/Email/Webhook), придушення дублікатів.
Incident Mgmt: тікети, ескалації, runbooks, SOAR-плейбуки.
Observability & Storage: метрики алертів, історія, «етикетки» (labels), аудиторський WORM-лог.
3) Потокові вікна та агрегати
Tumbling (фіксовані інтервали: 1, 5, 15 хвилин) - стабільні бізнес-метрики.
Sliding (вікна, що перекриваються) - раннє виявлення трендів.
Session windows - кейси поведінки гравця.
Watermarks - запізнілі події; допускаємо затримку (наприклад, 120с) перед фіналізацією вікна.
Ідемпотентність - унікальні event-id, дедуплікація, exactly-once семантика, «повторна звірка» при пізніх даних.
4) Типи алертів
1. Порогові (threshold): p95 latency PSP> 2000 мс, ставка успіху <99. 5%.
2. Зміна тренду (CUSUM/ADWIN): різкий зсув GGR/хв, аномалії в конверсії депозитів.
3. Кореляційні/СЕР: послідовність подій «KYC fail → депозит → чарджбек».
4. Складені: «низька свіжість + зростання помилок трансформацій».
5. Етичні/RG: зростання частки high-risk в сегменті> X п. п. за 10 хв.
6. Дані/якість: schema drift, різке падіння повноти, сплеск null/duplicates.
7. Приватність/безпека: PII в логах, несанкціонована детокенізація.
5) Зниження шуму (SNR)
Гістерезис і стійке порушення (X з Y вікон), щоб не смикатися на піки.
Динамічні пороги: базова лінія + σ, або квантиль по ковзаючому вікну.
Семплювання алертів: не більше N в T хвилин для одного'labels'-набору.
Угруповання інциденту: один тікет на «збій провайдера ігор» замість сотень алертів по іграх.
Сезонність: окремі пороги для ночі/прайму та акцій/турнірів.
SLO-усвідомлені правила: тригер, тільки якщо порушення впливає на користувацький SLO.
6) Пріоритизація та ескалації
P1: блокуючі гроші/регуляторку (виплати, RG-порушення, масштабний даун).
P2: помітна деградація (latency/помилки/свіжість), ризик регресу KPI.
P3: погіршення якості, що вимагає уваги (DQ, дрейф моделей).
Ескалації: власник домену → черговий SRE/DS → менеджер продукту → кризовий штаб.
7) Приватність і комплаєнс
Zero-PII в payload алертів: тільки токени/агрегати/посилання на кейси.
Режими RG/AML: окремі канали і списки доступу, redaction тексту.
Аудит незмінний (WORM) для регуляторів і постмортемів.
Geo/tenant-ізоляція: маршрутизація по бренду/країні; різні ключі/топіки.
8) SLO і метрики якості алертингу
MTTD (time to detect) и MTTA/MTTR (ack/recover).
Precision/Recall алертів (щодо інцидентів-істини).
False Alarm Rate і Suppression Rate (скільки шумів вирізали).
Coverage: % критичних шляхів (payments, game_rounds, KYC, RG) під алертами.
Drift Detection Latency: час від факту дрейфу до алерта.
On-call Load: алертів/зміну і «будильники вночі».
9) Кейси iGaming (приклади правил)
Платежі/PSP: `success_rate_deposits_5m < 99. 5%` И `psp=XYZ` И `country in [EE,LT,LV]` → P1, SOAR: перемкнути маршрут, підняти ретраї.
Ігрові провайдери: 'game _ rounds _ per _ min drop> 40% vs baseline_28d' на кластері ігор'provider = A'→ P1, повідомити провайдера, заховати лобі-тайли.
RG: 'high _ risk _ share _ 10m ↑> 3 п. п.'в'brand = B'→ P2, включити м'які ліміти, повідомити RG-команду.
Фрод: 'chargeback _ rate _ 60m> μ + 3 σ'І'new _ device _ share ↑'→ P1, включити посилення антифроду.
Дані/DQ: `freshness_payments_gold > 15m` И `ingest_errors > 0. 5%'→ P2, заморозити звіти, включити банер статусу.
10) Шаблони правил (DSL/YAML)
10. 1 Поріг + гістерезис
yaml rule_id: psp_success_drop severity: P1 source: stream:payments. metrics_1m when:
metric: success_rate filter: {psp: ["XYZ"], country: ["EE","LT","LV"]}
window: {type: sliding, size: PT5M, slide: PT1M}
threshold:
op: lt value: 0. 995 sustain: {breaches_required: 3, within: PT5M}
actions:
- route: pagerduty:payments
- runbook: url://runbooks/payments_psp_drop
- soars: [{name: "switch_route", params: {psp_backup: "XYZ2"}}]
privacy: {pii_in_payload: false}10. 2 Аномалія проти базової лінії
yaml rule_id: provider_volume_anomaly severity: P1 source: stream:games. rounds_1m baseline: {type: rolling_quantile, period: P28D, quantile: 0. 1}
anomaly:
op: lt_ratio value: 0. 6 # drop below 60% of baseline labels: {provider: "$ provider"}
suppress: {per: provider, max: 1, within: PT10M}
actions:
- route: slack:#games-ops
- feature_flag: {hide_provider_tiles: true}10. 3 Композит з CEP
yaml rule_id: kyc_deposit_chargeback severity: P2 pattern:
- event: kyc_result where: {status: "fail"}
- within: PT24H
- event: payment where: {type: "deposit"}
- within: PT14D
- event: chargeback actions:
- route: antifraud_queue
- create_case: {type: "investigation", ttl: P30D}11) Інтеграції та автоматичні реакції
SOAR: перемикання PSP/ендпоінта, збільшення ретраїв, активація фіч-прапорів, тимчасова деградація API.
Feature Flags: вимкнення проблемних ігор/віджетів, «уявні перила» для RG.
Status Page: автоматичні банери для внутрішніх/партнерських панелей.
Ticketing: заповнення полів "власник, домен, runbook, trace_id".
12) Операції та процеси
RACI: власники правил - доменні команди; платформа - рушій, SLO, масштаб.
Versioning: правила в Git,'MAJOR/MINOR/PATCH', canary-режим.
Тести: симуляції потоків, replays, ретроспективні перевірки за відомими інцидентами.
Пост-мортеми: кожне P1/P2 - уроки, оновлення порогів/гістерезисів, додавання CEP-обмежень.
13) Дорожня карта впровадження
0-30 днів (MVP)
1. Охопити критичні шляхи: payments, game_rounds, ingest freshness.
2. Завести DSL/YAML для правил, Git-сховище і каталог власників.
3. Включити гістерезис і придушення дублів; канали Slack/PagerDuty.
4. Завести 3 runbook'a: «платежі», «ігри», «DQ/freshness».
5. Метрики: MTTD/MTTR, Precision/Recall по ручній розмітці.
30-90 днів
1. Базові аномальні детектори (baseline/квантилі), CEP-шаблони.
2. SOAR-автоматизації (перемикання PSP, фіч-прапори, статус-сторінки).
3. SLO-усвідомлені правила і угруповання інцидентів.
4. Реплеї історій для «регресійних» тестів правил.
5. RG/AML-канали з редакцією та обмеженнями доступу.
3-6 місяців
1. Champion-Challenger для правил і моделей аномалій.
2. Каталог ефектів (які алерти реально знижували MTTR/втрати).
3. AIOps-підказки порогів і авто-тюнінг гістерезису.
4. Зовнішні інтеграції (провайдери ігор/PSP) з підписаними вебхуками.
5. Квартальні гігієна-сесії: видалення «мертвих» правил, злиття дублюючих.
14) Метрики успіху (приклад)
MTTD/MTTR: медіана і p90 за типами інцидентів.
Alert Precision/Recall: ≥ цільових порогів.
Noise↓: −X% 4хх/« помилкових »P3; «будильників вночі» ≤ У/тиждень.
Coverage: ≥ 95% критичних шляхів з активними правилами.
SOAR-ефект: економія часу до ручного втручання.
Бізнес-вплив: утримані депозити/платежі, зниження втрачених раундів.
15) Анти-патерни
Поріг «на око» без базової лінії і гістерезису.
Алерти, не прив'язані до SLO/бізнес-ризику.
PII в тілах алертів, скріншоти з даними в загальних каналах.
Відсутність suppression/grouping → «шторм» повідомлень.
Ніяких реплеїв - правила ламаються при кожному піку.
«Вічні» правила без рев'ю і власника.
16) Пов'язані розділи
DataOps-практики, API аналітики і метрик, Аудит і версійність, Контроль доступу, Безпека і шифрування, Політики зберігання, MLOps: експлуатація моделей, Responsible Gaming, Антифрод/Платежі.
Підсумок
Потокові алерти - це операційна нервова система даних: вони об'єднують події, контекст і автоматичні дії, щоб вчасно зупинити каскад проблем. При правильній архітектурі, гігієні порогів і повазі до приватності алерти скорочують MTTR, захищають виручку і підтримують довіру гравців і регуляторів.