PSP-X latency & loss

(Section : Technologie et infrastructure)

Résumé succinct

Chaos Engineering est une méthode scientifique pour la production : vous formulez une hypothèse de stabilité, brisez l'environnement d'une manière contrôlée et prouvez que la valeur utilisateur (SLO/métriques d'entreprise) est préservée. Pour iGaming, il s'agit de la vérification des paiements (PSP), de l'initialisation des jeux, des files d'attente des sorties, de la multiregion et des charges de pointe - dans des conditions de retard, de défaillance et de « tempête » des rétroactifs - avant que cela n'arrive aux utilisateurs vivants.

1) Les principes du chaos-ingénierie

1. De l'état steady à l'hypothèse. Définir la norme : Disponibilité, p95/p99, TTW, conversion de paiement.
2. Petit blast radius. L'expérience d'abord dans staging/canar, 1-5 % du trafic/1-2 sous-a/une région.
3. L'observation avant tout. Métriques/logs/tracés + annotations expérimentales.
4. Guardrails и abort. Seuils SLO/KPI d'entreprise rigides pour l'arrêt automatique.
5. Répétabilité et automatisation. Expériences en tant que code (IaC/GitOps), plan game-day.
6. Blameless culture. L'expérience n'est pas la recherche des coupables, mais la recherche des faiblesses.

2) Steady-state et métriques de succès

TexSLI : API p95/p99, taux d'erreur, saturation (CPU/IO), queue lag (withdrawals/dépôts), fournisseurs de latitude.
SLI d'entreprise : conversion 'attempt→success', TTW p95, succès 'game init', taux d'échec PSP par code.

3) Classes d'expérimentation (que « casser »)

Réseau : latency/jitter/packet loss/blackhole, pannes DNS, anomalies MTU.
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Processus et sites : kill/evict pods, node failure, zone/région failover.
Dépendances : temporisation PSP/erreurs, indisponibilité du fournisseur de jeux, dégradation du CDN/cache.
Files d'attente/streaming : croissance Kafka lag, pause consumers, rupture partis/leader.
Données/bases de données : retards de réplication, dégradation des index, mode read-only.
Releases/ficheflags : erreurs de migration, configis erronés, kill-switch.
Front/RUM : Chute LCP/INP, crash client en pointe.
Data/ML : vieillissement des dattes, augmentation du modèle de latitude, chute des tokens/s, dégradation de la qualité.

4) Processus : De l'hypothèse aux améliorations

1. Formuler une hypothèse (SLO/KPI d'entreprise spécifiques + comportement attendu des protections).
2. Concevoir l'expérience : type de panne, durée, radius blast, guardrails/abort.
3. Préparer l'observabilité : dashboards « release/experiment compare », annotations.
4. Démarrer sous le contrôle de la GI/TL, aviser l'entreprise/l'appel (le cas échéant).
5. Mesurer le résultat : SLO, p95/p99, TTW, conversion, lagas, retraits.
6. Formez des items d'action : limites, timeouts, retraits avec jitter, outlier-ejection, PDB/HPA/KEDA, flow de retour.
7. Automatiser (inclure les vérifications d'infrastructure par jour/CI dans le paquet reg).

5) Guardrails et critères d'arrêt

• SLO fast-burn activé (par exemple 14 × budget en 1 h),
• la conversion des paiements ↓ de plus de 0. 3 p.,
• TTW p95> 3 min consécutifs 10-15 min,
• error-rate > 1. 5 % et grandit à deux fenêtres.
• Communications : Canal/modèle de statut approuvé à l'avance, « bouton rouge » dans ChatOps ('/expérience abort ').

6) Exemples d'expériences (Kubernetes/nuage)

6. 1 Retards de réseau à PSP (dépliant canarien)

Objectif : vérifier les retraits/délais/routage.
Injection : + 200 ms RTT et 3 % packet loss uniquement pour 'payments-api' → 'pspX'.

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

Attendu : p95 '/deposit '<250 ms, error-rate <1 %, conversion ≥ baseline − 0. 3 p.; en cas de détérioration - auto-commutation de la route PSP.

6. 2 Panne du nœud et PDB

Objectif : vérifier l'APB/anti-affinité/HPA.
Injection : drain/terminate d'un noeud avec les pods 'games-api'.

Attente : pas de perte de disponibilité, p99 de pointe ne dépasse pas SLO, autoscaler obtient des répliques, PDB empêche le « double coup ».

6. 3 Kafka lag и KEDA

Objectif : pérennité des retraits lors de l'accumulation des messages.
Injection : congeler les consumers pendant 5-10 min, puis allumer.

L'attente : KEDA met à l'échelle воркеры, TTW p95 il reste ≤ 3 mines après la résorption, il n'y a pas de doubles (идемпотентность, les clés).

