Chaos engineering en empresa: más allá del caos por el caos

Actualizado: 2026-05-03

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 en local, 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):

1. Hipótesis sobre el steady state: ¿cómo se ve el sistema “normal”? Define métricas de referencia.
2. Variar eventos del mundo real: latencia, fallos de servicio, picos de carga, particiones de red.
3. Experimentar en producción: staging no reproduce el comportamiento real.
4. Automatizar los experimentos: chaos continuo, no solo sessions manuales.
5. 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:

1. Baseline: medir el success rate del checkout en condiciones normales.
2. Inject: añadir 2 s de latencia artificial al servicio de pagos, limitado al 1 % del tráfico.
3. Observe: ¿el success rate del checkout se mantiene? ¿se activó el fallback?
4. Analyse: ¿la hipótesis se validó o no?
5. 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 Fault Injection Service

AWS FIS^[4] 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:

1. Local dev / test environment: sin riesgo, para familiarizarse con la herramienta.
2. Staging: representa producción pero no la afecta.
3. Canary en producción (1 % de tráfico): primer paso en prod real.
4. Sampling (usuarios opt-in): para experimentos específicos.
5. 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 testean 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.

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:

1. Elige un escenario (por ejemplo: “el primary de la base de datos falla”).
2. Programa el tiempo con el equipo de on-call.
3. Ejecuta el escenario y deja que el equipo responda con sus runbooks.
4. 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.

1. Litmus
2. Chaos Mesh
3. Gremlin
4. AWS FIS