Actualizado: 2026-07-07

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, así que 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 es inmediato.

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. Litmus
  2. Chaos Mesh
  3. Gremlin
  4. AWS FIS
  5. Principles of Chaos Engineering: principlesofchaos.org