Chaos Engineering: Principios y Experimentos Seguros

Visión General

Chaos engineering es la práctica de romper tu propio sistema a propósito — antes de que producción lo rompa por ti. Inyectas fallos reales (pods muertos, latencia, pérdida de paquetes, presión de disco) en condiciones controladas, observas si el sistema degrada con gracia y arreglas lo que no lo hace. Netflix lo empezó con Chaos Monkey, que termina instancias de producción al azar cada día laboral desde 2011, precisamente para que una instancia muerta deje de ser un incidente y pase a ser un martes cualquiera.

Esta guía cubre la disciplina de punta a punta: los cinco principios, cómo diseñar un experimento seguro, el panorama de herramientas, y cómo crecer de un primer game day en staging hasta chaos continuo en producción. Si lo que quieres son los scripts listos para copiar, la receta de Chaos Engineering empaqueta las configs de inyección de fallos, un verificador de steady state y un runbook de game day — los dos recursos son complementarios.

Cuándo Usarlo

Recurre al chaos engineering cuando:

• Tu sistema dice ser “altamente disponible” pero esa afirmación nunca se ha probado bajo un fallo real
• Construiste auto-scaling, failover o circuit breakers y quieres verlos funcionar, no solo asumir que lo hacen
• Necesitas sacar a la luz dependencias ocultas y puntos únicos de fallo antes de que los encuentre un cliente
• Existen runbooks de respuesta a incidentes pero nadie ha ejecutado uno de extremo a extremo
• Se acerca un evento de alto riesgo — Black Friday, un lanzamiento, una migración — y “debería ir bien” no es un plan

Evítalo cuando el sistema aún cambia de forma cada día (el chaos necesita una línea base con la que comparar), cuando la observabilidad es demasiado débil para ver un radio de impacto, o cuando un simple load test o test de integración respondería la pregunta más rápido. Para trabajo de recuperación planificada en lugar de inyección de fallos, ver Disaster Recovery: RTO, RPO y Runbooks de Recuperación.

Los Cinco Principios del Chaos Engineering

Los principios del chaos codificados por Netflix definen la disciplina. Cada uno cambia cómo trabajas, no solo qué ejecutas:

1. Construye una hipótesis sobre el comportamiento en steady state. “Normal” tiene que ser un número antes de poder romperse: error rate por debajo del 0,1%, latencia p99 por debajo de 200ms, el 95% de los pedidos completándose de extremo a extremo. Sin un steady state medible, un experimento produce drama, no datos.

2. Varía eventos del mundo real. Inyecta fallos que de verdad ocurren en tu stack — pérdida de nodos, particiones de red, expiración de certificados, un mensaje envenenado en la cola — no fallos de laboratorio que nadie sufrirá jamás. Cuanto más cerca esté el fallo de un incidente real, más útil es la respuesta.

3. Corre experimentos en producción. Staging nunca reproduce la mezcla de tráfico, el volumen de datos ni la topología de dependencias de producción. El objetivo no es saltarse staging — es no quedarse ahí. Empieza controlado y pequeño; la verdad vive en producción.

4. Automatiza los experimentos para que corran en continuo. Un game day trimestral es teatro valioso, pero los sistemas derivan entre game days. El chaos programado y automatizado (un PodChaos con cron, una corrida semanal de FIS) atrapa regresiones mientras aún son baratas.

5. Minimiza el radio de impacto. El objetivo es confianza sin bajas. Un pod antes que un deployment, un canary antes que una AZ, el 10% del tráfico antes que el 100% — y una condición de aborto que salta automáticamente cuando se rompen los SLOs.

El Ciclo de Vida del Experimento

Todo experimento de chaos — desde un tc en solitario hasta un game day de toda la empresa — sigue el mismo bucle de seis pasos:

Los pasos 5 y 6 son donde los equipos suelen recortar. Un experimento que no encuentra nada es un pase — documéntalo y sigue adelante. Un experimento que encuentra una debilidad es la razón misma de hacer esto: arréglala y repite exactamente el mismo experimento hasta que pase. El bucle solo da fruto si lo cierras.

