PSP-X latency & loss

(Sección: Tecnologías e Infraestructura)

Resumen breve

Chaos Engineering es un método científico para la producción: se formula una hipótesis de estabilidad, se rompe el entorno de forma controlada y se prueba que se conserva el valor del usuario (SLO/Business Métricas). Para iGaming, se trata de comprobaciones de pagos (PSP), inicialización de juegos, colas de salida, multirregiones y cargas máximas -ante retrasos, fallos y una «tormenta» de retrayos- antes de que suceda a los usuarios vivos.

1) Principios de la ingeniería del caos

1. De steady-state a la hipótesis. Determine la norma: Disponibilidad, p95/p99, TTW, conversión de pagos.
2. Pequeño radius blast. Experimento primero en staging/canario, 1-5% de tráfico/1-2 poda/una región.
3. La observancia es primero. Métricas/logs/tracks + anotaciones del experimento.
4. Guardrails и abort. Umbrales rígidos SLO/KPI de negocios para parada automática.
5. Repetibilidad y automatización. Experimentos como código (IaC/GitOps), plan game-day.
6. Cultura Blameless. El experimento no es la búsqueda de culpables, sino la búsqueda de puntos débiles.

2) Steady-state y métricas de éxito

NatSLI: p95/p99 API, error-rate, saturation (CPU/IO), queue lag (withdrawals/deposits), latency proveedores.
SLI empresarial: conversión de 'attempt→success', TTW p95, éxito de 'game init', porcentaje de fallos de PSP por código.

3) Clases de experimentación (que «rompemos»)

Red: latency/jitter/packet loss/blackhole, fallas DNS, anomalías MTU.
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Procesos y sitios: kill/evist pods, node failure, zone/region failover.
Dependencias: temporizadores/errores PSP, inaccesibilidad del proveedor de juegos, degradación de CDN/caché.
Colas/streaming: crecimiento de Kafka lag, pausa de consumers, ruptura de partidos/líder.
Datos/DB: retardos de replicación, degradación de índices, modo read-only.
Lanzamientos/fichflags: errores de migración, configuraciones erróneas, kill-switch.
Frente/RUM: caída LCP/INP, troquelado del cliente en el pico.
Data/ML: envejecimiento de las fichas, aumento del modelo latency, caída de tokens/s, degradación de la calidad.

4) Proceso: desde hipótesis hasta mejoras

1. Formular una hipótesis (SLO/KPI de negocios específicos + comportamiento de protección esperado).
2. Diseñar un experimento: tipo de fallo, duración, blast radius, guardrails/abort.
3. Preparar la observancia: dashboards «release/experiment compare», anotaciones.
4. Ejecutar bajo el control de IM/TL, notificar a on-call/business (si afecta).
5. Medir el resultado: SLO, p95/p99, TTW, conversión, lags, retraídas.
6. Formar acciones items: límites, temporizadores, retraídas con jitter, outlier-ejection, PDB/HPA/KEDA, flow de retroceso.
7. Automatizar (incluir en el paquete reg game-day/CI las comprobaciones de infraestructura).

5) Guardaires y criterios de parada

• SLO fast-burn activado (por ejemplo, 14 × presupuesto por 1 hora),
• la conversión de pagos ↓ en más de 0. 3 p. m.,
• TTW p95> 3 minutos consecutivos 10-15 minutos,
• error-rate > 1. 5% y crece en dos ventanas.
• Comunicaciones: canal/plantilla de estado previamente aprobado, «botón rojo» en ChatOps ('/experiment abort ').

6) Ejemplos de experimentos (Kubernetes/nube)

6. 1 Retardos de red a PSP (deploy canario)

Objetivo: comprobar retraídas/temporizadores/enrutamiento.
Inyección: + 200 ms RTT y 3% packet loss solo para '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

Esperado: p95 '/depósito '<250 ms, error-rate <1%, conversión ≥ baseline − 0. 3 artículos; cuando se deteriora - conmutación automática de la ruta PSP.

6. 2 Error de nodo y PDB

Objetivo: verificar PDB/anti-affinity/HPA.
Inyección: drain/terminate un nodo con podas 'games-api'.

Expectativa: no hay pérdida de disponibilidad, el pico p99 no va más allá del SLO, el autoscaler llega a las réplicas, el PDB evita el «doble golpe».

6. 3 Kafka lag и KEDA

Objetivo: Sostenibilidad de las retiradas en la acumulación de mensajes.
Inyección: congelar los consumidores durante 5-10 min, luego encenderlos.

Anticipación: KEDA escala los workers, TTW p95 permanece ≤ 3 min después de ser resucitado, sin duplicados (idempotencia, llaves).

