Chaos engineering pasó de concepto contra-intuitivo (Netflix Chaos Monkey) a práctica reconocida de SRE maduro. En 2024 hay herramientas abiertas maduras, frameworks de experimentación, y ROI medible. Pero sigue habiendo confusion — no es “romper cosas random”, es experimentar con hipótesis sobre cómo responde tu sistema. Este artículo cubre cómo adoptarlo serio en empresa.
La definición real
Chaos engineering es:
- Experimentos con hipótesis: “si X falla, creemos que Y pasará”.
- Blast radius controlado: no “romper toda prod”.
- En producción (o casi): staging no captura comportamiento real.
- Objetivo: aumentar confianza en resiliencia sistema.
No es:
- “Apagar random servers”.
- “Testing negativo manual”.
- “Simulacros raros sin plan”.
Diferencia clave: disciplina y hipótesis.
Los principios
Principles of Chaos Engineering (manifiesto):
- Hypothesis about steady-state behavior: ¿cómo se ve “normal”?
- Vary real-world events: latencia, fallos, picos, partitions.
- Run experiments in production: staging no suficiente.
- Automate experiments: continuous chaos.
- Minimize blast radius: experimentos contenidos.
Ejemplo de experimento
Hipótesis: “Si el servicio de payments latency sube a 2s, el checkout sigue funcionando via fallback cache.”
Experimento:
- Baseline: medir success rate checkout normal.
- Inject: latencia 2s en payment service (blast radius: 1% de traffic).
- Observe: ¿success rate checkout se mantiene? ¿fallback activó?
- Analyze: hipótesis validada o no.
- Learn: fix issues descubiertos.
Resultado posible: descubres que fallback cache timeout es 1.5s → fallas silently en lugar de servir cached data. Fix.
Herramientas populares
Chaos Monkey (Netflix)
El original, foco en AWS. Kills random EC2 instances. Código viejo pero el concepto founded the field.
Litmus
Litmus (CNCF sandbox):
- Kubernetes-native.
- Catálogo de experimentos (pod kill, network loss, CPU stress, etc).
- UI web para orquestar.
- Hypothesis-driven con probes.
Open source fuerte para K8s.
Chaos Mesh
Chaos Mesh (CNCF sandbox):
- Kubernetes-native.
- More granular controls.
- DAG workflows de experimentos.
- Scheduler para chaos recurrente.
Más pulido que Litmus en algunos aspects.
Gremlin
Gremlin: comercial, full platform:
- GUI amigable.
- Experiment library extensa.
- Safety controls.
- Reporting detallado.
Para enterprises que quieren chaos-as-a-service.
AWS Fault Injection Service
AWS FIS: managed chaos para AWS resources.
Steadybit
Steadybit: platform comercial enfocada en experimentación.
Tipos de experimentos
Categorías:
Infrastructure
- Server kill: EC2, VM, pod termination.
- Disk fill: filesystem full.
- CPU/memory pressure: resource exhaustion.
- Network partition: cloud zones splitting.
Application
- Latency injection: slow responses.
- Error injection: 500 responses ratio.
- Dependency failure: mock downstream failure.
- Message queue drain: events backlog.
Data
- DB latency: slow queries.
- Replica lag: test read-from-replica behavior.
- Cache eviction: cold cache scenarios.
Human factor
- On-call drills: tabletop exercises.
- Runbook testing: ¿sabe equipo qué hacer?
Blast radius
Controlar impact:
- Primero: local dev. Inject chaos en test environment.
- Staging: siguiente nivel.
- Prod canary: 1% de users.
- Prod sampling: specific users opt-in.
- Prod completo: cuando confianza es alta.
Escalation gradual evita incidents serios.
Métricas y ROI
Lo que se mide:
- Incidents avoided: issues found in chaos before prod.
- MTTR reduction: equipo responde mejor por práctica.
- Runbook coverage: procedures validated.
- Resilience score: subjective/composite metric.
Casos reales:
- Netflix: chaos reduced major outages significantly.
- LinkedIn: blast radius de incidents reduced via learnings.
- Shopify: MTTR reduced by ~30% after year of chaos.
ROI difficult to measure precisely but directionally positive.
Adoption roadmap
Para empresa que empieza:
Fase 1: Culture
- Convince leadership and engineers.
- No blame, learning culture.
- Start in staging.
Fase 2: Basic experiments
- 1-2 experiments simple en staging.
- Document hypothesis, outcome, learnings.
- Share within team.
Fase 3: Production (limited)
- Experimentos en prod con blast radius 1%.
- Monitoring tight.
- Rollback immediate.
Fase 4: Continuous
- Automated chaos scheduled.
- Integrated into CI/CD.
- Game days regulares.
3-12 meses a maturity.
Game days
Exercise dedicado:
- Pick scenario: e.g. “database primary fails”.
- Schedule time: 2-4 horas.
- Execute: actual outage simulado.
- Team responds: follow runbook.
- Debrief: qué funcionó, qué no.
Game days regulares (trimestrales) mantienen skills.
Antipatterns
Cosas que no hacer:
- Chaos sin observability: no puedes aprender sin datos.
- Sin hipótesis: “let’s break stuff” no es chaos engineering.
- Sin buy-in: backfires si team no está on board.
- Blast radius grande primera vez: pierdes credibilidad con incident real.
- No documentar: aprendizaje se pierde.
Chaos engineering + SRE
Complementario con otras prácticas SRE:
- SLOs: chaos tests if error budget holds under stress.
- Post-mortems: chaos experiments test learnings.
- Runbooks: chaos validates them.
- On-call: chaos prepares engineers.
No es silo — integra con resto de cultura SRE.
Ejemplos concretos
Experimentos comunes que valen:
- Kill random pod en deployment con replicas. ¿K8s recovers?
- Network latency entre microservices. ¿Circuit breakers trigger?
- Memory pressure en DB. ¿OOM killer? ¿failover?
- DNS resolution fails. ¿App handles gracefully?
- Clock skew entre nodes. ¿Timestamps/logs consistent?
Cada uno puede descubrir bugs sutiles.
Conclusión
Chaos engineering es práctica madura y valuable para enterprises serious sobre reliability. Bien hecho (hypothesis-driven, blast radius controlled, con observability), produce incidents avoided y equipos más preparados. Mal hecho (random chaos sin plan), es ruido counterproductivo. Herramientas OSS (Litmus, Chaos Mesh) hacen adoption accesible sin comercial spend. Para equipos que ya tienen SRE basics, chaos es siguiente nivel. Para equipos sin observability o post-mortems, invertir en esos antes. Chaos sin infraestructura de aprendizaje es puro stress.
Síguenos en jacar.es para más sobre SRE, resiliencia y chaos engineering.
