Protocolo de reproducibilidad para pruebas de carga en producción

Una plataforma puede comportarse de forma estable en horario normal y degradarse cuando coincide el cierre de mes con un proceso batch o cuando la campaña de mayor demanda concentra tráfico en pocas horas. La prueba de carga existe para anticipar ese comportamiento, pero su utilidad como evidencia depende de una condición que rara vez se formaliza: que la corrida sea reproducible y atribuible al sistema bajo prueba. Sin esa condición, el informe describe un momento, no la capacidad de la aplicación.

Este artículo no trata sobre qué preguntas debe responder una prueba ni sobre quién autoriza la salida a producción. Define un protocolo operativo para declarar una corrida como válida o inválida como evidencia: qué variables deben quedar fijas entre ejecuciones, cómo separar el comportamiento de la aplicación del ruido del entorno y cuándo corresponde descartar el resultado y repetir la prueba.

Condiciones de repetición: las variables que deben quedar fijas entre corridas

Una corrida es repetible cuando puede volver a obtenerse bajo condiciones equivalentes. Esa equivalencia no se declara: se verifica sobre un conjunto acotado de variables que deben permanecer idénticas entre ejecuciones. Si alguna cambia, la comparación pierde sentido y el resultado deja de ser atribuible.

Las variables de control mínimas son cuatro:

• Entorno de ejecución: versiones de la aplicación, configuración de parámetros, topología de red y límites de recursos (CPU, memoria, conexiones). Un cambio de versión o de configuración entre corridas impide saber si la diferencia proviene del sistema o del ajuste.
• Perfil de carga: rampa de subida, mezcla de operaciones, distribución de usuarios concurrentes y duración de la meseta. El perfil debe estar documentado de forma que otra persona pueda reproducirlo sin interpretación.
• Dataset de prueba: volumen, distribución y estado de los datos. Un dataset que crece entre corridas o que se degrada por escrituras acumuladas altera el comportamiento del sistema sin que el estímulo haya cambiado.
• Instrumentación: métricas recolectadas, puntos de medición y percentiles reportados. Cambiar la forma de medir entre corridas invalida la comparación aunque el sistema no haya cambiado.

Estas variables se documentan antes de ejecutar, no después. Un protocolo reconstruido a partir del informe es un protocolo que no se aplicó. La consecuencia práctica es directa: si el equipo no puede declarar el valor de cada variable para dos corridas consecutivas, no tiene base para compararlas.

Atribución: cómo separar el comportamiento de la aplicación del ruido del entorno

Reproducir una corrida no basta. El resultado debe poder atribuirse a la aplicación y no a un componente externo que se comportó de forma distinta entre ejecuciones. La atribución se construye instrumentando las dependencias, no solo el front de la aplicación.

Cuando la base de datos, la caché, el balanceador o un servicio de terceros no se miden, el resultado refleja una combinación indeterminada de factores. Si la latencia sube entre corridas, no se puede saber si el cuello de botella está en la aplicación, en la base de datos o en la red. La atribución exige que cada salto relevante del flujo tenga su propia medición y que esa medición sea comparable entre corridas.

Tres señales permiten verificar la atribución:

• Consistencia de percentiles: si el P95 y el P99 se mantienen estables entre corridas equivalentes mientras el promedio fluctúa, la cola está bajo control. Si los percentiles cambian de forma significativa sin cambio de perfil, hay una variable no controlada.
• Tasa de error estable: una tasa de error que aparece y desaparece sin cambio de estímulo indica que algo fuera del sistema bajo prueba influye en el resultado.
• Comportamiento consistente en rampa y bajada: reconexiones, acumulación de colas o tiempos de estabilización que varían entre corridas apuntan a condiciones del entorno que no se replicaron.

La atribución no es una conclusión del informe: es una propiedad del diseño de la prueba. Si las dependencias no se instrumentaron desde el inicio, no se puede recuperar después.

Criterios de invalidación: cuándo una corrida no sirve como evidencia

Un protocolo de reproducibilidad necesita reglas explícitas para descartar corridas, no solo para aceptarlas. Sin criterios de invalidación, cualquier resultado se interpreta como válido y la prueba pierde valor como evidencia.

Una corrida debe invalidarse cuando se cumple al menos una de estas condiciones:

1. Dispersión alta entre corridas equivalentes: dos ejecuciones con el mismo perfil arrojan latencias o tasas de error que difieren más allá de la tolerancia definida. La conclusión no es que el sistema es variable, sino que la prueba no está midiendo lo que cree medir.
2. Dependencias no instrumentadas: no se midió un componente relevante del flujo y no se puede descartar su influencia en el resultado.
3. Cambio de perfil o de medición entre corridas: el estímulo o la forma de medir variaron, aunque sea de forma parcial.
4. Errores no atribuibles: la tasa de error no se explica por el comportamiento del sistema bajo prueba ni por una condición conocida del entorno.
5. Entorno no equivalente: versiones, configuración o dataset difieren entre corridas sin que esa diferencia esté declarada y justificada.

Invalidar una corrida no es un fracaso del equipo: es el resultado esperado de aplicar el protocolo. Una corrida invalidada identifica qué variable falta controlar antes de repetir. Lo que no es aceptable es presentar una corrida invalidada como evidencia de capacidad.

Protocolo mínimo para declarar una corrida reproducible

Con las variables de control, los criterios de atribución y las reglas de invalidación definidos, el protocolo se reduce a una secuencia verificable:

1. Documentar las variables de control antes de ejecutar: entorno, perfil, dataset e instrumentación, con sus valores para esa corrida.
2. Ejecutar al menos dos corridas equivalentes y comparar resultados contra la tolerancia definida.
3. Verificar la atribución: confirmar que las dependencias relevantes están instrumentadas y que sus mediciones son comparables entre corridas.
4. Aplicar los criterios de invalidación: si se cumple alguno, la corrida se descarta y se identifica la variable a corregir.
5. Registrar la declaración: corrida válida o inválida, con la variable que motivó la decisión y la acción de corrección asociada.

Este protocolo no decide si el sistema está listo para producción; decide si el resultado puede sostenerse como evidencia reproducible. La decisión de salida es un paso posterior y se apoya en un resultado que ya pasó el filtro de validez.

Para equipos que necesitan estructurar esta evaluación con criterios verificables y repetibles, el servicio de Stress & Performance aborda la brecha entre funcionar en condiciones normales y resistir el tráfico real con resultados que permiten sostener una decisión técnica.

La diferencia entre un informe tranquilizador y una evidencia defendible no está en el volumen de la prueba, sino en la capacidad de repetirla, atribuirla y descartarla cuando no cumple las condiciones. Ese es el criterio que convierte una corrida en algo que un equipo de infraestructura puede sostener ante una decisión de producción.