Chaos testing sobre fuentes externas
Que el contrato prometa un resultado parcial no prueba que el sistema lo devuelva. La falla se provoca a propósito, acotada, y siempre de este lado del cable.
Por Marco Ferreiro ·
Una integración de infracciones suele declarar qué devuelve cuando una jurisdicción no contesta: estado parcial, detalle por fuente, un problema estructurado y un reintento acotado. Declararlo no es lo mismo que haberlo visto ocurrir, y la primera caída real de un portal es un mal momento para descubrir que la respuesta dice “sin infracciones”.
El chaos testing provoca de manera deliberada y acotada una falla que ya sabemos posible, para verificar si el sistema se comporta como promete. No es romper cosas al azar: es un experimento con hipótesis escrita, alcance limitado y criterio de corte.
Con dependencias externas hay una restricción que ordena todo lo demás: la falla nunca se inyecta del otro lado.
La falla se inyecta de este lado
Un portal oficial no es un banco de pruebas: no se le mandan errores a propósito, ni se le fuerza latencia, ni se le agota una cuota. La inyección ocurre en lo propio: el adaptador que habla con esa fuente, la red del entorno de prueba y el doble de la fuente, un servidor que responde en su lugar con cuerpos ya observados y despersonalizados.
Eso limita la conclusión con honestidad: el experimento no muestra cómo se comporta el portal, sino cómo responde nuestro lado ante algo que ese portal podría devolver.
Los cuerpos del doble no llevan patentes ni documentos reales: alcanza con reproducir la forma de la respuesta para disparar el camino de error.
Qué fallas vale la pena provocar
El catálogo sale de lo ya observado en producción y de lo que la especificación permite. Conviene cubrir:
- la fuente no resuelve el nombre o rechaza la conexión;
- la conexión se abre y no llega nada hasta el timeout;
- el cuerpo llega en cuentagotas y termina pasado el límite del cliente;
- la conexión se corta a mitad del cuerpo y deja un documento truncado;
- la fuente declara indisponibilidad temporal con una espera sugerida;
- la respuesta es exitosa, pero el cuerpo es una página de mantenimiento o un formulario de acceso;
- el contenido llega completo con un campo renombrado o una fecha en otro formato.
RFC 9110 fija qué comunica cada código: 503 indica indisponibilidad presumiblemente temporal, 504 que un intermediario no obtuvo respuesta a tiempo, y 200 que la solicitud fue exitosa, no que el contenido sea el esperado. El éxito con cuerpo equivocado es el caso más caro: sólo aparece si algo mira el cuerpo, como desarrollamos en errores disfrazados.
Una hipótesis por experimento
Un experimento sin criterio de falla es una demostración. Escribí la hipótesis primero y en términos observables: si la fuente deja de responder durante una ventana definida, la consulta debe devolver las actas de las demás fuentes, marcar esa como no consultada, publicar un problema con un tipo estable y no afirmar en ningún campo que no hay infracciones.
Después se corre para falsarla. No alcanza con que el proceso siga en pie. Se miran cuatro superficies: el estado que recibe el cliente, el texto que lee una persona, la telemetría y el log. RFC 9457 define un formato de problema con tipo, título y detalle; el experimento comprueba que ese tipo existe, es estable y no cambia según el proveedor que falló.
El encuadre se define antes: entorno de prueba, duración fija, interruptor y alguien mirando. La guía de contingencia del NIST ubica las pruebas y los ejercicios como un paso del plan y no como un anexo, y les asigna funciones distintas: la prueba valida la capacidad de recuperación y el ejercicio expone los huecos de planificación. La guía de recuperación de AWS llega a lo mismo desde el otro lado: el único camino de recuperación que funciona es el que se ejercita seguido, porque el que casi nunca se ejecuta acumula supuestos vencidos.
Los efectos que conviene desconectar antes
Una corrida puede ensuciar más de lo que mide. Antes de inyectar nada se desactivan las notificaciones, los envíos a endpoints de clientes y todo consumo con costo. Queda un efecto menos visible y más dañino: la métrica de disponibilidad de la fuente doblada. Si la caída simulada se cuenta junto a las reales, la próxima decisión de cobertura se apoya en un dato falso que sobrevive al ensayo. Marcamos ese tráfico en el origen y lo excluimos de los tableros.
Qué queda después de la corrida
Un hallazgo que sólo vive en la memoria del equipo vuelve meses después. Cada respuesta que rompió algo se guarda como fixture sin datos personales y entra en la suite automática; el arreglo viaja con la prueba que lo sostiene.
También se registra el experimento: hipótesis, qué se inyectó y dónde, qué se observó en cada superficie y qué acción quedó abierta. Así la corrida se repite idéntica después del arreglo y sobre cada versión nueva.
Antes de la primera corrida, verificá que el entorno no pueda alcanzar una fuente oficial real; que haya un interruptor para cortar; que la telemetría distinga el tráfico del ensayo; que notificaciones y cargos estén desconectados; y que la hipótesis esté escrita de antemano, porque una redactada después siempre se cumple.
Metodología
- Alcance
- Diseño de experimentos de falla controlada sobre dependencias externas de una consulta de infracciones. No cubre pruebas de capacidad, auditorías de seguridad ni el comportamiento interno de un portal oficial.
- Unidad de análisis
- Un experimento: una falla inyectada en un punto propio, durante una ventana definida, contra una hipótesis escrita de antemano.
- Cobertura
- Semántica de códigos y de respuestas de error derivada de los estándares HTTP citados, encuadrada en la práctica general de ejercitar planes de contingencia y recuperación que describen las guías citadas.
Limitaciones
- El experimento observa el comportamiento propio ante una respuesta simulada; no permite concluir nada sobre la disponibilidad real del portal doblado.
- Un doble reproduce las respuestas ya conocidas: una falla nunca vista antes queda fuera del catálogo hasta que alguien la observa.
- El alcance, la duración y los criterios de corte dependen de la infraestructura de cada equipo y no se trasladan sin recalibrar.
Fuentes
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
- RFC 9457 — Problem Details for HTTP APIs — RFC Editor (consultada el )
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — National Institute of Standards and Technology (consultada el )
- Disaster Recovery of Workloads on AWS — Amazon Web Services (consultada el )
Preguntas frecuentes
¿El chaos testing se hace contra el portal oficial de la jurisdicción?
No. Un organismo público no es un banco de pruebas: no se le fuerzan errores, latencia ni consumo de cuota. La falla se inyecta en el adaptador propio, en la red del entorno de prueba o en un doble que responde en lugar de la fuente.
¿En qué se diferencia de una prueba de carga?
Una prueba de carga busca el límite de capacidad con volumen y concurrencia. El chaos testing no busca saturar: provoca una falla puntual y verifica si la degradación declarada en el contrato ocurre de verdad, con el estado, el mensaje y la telemetría esperados.
¿Se puede correr en producción?
Conviene empezar en un entorno de prueba, aunque descartar producción para siempre tampoco sale gratis: la guía de recuperación de AWS sostiene que un camino de recuperación crítico necesita ejecutarse de forma periódica en producción para saber que funciona. Eso vale para el camino propio, nunca para la fuente externa, y pide alcance chico, duración fija, interruptor y observación en vivo. Sin efectos desconectados y sin tráfico marcado, puede ensuciar métricas o alcanzar a usuarios reales.
¿Qué se hace con lo que encuentra el experimento?
La respuesta que rompió algo se guarda como fixture sin datos personales y entra en la suite automática, junto con el arreglo. Si el hallazgo no queda escrito como prueba de regresión, vuelve a aparecer en la próxima caída.
Notas relacionadas
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.
Cómo diseñar un sandbox de API útil sin usar patentes ni personas reales
Un entorno de prueba sirve cuando reproduce decisiones y fallas del contrato, no cuando copia expedientes de producción. Los escenarios deterministas hacen posible probar sin PII.
Circuit breaker sobre una fuente inestable
Cuando un portal empieza a fallar, insistir empeora las dos puntas. Un corte deliberado y temporal de las llamadas a esa fuente protege al organismo y devuelve antes una respuesta honesta.