Chaos Engineering

1) Principios básicos

Steady State como hipótesis original. Defina claramente la norma (por ejemplo: p95 <200 ms, error rate <0. 3%, éxito del flow crítico> 99. 5%).
Variables aisladas. Cambiar si es posible un factor a la vez para vincular causalmente el efecto y la mejora.
Grados. Comenzamos con pequeñas amplitudes en un entorno seguro → ampliamos la cobertura y la intensidad.
Guardrails. Condiciones de parada explícitas para SLO/alertas/presupuesto de errores.
Repetibilidad. El experimento debe reproducirse deterministamente (scripts/manifiestos/IaC).
Ética y seguridad. No hay datos personales reales y transacciones financieras en experimentos de riesgo.

2) Qué es el «estado sostenible»

• Latencias p50/p95/p99 de endpoints clave.
• Proporción de transacciones exitosas y conversión de rutas críticas.
• Error rate, temporizadores, porcentaje de consultas «shed» (recortadas cuando se saturan).
• Velocidad de recuperación automática (MTTR), resistencia a los retoques (sin tormentas).
• Invariantes de dominio: ausencia de «contras en el balance», pagos ejecutados una vez, consistencia del día de presentación de informes, etc.

3) Catálogo de inyecciones (que «rompemos»)

Red: latencia, jitter, pérdida/duplicados, limitación de ancho de banda, roturas TLS, flapping DNS.
Cálculos: sobrecarga de CPU, presión de memoria/GC, agotamiento de descriptores, clock skew.
Almacenamiento: alto p95 I/O, ENOSPC, falla líder/réplica, split-brain, fsync prolongado.
Dependencias: 5xx/429, «éxito lento», degradación de las API externas, rate-limit.
Datos: tomas/omisiones de mensajes, fuera de orden, registros «sucios», conflicto de versiones.
Operaciones: lanzamiento/confit fallido, bandera de ficha con bug, certificado caducado, rotación de clave.
Personas y procesos: inaccesibilidad de los responsables, retraso del aprove manual, runbook incorrecto.

4) Diseño del experimento (patrón)

1. Hipótesis: «Con + 300 ms al servicio de divisas p99 de la API principal <450 ms, se abre un rompedor, se da una respuesta stale ≤ hace 15 minutos».
2. Inyección: perfil de falla (tipo/amplitud/duración) y contorno de destino.
3. Métricas/etiquetas de registro: etiquetado 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: abort con 'error _ rate> 2%' o p99> SLA × 2 más de 1 minuto.
5. Resultados/conclusión: lista de observaciones, errores, mejoras, plan de trabajo y re-ejecución.

5) Observabilidad: lo que es obligatorio

Senderismo: ruta de consulta a través de dependencias; segmentos degradados marcados.
Métricas de recursos: CPU, heap/GC, FD, disco IOPS/lat, banda de red, profundidad de colas.
Métricas de negocio: conversión/éxito de las operaciones, proporción de transacciones compensadas.
Registros de eventos: apertura/cierre de rompedores, retiros y su presupuesto, cambio de líder de la DB.
El panel del experimento: un dashboard en vivo con umbrales guardrails y un «botón rojo» del aborto.

6) Guardrails y seguridad

Técnico: límites superiores de la tasa de error/latencia, caída de la proporción de operaciones exitosas, crecimiento de DLQ.
Organizacional: ventana de tiempo involucrada on-call, principio de «una zona - un experimento».
Datos/cumplimiento: sólo los conjuntos sintéticos o impersonales; prohibición de las pruebas que conduzcan a la violación de la capacidad regulatoria.
Retroceso: procedimiento listo para girar/desactivar la bandera/el tráfico de arrastre suave.

7) Patrones de sostenibilidad que deben manifestarse

Presupuestos de Taimout y retiros de jitter (sin tormentas).
Circuito Breaker con semiabsorción (medio abierto) y recuperación exponencial.
Bulkheads: aislamiento de grupos por criticidad (pagos vs análisis).
Backpressure y rate-limit: corte predecible de baja prioridad.
Caché con calzado, protección contra «tormentas de calentamiento».
Idempotencia de efectos secundarios y sagas con acciones compensatorias.
Quórum, Feilover y anti-entropía para la recuperación de datos.

8) Ejemplos de escenarios (sketches)