Fíjate en lo que no está en el bucle: “celebrar que el sistema sobrevivió”. Sobrevivir era la hipótesis, no el objetivo. El objetivo es el conjunto de cosas que casi fallaron — el timeout que era demasiado lento, el failover que funcionó pero tardó 90 segundos, la alerta que disparó tarde. Esos casi-fallos son donde ocurre el verdadero endurecimiento.

Diseñar un Experimento Seguro

Un experimento bien formado se lee como un pequeño protocolo científico. Los campos que importan:

• Steady state: las métricas que definen “sano” — error rate, latencia p99, throughput, profundidad de cola — capturadas en un dashboard antes de tocar nada.
• Hipótesis: falsable, específica y sobre el comportamiento del sistema. “Si la base de datos primaria recibe 500ms de latencia, el circuit breaker abre en menos de 5 segundos y ningún 5xx llega al cliente” es testeable; “a ver qué se rompe” no lo es.
• Radio de impacto: el ámbito más pequeño que aún responda la pregunta. Un solo pod, una sola instancia canary, el 5-10% del tráfico. Auméntalo solo después de que las corridas pequeñas pasen.
• Duración: corta. Treinta segundos a diez minutos dicen lo que necesitas; un fallo de una hora es una caída autoinfligida.
• Criterios de aborto: automáticos, no consultivos. Error rate sobre el umbral durante N minutos, p99 por encima de X, cualquier corrupción de datos — conéctalos a tu monitorización para que el experimento se suicide solo.

Elegir un Fallo: Tipos de Experimento Comunes

Experimento	Valida	Herramientas típicas
Pod/instance kill	Rescheduling de Kubernetes, readiness probes, réplicas	Chaos Mesh, Litmus, Chaos Monkey
Latencia de red	Manejo de timeouts, presupuestos de reintento, circuit breakers	Chaos Mesh, Gremlin, Toxiproxy
Pérdida de paquetes / blackhole	Aislamiento de dependencias, rutas de failover	Gremlin, Toxiproxy
Estrés de CPU/memoria	Disparadores de autoscaling, límites de recursos, vecinos ruidosos	Stress-ng, Gremlin
Disco lleno	Rotación de logs, alertas de almacenamiento, escritura	Litmus, Gremlin
Caída de AZ/región	Failover multi-zona, reencaminado DNS	AWS FIS, Gremlin
Deriva de certificado/reloj	Rotación TLS, expiración de tokens	Scripts propios, FIS

Empieza por el fallo que tu guardia de on-call realmente teme. Si tus tres últimos incidentes fueron de latencia, una inyección de 500ms vale más que diez llenados de disco hipotéticos.

Prerrequisitos: Observabilidad Antes del Chaos

El chaos sin observabilidad es vandalismo. Antes del primer experimento necesitas tres cosas instrumentadas:

• SLIs y SLOs — los mismos indicadores con los que abortarás: error rate, latencia p99, throughput, saturación. Si no están definidos y en un dashboard, no tienes steady state ni criterio de aborto. La Guía de Observabilidad cubre cómo construir esa línea base.
• Una línea base registrada — al menos una semana de tráfico normal para que “sano” sea una distribución real, no una suposición. Los servicios estacionales necesitan la línea base del mismo periodo que pruebas.
• Correlación — IDs de petición y logs estructurados que te permitan trazar una petición que falla a lo largo de la cadena durante un experimento. Sin ello, “el sistema degradó” es todo lo que sabrás sobre el por qué.

Si falta alguno, ese es tu primer “experimento”: instruméntalo, déjalo correr una semana, y solo entonces empieza a inyectar fallos.

Leer los Resultados

El resultado de un experimento no es pasa/falla — es un conjunto de observaciones sobre cómo el sistema se comporta de verdad frente a cómo decías que lo hacía. Las preguntas a hacerse tras cada corrida:

