Chaos engineering pasó de concepto contra-intuitivo (el Chaos Monkey de Netflix apagando servidores en producción) a práctica reconocida de SRE maduro. En la actualidad hay herramientas abiertas consolidadas, frameworks de experimentación y ROI medible. La confusión persiste: no es "romper cosas random", es experimentar con hipótesis sobre cómo responde tu sistema ante fallos reales. Este artículo cubre cómo adoptarlo de forma seria en una organización.

Puntos clave

  • Chaos engineering sin hipótesis es ruido, no ingeniería. La hipótesis define qué se espera observar antes de inyectar el fallo.

  • El blast radius debe ser gradual: empezar localmente, pasar por staging, luego por el 1 % de tráfico en producción.

  • Sin observabilidad (métricas, logs, trazas), es imposible aprender de los experimentos.

  • Los game days trimestrales mantienen los skills del equipo y validan los runbooks.

  • Las herramientas open-source (Litmus, Chaos Mesh) hacen la adopción accesible sin gasto comercial.

La definición real

Chaos engineering es:

  • Experimentos con hipótesis: "si X falla, creemos que Y ocurrirá".

  • Blast radius controlado: no "romper todo en producción".

  • En producción o cerca: staging no captura el comportamiento real del sistema.

  • Objetivo: aumentar la confianza en la resiliencia del sistema, no demostrar que falla.

No es:

  • Apagar servidores aleatorios sin plan.

  • Testing negativo manual sin documentar.

  • Simulacros raros sin hipótesis ni análisis.

La diferencia clave es la disciplina: hipótesis previa, observación durante, análisis posterior, aprendizaje compartido.

Los principios de Chaos Engineering

El manifiesto de la disciplina (principlesofchaos.org):

  • Hipótesis sobre el steady state: ¿cómo se ve el sistema "normal"? Define métricas de referencia.

  • Variar eventos del mundo real: latencia, fallos de servicio, picos de carga, particiones de red.

  • Experimentar en producción: staging no reproduce el comportamiento real.

  • Automatizar los experimentos: chaos continuo, no solo sessions manuales.

  • Minimizar el blast radius: experimentos contenidos, con rollback inmediato.

Ejemplo completo de experimento

Hipótesis: "Si la latencia del servicio de pagos sube a 2 s, el checkout sigue funcionando correctamente mediante fallback a caché."

Experimento:

  • Baseline: medir el success rate del checkout en condiciones normales.

  • Inject: añadir 2 s de latencia artificial al servicio de pagos, limitado al 1 % del tráfico.

  • Observe: ¿el success rate del checkout se mantiene? ¿se activó el fallback?

  • Analyse: ¿la hipótesis se validó o no?

  • Learn: compartir el resultado, arreglarlo si la hipótesis falló.

Posible resultado: descubres que el timeout del fallback caché es de 1,5 s. Cuando el servicio de pagos tarda 2 s, el fallback también falla silenciosamente en lugar de servir datos cacheados. Fix concreto, detectado en staging de chaos antes de que ocurra en producción.

Herramientas

Litmus (CNCF sandbox)

Litmus[1] es Kubernetes-native con un catálogo de experimentos (pod kill, network loss, CPU stress, memory pressure). Tiene UI web para orquestar y soporte de probes para validar la hipótesis automáticamente. Es el estándar open-source más adoptado para K8s.

Chaos Mesh (CNCF sandbox)

Chaos Mesh[2] es también Kubernetes-native, con controles más granulares, workflows DAG de experimentos y scheduler para chaos recurrente. Más pulido en ciertos aspectos que Litmus.

Gremlin (comercial)

Gremlin[3] es la plataforma comercial de referencia: GUI amigable, biblioteca extensa de experimentos, safety controls y reporting detallado. Para enterprises que quieren chaos-as-a-service con soporte.

AWS FIS

AWS FIS[4] (Fault Injection Service) es el chaos gestionado para recursos AWS. Si tu infraestructura es principalmente AWS, es el camino con menor fricción de setup.

Tipos de experimentos por categoría

Infraestructura:

  • Kill de pod o instancia con replicas disponibles.

  • Disco lleno (filesystem exhaustion).

  • CPU o memoria bajo presión sostenida.

  • Partición de red entre zonas de disponibilidad.

Aplicación:

  • Inyección de latencia en llamadas entre microservicios.

  • Inyección de errores (porcentaje de respuestas 500).

  • Fallo de dependencia externa simulado.

  • Vaciado de cola de mensajes.

Datos:

  • Latencia en queries de base de datos.

  • Lag de réplica: ¿qué pasa cuando lees de la réplica retrasada?

  • Evicción de caché: cold start scenario.

Control del blast radius

El escalado gradual es la clave:

  • Local dev / test environment: sin riesgo, para familiarizarse con la herramienta.

  • Staging: representa producción pero no la afecta.

  • Canary en producción (1 % de tráfico): primer paso en prod real.

  • Sampling (usuarios opt-in): para experimentos específicos.

  • Producción completa: solo cuando la confianza es alta y el rollback se ejecuta en un comando.

La escalada gradual evita incidentes serios durante los primeros meses de adopción.

Métricas e integración con SRE

