Netflix tomó hace más de una década una decisión que, vista desde fuera, parecía completamente irracional: empezar a romper voluntariamente su propia infraestructura de producción.
No lo hizo porque estuviera sufriendo caídas constantes ni porque quisiera poner a prueba a sus ingenieros. Lo hizo porque entendió una realidad que hoy comparten prácticamente todas las grandes plataformas cloud: los fallos son inevitables.
La pregunta nunca fue si un servidor dejaría de funcionar, sino qué ocurriría cuando eso sucediera.
De aquella idea nació Chaos Monkey, probablemente el proyecto de ingeniería de fiabilidad más influyente de la computación moderna. Quince años después, sus principios siguen más vivos que nunca y han terminado influyendo incluso en servicios gestionados de AWS, Azure, Google Cloud y en la forma en que se diseñan las aplicaciones distribuidas.
Las claves del Chaos Engineering en 20 segundos
- Netflix creó Chaos Monkey para apagar servidores de producción de forma aleatoria.
- El objetivo era descubrir debilidades antes que los usuarios.
- La iniciativa evolucionó hacia plataformas capaces de simular caídas de regiones completas, latencia o problemas de red.
- Hoy AWS, Kubernetes y muchas empresas incorporan estas técnicas como parte habitual de la ingeniería de fiabilidad.
- La llegada de la IA y los sistemas autónomos hará que probar fallos controlados sea todavía más importante.
Durante años, la alta disponibilidad se entendía como construir infraestructuras «que nunca fallaran».
Hoy sabemos que esa premisa es imposible.
Los discos fallan.
Los switches dejan de responder.
Las bases de datos sufren bloqueos.
Las regiones cloud pueden experimentar incidencias.
Incluso el software perfectamente desarrollado contiene errores que solo aparecen bajo determinadas condiciones.
La diferencia entre una arquitectura robusta y otra frágil no está en evitar todos esos problemas.
Está en cómo responde cuando ocurren.
¿Qué es realmente Chaos Engineering?
Chaos Engineering es una disciplina que consiste en introducir fallos controlados dentro de un sistema para comprobar que éste sigue funcionando correctamente.
No se trata de romper servidores por diversión.
Cada experimento parte de una hipótesis.
Por ejemplo:
«Si perdemos un nodo Kubernetes, los usuarios no deberían notar ninguna interrupción.»
O bien:
«Si aumenta la latencia entre dos microservicios, la aplicación debe seguir respondiendo gracias a los mecanismos de timeout y retry.»
Después se provoca deliberadamente ese fallo.
Si el sistema continúa funcionando, la hipótesis era correcta.
Si no lo hace, se acaba de descubrir un problema… antes que los clientes.
Ese es precisamente el enorme valor del Chaos Engineering.
Cómo nació Chaos Monkey
Todo comenzó después de que Netflix migrara desde su infraestructura tradicional hacia Amazon Web Services (AWS).
La arquitectura había pasado de unos pocos servidores a miles de instancias distribuidas.
En ese nuevo escenario aparecía un problema completamente diferente.
Ya no era realista pensar que todos los servidores estarían siempre disponibles.
Cada día alguno fallaría.
La solución fue extraordinariamente sencilla.
Crear un programa que eligiera máquinas virtuales al azar y las apagara durante el horario laboral.
¿Por qué precisamente durante el día?
Porque todos los ingenieros estaban trabajando.
Si algo fallaba, podrían verlo inmediatamente.
Si la aplicación dejaba de responder, el problema no era Chaos Monkey.
Era la arquitectura.
Del mono al ejército completo
Netflix pronto descubrió que apagar servidores solo representaba uno de los muchos tipos de fallo posibles.
Así nació el Simian Army.
Cada herramienta simulaba un problema distinto.
Chaos Monkey
El más conocido.
Finalizaba instancias EC2 aleatoriamente para comprobar que la aplicación podía sobrevivir sin ellas.
Latency Monkey
Introducía retrasos artificiales entre servicios.
Era especialmente útil en arquitecturas de microservicios, donde unas pocas decenas de milisegundos adicionales pueden multiplicarse rápidamente.
Chaos Gorilla
Simulaba la pérdida completa de una Availability Zone de AWS.
Es decir, una zona física entera del centro de datos dejaba de existir.
La aplicación debía continuar funcionando desde otra zona.
Chaos Kong
Llevaba el experimento al extremo.
Simulaba la desaparición completa de una región cloud.
Era una prueba crítica para comprobar estrategias multirregión.
Otros «monkeys»
Netflix desarrolló posteriormente herramientas orientadas a detectar:
- recursos infrautilizados;
- configuraciones incorrectas;
- problemas de seguridad;
- dependencias inesperadas;
- servicios huérfanos.
Con el paso del tiempo dejaron incluso de hablar de «monos».
El objetivo ya no era provocar fallos.
Era realizar experimentos científicos sobre el comportamiento del sistema.
Chaos Engineering moderno: ChAP y FIT
Netflix sustituyó progresivamente Simian Army por plataformas mucho más sofisticadas.
Entre ellas destacan:
- ChAP (Chaos Automation Platform).
- FIT (Failure Injection Testing).
En lugar de lanzar ataques aleatorios, permiten definir experimentos muy concretos.
Por ejemplo:
«¿Qué ocurre si el servicio de autenticación responde dos segundos más tarde?»
O bien:
«¿Cómo afecta perder un 25% del tráfico de una base de datos?»
Cada experimento tiene:
- una hipótesis;
- métricas;
- criterios de éxito;
- mecanismos automáticos para detener la prueba si aparecen efectos inesperados.
Es exactamente el mismo método científico aplicado a la infraestructura.
AWS convirtió la filosofía en un servicio
Las ideas de Netflix terminaron influyendo directamente en la industria cloud.
Hoy Amazon ofrece AWS Fault Injection Service (AWS FIS), un servicio administrado que permite realizar este tipo de experimentos sin desarrollar herramientas propias.
Con AWS FIS pueden simularse escenarios como:
- apagado de instancias EC2;
- pérdida de conectividad;
- aumento de latencia;
- consumo extremo de CPU;
- fallos de almacenamiento;
- interrupciones sobre Amazon ECS;
- incidencias en clústeres Amazon EKS;
- degradaciones de bases de datos.
La diferencia respecto a 2011 es enorme.
Netflix tuvo que construir toda la plataforma desde cero.
Hoy cualquier organización puede comenzar en pocas horas.
Kubernetes ha hecho todavía más importante esta filosofía
En un entorno basado en máquinas virtuales, los componentes cambiaban relativamente poco.
Con Kubernetes ocurre justo lo contrario.
Los pods aparecen y desaparecen constantemente.
Los contenedores se recrean.
Los nodos entran y salen del clúster.
Los balanceadores modifican continuamente el tráfico.
La infraestructura es dinámica por definición.
Eso convierte Chaos Engineering en una herramienta todavía más valiosa.
Ya no basta con comprobar que una aplicación funciona.
Hay que demostrar que sigue funcionando cuando el entorno cambia constantemente.
La IA añade un nuevo nivel de complejidad
El siguiente gran salto llegará con los agentes de inteligencia artificial.
Cada vez más plataformas delegarán decisiones en sistemas autónomos.
Balanceo de carga.
Escalado automático.
Asignación de recursos.
Resolución de incidencias.
Optimización energética.
En ese contexto ya no solo habrá que validar el software.
También habrá que comprobar cómo responde la propia IA cuando recibe información incompleta, contradictoria o errónea.
Probablemente veremos aparecer durante los próximos años una nueva generación de herramientas de Chaos Engineering específicamente diseñadas para validar agentes inteligentes.
Cómo empezar con Chaos Engineering
No hace falta ser Netflix.
Un buen programa de Chaos Engineering suele comenzar con experimentos muy sencillos.
Algunos ejemplos:
| Hipótesis | Experimento |
|---|---|
| El servicio soporta perder un nodo | Apagar una máquina virtual |
| Kubernetes redistribuye correctamente los pods | Drenar un nodo del clúster |
| La aplicación soporta alta latencia | Introducir retrasos artificiales |
| La base de datos replica correctamente | Desconectar temporalmente un nodo secundario |
| Los backups permiten recuperar el servicio | Restaurar periódicamente un entorno completo |
Lo importante es avanzar poco a poco.
Nunca comenzar con escenarios extremos.
Y medir absolutamente todo.
La resiliencia no aparece cuando llegan los problemas
Existe una idea que resume perfectamente toda esta disciplina.
La resiliencia no se demuestra en los diagramas de arquitectura.
Se demuestra cuando la infraestructura empieza a romperse.
Chaos Engineering cambió completamente la forma de entender la alta disponibilidad.
En lugar de preguntarse:
«¿Funcionará?»
La pregunta pasó a ser:
«¿Qué ocurrirá cuando deje de funcionar?»
Y esa probablemente siga siendo la mejor pregunta que puede hacerse cualquier equipo de infraestructura en la era del cloud, Kubernetes y la inteligencia artificial.
Preguntas frecuentes
¿Chaos Engineering consiste en romper servidores?
No. Consiste en realizar experimentos controlados para comprobar cómo responde un sistema ante fallos previamente definidos.
¿Es necesario hacerlo únicamente en grandes empresas?
No. Hoy existen herramientas como AWS Fault Injection Service, LitmusChaos o Chaos Mesh que permiten comenzar incluso en infraestructuras pequeñas.
¿Se ejecutan estos experimentos en producción?
Sí, aunque siempre de forma controlada, limitada y con mecanismos automáticos para detener el experimento si aparecen riesgos inesperados.
¿Por qué será todavía más importante con la IA?
Porque los sistemas autónomos tomarán decisiones sobre infraestructuras complejas. Será necesario comprobar no solo que el software funciona, sino que esos agentes reaccionan correctamente cuando aparecen fallos reales.