• ¿El radio de impacto se comportó? Si el fallo se escapó de su ámbito (el kill de “un pod” tumbó una cadena de dependencias), ese es el hallazgo #1 y no era de resiliencia — era de arquitectura.
• ¿Los sistemas de seguridad reaccionaron? Circuit breakers, autoscaling, failover — ¿saltaron a tiempo, al umbral correcto, o siquiera saltaron? Un circuit breaker que abre a los 10s cuando tu tolerancia son 2s es un bug latente, no una defensa.
• ¿Cuánto tardó la recuperación? El tiempo de vuelta al steady state importa tanto como sobrevivir. Un experimento que “pasa” pero tarda 20 minutos en recuperarse te está hablando de un cuello de botella.
• ¿Qué aprendiste que no probaste? Los efectos secundarios inesperados — una tormenta de logs, una cola que se atasca, una caché que se enfría — suelen ser el resultado más valioso. Escríbelos aunque la hipótesis se mantenga.

Cada hallazgo se convierte en un ticket con dueño y fecha, y cada arreglo se re-prueba con el mismo experimento. Esa es la diferencia entre el chaos como práctica y el chaos como hobby.

El Panorama de Herramientas

• Chaos Monkey (Netflix): el original — termina instancias al azar en producción. Simple, brutal, solo instancias. Genial para endurecer una flota, inútil para fallos de red.
• Litmus / Chaos Mesh: CRDs nativas de Kubernetes. Chaos Mesh es más amplio (pod, red, I/O, tiempo, fallos de kernel); Litmus trae plantillas de experimento y un chaos hub. Si corres K8s, empieza aquí.
• Gremlin: comercial, multi-cloud, el catálogo de fallos más amplio (CPU, memoria, red, estado). UX pulida y controles de seguridad — la opción “enterprise”.
• AWS Fault Injection Simulator (FIS): servicio gestionado de AWS para fallos de EC2, ECS, EKS y RDS. Su integración profunda con IAM lo hace la elección natural en stacks muy AWS.
• Toxiproxy (Shopify): un proxy TCP que se interpone entre tu app y una dependencia, inyectando latencia, timeouts y caídas de conexión. La forma más ligera de probar dependencias con chaos sin tocar el clúster.

Ejemplo de 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 de 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"

De Staging al Chaos Continuo: El Camino de Madurez

Los equipos no saltan al chaos diario en producción; se lo ganan por etapas:

1. Experimentos en staging — aprende las herramientas, demuestra que tus mecanismos de aborto funcionan, construye los primeros dashboards. Riesgo cero para el cliente; aun así atrapa bugs reales.
2. Producción, ámbito mínimo — un pod, una instancia canary o una sola dependencia en horas valle. La primera corrida que sobrevive staging y producción es cuando la confianza de verdad se construye.
3. Corridas programadas en producción — experimentos semanales o diarios con radio de impacto estrecho, anunciados al on-call. Aquí es donde se atrapa la deriva.
4. Chaos continuo e integrado — chaos como parte de los pipelines de despliegue y la verificación de steady state (la receta tiene un verificador listo). Netflix opera aquí.

La mayoría de equipos se atasca entre el 2 y el 3. El bloqueo rara vez es la herramienta — es que nadie es dueño de los experimentos. Asigna un responsable de game days, pon el calendario en un doc compartido y trata los hallazgos como tickets de incidente.

El coste cultural también es real. Los experimentos de chaos generan trabajo: cada debilidad encontrada es un ticket que alguien tiene que arreglar, y si los hallazgos solo se apilan en un doc que nadie lee, el programa muere más rápido que los sistemas que rompe. Reserva el tiempo de remediación antes que el de la herramienta — una buena regla es que cada game day genere como máximo tantos tickets como el equipo pueda cerrar en un sprint.

Un Game Day Real: E-commerce Antes de Black Friday

Así se ve un programa de chaos de seis meses en la práctica — una plataforma de e-commerce con 15 microservicios validando resiliencia antes de Black Friday:

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