8. 1 Dependencia lenta (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 Pérdida del líder de la DB

Inyección: detención del líder/reelección forzada.
Espera: prohibición temporal de registros, lectura de quórum, preservación de WAL/Outbox, auto-recuperación de replicación, sin escritura doble.

8. 3 ENOSPC en disco de registro

Inyección: llenar el disco hasta 95-100%.
Anticipación: rotación de registros de emergencia, conservación de registros críticos, apagado de fichas no críticas, alerta y auto-remediación.

8. 4 tráfico Burst + shading

Inyección: × 3 RPS durante 5 minutos por endpoint caliente.
Expectativa: descartar baja prioridad, p95 «kernel» estable, sin cascada de retraídas.

9) Automatización en CI/CD

Chaos-smoke en stage para cada lanzamiento (inyecciones cortas en amplitudes seguras).
Carreras nocturnas por catálogo de experimentos (matriz de servicios × tipos de fallos).
Gates: la liberación se bloquea si «la estabilidad está por debajo del umbral» (por ejemplo, la proporción de fallback exitosos es <95%).
Artefactos: informe, tracks, flamgrafos CPU/heap, snapshots de métricas y confites.

10) Días de juego (Días de juego)

• Roles: líder del experimento, observador de métricas, operador de retroceso, representante de negocios.
• Escenarios: degradación de caché, falla parcial de AZ/región Feilover, «mala liberación», inaccesibilidad del proveedor externo.
• Resultados: lagunas encontradas en el runbook, mejoras en las alertas, ajuste de SLO y presupuestos de retrés.

11) Caos para datos, eventos y ML

Flujos de datos: pruebas de duplicados, omisiones, fuera de orden, retrasos; validación de consumers idempotentes y estrategias DLQ.
Repositorios: degradación de índices, hot-partition, conflicto de bloqueos, replicación bajo la laguna.
ML: retardo del fih stor, retroceso al modelo baseline, deterioro de la calidad de la entrada (drift) - el sistema debe «tupir suavemente» en lugar de caer.

12) Anti-patrones

Caos sin observabilidad: eres «ciego», las conclusiones son especulativas.
Las inyecciones están inmediatamente en venta sin stage y reiles de guardia.
«Un gran experimento» a la vez - no está claro qué funcionó exactamente.
Acciones de caos desordenadas sin hipótesis y retesta después de las ficciones.
Enfocarse solo en la infraestructura - invariantes empresariales olvidados.
Ignorar personas/procesos: alertas, on-call, runbook es parte del sistema.

13) Madurez de la práctica (modelo)

1. Ad-hoc: inyecciones únicas localmente.
2. Stage-caos: catálogo de guiones, corridos repetidos, dashboards.
3. Lanzamiento-caos: caos de humo en cada lanzamiento, gates, reportes.
4. Caos prod con restricciones: poco tráfico, estrictos guardrails, retroceso listo.
5. Estabilidad continua: auto-experimentación, control SLO, mejoras como flujo de trabajo.

14) Integración con prácticas arquitectónicas

Pruebas de resistencia: los experimentos de caos complementan las inyecciones de fault y los escenarios de degradación.
Pruebas de carga: los experimentos combinados «carga + falla» revelan cascadas y una tormenta de retraídas.
Policy as Code/RBAC/ABAC: guardrails, pasos de retroceso y límites para formalizar como políticas.
Gestión de consentimiento/privacidad: no permita experimentos que violen el modo de procesamiento de datos.
Geo-architecture: cheques de failover de regiones y enlaces de datos a jurisdicciones.

15) Mini recetas (pseudocódigo)

Rompedor + degradación

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Limiter + shading

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Efecto secundario idempotente

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Check-list del arquitecto

1. ¿Definidos por Steady State y Guardrails?
2. ¿Hay un directorio de scripts (red/CPU/almacenamiento/dependencias/datos/operaciones)?
3. ¿La observancia cubre recursos, colas de latencia, invariantes de negocios?
4. ¿Los temporizadores/retraídos/rompedores/limitadores/bulkheads están habilitados y son parametrizables?
5. ¿Preparado el runbook y el «botón rojo»?
6. ¿Hay un caos-smoke en el stage y experimentos nocturnos?
7. ¿Las ventanas y roles «seguros» para los días de juego están descritos?
8. Los experimentos son reproducibles (IaC/scripts), ¿se versionan los resultados?
9. Las mejoras se registran por tareas, ¿se hace un retesto?
10. ¿Están cubiertos los transportadores de datos y ML, no sólo HTTP?

Conclusión

Chaos Engineering convierte «incidencias imprevistas» en escenarios previsibles. La hipótesis de resistencia, las inyecciones controladas, los guardrails rígidos, la rica observabilidad y la disciplina de los retestos son herramientas que reducen el riesgo de liberaciones y aumentan la confianza en la plataforma. Como resultado, el equipo entiende los límites del sistema, sabe cómo degradarse elegantemente y devolver rápidamente el servicio al usuario incluso en condiciones de fallos.