¿Qué es la ingeniería del caos, y por qué querrías romper deliberadamente sistemas similares a producción?

#No es "romper cosas y ver qué pasa"

La ingeniería del caos suele caricaturizarse como imprudencia —provocar deliberadamente una caída en producción suena como lo opuesto a una buena práctica de ingeniería— hasta que te fijas en la definición real: la ingeniería del caos es la disciplina de experimentar sobre un sistema para generar confianza en su capacidad de resistir condiciones turbulentas en producción. La palabra que hace todo el trabajo ahí es "experimentar". Un experimento tiene una hipótesis, un control, una medición y una forma de fallar de manera segura; sin esas cuatro cosas no estás haciendo ingeniería del caos, solo estás provocando una caída a propósito y llamándolo práctica.

El método tiene cuatro pasos, y saltarse el primero es la forma más común en que los equipos lo hacen mal:

1. Definir una hipótesis de estado estable (steady state) — elegir una salida medible que represente el comportamiento normal del sistema. No "el sistema está arriba", sino algo con un número asociado: la tasa de éxito del checkout se mantiene por encima del 99.5%, la latencia p99 de la API se mantiene bajo 300ms, el throughput de procesamiento de órdenes se mantiene dentro del 10% de la línea base móvil. Sin esto no tienes forma de distinguir "el sistema toleró la falla" de "el sistema está ardiendo ahora mismo y nadie está mirando el dashboard correcto".
2. Formular la hipótesis de que el estado estable se mantiene tanto en el grupo de control como en el experimental — es decir, predecir que inyectar la falla no moverá la métrica fuera de su rango normal. Este enfoque importa: estás intentando refutar que el sistema es resiliente, no intentando probarlo. Un buen experimento es falsable.
3. Introducir una variable del mundo real — matar un proceso, inyectar latencia, saturar un recurso, quitar una dependencia— algo que de todos modos podría pasar en producción, no un acto arbitrario de destrucción.
4. Intentar refutar la hipótesis comparando el estado estable entre los dos grupos. Si se mantiene, ganaste evidencia —no prueba, evidencia— de que el sistema tolera esa falla específica. Si se rompe, encontraste una debilidad real, en una ventana controlada, con un plan de rollback ya en la mano, en lugar de encontrarla durante un incidente real a las 3 de la mañana.

#Qué inyectas en realidad, y qué demuestra cada cosa

Cada fila existe porque la alternativa —confiar en que la redundancia, los reintentos, los circuit breakers y el failover "deberían" funcionar porque están configurados— es exactamente el supuesto que falla en un incidente real. Un circuit breaker con un umbral que nunca se probó contra latencia real es un pedazo de código que se ve correcto y que jamás se ha abierto de verdad.

#La disciplina es lo que hace que esto sea seguro de hacer

Nada de esto funciona —y buena parte se vuelve activamente peligroso— sin disciplina de radio de impacto: empezar en una sola instancia, en staging o en horas de bajo tráfico, con una condición de aborto automática conectada a la misma métrica de estado estable que estás probando, y un interruptor que detenga el experimento en el instante en que la métrica se salga de los límites. Netflix no inventó Chaos Monkey matando servidores de producción al azar sin ningún plan: primero construyeron la disciplina de medir el estado estable y de abortar automáticamente, y solo ampliaron el radio de impacto a medida que crecía la confianza en las herramientas, hasta eventualmente llegar a fallas de regiones completas con Chaos Kong.

Los GameDays son el hermano manual y programado de las herramientas de caos automatizadas: un ejercicio entre equipos, anunciado con anticipación, donde se simula un escenario de falla específico (a veces literalmente una persona apretando un interruptor, a veces corriendo en vivo un experimento automatizado) y se pone a prueba tanto la respuesta de la organización como la del sistema: si a la persona correcta le llega la alerta, si el runbook coincide con lo que realmente es cierto, si el rol de incident commander funciona en la práctica, si el proceso de actualizar el status page es lo bastante rápido. Un sistema puede pasar todos los experimentos de caos automatizados y aun así fallar gravemente en un incidente real si nunca se ensayaron las personas y el proceso a su alrededor.

La mayoría de las organizaciones sube una escalera de madurez más o menos así: ninguna prueba de caos → GameDays manuales ocasionales → experimentos de caos automatizados en staging → caos automatizado en producción con criterios estrictos de aborto y un interruptor de emergencia → caos continuo como una puerta permanente en el pipeline de despliegue, donde un servicio no se considera listo para producción hasta que sobrevive su batería estándar de fallas. En qué punto de esa escalera estás es en sí misma una respuesta legítima en una entrevista: muy pocas organizaciones reales están en la cima, y saber por qué (confianza organizacional, madurez del on-call, el costo de los falsos positivos) importa más que recitar la escalera de memoria.