Alertes en temps réel

1) Objectif et principes

Objectif : avertir à temps, précisément et de manière ciblée les bonnes personnes/systèmes des événements menaçant le SLO, les revenus et la conformité, et lancer des actions correctes (manuelles/automatiques).
Principes : SLO-first, minimisation du bruit, explication, contexte, priorité par impact commercial, « un signal est une action compréhensible ».

2) Taxonomie des signaux

Signaux SLO : burn-rate budget d'erreur sur les chemins critiques (login, dépôt, pari, retrait).
KRI : premiers indicateurs de risque (chute auth-success chez PSP par banque/GEO, croissance consumer-lag, p99↑).
Evénement : flaps de dépendance, failover, commutation manuelle, déclenchement des protections (rate-limit, WAF).
Sécurité/conformité : sursaut d'opérations sensibles, exportation de PII, violations de la SoD.

3) Niveaux et alertes SLA

4) Sources et corrélation du contexte

Télémétrie : métriques/trajets/logs, synthétiques et RUM.
Catalogues : CMDB/service-map, propriétaires, dépendances.
Changements : versions, fichflags, migrations, travaux planifiés.
Fournisseurs externes : PSP/KYC/studios de jeux/CDN/WAF statuts.
Chaque alert s'enrichit : qu'est-ce qui a changé à ses côtés ? (sortie/fichflag), quelles dépendances sont rouges ?, quel segment est affecté ? (GEO/PSP/banque/tenante).

5) Règles de SLO-alerting (noyau)

Burn-rate : deux fenêtres (1h rapide et lente 6-24h). Pager - seulement en cas de dépassement simultané.
Guardrails : les seuils p99/error-rate ne servent qu'à déclencher l'analyse contextuelle, ne remplacent pas les SLO.
Impact : évaluation « part d'audience × argent/min × réglementation » → niveau de P1-P4.

6) Suppression du bruit

Déduplication : regroupement par service/tenant/cause ; Nous briserons un incident au lieu de dizaines de signaux.
Hystérésis : N-des-M confirmations, durée minimale de l'anomalie.
Silens/mutes : travaux planifiés, incidents connus, fenêtres « follow-the-sun ».
Limites de rate et quotas : par source/label/tenant ; protection contre la « tempête ».
Diminution de la cardinalité : interdit par userId/sessionId dans les labels alert.

7) Routage et escalade

Itinérance par contexte : domaine (Payments/Games/Core), environnement (prod/stage), région, gravité.
Escalade : t0 - on-call L1 ; t0 + X - L2/propriétaire de domaine ; t0 + Y - IC/guide. Le temps X/Y dépend du P1-P3.
Duplication sur les canaux : pager + chat en P1 ; chat/ticket en P3.
Changement de poste : auto-transfert de contexte (timeline, actions effectuées, hypothèses).

8) Auto-action (auto-remediation)

Paiements : changement de PSP par santé × fee × conversion, limitation des banques/méthodes, retraits avec gitter.
Jeux/paris : activer le cache-wedge/limiter les opérations write, queue-page/waiting-room à l'avant.
Infra : évacuation du trafic, restauration des workers dégradés, mise à l'échelle par lag.
Sécurité/conformité : fermer temporairement les exportations de PII, introduire le contrôle double pour les opérations P1.
Toute action auto - avec politique de retour et critères de retour.

9) Runbook-première expérience

Chaque alert est associé à un runbook : objectif, diagnostic rapide (3-5 contrôles), étapes de fixation/retour, personnes de contact, liens vers les dashbords et la page de statut. Dans le chat/pager, nous montrons une brève carte d'action.

10) Il-call politique

Rotation 24 × 7, couverture de domaine (Payments/Game Core/SRE).
"Second on-call'pour P1, règle des deux personnes dans la salle du var.
Quiet-hours et fenêtres de garde par zone (follow-the-sun).
Formation : exercice trimestriel (tabletop/game-day), shadow-stop.
Crédits post-incident (bou-time) pour éviter le burn-out.

11) Intégration