Calendario de game days (mensual):
  | Mes | Experimento | Hipótesis | Resultado |
  |-----|-----------|-----------|--------|
  | Ene | Matar pod de pagos | Auto-scaling reemplaza en < 30s | Pasa |
  | Feb | 500ms latencia DB | Circuit breaker activa fallback | Falla: sin fallback |
  | Mar | Matar AZ entera | Tráfico reencamina a AZ sana | Pasa |
  | Abr | Latencia Redis | Cache miss degrada con gracia | Falla: timeouts en cascada |
  | May | Matar servicio búsqueda | Catálogo sin búsqueda funciona | Pasa |
  | Jun | Mensaje Kafka corrupto | Consumidor maneja poison pill | Falla: consumidor se cuelga |

Experimento detallado (Feb):
  Nombre: DB-latency-injection
  Hipótesis: Si la DB tiene 500ms de latencia, el circuit breaker
              activa el fallback de caché en < 5s sin errores 5xx
  Radio de impacto: 10% del tráfico (canary)
  Duración: 10 minutos
  Aborto: error rate > 5% o p99 > 3s

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

  Monitorización durante el experimento:
    - Error rate: 0% -> 12% (FALLA)
    - Latencia p99: 200ms -> 4.5s (FALLA)
    - Circuit breaker: nunca activó (FALLA)
    - Fallback de caché: no implementado (FALLA)

  Análisis post-mortem:
    Causa raíz: Umbral del circuit breaker en 10s
                pero la DB respondía en 500ms (sin timeout).
                El fallback de caché no existía.

    Acciones:
    1. Implementar fallback de caché para consultas de producto
    2. Bajar umbral del circuit breaker a 2s
    3. Añadir timeout de 1s a consultas de DB
    4. Repetir el experimento en staging

  Repetición (Mar):
    - Error rate: 0% (PASA)
    - Latencia p99: 200ms -> 350ms (PASA)
    - Circuit breaker: activo a los 3s (PASA)
    - Fallback de caché: sirvió datos stale (PASA)

