Pruebas de resiliencia

1) Conceptos y objetivos básicos

Fiabilidad (reliability): probabilidad de mantenimiento; resistencia (resilience) - comportamiento durante y después de la falla.
SLO/presupuesto erróneo: criterios de «admisibilidad» de la degradación.
hypothesis steady-state: espera formal de métricas estables (por ejemplo, p95 <200 ms, error rate <0. 5%). El experimento se considera exitoso si la hipótesis se sostiene.
Tipos de fallas: de red (latencia, pérdidas/tomas, roturas), computacionales (CPU, memoria), storage (I/O, agotamiento del disco), dependencias (5xx, timeouts, rate-limit), lógicas (incidencias parciales, «degradación lenta»), operativas (liberación), config), «dark» (split-brain, turnos de horas).

2) Pirámide de estabilidad

1. Pruebas unitarias de fallas lógicas (retraídas, idempotencia, taimautas).
2. Componentes con adaptadores de inyección de fault (Testcontainers/tc-netem).
3. Integración/sistema con red/DB/caché y perfiles de mundo real.
4. Experimentos de caos en pre-prod (y luego limitado en venta) por runbook 'am.
5. El juego-dei es las enseñanzas de guión del equipo (personas + herramientas).

3) Observabilidad como base

SLI: latencia p50/p95/p99, error rate, saturation (CPU/heap/FD/IOPS), drop/timeout, queue depth.
Tracks: para buscar «cuellos de botella» bajo el fallo.
Métricas de sostenibilidad semántica: fracción de graceful-degrade exitosa, fracción de solicitudes shed, velocidad de auto-recuperación (MTTR).
Etiquetado de experimentos: 'chaos. experiment_id', 'phase = inject/recover' en eventos/logs.

4) Catálogo de inyecciones de fallas (faults)

Red: latencia/jitter, pérdida/duplicados/reordenación, limitación de ancho de banda, «tormentas» por lotes, acantilados TLS.
Host: limitación de CPU, fugas/límites de memoria, pausas de GC, agotamiento de descriptores, «clock skew».
Almacenamiento: aumento de la latencia, EROFS, ENOSPC, degradación de la réplica, pérdida de líder.
Dependencias: 5xx/429, ralentización, flapping DNS, certificados obsoletos, rate-limit, «respuestas parciales».
Datos: corrupción de registros, «agujeros» en los flujos, tomas de eventos, conflictos de versiones.
Operaciones: lanzamiento fallido, bandera de ficha, deriva de config, error manual (dentro de la simulación).

5) Patrones de la estabilidad (qué comprobar)

Retrés con jitter y timeouts en cada RPC.
Circuito Breaker (descubrimiento/semiabierto, recuperación exponencial).
Bulkheads (aislamiento de grupos/colas en dominios críticos).
Carga de carga (restablecemos las solicitudes de baja prioridad cuando se saturan).
Backpressure (señales de cadena ascendente, límites de concurrencia).
Idempotency (claves de idempotencia en «efectos secundarios»).
Cacheo y bandadas en caso de degradación del origen.
Degradación Graceful (respuestas ligeras, datos stale, apagado de fichas).
Timeout-budget (presupuesto total de tiempo por cadena de llamadas).
Atomicidad/compensación (Saga/Outbox/Transactional Inbox).
Quórum y replicación (quórum R/W, degradación de consistencia en aras de la accesibilidad).
Anti-entropy/relay (recuperación en «agujeros» de eventos).

6) Recetas para inyecciones y expectativas (pseudocódigo)

Retray con el jitter y el rompedor

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

Shading y retroceso

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Idempotencia

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) Experimentos: escenarios e hipótesis

7. 1 «Dependencia lenta»

Inyección: + 400 ms p95 a la API externa.
Expectativa: crecimiento de temporizadores ≤ X%, apertura de rompecabezas, respuestas fallback, mantenimiento del servicio p99 <SLA, ausencia de cascada en los retiros.

7. 2 «Pérdida parcial de caché»

Inyección: falla del 50% de los nodos Redis/Caché Shard.
Expectativa: aumentada miss, pero sin avalancha al origen (request coalescing/TTL inmutable), auto-calentamiento y recuperación.