Chaos engineering encaja de forma natural con las prácticas SRE existentes:

  • SLOs: los experimentos validan si el error budget aguanta bajo estrés.

  • Post-mortems: los experimentos reproducen y verifican los aprendizajes de incidentes pasados.

  • Runbooks: chaos valida que los runbooks funcionan de verdad, no solo en teoría.

  • On-call: los game days preparan a los ingenieros para responder mejor bajo presión.

Para equipos sin observabilidad madura, invertir en OpenTelemetry o en un stack de métricas + logs antes de empezar con chaos. Las prácticas SRE que sustentan esta disciplina, SLOs, error budgets y post-mortems, se tratan en detalle en el artículo sobre cómo aplicar el libro de SRE de Google.

Roadmap de adopción

Fase 1: Cultura (semanas 1-4)

  • Convencer a liderazgo e ingeniería del valor.

  • Establecer cultura de no-blame: los experimentos revelan debilidades del sistema, no incompetencia personal.

  • Empezar en staging.

Fase 2: Experimentos básicos (meses 1-3)

  • 1-2 experimentos simples con hipótesis documentadas.

  • Documentar hipótesis, resultado y aprendizajes.

  • Compartir los resultados con el equipo.

Fase 3: Producción limitada (meses 3-6)

  • Experimentos con blast radius del 1 % en producción.

  • Monitorización estrecha y rollback inmediato disponible.

Fase 4: Chaos continuo (meses 6-12)

  • Chaos automatizado en el pipeline de CI/CD.

  • Game days trimestrales.

  • Biblioteca interna de experimentos.

Game days

Un game day es un ejercicio dedicado de 2-4 horas:

  • Elige un escenario (por ejemplo: "el primary de la base de datos falla").

  • Programa el tiempo con el equipo de on-call.

  • Ejecuta el escenario y deja que el equipo responda con sus runbooks.

  • Debrief: ¿qué funcionó? ¿qué no? ¿qué hay que arreglar?

Los game days trimestrales mantienen el músculo de respuesta ante incidentes y validan que los runbooks están actualizados.

Antipatrones

  • Chaos sin observabilidad: sin datos, es imposible aprender.

  • Sin hipótesis: "rompamos cosas a ver qué pasa" no es chaos engineering.

  • Sin buy-in del equipo: si el equipo lo vive como amenaza, el resultado será resistencia.

  • Blast radius grande en el primer intento: perder credibilidad con un incidente real en las primeras semanas es el peor inicio posible.

  • No documentar: el aprendizaje se pierde si no queda escrito.

Conclusión

Chaos engineering es una práctica madura y valiosa para organizaciones que se toman en serio la resiliencia. Bien hecho (con hipótesis, blast radius controlado y observabilidad) produce incidentes evitados y equipos mejor preparados. Las herramientas open-source (Litmus, Chaos Mesh) hacen la adopción accesible.

Para equipos que ya tienen los fundamentos de SRE (SLOs, post-mortems, runbooks), chaos es el siguiente nivel. Para equipos sin esa base, invertir en ella primero: chaos sin infraestructura de aprendizaje es puro estrés sin valor.

Este artículo también está disponible en inglés: Chaos Engineering in Enterprise: Beyond Chaos for Chaos’s Sake.

Fuentes:

  1. Principles of Chaos Engineering: principlesofchaos.org[5]
  2. Litmus: CNCF chaos engineering framework for Kubernetes[1]
  3. Chaos Mesh: A Powerful Chaos Engineering Platform for Kubernetes[2]
  4. AWS Fault Injection Service: documentación oficial[4]

Preguntas frecuentes

¿Puedo hacer chaos engineering solo en staging sin tocar producción?

Puedes empezar ahí, pero no quedarte. Staging no reproduce el comportamiento real del sistema, así que uno de los principios de la disciplina es experimentar en producción o cerca de ella. La forma segura es escalar el blast radius de manera gradual: entorno local, staging, canary con el 1 % del tráfico en producción, sampling con usuarios opt-in y solo al final producción completa. Ese último paso llega cuando la confianza es alta y el rollback se hace en un comando.

¿Qué herramienta de chaos engineering elijo si mi plataforma es Kubernetes o AWS?

Para Kubernetes, las dos opciones open-source son Litmus y Chaos Mesh, ambas en CNCF sandbox: Litmus es el estándar más adoptado, con catálogo de experimentos, UI web y probes para validar hipótesis. Chaos Mesh ofrece controles más granulares, workflows DAG y scheduler para chaos recurrente. Si tu infraestructura es principalmente AWS, AWS FIS es el camino con menor fricción de setup. Gremlin es la plataforma comercial de referencia para quien quiere chaos-as-a-service con soporte.

¿Cuánto se tarda en adoptar chaos engineering en una organización?

El roadmap propuesto cubre unos 12 meses en cuatro fases. Cultura y no-blame en las semanas 1-4 empezando en staging; 1-2 experimentos básicos con hipótesis documentadas en los meses 1-3. Producción limitada con blast radius del 1 % en los meses 3-6; chaos continuo automatizado en el pipeline de CI/CD, game days trimestrales y biblioteca interna de experimentos en los meses 6-12. Sin observabilidad madura conviene invertir primero en OpenTelemetry o en métricas y logs.

Fuentes

  1. Litmus
  2. Chaos Mesh
  3. Gremlin
  4. AWS FIS
  5. Principles of Chaos Engineering: principlesofchaos.org