Curiosidades QA — Día 3 de 7 Esta semana publico una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
Romper para que no se rompa
En 2011, Netflix creó una herramienta llamada Chaos Monkey. Su trabajo era simple: elegir servidores al azar en producción y apagarlos. Sin aviso. En horario laboral.
No era un bug. No era un accidente. Era una decisión deliberada.
La idea detrás es contraintuitiva: si tu sistema no sobrevive a que una pieza desaparezca, entonces no es resiliente — solo está teniendo suerte.
Chaos Monkey fue solo el principio
Después de Chaos Monkey, Netflix creó toda una familia de herramientas de destrucción:
- Latency Monkey — inyecta retrasos artificiales en las comunicaciones entre servicios
- Conformity Monkey — encuentra instancias que no siguen las mejores prácticas y las apaga
- Chaos Kong — simula la caída de una región completa de AWS (no un servidor, una región entera)
- Chaos Gorilla — apaga una zona de disponibilidad completa
Lo llamaron The Simian Army (el ejército de simios). Y cada uno tiene un trabajo: encontrar debilidades antes de que un incidente real las encuentre.
¿Por qué en producción? Porque staging miente. Un ambiente de staging no tiene el mismo tráfico, los mismos datos, ni las mismas condiciones que producción. Si quieres saber si tu sistema aguanta, tienes que probarlo donde la realidad no perdona.
Cómo funciona en la práctica
Chaos Engineering no es “apagar cosas a lo loco”. Tiene un método:
1. Define el estado normal
Antes de romper algo, necesitas saber qué significa “funciona bien”. Netflix mide: latencia de respuesta, tasa de error, número de streams iniciados por segundo. Si no sabes qué es “normal”, no puedes detectar “anormal”.
2. Genera una hipótesis
“Si apagamos el servicio de recomendaciones, el usuario debería ver una lista genérica en vez de una pantalla de error.” Esa es la hipótesis. Si no se cumple, encontraste un problema.
3. Rompe algo de forma controlada
Apaga un servidor. Inyecta latencia. Corta la conexión a una base de datos. Pero hazlo de forma que puedas revertir rápido si el impacto es mayor de lo esperado.
4. Observa qué pasa
¿El sistema se recuperó solo? ¿El usuario notó algo? ¿Las alarmas se dispararon? ¿El equipo se enteró? Si la respuesta a alguna de estas es “no” cuando debería ser “sí” — tienes un hallazgo.
Lo que Netflix descubrió rompiéndose a sí mismo
Algunos hallazgos reales que encontraron gracias a Chaos Engineering:
- Servicios que dependían de otros servicios sin timeout — cuando uno se caía, arrastraba a los demás
- Cachés que parecían opcionales pero en realidad eran críticos — sin ellos, la latencia se multiplicaba por 10
- Alarmas que no se disparaban porque los umbrales estaban mal configurados
- Equipos que no sabían que su servicio dependía de otro que mantenía un equipo diferente
Ninguno de estos problemas habría aparecido en un test funcional. Ni en staging. Ni en un code review. Solo aparecen cuando el sistema está bajo estrés real.
¿Qué tiene que ver esto contigo?
No necesitas ser Netflix para pensar en resiliencia. Las preguntas de Chaos Engineering aplican a cualquier escala:
- ¿Qué pasa si la base de datos tarda 10 segundos en responder? ¿Tu app muestra un error o un loading infinito?
- ¿Qué pasa si la API de pagos no está disponible? ¿El usuario pierde su carrito?
- ¿Qué pasa si el servicio de email se cae? ¿El registro se queda en un estado inconsistente?
- ¿Qué pasa si alguien despliega una versión rota? ¿Hay rollback automático?
No necesitas Chaos Monkey. Necesitas hacerte estas preguntas antes de que la realidad te las haga a las 3am un sábado.
La reflexión
La mayoría de los equipos testean que las cosas funcionen. Netflix testea que las cosas sigan funcionando cuando algo falla.
Esa diferencia de mentalidad es la que separa un sistema frágil de uno resiliente. Y no requiere herramientas sofisticadas — requiere un cambio de pregunta:
En vez de “¿funciona?” → “¿qué pasa cuando deja de funcionar?”
Si esa pregunta no tiene respuesta en tu equipo, ahí tienes tu próximo caso de prueba.
Mañana: ¿Sabías que el 40% de los bugs no los encuentran los QA? → Día 4