Señales de una prueba de carga que se leen mal antes de autorizar producción

Autorizar el paso a producción después de una prueba de carga es una decisión de riesgo, no un trámite. Muchas veces la prueba entrega datos correctos, pero se interpretan con sesgo optimista: se mira el promedio, se ignora la cola de latencia, se acepta un error rate "bajo" sin contexto y se firma el go-live con una confianza que el propio informe no respalda.

Este artículo no repite qué debería responder una prueba de carga. Se enfoca en lo complementario: qué señales se leen mal con más frecuencia y cómo evitar que esa mala lectura termine en una autorización con falsa confianza. Está dirigido a quien firma el paso a producción —gerencia TI, jefatura de infraestructura, operaciones, continuidad o ciberseguridad—, no a quien ejecuta la prueba.

El promedio de latencia es la señal más engañosa del informe

Un informe que reporta "latencia promedio 320 ms" bajo carga puede ser técnicamente correcto y operativamente inútil. El promedio esconde la distribución. Un sistema con p50 de 200 ms y p99 de 4 segundos tiene un promedio que se ve sano, pero un 1% de usuarios esperando cuatro segundos en cada operación. En tráfico real, ese 1% se concentra en los flujos críticos: login, pago, confirmación, consulta de saldo.

Qué conviene mirar en lugar del promedio:

• Percentiles altos (p95, p99, p99.9) por endpoint, no agregados globales. Un p99 global puede verse bien mientras un endpoint específico tiene p99 de 8 segundos.
• Distribución, no solo el valor. Si el informe no muestra histograma o al menos varios percentiles, la lectura es incompleta.
• Latencia por tipo de operación. Lecturas y escrituras se comportan distinto bajo carga; mezclarlas oculta el cuello de botella.
• Tiempo de espera en cola vs. tiempo de procesamiento. Un p99 alto puede venir de saturación de pool de conexiones, no de la aplicación.

Si el informe solo entrega promedio y máximo, la decisión se está tomando con información insuficiente, aunque la prueba haya corrido sin errores.

"No se cayó" no es lo mismo que "sostiene la carga"

Una prueba que termina sin caídas ni errores visibles puede estar validando muy poco. Tres patrones producen esta falsa sensación de seguridad:

Throughput estancado con latencia creciente. El sistema no falla, pero deja de procesar más transacciones por segundo mientras la latencia sube. Eso indica saturación: llegó a su techo y todo lo que entra de más se acumula. Si el informe no muestra la curva de throughput vs. concurrencia, no se puede saber si el sistema tiene margen o ya está en el codo.

Errores absorbidos por reintentos. Un error rate del 0,1% puede parecer aceptable hasta que se descubre que corresponde a timeouts que el cliente reintentó. El usuario final vio la operación lenta o duplicada. La prueba "pasó", pero la experiencia no.

Carga aplicada sobre un entorno que no representa producción. Diferencias de tamaño de base de datos, configuración de pool, número de réplicas, caché tibia o fría, o versiones de middleware pueden hacer que el resultado no sea trasladable. Si el informe no declara las diferencias entre el entorno de prueba y producción, la autorización se apoya en un supuesto no verificado.

La pregunta útil no es "¿se cayó?", sino "¿en qué punto dejó de escalar y con qué margen respecto al peak esperado?".

El error rate sin contexto de negocio no dice nada

Un 0,5% de errores puede ser tolerable en un endpoint de telemetría y catastrófico en el flujo de pago. La lectura correcta exige cruzar el error rate con:

• Criticidad del flujo. No todos los endpoints pesan igual en el negocio.
• Tipo de error. Un 400 por dato inválido del generador de carga es distinto de un 500 por excepción no controlada o un timeout por saturación.
• Momento del error. Errores al inicio de la prueba (calentamiento, caché fría) tienen implicancia distinta que errores sostenidos en la meseta.
• Comportamiento del cliente. Si la aplicación reintenta, el error puede no llegar al usuario, pero sí amplificar la carga.

Un informe serio desglosa errores por código, por endpoint y por fase de la prueba. Si solo reporta un porcentaje agregado, la jefatura que firma no tiene cómo juzgar si ese número es aceptable para su operación.

Supuestos de la prueba que rara vez se cuestionan

Antes de firmar, conviene revisar qué se asumió y no se verificó:

• Modelo de tráfico. ¿La mezcla de operaciones refleja el uso real? Una prueba con 90% lecturas y 10% escrituras puede verse excelente y no representar un cierre mensual o una campaña.
• Perfil de concurrencia. Usuarios concurrentes constantes no equivalen a un pico abrupto. Los peaks operacionales —apertura de portal, facturación, campaña— tienen rampas distintas.
• Duración. Una prueba de 30 minutos no expone fugas de memoria, degradación de caché ni crecimiento de colas que aparecen a las 4 o 6 horas.
• Datos. Volumen y distribución de la base de datos influyen directamente en tiempos de consulta. Un dataset reducido produce latencias que no se replican en producción.
• Dependencias externas. Pasarelas de pago, servicios de terceros, APIs de autenticación: si se mockearon, el resultado no cubre su comportamiento bajo carga.

Ninguno de estos puntos invalida automáticamente una prueba. Lo que invalida la decisión es autorizar producción sin que estos supuestos estén declarados y aceptados explícitamente por quien firma.

Cómo leer el informe antes de firmar el paso a producción

Un criterio práctico para la jefatura que recibe el informe:

1. Verificar que existan percentiles altos por endpoint crítico, no solo promedio global.
2. Confirmar que la curva de throughput vs. carga esté incluida y que se identifique el punto de saturación.
3. Revisar el desglose de errores por código, endpoint y fase.
4. Exigir la declaración de diferencias entre entorno de prueba y producción.
5. Comprobar que el peak probado tenga relación con el peak esperado y con el margen que la operación necesita.
6. Identificar qué no se probó —dependencias mockeadas, escenarios no cubiertos, duración insuficiente— y decidir si ese vacío es aceptable para el riesgo del despliegue.

Si el informe no permite responder estos puntos, la decisión no es "autorizar con reservas": es pedir una prueba complementaria o acotar el alcance del go-live. La autorización a producción es un acto de gobierno, y el gobierno se ejerce sobre evidencia legible, no sobre la ausencia de incidentes durante una ventana controlada.

Para equipos que necesitan estructurar esta evaluación con criterios técnicos y de gobernanza, el servicio de Stress & Performance de Mister IT aborda el diseño, ejecución y lectura de pruebas bajo esta lógica: no como validación de que el sistema "aguanta", sino como insumo para decidir con información defendible.

Preguntas que la jefatura de continuidad o ciberseguridad debería hacer

Cuando la firma del paso a producción involucra a continuidad o ciberseguridad, hay preguntas que van más allá del desempeño:

• ¿La prueba incluyó escenarios de degradación parcial —caída de una réplica, latencia de una dependencia— o solo el camino feliz?
• ¿Se probaron los mecanismos de limitación de tasa, circuit breakers y timeouts bajo carga sostenida?
• ¿El comportamiento observado es consistente con los objetivos de recuperación definidos para la aplicación?
• ¿Los logs y métricas generados durante la prueba permiten reconstruir qué pasó en cada fase?
• ¿Existe un plan de reversa si el comportamiento en producción difiere del observado en la prueba?

Estas preguntas no buscan bloquear el despliegue. Buscan que la autorización se apoye en una comprensión compartida del riesgo residual, no en la confianza de que "la prueba salió bien".