Durante años, la alta disponibilidad se resumía en comprar mejores servidores, montar un clúster, añadir redundancia y confiar en que todo siguiera funcionando cuando llegara el siguiente fallo.
Netflix demostró que esa estrategia ya no era suficiente.
Hace unos 15 años empezó a apagar servidores de producción de forma completamente aleatoria. No porque estuvieran averiados, sino para comprobar si realmente su arquitectura podía soportar el fallo de cualquiera de ellos sin que ningún usuario lo notara.
Aquella herramienta recibió el nombre de Chaos Monkey y terminó dando origen a una disciplina que hoy forma parte de la ingeniería de fiabilidad moderna: Chaos Engineering.
Con Kubernetes, los microservicios, las aplicaciones distribuidas y la llegada de agentes de inteligencia artificial capaces de tomar decisiones automáticamente, provocar fallos de forma controlada está dejando de ser una curiosidad para convertirse en una práctica cada vez más recomendable.
Las claves del Chaos Engineering en 20 segundos
- Netflix creó Chaos Monkey para apagar servidores de producción de forma aleatoria.
- La idea evolucionó hacia plataformas capaces de simular latencia, caídas de redes, regiones cloud completas o problemas de almacenamiento.
- Hoy existen herramientas como AWS Fault Injection Service, LitmusChaos o Chaos Mesh que automatizan estos experimentos.
- El objetivo no es romper sistemas, sino descubrir errores antes de que lo hagan los usuarios.
El mayor error es asumir que todo va a funcionar
Todo administrador de sistemas ha escuchado alguna vez frases como:
«Tenemos alta disponibilidad.»
«Tenemos redundancia.»
«Si cae un nodo no pasa nada.»
La realidad es que muchas veces esas afirmaciones nunca se han comprobado.
El nodo secundario jamás ha asumido el servicio.
Los backups nunca se han restaurado.
La réplica de la base de datos lleva semanas con errores.
El balanceador tiene una configuración incorrecta que nadie ha detectado.
Mientras todo funciona parece que la infraestructura es robusta.
Hasta que un día deja de serlo.
Chaos Engineering parte precisamente de esa idea.
No confiar en que algo funciona.
Comprobarlo.
Chaos Monkey cambió la forma de entender la disponibilidad
Cuando Netflix migró completamente a AWS descubrió que los fallos ya no eran una excepción.
En una plataforma formada por miles de máquinas virtuales siempre había servidores entrando o saliendo de servicio.
Esperar que todos permanecieran disponibles era simplemente imposible.
Así nació Chaos Monkey.
Su funcionamiento era extremadamente sencillo.
Durante el horario laboral elegía una instancia EC2 al azar y la apagaba.
Nada más.
Si la plataforma seguía funcionando, todo iba bien.
Si aparecía una incidencia, significaba que la arquitectura todavía dependía demasiado de ese servidor.
No era un problema del experimento.
Era un problema del diseño.
Después llegaron fallos mucho más realistas
Con el tiempo Netflix comprobó que apagar servidores solo cubría una pequeña parte de los problemas reales.
Una infraestructura distribuida puede fallar de muchas maneras distintas.
Por eso apareció el conocido Simian Army, donde cada herramienta simulaba un escenario diferente.
Entre los más conocidos estaban:
- Latency Monkey, que añadía latencia artificial entre microservicios.
- Chaos Gorilla, capaz de simular la pérdida completa de una Availability Zone.
- Chaos Kong, diseñado para comprobar qué ocurría si desaparecía una región entera de AWS.
Posteriormente llegarían plataformas mucho más avanzadas como ChAP (Chaos Automation Platform) o FIT (Failure Injection Testing), donde cada experimento responde a una hipótesis concreta y se ejecuta únicamente bajo determinadas condiciones.
Ya no se trata de romper infraestructura al azar.
Se trata de validar científicamente el comportamiento del sistema.
Kubernetes ha convertido Chaos Engineering en algo mucho más útil
En un entorno tradicional los servidores podían permanecer meses sin cambios.
Hoy un clúster Kubernetes recrea contenedores constantemente.
Los pods aparecen y desaparecen.
Los nodos entran en mantenimiento.
Los servicios cambian dinámicamente.
Las aplicaciones se escalan automáticamente.
En ese escenario los fallos son parte normal del funcionamiento.
Por eso muchas organizaciones comienzan a introducir experimentos periódicos como:
- eliminar un nodo del clúster;
- reiniciar pods críticos;
- bloquear tráfico entre namespaces;
- degradar temporalmente el almacenamiento;
- provocar pérdida parcial de conectividad.
El objetivo es verificar que Kubernetes hace exactamente aquello para lo que fue diseñado.
Ya no hace falta desarrollar herramientas propias
Cuando Netflix comenzó este proyecto prácticamente no existía nada parecido.
Hoy sucede justo lo contrario.
Existen numerosas soluciones listas para utilizar.
AWS Fault Injection Service (AWS FIS)
Permite lanzar experimentos directamente sobre servicios gestionados de AWS.
Entre otras acciones puede:
- detener instancias EC2;
- introducir latencia;
- saturar CPU;
- provocar pérdida de red;
- degradar almacenamiento;
- afectar servicios ECS o EKS.
LitmusChaos
Uno de los proyectos Open Source más utilizados dentro del ecosistema Kubernetes.
Incluye decenas de experimentos preparados para validar aplicaciones cloud-native.
Chaos Mesh
Muy popular entre usuarios de Kubernetes.
Permite introducir fallos de red, CPU, memoria, I/O, DNS o procesos directamente desde Kubernetes.
Gremlin
Una plataforma comercial ampliamente utilizada por grandes empresas para automatizar programas completos de Chaos Engineering.
Qué puede probar un administrador de sistemas
No hace falta empezar simulando la caída completa de un centro de datos.
De hecho, lo recomendable es comenzar por escenarios sencillos.
Por ejemplo:
| Hipótesis | Experimento |
|---|---|
| Los pods sobreviven a la pérdida de un nodo | Apagar un worker de Kubernetes |
| El balanceador detecta servidores caídos | Finalizar una VM del backend |
| La aplicación soporta retrasos entre APIs | Introducir 500 ms de latencia |
| El clúster mantiene el quorum | Desconectar temporalmente un nodo |
| El procedimiento de recuperación funciona | Restaurar una copia completa en laboratorio |
Cada experimento debería responder siempre a tres preguntas:
- ¿Qué espero que ocurra?
- ¿Qué métricas voy a observar?
- ¿Cómo detendré el experimento si algo sale mal?
La IA también necesitará Chaos Engineering
Uno de los cambios más interesantes llegará durante los próximos años.
Cada vez más infraestructuras incorporarán agentes capaces de tomar decisiones automáticamente.
Escalado.
Balanceo.
Optimización de costes.
Recuperación automática.
Gestión energética.
Eso obligará a probar no solo la infraestructura, sino también el comportamiento de esos agentes cuando reciban información incompleta o situaciones inesperadas.
Chaos Engineering probablemente evolucionará desde validar sistemas distribuidos hasta validar también decisiones autónomas.
Lo importante no es romper servidores
Existe una idea equivocada muy extendida.
Chaos Engineering no consiste en destruir infraestructura.
Consiste en ganar confianza.
Cada fallo descubierto durante un experimento evita una posible caída futura en producción.
Cada hipótesis validada reduce incertidumbre.
Cada mejora incorporada convierte la plataforma en un sistema más resiliente.
Al final, la mejor infraestructura no es la que nunca falla.
Es aquella que sigue funcionando cuando inevitablemente algo deja de hacerlo.
Preguntas frecuentes
¿Chaos Engineering solo es útil para grandes empresas?
No. Cualquier organización con servicios críticos, máquinas virtuales, Kubernetes o aplicaciones distribuidas puede beneficiarse de realizar experimentos controlados.
¿Es seguro ejecutar estos experimentos en producción?
Sí, siempre que estén correctamente diseñados, tengan un alcance limitado y existan mecanismos automáticos para detenerlos si aparecen riesgos inesperados.
¿Qué herramientas Open Source son las más utilizadas?
Actualmente destacan LitmusChaos y Chaos Mesh para Kubernetes, además de AWS Fault Injection Service en entornos AWS y plataformas comerciales como Gremlin.
¿Qué conocimientos necesita un administrador para empezar?
Conviene conocer bien la arquitectura, la monitorización, los procedimientos de recuperación y disponer de métricas suficientes para validar objetivamente el resultado de cada experimento.
