Chaos Engineering

Visión General

El chaos engineering es la disciplina de experimentar en sistemas distribuidos para construir confianza en su resiliencia. Al inyectar fallas intencionalmente — matar instancias, inyectar latencia, corromper paquetes — los equipos descubren debilidades antes que los clientes. Netflix fue pionero con Chaos Monkey; hoy, herramientas como Litmus, Gremlin y AWS Fault Injection Simulator lo hacen accesible para cualquier equipo.

Cuándo Usar

Usa este recurso cuando:

• Operas sistemas distribuidos donde las fallas son inevitables
• Te preparas para drills de disaster recovery y game days
• Validas auto-escalado, failover y mecanismos de auto-curación
• Construyes confianza antes de eventos de alto tráfico (lanzamientos, Black Friday)

Solución

Chaos de Pods en Kubernetes (Litmus)

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-delete-experiment
spec:
  appinfo:
    appns: 'production'
    applabel: 'app=payment-service'
    appkind: 'deployment'
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'
            - name: CHAOS_INTERVAL
              value: '10'
            - name: FORCE
              value: 'false'

Inyección de Latencia de Red (tc + Bash)

#!/bin/bash
# Agregar 500ms de latencia al tráfico de salida en eth0

echo "Inyectando 500ms de latencia por 60 segundos..."
tc qdisc add dev eth0 root netem delay 500ms 50ms distribution normal

sleep 60

echo "Removiendo latencia..."
tc qdisc del dev eth0 root

# Verificar con ping
ping -c 5 api.example.com

AWS Fault Injection Simulator (Python)

import boto3

fis = boto3.client('fis')

response = fis.start_experiment(
    experimentTemplateId='EXT-12345678',
    tags={'Environment': 'staging'}
)

print(f"Experimento iniciado: {response['experiment']['id']}")

Explicación

Cinco tipos de experimentos de chaos:

1. Infraestructura: Matar VMs, terminar contenedores, desacoplar volúmenes
2. Red: Inyectar latencia, dropear paquetes, particionar zonas
3. Aplicación: Lanzar excepciones, retornar 503s, activar memory leaks
4. Estado: Llenar discos, corromper bases de datos, expirar certificados
5. Dependencia: Hacer que APIs downstream hagan timeout o retornen errores

El principio del blast radius:

• Empieza en staging, luego mueve a producción con tráfico mínimo
• Siempre ten un botón de abortar (rollback automático ante violación de SLO)
• Ejecuta durante horas de oficina cuando el equipo esté disponible
• Mide contra SLOs, no solo “¿se cae?”

Variantes

Herramienta	Plataforma	Tipos de Experimento
Chaos Monkey	AWS/Netflix	Terminación de instancias
Litmus	Kubernetes	Pod, red, disco, stress
Gremlin	Multi-cloud	CPU, memoria, red, estado
AWS FIS	AWS	Fallas EC2, ECS, EKS, RDS
Toxiproxy	Cualquiera	Latencia de red, timeouts

Mejores Prácticas

• Define steady state primero: Conoce tu tasa de error normal, latencia y throughput
• Hipótesis-driven: “Si matamos la base de datos primaria, el failover completa en <30s”
• Automatiza rollback: Detén experimentos automáticamente si la tasa de error excede el 1%
• Corre game days: Eventos de chaos programados trimestralmente con todo el equipo
• Documenta hallazgos: Cada experimento produce una actualización de runbook o un fix arquitectónico

Errores Comunes

1. Chaos sin monitoreo: No puedes observar efectos si los dashboards están incompletos
2. Producción primero: Nunca corras chaos en producción antes de probarlo seguro en staging
3. Sin plan de rollback: Experimentos que no se pueden detener rápidamente se convierten en outages
4. Probar solo fallas: También prueba recuperación (¿el auto-healing realmente sana?)
5. Ignorar blast radius: Un experimento no debería afectar a todos los clientes

Preguntas Frecuentes

P: ¿El chaos engineering es solo romper cosas al azar? R: No. Es experimentación hipótesis-driven con resultados medidos y guardias de seguridad automáticas.

P: ¿Cómo convenzo a la gerencia de permitir chaos en producción? R: Empieza en staging, muestra hallazgos, cuantifica outages prevenidos. Enmarca como un seguro proactivo.

P: ¿Cuál es la diferencia entre chaos engineering y load testing? R: El load testing verifica comportamiento bajo alto tráfico. El chaos engineering verifica comportamiento bajo fallas.