Chaos Engineering

Overview

Chaos engineering es la disciplina de experimentar en un sistema para construir confianza en su capacidad de soportar condiciones turbulentas. En lugar de esperar a que los fallos ocurran en produccion, los inyectas intencionalmente — kills de pods, latencia de red, agotamiento de CPU, llenado de disco — para validar que tu sistema se degrada gracefulmente y se recupera automaticamente. Originado en Netflix con Chaos Monkey, ha evolucionado hacia una practica estructurada con principios, herramientas y salvaguardas de seguridad.

When to Use

• For alternatives, see Disaster Recovery: RTO, RPO, and Resilient Recovery Runbooks.

• Tu sistema afirma ser “altamente disponible” pero nunca ha sido probado bajo fallo

• Quieres validar autoscaling, failover y circuit breakers

• Necesitas descubrir dependencias desconocidas y puntos unicos de fallo

• Los runbooks de respuesta a incidentes existen pero no han sido probados

• Estas corriendo Kubernetes y quieres validar resiliencia de pods

Los Cinco Principios del Chaos Engineering

1. Construye una hipotesis alrededor del comportamiento de estado estable — define metricas normales (tasa de error < 0.1%, latencia p99 < 200ms)
2. Varia eventos del mundo real — inyecta fallos que realmente ocurren: particiones de red, fallos de disco, caidas de dependencias
3. Ejecuta experimentos en produccion — staging raramente coincide con la topologia y carga de produccion
4. Automatiza experimentos para que corran continuamente — los game days manuales son valiosos pero no sostenibles
5. Minimiza el radio de impacto — comienza pequeno (un pod, una AZ), aborta si los SLOs se rompen

Diseno de Experimentos

┌─────────────────┐
│ 1. Estado estable │ ← Define normal via metricas
│ 2. Hipotesis     │ ← "Si X falla, Y autoscala en < 60s"
│ 3. Inyecta fallo │ ← Mata pod, agrega latencia, llena disco
│ 4. Observa       │ ← Compara actual vs hipotesis
│ 5. Revierte      │ ← Aborta si el radio de impacto excede limites
│ 6. Aprende       │ ← Arregla debilidades, automatiza fix
└─────────────────┘

Ejemplo Chaos Mesh (Kubernetes)

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-api
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: api
  duration: 30s
  scheduler:
    cron: "@every 10m"

Ejemplo LitmusChaos

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: api-pod-delete
  namespace: litmus
spec:
  appinfo:
    appns: production
    applabel: "app=api"
    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"

Tipos de Experimentos Comunes

Experimento	Valida	Herramienta
Matar pod	Reprogramacion de Kubernetes, readiness probes	Chaos Mesh, Litmus
Latencia de red	Manejo de timeouts, circuit breakers	Chaos Mesh, Gremlin
Stress CPU/memoria	Triggers de autoscaling, limites de recursos	Stress-ng, Gremlin
Llenar disco	Rotacion de logs, alertas de storage	Litmus, Gremlin
Caida de zona	Failover multi-AZ	AWS FIS, Gremlin

Salvaguardas de Seguridad

• Condiciones de aborto — auto-detener experimento si tasa de error > 1% o p99 > 500ms
• Tiempo limitado — limitar duracion del experimento (30s, 5m, no indefinido)
• Alcance pequeno — un pod → un deployment → un namespace → una AZ
• Horario laboral — ejecutar experimentos cuando ingenieros estan disponibles
• Comunicacion clara — anunciar experimentos para evitar duplicacion de incidentes

Common Mistakes

• Sin definicion de estado estable — no puedes detectar degradacion si no sabes como es lo normal
• Radio de impacto demasiado grande — comenzar con una caida de region completa puede impactar clientes reales
• Sin mecanismo de aborto — los experimentos deben auto-terminar si los SLOs se rompen
• Culpar a individuos por fallos encontrados — chaos engineering encuentra debilidades del sistema, no errores humanos
• Ejecutar experimentos sin runbooks — si el experimento encuentra un bug, necesitas un plan de remediacion

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Temas Avanzados

Escenario: Game Days para Plataforma E-commerce

Sistema: E-commerce, 15 microservicios, K8s
Objetivo: Validar resiliencia antes de Black Friday

Calendario de Game Days (mensual):
  | Mes | Experimento | Hipotesis | Resultado |
  |-----|-------------|-----------|-----------|
  | Ene | Matar pod de pagos | Auto-scaling reemplaza en < 30s | Pasa |
  | Feb | Latencia 500ms en DB | Circuit breaker activa fallback | Falla: no habia fallback |
  | Mar | Matar AZ completa | Trafico redirige a AZ sana | Pasa |
  | Abr | Latencia en Redis | Cache miss degrada graceful | Falla: timeouts en cascada |
  | May | Matar servicio de search | Catalogo sin search funciona | Pasa |
  | Jun | Corrupt message en Kafka | Consumer maneja poison pill | Falla: consumer se cuelga |

Experimento detallado (Feb):
  Nombre: DB-latency-injection
  Hipotesis: Si la DB tiene 500ms de latencia, el circuit breaker
             activa el fallback de cache en < 5s sin errores 5xx
  Blast radius: 10% del trafico (canary)
  Duracion: 10 minutos
  Aborto: tasa de error > 5% o latencia p99 > 3s

  Ejecucion (Gremlin):
    gremlin attack latency -t 500ms -i 600 --service payment-db
    --tags env=canary

  Monitoreo durante experimento:
    - Tasa de error: 0% -> 12% (FALLO)
    - Latencia p99: 200ms -> 4.5s (FALLO)
    - Circuit breaker: nunca se activo (FALLO)
    - Cache fallback: no implementado (FALLO)

  Analisis post-mortem:
    Causa raiz: Circuit breaker configurado con threshold de 10s
                pero la DB respondia en 500ms (no timeout).
                El fallback de cache no existia.

    Acciones:
    1. Implementar cache fallback para queries de producto
    2. Bajar threshold del circuit breaker a 2s
    3. Agregar timeout de 1s en queries de DB
    4. Re-ejecutar experimento en staging

  Re-ejecucion (Mar):
    - Tasa de error: 0% (PASA)
    - Latencia p99: 200ms -> 350ms (PASA)
    - Circuit breaker: activo a los 3s (PASA)
    - Cache fallback: sirvio datos stale (PASA)

Automatizacion (Chaos Mesh):
  apiVersion: chaos-mesh.org/v1alpha1
  kind: PodChaos
  metadata:
    name: payment-pod-kill
  spec:
    action: pod-kill
    mode: fixed-percent
    value: "10"
    selector:
      namespaces: [production]
      labelSelectors:
        app: payment-service
    scheduler:
      cron: "@every 1h"

Como convence a management de chaos engineering?

Empieza con un game day en staging. Documenta los hallazgos: cada falla descubierta es un incidente de produccion evitado. Cuantifica el impacto: “Este experimento encontro un bug que habria causado 2h de downtime en Black Friday ($500K)”. Los game days en staging tienen riesgo cero y alto ROI.

End of document. Review and update quarterly.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de chaos-engineering y resilience para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica chaos engineering cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.