Automatización (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"

Tres de los seis experimentos mensuales fallaron — y ese es el triunfo. Cada “Falla” es un incidente de producción que no ocurrirá en Black Friday: un fallback de caché ausente, timeouts en cascada por latencia de Redis, un consumidor que se cuelga con mensajes envenenados de Kafka. La repetición de febrero es la parte que la mayoría olvida: el experimento solo cuenta cuando pasa.

Temas Avanzados

Cuando lo básico ya es rutina:

• Probes de steady state como código — Litmus y Chaos Mesh pueden correr probes dentro del propio experimento; el experimento se auto-abortta cuando un probe falla.
• Escenarios multi-fallo — combina pod kills + latencia para simular incidentes compuestos (los que de verdad tumban sitios).
• Chaos en CI/CD — inyecta fallos en un entorno preview durante los tests de integración, antes de que el código llegue siquiera a staging.
• Chaos para sistemas con estado — bases de datos, colas y cachés necesitan fallos más suaves y ventanas de observación más largas; los replica kills prueban failover, no solo rescheduling.
• Gobernanza — un registro de experimentos: quién corrió qué, cuándo, con qué radio de impacto y resultado. Convierte el chaos puntual en una práctica auditable.

Salvaguardas de Seguridad

• Condiciones de aborto — detén el experimento si el error rate > 1% o p99 > 500ms; conectado a monitorización, no manual
• Acotado en tiempo — limita la duración (30s, 5m); un fallo abierto es una caída
• Ámbito pequeño — un pod → un deployment → un namespace → una AZ, en ese orden
• Horario laboral — corre cuando hay ingenieros despiertos y disponibles, no a las 3am
• Comunicación clara — anuncia los experimentos al equipo para que una alarma de chaos no se responda como incidente real

Errores Comunes

• Sin definición de steady state — si no sabes numéricamente cómo se ve lo normal, no puedes detectar la degradación
• Radio de impacto demasiado grande — empezar con una caída de región entera convierte un experimento en un incidente con clientes
• Sin mecanismo de aborto — los experimentos deben auto-terminarse al violar SLOs; un interruptor manual falla exactamente cuando lo necesitas
• Culpar a individuos — el chaos encuentra debilidades del sistema, no errores humanos; una cultura de game day sin culpa produce hallazgos honestos, una con culpa produce cancelación
• Correr sin runbooks — encontrar el bug es la mitad del trabajo; que nadie sepa qué hacer con él es la otra mitad

Errores Comunes en Producción

• Tratar la guía como un checklist a completar una vez en lugar de una práctica que evolucionar.
• Adoptar todas las recomendaciones a la vez en lugar de empezar con un cambio medido.
• Saltarse la evaluación de madurez y forzar chaos en producción a un equipo no preparado.
• No actualizar runbooks ni expectativas de on-call a medida que aterrizan prácticas nuevas.
• Ignorar los datos de incidentes reales al priorizar qué fallos inyectar primero.
• No asignar un responsable que revise experimentos y hallazgos trimestralmente.
• Copiar configs de ejemplo sin adaptarlas a las herramientas y restricciones del equipo.
• No medir nada antes de añadir el siguiente experimento al calendario.

Notas de Producción

• Despliega gradualmente — canary o blue-green atrapa regresiones antes de que se mezclen con tus fallos de chaos y confundan la señal.
• Alerta sobre los mismos SLOs con los que abortas: error rate, latencia p99, failure rate. Si tus criterios de aborto no son también tus alertas, son adivinanzas.
• Documenta el rollback en el runbook y ensáyalo en staging al menos una vez por trimestre — un rollback no probado es una esperanza, no un plan.
• Correlaciona con logs — logs estructurados con IDs de petición permiten trazar qué petición chocó con qué fallo durante un experimento.

Solución de Problemas

• El experimento nunca dispara: revisa el RBAC/service account del agente de chaos y el ámbito de namespace; la mayoría de fallos “silenciosos” de Chaos Mesh o Litmus son denegaciones de permisos visibles en kubectl describe.
• El aborto no salta: la condición de aborto tiene que llegar a tu monitorización — pruébala con un fallo benigno (50ms de latencia) antes de confiarla en uno real.
• Las métricas se ven planas: verifica que miras el servicio que consume la dependencia, no el que inyectas. La latencia se manifiesta aguas abajo.
• El equipo no distingue chaos de incidente: anuncia cada experimento en el canal de on-call con ventana de inicio/fin y un tag (chaos=true) en los recursos inyectados.
• Los resultados no se reproducen: los sistemas reales difieren bajo carga — repite a la misma hora del día con el mismo perfil de tráfico antes de concluir que un arreglo funcionó.

Puntos Clave

• El chaos engineering es inyección de fallos controlada y guiada por hipótesis — el objetivo es confianza, no cosas rotas.
• Los cinco principios se reducen a dos reglas: conoce tu steady state y mantén pequeño el radio de impacto.
• Madura por etapas — staging, producción acotada, corridas programadas — antes de tocar el chaos continuo.
• Un experimento que “falla” es el producto: cada debilidad encontrada en un game day es una caída que no ocurrirá en vivo.
• La receta de Chaos Engineering tiene el lado ejecutable de esta guía: configs de inyección, verificador de steady state y plantilla de game day.

Lectura Adicional

• Principles of Chaos Engineering — el manifiesto canónico.
• Documentación de Litmus Chaos y documentación de Chaos Mesh — herramientas nativas de Kubernetes.
• AWS Fault Injection Simulator — chaos gestionado para cargas AWS.
• The Netflix Simian Army — cómo funciona Chaos Monkey y por qué.
• Postmortems públicos (GitHub, Cloudflare, Honeycomb) — los informes de incidentes reales son la mejor fuente de fallos que vale la pena inyectar.