Gestion de l'incident : auto-création de cartes, bandes d'update, rôle IC/CL, minuteries.
Status Page : Publier un P1/P2 (via Comms Lead) avec des modèles et des localisations.
Sorties : release-gates sur SLI, auto-stop/rollback sur alerts.
Catalogues : propriétaires, CMDB, contacts des fournisseurs.

12) Exemples d'alertes (iGaming)

1. Auth-success chez PSP-1 en TR↓ de 25 % en 10 min

P2→P1 avec une couverture> 30 % des transactions.
Auto-action : redistribuer le trafic PSP-2/3 ; inclure une 3DS simplifiée ; alert Partner Manager.

2. p99 « stavka→settl »> 3 normes × dans l'UE

Causes : lag de réplication, file d'attente de workers.
Auto-action : scale-out workers, warmup cache, éteindre temporairement les fiches non critiques.

3. Export PII spikes

P1 en l'absence de tiquet/approbation.
Auto-action : unité de déchargement, notification de conformité, vérification SoD.

13) Métriques de qualité d'alerte (KPI/KRI)

MTTA-Comms/MTTA-Ops : temps avant réaction/première action.
Precision/Recall (alert ↔ incident), Faux taux d'alerte.
Lead-time avant la violation de SLO, TTD (temps de détection).
Pager fatigue : alert/personne/ned, appels de nuit, pourcentage de « nuls ».
Taux auto-fix : proportion de problèmes fermés par une réaction automatique sans personne.
Aging : proportion de P3/P4 pendantes> X jours.

14) Gestion des coûts

Quotas d'alertes/sources, coupure des étiquettes excédentaires.
Downsampling et agrégation de métriques, sempling de pistes ; retraite par classe.
Cost-review régulier : $/alert, $/SLI-dashboard, séries « lourdes ».

15) Vie privée et conformité

Sans PII dans le texte des alerts et des labels ; Tokénisation des identifiants.
Politiques d'accès (RBAC/ABAC), SoD sur la configuration des alertes.
Audit des modifications des règles, versioning, tests et diff.

16) Feuille de route pour la mise en œuvre (6-10 semaines)

Ned. 1-2 : catalogue SLI/KRI, carte des propriétaires, niveaux de P1-P4, premières règles SLO (burn-rate).
Ned. 3-4 : dedup/hystérésis/sylens, intégration avec le système d'incident et les chats, runbook-ligaments.
Ned. 5-6 : auto-action pour Payments/Queues, release-gates, status page fid.
Ned. 7-8 : contexte (communiqués/fichflags/fournisseurs), cartes thermiques PSP × banque × GEO, exercice P1/P2.
Ned. 9-10 : FinOps alerting, KPI-dashboards, révision des seuils et quotas, formation on-colla.

17) Artefacts et modèles

Alert Spec : métrique/condition, fenêtres, suppression, propriétaire, runbook, auto-action.
Routing Map : domen→kanal→eskalatsii, contacts de secours.
Politique de silence : règles de mute (incidents planifiés/connus) qui peuvent inclure.
On-call Handbook : rotations, changements de poste, chèques-feuilles de P1/P2, canaux.
Pack post-incident : déchargement d'alertes/lignes temporelles, analyse de la qualité des signaux.

18) Anti-modèles

Pager par « cru » p95/p99 sans SLO → bruit et fatigue.
Des dizaines de signaux sur la même chose (pas de déduplication/corrélation).
L'absence de runbook ou de propriétaire d'alert.
Seuil « en pierre » sans saisonnalité/segmentation (GEO/PSP/banque/heure).
Pas de retour après auto-action (pas de critères roll-back).
Les labels PII et userID → les risques et l'explosion de la cardinalité.

Total

L'alerting vraiment utile est un convoyeur SLO-centré : règles contextuelles avec burn-rate, suppression intelligente du bruit, itinérance et escalade claires, runbook-first experience et auto-action sécurisée. Ce circuit attrape les événements critiques avant les utilisateurs, réduit MTTR, protège les revenus et en même temps protège son appel de la routine « pager-enfer ».