⏱️ Lectura: 15 min
Netflix apaga servidores de producción a propósito, todos los días, y así construye el servicio de streaming más confiable del mundo. La práctica se llama ingeniería del caos y consiste en inyectar fallos controlados en sistemas reales para descubrir sus puntos débiles antes de que un apagón, un pico de tráfico o un disco lleno los descubra por vos.
📑 En este artículo
- TL;DR
- Qué es la ingeniería del caos y por qué importa
- Cómo funciona un experimento de caos, paso a paso
- Ejemplos prácticos: de un script simple a un experimento en Kubernetes
- Cómo empezar hoy: instalar Chaos Mesh en un clúster de prueba
- Casos de uso reales
- Errores comunes y buenas prácticas
- Comparativa de herramientas de ingeniería del caos
- Profundizando: game days y el radio de impacto creciente
- Preguntas frecuentes
- Referencias
No es correr scripts al azar ni romper por romper: es un método con hipótesis, métricas y un radio de impacto medido de antemano. En este artículo vas a ver cómo funciona, qué herramientas usar y cómo montar tu primer experimento hoy mismo.
TL;DR
- Vas a entender los cuatro principios formales de la ingeniería del caos y de dónde vienen.
- Vas a instalar Chaos Mesh en Kubernetes con Helm y lanzar tu primer experimento PodChaos.
- Vas a distinguir cuándo conviene Chaos Monkey, Chaos Mesh, Litmus o AWS Fault Injection Simulator.
- Vas a poder definir un radio de impacto seguro antes de correr un experimento en producción.
- Vas a saber verificar con kubectl si un experimento de caos sigue activo o ya terminó.
- Vas a identificar los errores más comunes al empezar, como no tener un botón de pánico.
Qué es la ingeniería del caos y por qué importa
La ingeniería del caos es la disciplina de experimentar sobre un sistema distribuido para generar confianza real en su capacidad de resistir condiciones turbulentas en producción. La definición formal viene del manifiesto Principles of Chaos Engineering, escrito por ingenieros de Netflix que crearon la primera herramienta del género, Chaos Monkey, a comienzos de la década de 2010.
La idea nació de un problema concreto. Netflix migraba de centros de datos propios a AWS y necesitaba una garantía: si una instancia moría sin aviso, algo que ocurre todo el tiempo en la nube, el servicio no podía caerse con ella. En vez de esperar a que fallara sola, el equipo escribió un programa que mataba instancias al azar en horario laboral, para obligar a cada equipo a diseñar servicios tolerantes a fallos desde el principio.
Hoy el concepto se expandió mucho más allá de matar una máquina. Se inyecta latencia de red, se llena un disco, se satura la CPU, se corta el acceso a una base de datos o se simula la caída de una zona de disponibilidad completa. El objetivo siempre es el mismo: encontrar la debilidad en un entorno controlado, con gente mirando el panel de métricas, en vez de descubrirla un fin de semana con el sistema completo caído.
Esto la distingue de un simulacro clásico de recuperación ante desastres. Un simulacro suele ser un evento planificado una vez al año; un experimento de ingeniería del caos está pensado para correrse de forma continua y automática, como una prueba más del pipeline, no como un evento excepcional.
Cómo funciona un experimento de caos, paso a paso
Todo experimento serio sigue el mismo ciclo, sin importar la herramienta que uses. Primero se define el estado estable: una métrica de negocio, no puramente técnica, que representa que el sistema funciona bien, por ejemplo la latencia p99 o la tasa de checkouts completados por minuto. Después se formula una hipótesis: si matamos un pod del servicio de pagos, el estado estable se mantiene porque existen réplicas y reintentos.
Con la hipótesis clara, se inyecta el fallo real y se compara lo observado contra lo esperado. Si el estado estable se mantiene, la hipótesis queda confirmada y se gana confianza verificable, no teórica. Si el estado estable se rompe, se encontró una debilidad real antes que un cliente.
flowchart TD
A["Definir estado estable"] --> B["Formular una hipotesis"]
B --> C["Inyectar un fallo controlado"]
C --> D["Observar metricas en vivo"]
D --> E{"Se cumple la hipotesis"}
E -->|"Si"| F["Confirmar que el sistema es resiliente"]
E -->|"No"| G["Corregir la debilidad hallada"]
G --> A
F --> ALos cuatro principios formales
El primer principio pide definir el estado estable en términos medibles, no en supuestos. El segundo pide variar eventos del mundo real: caídas de hardware, fallos de red, picos de tráfico y errores de terceros, no solo apagar un servidor.
El tercer principio, el más resistido en la práctica, pide correr los experimentos lo más cerca posible de producción, porque un entorno de staging casi nunca reproduce el tráfico y las dependencias reales. El cuarto pide automatizar los experimentos para que corran de forma continua, en vez de ejecutarse una sola vez y archivarse.
Antes de empezar hace falta observabilidad
Ningún experimento de caos tiene sentido si nadie puede ver qué pasó durante la inyección del fallo. Antes de instalar cualquier herramienta de caos conviene tener métricas (Prometheus), trazas (OpenTelemetry) y logs centralizados funcionando, porque el experimento solo aporta valor si se puede comparar el estado estable antes, durante y después del fallo.
Ejemplos prácticos: de un script simple a un experimento en Kubernetes
El experimento de caos más simple posible es un script que mata procesos al azar. No usa ninguna herramienta especializada, pero ilustra la idea central: introducir un fallo real de forma repetible.
#!/bin/bash
# hola-mundo-caos.sh: mata un proceso de checkout-service cada 60 segundos
while true; do
PID=$(pgrep -f checkout-service | shuf -n 1)
if [ -n "$PID" ]; then
kill -9 "$PID"
echo "Proceso $PID terminado a las $(date)"
fi
sleep 60
doneAl correr este script contra una instancia de checkout-service con varias réplicas, debería verse en los logs cómo el proceso muere y el balanceador redirige el tráfico a otra réplica sin que el usuario note nada. Si el usuario sí nota un error, ya apareció la primera debilidad real.
En Kubernetes, el equivalente productivo es un manifiesto de Chaos Mesh, que declara el experimento como un recurso más del clúster:
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: kill-pod-checkout
namespace: chaos-mesh
spec:
action: pod-kill
mode: one
selector:
namespaces:
- produccion
labelSelectors:
app: checkout-service
scheduler:
cron: "@every 10m"Este manifiesto le indica al operador de Chaos Mesh que, cada 10 minutos, elija un pod con la etiqueta app: checkout-service en el namespace produccion y lo mate. La diferencia con el script bash es enorme: acá el experimento queda versionado en Git, tiene un scheduler declarativo y se revierte con un solo kubectl delete.
⚠️ Ojo: nunca corras tu primer experimento de caos directo en producción sin avisar al equipo de guardia. El objetivo es aprender, no generar un incidente real sin monitoreo activo.
Inyectar latencia de red en vez de matar el pod
Matar un pod es el fallo más simple, pero muchas veces el problema real es más sutil: una dependencia que responde lento. Chaos Mesh también permite inyectar latencia con un recurso NetworkChaos:
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: latencia-checkout
namespace: chaos-mesh
spec:
action: delay
mode: all
selector:
namespaces:
- produccion
labelSelectors:
app: checkout-service
delay:
latency: "300ms"
jitter: "50ms"
duration: "5m"Este experimento agrega 300 ms de latencia, más un jitter de 50 ms, durante 5 minutos, a todo el tráfico del servicio. Es el tipo de fallo que suele revelar timeouts mal configurados que un simple pod-kill nunca expone.
sequenceDiagram
participant Op as Operador Chaos Mesh
participant K as API de Kubernetes
participant Pod as Pod objetivo
participant Mon as Prometheus
Op->>K: aplica manifiesto PodChaos
K->>Pod: inyecta el fallo declarado
Pod-->>Mon: expone metricas degradadas
Mon-->>Op: confirma que el experimento esta activo
Note over Op,Pod: el experimento se revierte solo al vencer durationCómo empezar hoy: instalar Chaos Mesh en un clúster de prueba
Para probar los ejemplos anteriores en un clúster propio, sirve minikube o kind si no hay uno a mano. Se instala Chaos Mesh con Helm:
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh \
--namespace=chaos-mesh \
--set chaosDaemon.runtime=containerd \
--set chaosDaemon.socketPath=/run/containerd/containerd.sockCon el operador instalado, se aplica el manifiesto PodChaos del ejemplo anterior:
kubectl apply -f kill-pod-checkout.yaml
kubectl get podchaos -n chaos-meshPara confirmar que el experimento está corriendo, y no solo declarado, hay que revisar su estado:
kubectl describe podchaos kill-pod-checkout -n chaos-meshHay que buscar el campo Phase en la salida: Running confirma que Chaos Mesh está inyectando el fallo en ese momento; Waiting significa que espera al siguiente disparo del cron. Chaos Mesh también expone un dashboard web donde queda el historial de cada experimento y su resultado.
Casos de uso reales
Netflix mantuvo durante años el llamado Simian Army, una familia de herramientas derivadas de Chaos Monkey: Latency Monkey para inyectar demoras artificiales, Conformity Monkey para detectar instancias que no seguían buenas prácticas, y Chaos Kong para simular la caída de una región entera de AWS. El origen y el código siguen documentados en el repositorio público de Chaos Monkey.
AWS formalizó el enfoque como producto administrado con AWS Fault Injection Simulator, que permite definir experimentos (matar instancias EC2, saturar CPU, cortar el acceso a una API) sin instalar nada en un clúster propio. Es la vía más simple para equipos que ya viven dentro del ecosistema de AWS.
En el mundo open source, los equipos que corren Kubernetes fuera de una nube gestionada suelen elegir entre Chaos Mesh y Litmus Chaos, ambos proyectos de la Cloud Native Computing Foundation. La elección típica depende de si el equipo ya piensa en CRDs como forma principal de configuración, donde Chaos Mesh se siente más nativo, o si prefiere un catálogo de experimentos reutilizables, el punto fuerte del ChaosHub de Litmus.
Plataformas de comercio electrónico usan estos experimentos antes de eventos de tráfico alto para verificar que el sistema de pagos aguanta la caída de un proveedor externo, y bancos y fintechs los aplican para probar que una transacción se reintenta o se revierte correctamente si el servicio de fraude no responde a tiempo.
Errores comunes y buenas prácticas
- Empezar sin acotar el radio de impacto: el primer experimento nunca debería poder afectar a más del 1% del tráfico. Hay que ajustar el
selectorpara que apunte a una sola réplica o a un canary, no a todo el despliegue. - No tener un botón de pánico: todo experimento necesita una forma de abortarlo en segundos. En Chaos Mesh alcanza con
kubectl delete podchaos kill-pod-checkout -n chaos-mesh; si un script casero no tiene un equivalente, mejor no correrlo. - Confundir carga con caos: una prueba de carga mide cuánto tráfico aguanta el sistema; un experimento de caos mide qué pasa cuando algo se rompe con tráfico normal. Son complementarios, no lo mismo.
- No automatizar: un experimento manual que se corre una vez y se archiva no genera confianza continua. El cuarto principio del manifiesto pide justamente automatizar los experimentos para que corran solos, todo el tiempo.
- Saltarse el game day: antes de automatizar conviene correr el experimento en vivo con todo el equipo mirando el dashboard de métricas, para poder abortar y aprender en conjunto.
💡 Tip: arrancá siempre en un entorno que sea una réplica fiel de producción antes de mover el experimento al entorno real. Si ese entorno no refleja producción, el experimento no dice nada útil.
Ninguno de estos errores es exclusivamente técnico. La mayoría aparece cuando la ingeniería del caos se trata como una herramienta más de infraestructura y no como una práctica que necesita apoyo de todo el equipo, incluidos quienes atienden guardias y quienes definen qué métrica de negocio importa de verdad.
Comparativa de herramientas de ingeniería del caos
| Herramienta | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Chaos Monkey | Instancias en AWS con Spinnaker ya integrado | Pionera, probada durante más de una década en Netflix | Pensada para instancias, no nació para Kubernetes |
| Chaos Mesh | Clústeres Kubernetes propios, on-premise o en la nube | Experimentos como CRDs nativos, con dashboard incluido | Requiere operar el propio clúster y su RBAC |
| Litmus Chaos | Equipos que quieren un catálogo de experimentos reutilizables | ChaosHub con experimentos ya empaquetados | Curva de aprendizaje mayor para casos simples |
| AWS Fault Injection Simulator | Infraestructura ya centralizada en AWS | Servicio administrado, sin operar infraestructura propia | Atado al ecosistema de AWS |
Ninguna opción es universalmente mejor: la decisión depende de dónde vive ya la infraestructura y de cuánto control declarativo necesita el equipo sobre cada experimento.
Profundizando: game days y el radio de impacto creciente
Los equipos maduros no corren experimentos directo contra el 100% de producción. Escalan el radio de impacto en etapas: primero contra desarrollo, después en staging, luego contra un canary que recibe una fracción mínima del tráfico real, y solo al final contra producción completa, con el experimento ya probado en las etapas anteriores.
flowchart LR
A["Entorno de desarrollo"] --> B["Staging"]
B --> C["Canary en produccion, trafico minimo"]
C --> D["Produccion completa"]
subgraph "Radio de impacto creciente"
A
B
C
D
end
Esta escalada convive con la práctica del game day: una sesión programada donde varios equipos, no solo el de infraestructura, observan juntos un experimento en vivo. La ventaja frente a automatizarlo directamente es humana: genera contexto compartido sobre cómo reacciona el sistema real, y ese conocimiento después se traduce en runbooks y alertas mejor calibradas.
Un detalle que suele pasarse por alto es que el estado estable no es una sola métrica técnica sino un conjunto acordado con el equipo de producto. Netflix, por ejemplo, no medía únicamente si un servidor respondía, sino si el usuario podía seguir reproduciendo un video. Esa distinción entre métrica técnica y métrica de negocio separa un experimento útil de uno que pasa en el dashboard técnico pero igual deja al usuario con la pantalla en blanco.
La progresión típica de madurez de un equipo pasa por tres etapas: experimentos manuales y ad hoc, experimentos programados y gestionados con un catálogo interno, y por último experimentos automatizados que corren solos dentro del pipeline de despliegue, sin intervención humana en cada corrida.
💭 Clave: el objetivo final de la ingeniería del caos no es demostrar que el sistema es perfecto, sino encontrar la próxima debilidad antes que un incidente real la encuentre por vos.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: instalá Chaos Mesh en un clúster de minikube y corré el manifiesto PodChaos de este artículo contra un despliegue propio con al menos dos réplicas.
Preguntas frecuentes
¿La ingeniería del caos es lo mismo que romper cosas al azar?
No. Cada experimento parte de una hipótesis clara sobre el estado estable del sistema y se mide contra esa hipótesis. Romper algo sin medir nada no genera ningún aprendizaje.
¿Hace falta usar Kubernetes para practicar ingeniería del caos?
No. Chaos Monkey nació para instancias de AWS sin Kubernetes, y AWS Fault Injection Simulator funciona directo sobre EC2, RDS o Lambda sin un clúster de por medio.
¿Es seguro correr experimentos directo en producción?
Es seguro si el radio de impacto está acotado, existe un botón de pánico y el equipo de guardia sabe que el experimento está corriendo. Sin esas tres condiciones, no conviene.
¿Qué es un game day?
Una sesión programada donde varios equipos observan en vivo un experimento de caos, con el objetivo de generar contexto compartido y detectar huecos en las alertas y los runbooks.
¿Cuánto cuesta empezar?
Chaos Mesh y Litmus Chaos son open source y gratuitos; el único costo es la infraestructura de prueba donde se corren. AWS Fault Injection Simulator cobra por experimento ejecutado dentro de la nube de Amazon.
¿La ingeniería del caos reemplaza al testing tradicional?
No. Los tests unitarios y de integración verifican que el código haga lo esperado en condiciones normales; la ingeniería del caos verifica que el sistema completo, con todas sus dependencias reales, siga funcionando cuando algo falla.
Referencias
- Principles of Chaos Engineering: el manifiesto original con los cuatro principios formales.
- Netflix/chaosmonkey en GitHub: el código fuente de la herramienta que inició la disciplina.
- Chaos Mesh: documentación oficial del proyecto de la Cloud Native Computing Foundation para Kubernetes.
- Litmus Chaos: sitio oficial del proyecto y su catálogo ChaosHub.
- AWS Fault Injection Simulator: página oficial del servicio administrado de AWS.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios