PSP-X latency & loss

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Chaos Engineering è un metodo scientifico per la produzione: si formula un'ipotesi di stabilità, si rompe l'ambiente in modo controllato e si dimostra che il valore utente (SLO/metriche aziendali) è conservato. Per i controlli sui pagamenti (PSP), l'inizializzazione di giochi, le code di conclusioni, i multi-regionari e i picchi di carico - in caso di ritardi, guasti e «tempesta» dei retrai - prima che ciò accada agli utenti vivi.

1) Principi del caos-ingegneria

1. Da steady-state a ipotesi. Definire la norma: Availability, p95/p99, TTW, conversione dei pagamenti.
2. Piccolo blast radius. Esperimento prima in staging/canaro, 1-5% del traffico/1-2 per regione.
3. L'osservazione è prima di tutto. Metriche/fogli/trailer + annotazioni esperimenti.
4. Guardrails и abort. Soglie rigide SLO/Business KPI per arresto automatico.
5. Ripetibilità e automazione. Esperimenti come codice (IaC/GitOps), piano game-day.
6. Blameless culture. L'esperimento non è trovare i colpevoli, ma trovare i punti deboli.

2) Steady-state e metriche di successo

TexSLI: p95/p99 API, error-rate, saturation (CPU/IO), queue lag (withdrawals/deposits), latency provider.
Business SLI: conversione "attempt→success", TTW p95, successo dì game init ", percentuale di guasti PSP codici.

3) Classi di esperimento (che «rompiamo»)

Rete: latency/jitter/packet loss/blackhole, guasti DNS, anomalie MTU.
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Processi e siti: kill/evict sotto, node failure, zone/region failover.
Dipendenze: timeout PSP/errori, inattività del provider di giochi, degrado CDN/cache.
Code/streaming: crescita di Kafka lag, interruzione dei concertisti, interruzione delle partenze/leader.
Dati/Database: ritardi nella replica, degrado degli indici, modalità read-only.
Release/phicheflagi: errori di migrazione, configi errati, kill-switch.
Fronte/RUM: caduta LCP/INP, cricca cliente a picco.
Data/ML: invecchiamento dei ficchi, aumento del latency model, calo del tokens/s, degrado della qualità.

4) Processo: da ipotesi a miglioramenti

1. Formulare un'ipotesi (specifico SLO/Business KPI + comportamento di blocco previsto).
2. Progettare l'esperimento: tipo di guasto, durata, blast radius, guardrails/abort.
3. Preparare l'osservazione dei dashboard «release/experience compare», annotazioni.
4. Avvia il controllo IM/TL, avvisa on-call/business (se influisce).
5. Misurare il risultato: SLO, p95/p99, TTW, conversione, laghe, retrai.
6. Formare action items: limiti, timeout, retrai con jitter, outler-ejection, PDB/HPA/KEDA, flow di riparazione.
7. Automatizza (includere il gioco-day/CI Check-pack dell'infrastruttura).

5) Guardrail e criteri di arresto

• SLO fast-burn è attivato (ad esempio 14 x budget per 1 ora),
• la conversione dei pagamenti è di oltre 0. 3 p.p.,
• TTW p95> 3 min consecutive 10-15 min,
• error-rate > 1. Il 5% e cresce in due finestre.
• Comunicazioni: canale/modello di stato precompilato, pulsante rosso nel ChatOps ('/experience abort ').

6) Esempi di esperimenti (Kubernets/cloud)

6. 1 Ritardi di rete per PSP (deposito canario)

Scopo: controllare i retrai/timeout/routing.
Iniezione: + 200 ms RTT e 3% packet loss solo per "payments-api" ".

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

Previsto: p95 '/deposit' <250 ms, error-rate <1%, conversione ≥ baseline -0. 3 P; in caso di deterioramento, il passaggio automatico della rotta PSP.

6. 2 Guasto del sito e PDB

Obiettivo: controllare PDB/anti-affinity/HPA.
Iniezione: drain/terminate con un singolo seme «games-api».

In attesa: nessuna perdita di disponibilità, il p99 a picco non esce da SLO, l'autoscaler ottiene repliche, il PDB impedisce il doppio impatto.

6. 3 Kafka lag и KEDA

Obiettivo: resilienza dei prelievi per l'acquisizione dei messaggi.
Iniezione: congelare i consumatori di 5-10 min, quindi attivarlo.

In attesa: KEDA scala i worker, TTW p95 rimane a 3 minuti dopo la dissezione, nessun duplicato (idampotenza, chiavi).

6. 4 DNS guasto provider di giochi

Obiettivo: fallback/cache/retrai.
Iniezione: NXDOMAIN/timeout per il dominio "providerA. example`.

In attesa: folback veloce su « », in UI - modalità degradante e striscione di stato; 'game init success' 99. 5%.

6. 5 Read-only BD

L'obiettivo è il comportamento quando si perde la registrazione.

Iniezione: read-only di 10-15 minuti

In attesa: il codice gestisce correttamente gli errori, le rotte critiche sono limitate, le code trattengono le richieste, non ci sono perdite o doppi prelievi.

7) Automazione e GitOps

Esperimenti come codice: memorizza script/parametri/guardrails in Git, invidia attraverso PR.
Programma game-day: pianificazione, proprietari, metriche, condizioni abort, assegno-foglio di comunicazione.
Annotazioni in Grafana: inizio/fine esperimento, config, risultato SLO.

8) Osservazione durante il caos

Explars: da p95/p99 a specifici «trace _ id».
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Le chiamate esterne sono contrassegnate'fault '. innected = true ', vedete i retrai/timeout.
Dashboard: «SLO-Card», release/experience compare, Payments/Game init/Queues.

9) Specifica di cosa controllare in primo luogo

1. Pagamenti e TTW: timeout PSP, percorso folback, idampotenza.
2. Inizializzazione dei giochi: indisponibilità/lentezza degli studi, guasti CDN.
3. Code di output/bonus: crescita di lag, rielaborazione.
4. Multiregion: guasto zona/RR, cambio leader, replica database.
5. Picchi: auto-scale, rate-limit, circuito-breaker, riscaldamento della cache.
6. RG/Compliance: correttezza della logica in caso di guasti, assenza di PII nella telemetria.

10) Gestione del rischio (governance)

Calendario e finestre: esperimenti fuori dai tornei di punta, allineamento con il business.
Роли: Experiment Lead, Observer (SRE), Business Rep; IM sulla linea telefonica.
Criteri dei dati: niente PII nei manufatti; Storage WORM per il controllo.
Limiti legali: escludere gli scenari che violano la SLA senza concordare.

11) Game-day - Modello di script

12) Scoperte e azioni tipiche

Ritrai troppo aggressivi, una tempesta di richieste, per aggiungere timeout/jitter/limiti.
No outlier ejection  L'istanza «velenosa» rovina il p99 per attivare la selezione.
Le fragili migrazioni di  read-only rompono il flusso di  + phicheflagi.
Il segnale HPA non valido scrisse troppo tardi per passare alle metriche RPS/lag.
La cache condivisa per le versioni dei ripristini  rovina i dati delle chiavi di versione.

13) Assegno-foglia di maturità pratica di caos

1. Steady-state e SLO sono descritti, i dashboard sono pronti.
2. Esperimenti come codice, ringiovanimento/controllo al Git.
3. Guardrails/abort automatizzati (Alertmanager/ChatOps).
4. Osservabilità: exemplars, trace/log correlation, annotazioni.
5. Game-day trimestrale, script copre pagamenti/giochi/code/multiregione.
6. I post-sperimentali action items fanno parte del piano sprint; Controllo dell'esecuzione.
7. Le soglie retraes/timeout/circuito-breaker in config-repo.
8. Security/policy PII rispettate, manufatti senza dati sensibili.
9. Le remediazioni auto SLO (rollback/scale/reroute) sono state testate dal caos.
10. Metriche di processo:% superati senza abort, MTTR in esercizio, riduzione degli incidenti di classe.

14) Anti-pattern

«Rompiamo tutto» senza SLO/guardrail/osservabilità.
Esperimenti senza ipotesi o obiettivi misurabili.
Grande blast radius al primo lancio.
I retrae senza timeout/jitter sono disponibili a cascata.
Caos invece di prevenzione: curiamo i sintomi, ignoriamo le cause radici.
Assenza di RCA/action items dopo l'esercizio.
Esperimenti durante gli orologi di punta senza allineamento con gli affari.

Riepilogo

Il caos-ingegneria è la prova metodica della stabilità: riproduce in anticipo i problemi reali, misura l'impatto su SLO e metriche aziendali e rafforza l'architettura, dai retrai e dal circuito-breaker all'orchestrazione multiregionale e alla remediazione auto. Con il game-day regolare e la disciplina di guardrails, la piattaforma di iGaming conserva p95/p99, conversione e TTW anche nei periodi più caldi.