7. 3 «Split-brain en DB»

Inyección: pérdida de líder, cambio a réplica.
Espera: entradas de deny a corto plazo, leer de quórum, sin pérdida de datos, Outbox no pierde el mensaje.

7. 4 «ENOSPC/disco lleno»

Inyección: disco al 95-100%.
Espera: rotaciones de registro de emergencia, fallas en los registros sin bloqueo, conservación de registros críticos (WAL), alertas y autoliquidados.

7. 5 «Tráfico Burst»

Inyección: × 3 RPS a un endpoint caliente de 10 min.
Expectativa: shading de baja prioridad, p95 estable en las rutas «nucleares», aumento de colas dentro de los límites, ausencia de tormentas DLQ.

7. 6 «Clock Skew»

Inyección: desplazamiento del tiempo del nodo por +/−2 min.
Espera: TTL/firmas correctas (leeway), temporizadores monotónicos en retrés, tokens válidos en la deriva permitida.

8) Entorno y seguridad de los experimentos

Comience con pre-prod, datos sintéticos lo más cerca posible de la venta de confecciones/topología.
En la venta - sólo ventanas controladas, banderas de fichas, amplitud paso a paso, auto-retroceso, «botón rojo».
Guardrails: límites de RPS/errores, guardias SLO, bloquear lanzamientos durante incidentes críticos.
Es obligatorio el runbook: cómo retrotraer, a quién llamar, dónde mirar.

9) Automatización y CI/CD

Catálogo de experimentación como código (YAML/DSL): objetivos, inyecciones, métricas, umbrales, «botones» de retroceso.
Smoke-chaos en cada lanzamiento: inyecciones cortas (por ejemplo, 2 min + 200 ms a la adicción) en el stage.
Las carreras nocturnas de la matriz: servicios × tipos de fallos.
Gate to release: proscribir el deploy si la estabilidad está por debajo del umbral (por ejemplo, 'fallback coverage <95%' bajo 'lenta dependencia').

10) Datos y consistencia

Compruebe la compensación (Saga): las operaciones parcialmente realizadas deben ser llevadas a un estado acordado.
Pruebe repeticiones/tomas de eventos, entrega fuera de orden, «agujeros» y réplicas.
Verifique los invariantes de dominio después de los fallos: el balance no es negativo, las transacciones no se «atascan», los límites no se rompen.

11) Anti-patrones

Prueba sólo happy-path y carga sin fallos.
Retraídas sin jitter → una tormenta bajo degradación.
La falta de un presupuesto global de taimaut → los timautas en cascada.
Una agrupación única para todas las tareas → sin aislamiento (bulkheads).
Colas «infinitas» → aumento de la latencia/OOM.
La telemetría cero de los experimentos → prácticas de caos «ciegas».
Caos en la venta sin retroceso/límites/propietario responsable.

12) Check-list del arquitecto

1. ¿Definida la hipótesis steady-state y el SLO?
2. En cada RPC, ¿hay temporizadores, retiros con jitter, rompedores?
3. ¿Se han implementado bulkheads, limitadores, backpressure, load-shedding?
4. Caché resistente: coalescing, protección contra tormentas de caché, calentamiento?
5. Outbox/Saga para efectos secundarios, ¿llaves idempotentes?
6. ¿Se han probado los quórums/replicación/failover?
7. ¿Hay un catálogo de experimentos, caos nocturno y gaitas en CI/CD?
8. Métricas/rastros marcan experimentos, ¿hay dashboards?
9. Runbook 'y y el «botón rojo» están listos, ¿responsabilidad asignada?
10. ¿Un juego regular con Dev/SRE/Support?

13) Mini herramientas y ejemplos de scripts (YAML-sketches)

Red (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/Heap

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

Dependencia

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

la Conclusión

Probar la sostenibilidad no es un «truco con caos», sino una disciplina que hace predecible el sistema bajo fallos. Hipótesis claras, telemetría, un catálogo de experimentos guiados y patrones incrustados en la arquitectura (timeouts, breakers, aislamiento, idempotencia) convierten posibles incidentes en escenarios controlados. El equipo obtiene confianza en las versiones y los usuarios obtienen un servicio estable incluso en condiciones de fracaso.