6. 4 fallo de DNS del proveedor de juegos

Objetivo: fallback/caché/retrés.
Inyección: NXDOMAIN/timeout para el dominio 'providerA. example`.

Expectativa: folback rápido en 'providerB', en IU - modo de degradación y banner de estado; 'game init success' ≥ 99. 5%.

6. 5 Read-only DB

Objetivo: comportamiento cuando se pierde un registro.
Inyección: Cambiar la réplica a read-only a 10-15 min.

Espera: el código maneja correctamente los errores, las rutas críticas son limitadas, las colas retienen las solicitudes, no hay pérdidas/cargos dobles.

7) Automatización y GitOps

Experimentos como código: almacena scripts/parámetros/guardrails en Git, rugiendo a través de PR.
Plan de día del juego: horarios, propietarios, métricas, condiciones abortivas, lista de verificación de comunicaciones.
Anotaciones en Grafana: inicio/fin del experimento, confit, SLO final.

8) Observabilidad durante el caos

Exemplars: de p95/p99 a 'trace _ id' específico.
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Tracks: las llamadas externas están marcadas con 'fault. inyected = true ', se ven retraídas/timeouts.
Dashboards: "SLO-card', release/experiment compare, Payments/Game init/Queues.

9) Especificidad de iGaming: qué comprobar en primer lugar

1. Pagos y TTW: Timeout PSP, ruta folback, idempotencia.
2. Inicialización de juegos: inaccesibilidad/lentitud de los estudios, fallas CDN.
3. Colas de retiros/bonificaciones: crecimiento de la carga, volver a procesar.
4. Multirregión: fallo de zona/RR, cambio de líder, replicación de DB.
5. Picky: auto-skale, rate-limit, circuit-breaker, calentar caché.
6. RG/Compliance: corrección de lógica en fallas, ausencia de PII en telemetría.

10) Gestión de riesgos (gobierno)

Calendario y ventanas: experimentos fuera de los torneos pico, alineación con el negocio.
Роли: Experiment Lead, Observer (SRE), Business Rep; IM en la línea directa.
Políticas de datos: ningún PII en artefactos; Almacenamiento WORM para auditoría.
Límites legales: excluir los escenarios que violan el SLA sin acuerdo.

11) Game-day: plantilla de script

12) Hallazgos y acciones típicas

Los retoques demasiado agresivos → la tormenta de solicitudes → agregar temporizadores/jitter/límites.
No outlier ejection → «venenoso» instans estropea p99 → habilitar la selección.
Migraciones frágiles → sólo read-only rompe el flujo de → expand→migrate→contract + fichflags.
La señal HPA incorrecta → se patinará tarde → cambiará a métricas RPS/lag.
La caché compartida para las versiones → revisiones estropea los datos → las claves de versión.

13) Lista de verificación de la madurez de la práctica del caos

1. Steady-state y SLO se describen, los dashboards están listos.
2. Experimentos como código, rugido/auditoría en Git.
3. Guardrails/abort automatizados (Alertmanager/ChatOps).
4. Observabilidad: exemplars, trace/log correlation, anotaciones.
5. El día del juego es trimestral, los escenarios cubren pagos/juegos/colas/multirregiones.
6. Los items de acción post-experimentales están incluidos en el plan de sprint; control de ejecución.
7. Políticas de umbral Retray/Timeout/Circuit-breaker en el reposo de configuración.
8. Se cumplen las políticas de titulización/PII, artefactos sin datos sensibles.
9. Las remediaciones automáticas por SLO (rollback/scale/reroute) están probadas por el caos.
10. Métricas de proceso:% pasado sin abort, MTTR en ejercicios, reducción de incidentes de clase.

14) Anti-patrones

«Rompemos todo en venta» sin SLO/guardrails/observabilidad.
Experimentos sin hipótesis y objetivos medibles.
Gran radius blast en el primer lanzamiento.
Retiros sin temporizadores/jitter → tolerancias en cascada.
Caos en lugar de prevención: tratamos los síntomas, ignoramos las causas raíz.
Ausencia de RCA/items de acción después del ejercicio.
Experimentos en horas punta sin acuerdo con el negocio.



La ingeniería del caos es una prueba metódica de resiliencia: reproduce fallas reales de antemano, mide el impacto en SLO y métricas de negocio y fortalece la arquitectura, desde retraídas y circuitos-breaker hasta orquestación multirregional y auto-remediaciones. Con un día regular de juego y disciplina guardrails, la plataforma iGaming conserva p95/p99, conversiones y TTW incluso en los períodos más calurosos.