¿Cómo es el testing de caos y resiliencia cuando forma parte del CI en lugar de ser un GameDay puntual?
Los GameDays prueban la resiliencia una vez por trimestre; el chaos testing en CI la prueba en cada commit, con una hipótesis de estado estable, un radio de impacto y un rollback automático.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo es el testing de caos y resiliencia cuando forma parte del CI en lugar de ser un GameDay puntual?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Del GameDay a una etapa del pipeline
Un GameDay es ingeniería del caos como teatro: una sala llena de personas, un canal de guerra, un facilitador que apaga una réplica de base de datos un martes a las dos de la tarde, y todo el equipo mirando dashboards para ver si el sistema se cae. Tiene valor — genera memoria muscular en el equipo y descubre sorpresas sistémicas reales — pero ocurre una vez por trimestre, ataca lo que a los organizadores se les ocurrió ese día, y depende por completo de que alguien se acuerde de repetirlo cuando el sistema que hay debajo haya cambiado.
El chaos testing integrado en CI convierte la misma idea en una etapa de pipeline repetible y automática que corre en cada despliegue (o cada noche, o en cada merge a main), sin humanos en el bucle, con una decisión de aprobado/rechazado automática. Es la diferencia entre "demostramos una vez que el sistema era resiliente" y "el sistema no puede perder resiliencia sin que un build se ponga en rojo".
#La hipótesis de estado estable
Todo experimento de caos automatizado arranca igual que un experimento científico: definir qué es "normal" antes de tocar nada. Eso significa elegir señales reales y medibles — latencia p99 por debajo de cierto umbral, tasa de error por debajo de cierto porcentaje, throughput dentro de una banda alrededor de la línea base — no una sensación vaga de que "las cosas se ven bien". El experimento luego inyecta una falla, sigue midiendo las mismas señales durante y después, y pasa solo si la hipótesis de estado estable se sostiene dentro de tolerancia todo el tiempo.
#Qué se automatiza
- Inyección de fallas: matar pods o instancias, inyectar latencia de red o pérdida de paquetes, saturar CPU o memoria, bloquear el acceso a una dependencia, inyectar HTTP 500 o timeouts a través de las funciones de fault injection de un service mesh (Istio/Envoy), simular la caída de una zona de disponibilidad o región.
- Medición del estado estable: consultar el mismo backend de observabilidad (Prometheus, Datadog, u otro similar) que ya alimenta los dashboards de SLO en producción — no hay un pipeline de métricas aparte "solo para caos" que mantener.
- Control del radio de impacto: empezar con un porcentaje pequeño de pods o de tráfico, limitar el alcance y la duración del experimento, y darle una condición de aborto automática.
- Veredicto y rollback: si el estado estable se rompe más allá del umbral, la etapa del pipeline falla, la falla se revierte automáticamente, el despliegue se bloquea y se alerta a la guardia — exactamente igual que cualquier otro gate de test que falla.
#Dónde vive en el pipeline
Normalmente esto no va en el camino rápido de "cada commit debe pasar en 90 segundos". Los experimentos de caos suelen correr después de que pasan los tests unitarios y de integración, y el build ya se desplegó a un entorno de staging o preproducción — a veces un canary de baja proporción de tráfico en producción — como una etapa dedicada antes de promover a tráfico completo de producción.
#GameDay vs. chaos testing en CI
| Aspecto | GameDay | Chaos en CI |
|---|---|---|
| Cadencia | Trimestral / puntual | Cada despliegue / cada noche |
| Quién lo ejecuta | Personas, de forma programada | El pipeline, de forma automática |
| Alcance | Lo que se le ocurra a los organizadores | Codificado a partir de incidentes pasados y dependencias clave |
| Aprobado/rechazado | Post-mortem subjetivo | Gate automático contra métricas de estado estable |
| Valor | Memoria muscular del equipo, descubre incógnitas reales | Evita que huecos de resiliencia conocidos regresionen |
#Convertir incidentes en tests de regresión permanentes
El uso de mayor apalancamiento del chaos testing en CI es este: cada vez que un post-mortem identifica un hueco de resiliencia — un timeout que faltaba, una tormenta de reintentos, un circuit breaker que nunca se abrió — ese modo de falla exacto se codifica como un experimento automático permanente. El arreglo ya no depende de "nos acordamos de tener cuidado la próxima vez"; depende de que el pipeline reviente el build si eso llega a regresionar, la misma disciplina que ya aplica cuando un fix de bug siempre llega acompañado de un test.
En una entrevista, la versión más sólida de esta respuesta nombra las tres piezas explícitamente: una hipótesis de estado estable atada a métricas reales, una etapa automatizada de inyección de fallas integrada en el pipeline con controles de radio de impacto, y un bucle de retroalimentación que convierte cada incidente pasado en un test de regresión permanente y automático, en lugar de una lección que solo vive en un documento de post-mortem.