¿Qué es la Ingeniería del Caos?
La ingeniería del caos es la disciplina de experimentar en un sistema distribuido para construir confianza en su capacidad de resistir condiciones turbulentas en producción. Fue pionera de Netflix, que creó Chaos Monkey para terminar instancias de producción aleatoriamente.
La idea central: en lugar de esperar a que los fallos ocurran inesperadamente, inyectar fallos proactivamente y observar cómo responde el sistema.
Principios
- Construye una hipótesis sobre el estado estable. Define qué es “normal”: error rate, latencia, throughput.
- Varía eventos del mundo real. Inyecta fallos que realmente ocurren: crashes, particiones de red, disco lleno.
- Ejecuta experimentos en producción. Comienza en staging, avanza a producción.
- Automatiza para ejecución continua.
- Minimiza el radio de impacto. Comienza pequeño.
Ciclo de Vida del Experimento
Paso 1: Definir Estado Estable
Error rate < 0.1%, P95 < 200ms, health checks pasando, tasa de completación de ordenes > 99%.
Paso 2: Hipótesis
“Si terminamos una instancia del servicio de pagos, el sistema continúa procesando pagos sin aumento en error rate.”
Paso 3: Diseñar el Experimento
- Objetivo: Servicio de pagos, una instancia
- Tipo de fallo: Terminación de proceso
- Duración: 5 minutos
- Criterios de aborto: Error rate > 1% o P95 > 1 segundo
Paso 4: Ejecutar
Con monitoreo activo y kill switch listo.
Paso 5: Analizar
Comparar métricas durante y después del experimento con el estado estable.
Paso 6: Corregir y Repetir
Tipos de Experimentos
| Experimento | Qué Testea | Ejemplo |
|---|---|---|
| Terminación de instancia | Auto-scaling, balanceo | Matar un pod/VM aleatorio |
| Latencia de red | Manejo de timeouts, reintentos | Agregar 500ms de latencia |
| Partición de red | Consistencia, split-brain | Bloquear tráfico entre servicios |
| Disco lleno | Logging, manejo de datos | Llenar disco al 100% |
| Estrés CPU/Memoria | Throttling, límites | Consumir 90% CPU |
| Fallo de dependencia | Circuit breakers, fallbacks | API tercera no disponible |
Herramientas
| Herramienta | Tipo | Mejor Para |
|---|---|---|
| Chaos Monkey | Open source (Netflix) | Terminación aleatoria de instancias |
| Litmus | Open source (CNCF) | Experimentos nativos de Kubernetes |
| Gremlin | SaaS | Chaos-as-a-service enterprise |
| Toxiproxy | Open source (Shopify) | Simulación de condiciones de red |
Ejercicio: Diseña un Experimento de Caos
Tu aplicación e-commerce tiene: API gateway, servicio de productos, carrito, pagos, notificaciones, PostgreSQL, Redis. Diseña tres experimentos de riesgo creciente.
Solución
Experimento 1: Fallo de Caché Redis (Bajo Riesgo)
Hipótesis: Si Redis no está disponible, la aplicación continúa sirviendo con fallback a BD. Inyección: Detener contenedor Redis por 5 minutos. Esperado: Tiempo de respuesta sube a 500-800ms, sin errores.
Experimento 2: Fallo de Instancia de Pagos (Riesgo Medio)
Hipótesis: Si una de tres instancias muere, el balanceador enruta a instancias saludables. Inyección: Matar un pod del servicio de pagos. Esperado: Kubernetes reinicia en 30s. Sin pagos fallidos.
Experimento 3: Partición de Red (Riesgo Mayor)
Hipótesis: Si el servicio de productos no alcanza inventario, sirve datos cacheados. Inyección: Bloquear red entre product-service e inventory-service por 3 minutos.
Conclusiones Clave
- La ingeniería del caos es testing proactivo de resiliencia
- Siempre define estado estable primero
- Comienza pequeño y escala
- Automatiza y repite
- QA aporta valor único — habilidades de diseño de tests y conocimiento de monitoreo