Ingenieria del caos

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 novedoso 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. Consulta Event-Driven Microservices para arquitecturas resilientes.
• Te preparas para drills de disaster recovery y game days. Consulta Load Testing para verificación de capacidad.
• Validas auto-escalado, failover y mecanismos de auto-curación. Consulta Health Check Endpoint para configuración de probes.
• Construyes confianza antes de eventos de alto tráfico (lanzamientos, Black Friday). Consulta Retry Logic para manejar fallas gracefulmente.

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

Lo que funciona

• 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

Errores Comunes Adicionales

1. Correr experimentos sin baselines. Necesitas métricas de steady-state antes del chaos para comparar:

# Registrar baseline antes del experimento
curl -s https://api.example.com/metrics > baseline-metrics.json
# Correr experimento
# Comparar después
curl -s https://api.example.com/metrics > post-experiment-metrics.json
diff <(jq '.latency_p99' baseline-metrics.json) <(jq '.latency_p99' post-experiment-metrics.json)

1. No limpiar después de experimentos. Los toxics de Toxiproxy, reglas tc, y fallas inyectadas persisten si no se remueven:

# Siempre limpiar
tc qdisc del dev eth0 root 2>/dev/null
toxiproxy-cli toxic delete --all
kubectl delete chaosengine --all -n staging

Tips de Rendimiento

1. Corre experimentos en horas valle. Incluso con blast radius reducido, los experimentos añaden carga:

# Programar a las 2am cuando el tráfico es menor
0 2 * * * /usr/local/bin/chaos-experiment.sh

1. Usa duraciones cortas de experimento. 30-60 segundos son suficientes para observar comportamiento:

# Litmus: 30 segundos máximo
env:
  - name: TOTAL_CHAOS_DURATION
    value: '30'

1. Cachéa resultados de escaneos. Si los experimentos de chaos dependen de resultados de escaneo, cachéalos:

import functools

@functools.lru_cache(maxsize=1)
def get_service_inventory():
    return fetch_service_inventory()  # Llamada costosa

1. Paraleliza checks de steady-state. Verifica múltiples endpoints simultáneamente:

import concurrent.futures

def check_all_endpoints(urls):
    with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
        results = list(executor.map(check_endpoint, urls))
    return all(results)