Détection d'anomalies dans les opérations

1) Pourquoi

Les anomalies sont les premiers marqueurs d'incidents et de pertes financières. Dans iGaming, ce sont des chutes d'autorisations réussies, des surtensions de temps, une augmentation des files d'attente, des échecs de conversion KYC, des sautes de taux, des erreurs des fournisseurs de jeux. L'objectif est de détecter avant l'utilisateur, de localiser la cause et de lancer des réactions automatiques/opérateurs.

2) Signaux et domaines d'observation

Paiements/finances : success-rate autorisations PSP/banques/GEO, soft/hard declines, temps de compensation, chargeback-premiers indicateurs.
Noyau de jeu : p95/p99 paris et settles, error-rate, divergence des bilans, outliers en coefficients/lignes.
Infrastructure : API latency/5xx, saturation (CPU/RAM/IO), replication lag DB, file d'attente consumer-lag, cache-hit/evection.
KYC/AML : files de vérification, TAT (time turnaround), proportion de vérification manuelle.
Front/RUM : TTFB/LCP, erreurs JS, dégradations géo-spécifiques.
Sécurité/fraude : surtensions d'entrées/inscriptions/sorties, anomalies de velocity, schémas atypiques.

3) Types d'anomalies

Point (point) : sursaut/échec ponctuel (par exemple, chute de 20 % de l'auth-success dans l'UE).
Contextuel (contextual) : « anormal pour cette heure/jour/événement » (pic de nuit - ok, diurne - non).
Collectif (collectif) : séquence de petites anomalies formant un incident (croissance rampante p99).
Changement de mode (change-point) : nouveau niveau de série (après sortie/configuration/fournisseur).

4) Techniques de détection (du simple au complexe)

1. Règles de seuil : statiques ou dynamiques (percentile par fenêtre glissante, médiane ± k· MAD).
2. La décomposition de saison (STL) : la tendance/période de saison → l'analyse du reste (residual) et IQR/MAD.
3. Cartes de contrôle (CUSUM/EWMA) : sensibles aux petits changements de moyenne/variance.
4. Détection de changement (Change Point Detection) : BOCPD, ruptures/PELT ; nous enregistrons les moments de changement de régime.
5. Anomalies multidimensionnelles : Mahalanobis, Isolation Forest/LOF par ensembles de fiches (latitude, error-rate, lag, hit-ratio).
6. Méthodes de streaming (stream) : ADWIN, SSD, statistiques de sketch ; low-latency et avec une mémoire limitée.
7. Prévisions + delta : ARIMA/ETS/Prophet/GBM → comparaison des faits avec l'intervalle de confiance (en particulier pour les séries commerciales).
8. Semi-surveillé ML : apprentissage sur la « normale » (One-Class SVM/Autoencoder), utile pour les marques rares.

Pratique : combiner 2 à 3 méthodes et agréger par vote ou par priorité (rule-of-thumb : STL saisonnier + CUSUM + bande prédictive).

5) Anomalies Pipline : des données à l'action

1. Collecte → normalisation : séries unifiées (OTel/métriques), granularité unique (10-60 secondes).
2. Fichi et contexte : GEO/PSP/banque/canal, "heures de travail ? «, « match/tournoi ? ", sorties/ficheflags, travaux planifiés.
3. Saisonnalité et calendrier : modèles aware sur week-end/prime time/match/vacances.
4. Détecteur : méthodes sélectionnées (seuil/statistiques/ML/stream) avec paramètres par segment.
5. Suppression du bruit : hystérésis et confirmation par plusieurs fenêtres (N-of-M), déduplication des incidents.
6. Démultiplication et hiérarchisation : évaluation de l'impact (SLO, argent/min, part d'audience), appropriation des P1-P4.
7. Réaction : auto-action (faussaire PSP, dégradation des fiches, autoscaling par lag), création de l'incident et du var, mise à jour de la page de statut.
8. Loging et audit : ce qui a fonctionné/pourquoi, seuils/versions de modèles, communication.

6) Étalonnage des seuils et de la qualité

Precision/Recall/F1 pour « anomalie ↔ incident ».
Time-to-Detect (TTD) : l'objectif est avant MTTA utilisateurs/Sapport.
Taux d'alerte faux : cible ≤ 5-10 % pour les P1/P2.
Lead Time : une fenêtre entre un enfant et une violation de SLO - donne une chance d'action auto.
Drift monitoring : rééducation/recalibrage selon les horaires et lors du changement de saison/architecture.

7) Annuaire des anomalies (iGaming exemples)

7. 1 Paiements

Échec de l'auth-success chez PSP-X dans TR/EU : contexte - banque BIN spécifique, fenêtre 5-10 min.
Croissance soft-decline avec un trafic normal : un problème 3DS/issuer possible.
Retards de compensation : risque de discontinuité.
Réactions : itinérance sur une PSP alternative (santé × fee × conversion), retraits avec gitter, inclusion d'une 3DS simplifiée, paquet de commm aux partenaires.

7. 2 Paris/jeux

Saut de la grille de paris p99 : réplique/cache/file d'attente.
Écart entre le RGG attendu et la normale : anomalies contextuelles sur les tournois/événements sportifs.
Réactions : cache-warmup, redistribution de la charge, maintien d'une partie de la fiche non critique.

7. 3 Infra/données

