Observation et contrôle de l'état

1) Objectifs et principes

Objectif : comprendre en temps réel « ce qui se passe » et « pourquoi » pour prévenir les incidents et récupérer rapidement sans perturber le SLO et sans gonfler l'OPEX.
Principes : SLO-first, « signaux dorés » (latency, traffic, errors, saturation), norme unique de télémétrie (OpenTelemetry), détails minimes, explication, observabilité cost-aware.

2) Couches d'observabilité

1. Métriques : agrégats pour SLI/SLO, capacity et tendances (modèles RED/USE).
2. Tracks : chaînes causales de demandes, de paiements et de transactions de jeux.
3. Logs/events : contexte détaillé et audit des actions des opérateurs/services.
4. Synthétique (black-box) : vérifications externes des API/chemins Web, PSP/KYC chels-pings.
5. RUM (utilisateur réel) : métriques de front (TTFB, LCP, erreurs JS), tranches géo/device.
6. Télémétrie de bas niveau : eBPF/profilage CPU/IO/alloc, retard percentyle réseau.

3) Jeu de SLI et « signaux dorés »

Latitude : p50/p95/p99 selon les voies critiques (login, dépôt, pari, retrait).
Errors : part 5xx/timeout/decline (avec normalisation par fournisseurs/banques).
Traffic/Throughput : RPS/TPS, sessions actives, événements/s.
Saturation : chargement CPU/RAM/IO, profondeur des files d'attente, pool-utilisation, replication lag.
SLI d'entreprise : taux de dépôt/% par fenêtre, refus de conversion KYC/PSP, part de charge.

4) L'architecture de télémétrie

Standardisé инжест : OpenTelemetry SDK/collector → la normalisation, семплинг, les privacy-filtres → les dépôts (TSDB, трассировки, логи).
Corrélation : trace-id/span-id dans les logs et métriques (examplars) ; un seul correlation-id pour les paiements/événements de jeu.
Topologie : service-map (service graph), fournisseurs externes dépendants avec SLI en direct.
Gestion des coûts : niveaux de rétraction, agrégation, échantillonnage dynamique, classes de stockage « chaud « / » froid ».

5) Métriques : conception et cardinalité

Règles : petit nombre de labels, interdiction de la haute cardinalité (userId, sessionId) dans la série time ; ces détails ne sont que dans les pistes/logs.
RED/USE: Requests-Errors-Duration для API; Utilisation-Saturation-Errors pour les infrastructures.
Exemplars : ancre des percentiles élevées à des exemples de trace spécifiques.
Mesures commerciales : $/RPS, conversion PSP par banque/GEO, tolérance aux pannes des fournisseurs.

6) Tracing : Profondeur et échantillonnage

Contexte : Nous faisons passer le contexte trace à travers le front → API → les courtiers → les workers → OBD/PSP.
Sempling : Base 1-10 %, en cas d'anomalie - augmentation dynamique selon les règles (tail-based).
Focus : flow de paiement (init → auth → capture/settle), transactions de jeu (bet → settle), KYC (init → verify).
Annotations : PSP-code de réponse, bank-BIN/issuer-catégorie, région, risque-score.

7) Logs et audit

Logs structurés : JSON, niveau par profil (INFO sur la vente, DEBUG dans le débogage).
Filtres de vie privée : masque PII, interdiction des documents KYC crus dans les logs.
Evénements d'audit : qui/quoi/où/quand/pourquoi, ID tiketa, valeurs pre/post pour les opérations à haut risque (bonus, limites, itinérance PSP).
Inamovibilité : WORM/immutable, signature, rétention par stratégie.

8) Contrôle de l'état (santé)

Liveness/Read..../Startup : échantillons corrects (ne pas vérifier les dépendances externes dans liveness).
Degraded-mode : drapeaux explicites de dégradation du service pour que les alertes et la page d'état soient négociées.
Budget santé : burn-rate budget des erreurs (fenêtre rapide/lente), headroom par ressources et files d'attente.

9) Alerte rapide et alerte rapide

SLO-alertes : sur le budget des erreurs (4 heures et 1 heure fenêtres) au lieu de « brut » p95.
Anomalies : STL/IQR/détecteurs en ligne pour les surtensions 5xx, chute des autorisations PSP dans un GEO/banque spécifique.
Root-cause hints : nous associons les alertes aux dernières versions/ficheflags/travaux planifiés.
Runbooks : chaque alert a des liens de pleybuck, des graphiques, des « contrôles rapides ».