6. 4 faille DNS du fournisseur de jeux

Objectif : fallback/cache/retrai.
Injection : NXDOMAIN/timeout pour le domaine 'providerA. example`.

Attente : folback rapide sur 'providerB', en UI - mode dégradé et bannière de statut ; 'game init success' ≥ 99. 5%.

6. 5 Read-only OBD

Objectif : comportement en cas de perte d'enregistrement.
Injection : commutation de la réplique en lecture seule de 10 à 15 min.

Attente : le code traite correctement les erreurs, les itinéraires critiques sont limités, les files d'attente retiennent les demandes, il n'y a pas de pertes/doubles débits.

7) Automatisation et GitOps

Expérimentation en tant que code : stocker les scripts/paramètres/guardrails dans Git, ronfler via PR.
Plan game-day : horaires, propriétaires, métriques, conditions d'abort, chèque de communication.
Annotations dans Grafana : début/fin de l'expérience, config, SLO final.

8) Observabilité pendant le chaos

Exemples : de p95/p99 à des 'trace _ id'spécifiques.
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Tracs : les appels externes sont marqués 'fault. injected = true ', vous pouvez voir les Retrai/Timouts.
Dashboards : « SLO map », release/experiment compare, Payments/Game init/Queues.

9) Spécificité de l'iGaming : ce qu'il faut vérifier en premier lieu

1. Paiements et TTW : délais PSP, itinéraire folback, idempotence.
2. Initialisation des jeux : indisponibilité/lenteur des studios, pannes CDN.
3. Files de retraits/bonus : croissance lag, traitement répété.
4. Multiregion : refus de zone/RR, changement de leader, réplication OBD.
5. Pics : auto-skale, rate-limit, circuit-breaker, chauffage des caches.
6. RG/Conformité : exactitude du logage en cas de défaillance, absence de PII dans la télémétrie.

10) Gestion des risques (gouvernance)

Calendrier et fenêtres : expériences en dehors des tournois de pointe, alignement avec les entreprises.
Роли: Experiment Lead, Observer (SRE), Business Rep; IM sur la ligne téléphonique.
Politiques en matière de données : pas de PII dans les artefacts ; Stockage WORM pour l'audit.
Limites légales : exclure les scénarios violant les SLA sans accord.

11) Game-day : modèle de scénario

12) Découvertes et actions typiques

Les retraits trop agressifs → la tempête de requêtes → ajouter des délais/jitter/limites.
Il n'y a pas d'éjection outlier → l'instance « toxique » gâche p99 → allumer l'éjection.
Les migrations fragiles → read-only brisent le flux → expand→migrate→contract + ficheflagi.
Le signal HPA incorrect → scale tard → passer aux métriques RPS/lag.
Le cache commun aux versions → les restaurations gâchent les données → les clés de version.

13) Chèque de maturité de la pratique du chaos

1. Steady-state et SLO sont décrits, les dashboards sont prêts.
2. Expérimentation comme code, revoyez/vérifiez chez Git.
3. Les Guardrails/Abort sont automatisés (Alertmanager/ChatOps).
4. Observabilité : implars, trace/log correlation, annotations.
5. Jeu-jour trimestriel, les scénarios couvrent les paiements/jeux/files d'attente/multi-régions.
6. L'action post-expérimentale fait partie du plan de sprint ; contrôle de l'exécution.
7. Les politiques liminaires ретраев/таймаутов/circuit-breaker à konfig-repo.
8. Les politiques de titrisation/PII sont respectées, les artefacts sans données sensibles.
9. Les auto-remediations par SLO (rollback/scale/reroute) ont été testées par le chaos.
10. Métriques de processus :% passé sans abort, MTTR sur les exercices, réduction des incidents de classe.

14) Anti-modèles

« Cassons tout dans la vente » sans SLO/guardrails/observabilité.
Expériences sans hypothèses et objectifs mesurables.
Grand rayon blast au premier lancement.
Les retraits sans temporisation/jitter → la tolérance aux pannes en cascade.
Chaos au lieu de prévention : nous traitons les symptômes en ignorant les causes racines.
Absence de RCA/items d'action après l'exercice.
Expériences en heures de pointe sans accord avec les entreprises.

Résultats

L'ingénierie du chaos est une preuve méthodique de la durabilité : vous reproduisez à l'avance les défaillances réelles, mesurez l'impact sur les SLO et les métriques d'entreprise et renforcez l'architecture - des retraits et circuits-breaker à l'orchestration multirégionale et aux remèdes automatiques. Avec un jour de jeu régulier et une discipline de guardrails, la plate-forme iGaming conserve p95/p99, conversion et TTW même pendant les périodes les plus chaudes.