Disciplina de experimentar en sistemas de producción para descubrir debilidades antes de que causen incidentes, inyectando fallos controlados.
Chaos Engineering es la disciplina de experimentar en sistemas distribuidos para construir confianza en su capacidad de resistir condiciones turbulentas en producción. A diferencia del testing tradicional que valida comportamientos conocidos, chaos engineering busca descubrir propiedades emergentes del sistema mediante la inyección controlada de fallos.
La práctica se basa en el principio de que los sistemas complejos fallan de maneras impredecibles. En lugar de esperar a que estos fallos ocurran naturalmente, chaos engineering los provoca de manera controlada para identificar debilidades antes de que se conviertan en incidentes críticos. Esta aproximación proactiva permite a los equipos mejorar la resiliencia del sistema basándose en evidencia empírica.
Netflix popularizó esta disciplina con Chaos Monkey en 2010, pero el concepto ha evolucionado hacia una metodología estructurada que abarca desde experimentos simples hasta game days complejos que involucran múltiples equipos y sistemas.
Los cuatro principios de chaos engineering establecen una metodología científica para los experimentos:
| Tipo de fallo | Qué simula | Qué valida | Blast radius |
|---|---|---|---|
| Terminar instancias | Hardware failure, deployment issues | Auto-healing, redundancia | Instancia/AZ |
| Inyectar latencia | Red degradada, sobrecarga | Timeouts, circuit breakers | Conexión específica |
| Fallo de dependencias | Servicio externo caído | Fallbacks, graceful degradation | Servicio downstream |
| Agotar recursos | CPU/memoria/disco al límite | Autoscaling, alerting | Nodo/cluster |
| Corrupción de datos | Inconsistencias, bugs | Validación, reconciliación | Dataset específico |
| Partición de red | Split-brain, CAP theorem | Consensus algorithms, data consistency | Segmento de red |
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: pod-delete-experiment
namespace: production
spec:
# Hipótesis: El sistema mantiene 99.9% uptime con pods eliminados
appinfo:
appns: ecommerce
applabel: "app=checkout-service"
chaosServiceAccount: litmus-admin
experiments:
- name: pod-delete
spec:
components:
env:
# Eliminar 1 pod cada 30 segundos durante 5 minutos
- name: TOTAL_CHAOS_DURATION
value: "300"
- name: CHAOS_INTERVAL
value: "30"
- name: FORCE
value: "false"
probe:
# Validar que el endpoint responde correctamente
- name: checkout-availability
type: httpProbe
httpProbe/inputs:
url: "https://api.example.com/health"
insecureSkipTLS: false
method:
get:
criteria: ==
responseCode: "200"
mode: Continuous
runProperties:
probeTimeout: 5s
interval: 10sHipótesis: Durante condiciones normales, el servicio de checkout mantiene:
- Latencia P95 < 500ms
- Tasa de éxito > 99.5%
- Throughput > 1000 transacciones/minuto
- CPU utilization < 70%
Experimento: Eliminar 2 de 10 pods del servicio durante 10 minutos
Métrica de éxito: Todas las métricas se mantienen dentro de los umbrales
Hipótesis: El API Gateway maneja gracefully la pérdida de backend services:
- Respuestas de fallback en < 200ms
- Circuit breaker activa después de 5 fallos consecutivos
- Logs de error estructurados generados
Experimento: Simular fallo completo de un microservicio durante 5 minutos
Validación: Verificar activación de circuit breaker y respuestas de fallback
El blast radius define el alcance potencial de impacto de un experimento. Estrategias de control:
Los game days son ejercicios coordinados que simulan incidentes mayores:
❌ Malo: "Vamos a ver qué pasa si eliminamos pods"
✅ Bueno: "Hipótesis: El sistema mantiene 99.9% uptime cuando se eliminan
2 de 10 pods del servicio de checkout durante 5 minutos"
❌ Malo: Experimentos en producción sin límites de alcance
✅ Bueno: Experimentos limitados por tiempo, geografía, y porcentaje de tráfico
❌ Malo: Ejecutar experimentos sin métricas de validación
✅ Bueno: Dashboards en tiempo real con métricas de steady-state
En sistemas distribuidos modernos, la complejidad emergente hace que los fallos sean inevitables e impredecibles. Chaos engineering transforma esta realidad de reactiva a proactiva: en lugar de esperar que los sistemas fallen en el peor momento posible, los hacemos fallar cuando estamos preparados para aprender de ello.
Para equipos de staff+ engineering, chaos engineering proporciona evidencia empírica sobre trade-offs de arquitectura. ¿Realmente necesitamos esa redundancia multi-región? ¿Los circuit breakers están configurados correctamente? ¿El auto-scaling responde lo suficientemente rápido? Solo los experimentos controlados pueden responder estas preguntas con datos reales.
La práctica también acelera el desarrollo de expertise en incident management. Los equipos que practican chaos engineering regularmente responden más rápido y efectivamente a incidentes reales, porque ya han experimentado escenarios similares en condiciones controladas. Es la diferencia entre entrenar en simuladores de vuelo versus aprender durante una emergencia real.
Disciplina que aplica principios de ingeniería de software a operaciones de infraestructura, enfocándose en crear sistemas escalables y altamente confiables.
Enfoques y niveles de testing para validar que el software funciona correctamente, desde unit tests hasta tests end-to-end y testing en producción.
Capacidad de entender el estado interno de un sistema a partir de sus outputs externos: logs, métricas y traces, permitiendo diagnosticar problemas sin acceso directo al sistema.
Procesos y prácticas para detectar, responder, resolver y aprender de incidentes de producción de forma estructurada y efectiva.