10) Dashboards (qui et ce qu'il voit)

Exec : aptyme/SLO, taux de croissance, dépôts/paris réussis, statut des fournisseurs, prévisions de capacité et $/RPS.
SRE/plateforme : RED/USE par service, file d'attente/lag, pool-utilisation, replication lag, CDN/WAF, profiles eBPF.
Payments/Risk : succès des autorisations PSP/banques/GEO, soft/hard declines, heure KYC, chargeback early-signals.
Support/CS : tableau de bord des incidents, réponses SLA, macros FAQ.

11) Gestion du coût de l'observation (FinOps-Observability)

Rétention : 7-14 jours pour les pistes « crues », les agrégats sont plus longs ; sélectivement - services chauds.
Sampling/agrégation : échantillonnage dynamique par anomalies, downsampling des anciennes séries.
Ingest-policy : couper le bruit (ping santé, logs redondants), quotas de métriques de haute cardinalité.
Valeur KPI : $/GB ingest, $/trace, $/SLI dashboard ; Je revois périodiquement les meilleurs mangeurs.

12) Vie privée et conformité

PII/finance : masquage, tokenisation, minimisation des données en télémétrie.
Géolocalisation : stockage et traitement par juridiction ; log-export - uniquement via le flux de travail approuvé avec cryptage et TTL.
Vérification de l'accès à la télémétrie : RBAC/ABAC, SoD pour les téléchargements, journal des demandes.

13) Intégration avec la gestion des incidents et des communiqués

Page de statut : Fid automatique des updates de l'incident de carte.
Release-gate : analyse canarique par SLI, auto-stop release à burn-rate> seuil.
Post-mortem : temporisation des pistes/logs, SLI réels et fenêtres de violation.

14) Méthode de mise en œuvre pratique (8-12 semaines)

Ned. 1-2 : inventaire des voies critiques et des ISS ; Sélection de la pile (OTel, TSDB, logs, pistes) ; carte des dépendances.
Ned. 3-4 : introduction d'OTel dans 3-5 services clés (login/dépôt/pari), RED/USE de base, trace-contexte dans les logs.
Ned. 5-6 : SLO et burn-rate-alerts ; synthétique selon PSP/KYC ; les premiers runbooks ; RUM sur le web/mobile.
Ned. 7-8 : échantillonnage dynamique, essais, service-map ; Dashboards Exec/SRE/Payments.
Ned. 9-10 : eBPF/profilage des goulets d'étranglement chauds ; filtres de confidentialité ; quotas/retraits.
Ned. 11-12 : release-gates et auto-rollback sur SLI ; intégration avec la page de statut ; l'exercice tabletop.

15) Modèles d'artefacts

Carte SLO du service : SLI, cibles, fenêtres, budget des erreurs, alertes, propriétaires.
Alert Spec : métrique/condition, seuils, dedup/silens, destinataires, runbook.
Dashboard Spec : audience, questions, 6-8 widgets, source de données, taux de mise à jour.
Politique de télémétrie : Quels champs sont autorisés/interdits, rétentions, masquage, exportation.
Cost Review Pack : Top series/trajets, offre de sampling/TTL, économies attendues.

16) Fonction d'observation KPI

MTTA/MTR (amélioration après l'introduction de l'alerting SLO).
% des incidents détectés par Synthetic/SLI avant les plaintes des utilisateurs.
Proportion de sorties qui ont passé le gate sur SLI sans intervention manuelle.
Réduction de $/RPS par télémétrie tout en maintenant le diagnostic.
Couverture par voie critique (> 90 %).
Précision de la corrélation « état apdate ↔ SLI réel ».

17) Anti-modèles

« Tout le monde » → l'explosion du coût et du bruit.
Alerties par métriques « brutes » au lieu de SLO/burn-rate → pager-fatigue.
Haute cardinalité des métriques (userId) → tempêtes TSDB.
Trajets sans contexte d'affaires (PSP/banque/GEO) → pas d'initiation.
Il n'y a pas de lien d'observation avec les rejets/incidents → la télémétrie vit séparément.

Résultat

L'observation et le contrôle de l'état ne sont pas un ensemble d'outils, mais un système géré : SLI/SLO correct → télémétrie standardisée et corrélation → SLO-alerting et runbooks → intégration avec les versions et le status-communication → cost-aware et la vie privée. Une telle boucle donne les premiers signaux, RCA rapide et la résilience de l'entreprise, même dans les pics extrêmes de trafic.