Replication lag↑ et lock-waits : surchauffe OBD.
Consumer-lag saute : malentendu de lots ou clé chaude.
Réactions : autoscaling, rediffusion, limites de production.

7. 4 KYC/AML

Temps de verifikatsii↑ : le fournisseur est dégradé.
Réactions : fallback-fournisseur/file d'attente manuelle, notification de conformité.

7. 5 Front/RUM

Erreurs LCP/JS dans un navigateur/version spécifique : régression de sortie.
Réactions : rollback canaries, feature-flag off, message sur la page de statut.

8) SLO-aware alerting

Le signal d'anomalie devient une alerte s'il affecte le budget des erreurs ou prédit son burn-rate.
Deux fenêtres : rapide (1 h) et lente (6-24 h) ; « pager immédiat » uniquement pour les P1 à fort impact.
N'importe quel alert est lié au runbook et au rôle du propriétaire.

9) Architecture de la solution

Ingest : OTel/métriques → Kafka/stream → cadre de traitement (Flink/Spark/Kafka Streams).
Fiche-engineering : agrégats, indicateurs saisonniers, one-hot par PSP/banques/GEO.
Détecteurs : bibliothèques statistiques + modèles (on-line/mini-batch) avec versioning.
Stockage des résultats : « anoma-line » (événements) avec le contexte, lien avec l'incident-gestion.
Service de prise de décision : hiérarchisation, auto-réactions, publication sur la page de statut/dans les canaux.
Observabilité : graphiques de qualité des modèles, alarmes drift, coût de l'injection.

10) Coût et vie privée

Cost-aware : échantillonnage des lignes d'entrée, downsampling de l'histoire, agrégation ; classes séparées de QoS.
PII : ne pas loger userId en métriques ; pour l'analyse - Tokenization/masques et accès par SoD ; exportation - via workflow avec TTL/cryptage.

11) Processus et rôles

Responsible : SRE/Observability/Payments Risk dans ses domaines.
Accountable: Head of Ops/SRE.
Consulted: Data Science, Product, Compliance, Security.
Informed: Support, Partner Management, Finance.
Rituels : étalonnage hebdomadaire des seuils/règles, rétro mensuel par signaux faux/sautés.

12) Dashboards

Exec : carte des anomalies par domaine, tendances false/true alarms, TTD et lead time, impact sur le chiffre d'affaires/SLO.
Ops/SRE : bandes de détails avec contexte (sorties/drapeaux/travaux planifiés), distribution des résidus STL, cartes de changement de points.
Payments/Risk : cartes thermiques PSP × banque × GEO, vortex de défaillance, auto-rooting et effet des mesures.
Front/RUM : браузер×версия×GEO, les régressions des releases, l'expérience du VIP.

13) fonction KPI/KRI

TTD (min) et Lead Time (min) avant la violation de SLO.
Precision/Recall/F1 de référence aux incidents.
Taux d'alerte faux et quota de pager (fatigue sur appel).
Proportion de réactions automatiques qui ont fermé le problème sans intervention manuelle.
Réduction de MTTR après la mise en œuvre.
Coût/valeur : $/alert et économies sur les pertes évitées.

14) Feuille de route pour la mise en œuvre (8-12 semaines)

Ned. 1-2 : inventaire SLI/KPI, sélection des séries prioritaires (paiements/taux/files d'attente/OBD), seuils de base et STL.
Ned. 3-4 : streaming (Kafka + Flink/Streams), contexte (GEO/PSP/releases), hystérésis et dedup.
Ned. 5-6 : change-point + CUSUM, bandes prédictives pour les séries d'affaires, communication avec la plate-forme d'incident, runbooks.
Ned. 7-8 : auto-réactions (PSP-feilover, dégradation des fiches, autoscaling par lag), dashboards et métriques de qualité.
Ned. 9-10 : modèles multivariants (Isolation Forest/IForest/AE) dans les domaines pilotes, drift-monitoring.
Ned. 11-12 : optimisation des coûts, étalonnage des seuils A/B, réglementation de la revue mensuelle et formation des équipes.

15) Modèles d'artefacts

Anomaly Spec : signal, segmentation (GEO/PSP/banque), méthode, seuils, fenêtres, hystérésis, propriétaire, runbook, auto-réactions.
Rapport Change-Point : temps, composant, niveaux avant/après, corrélations (versions/fichflags/travaux).
Quality Dashboard Definition : métriques de qualité, limites cibles, période de révision.
Politique Auto-Action : conditions et limites des actions Auto-Action, critères de retour, audit.

16) Anti-modèles

Seuils statiques universels sans saisonnalité et segmentation.
Absence d'hystérésis → flapping et « pager fatigue ».
Les alertes hors contexte SLO/argent → beaucoup de bruit, peu d'avantages.
« Black Box » ML sans explication ni journalisation.
Aucun lien avec les versions/ficheflags/travaux planifiés.
Ignorer le coût de l'injection/stockage pour les rangées auxiliaires.

Résultat

La détection des anomalies est un processus et une plate-forme, pas seulement un modèle : les signaux et le contexte corrects → des méthodes durables (STL/CUSUM/CPD/prévisions) → la suppression du bruit et la priorité sur les SLO/revenus → les réactions automatiques et les runbooks compréhensibles → un cycle fermé de qualité et de coût. Cette boucle attrape les problèmes avant les utilisateurs, réduit MTTR et protège les flux d'affaires de la plate-forme iGaming.