Lista de Verificación de Mejores Prácticas para Pruebas de Carga

# Pruebas de carga desde la perspectiva de un ingeniero de confiabilidad orientado al rendimiento - Inicia cada prueba de carga con un objetivo escrito, como latencia p95 por debajo de 300 ms a 500 solicitudes por segundo, no desde un vago "ver qué se rompe". - Escribe pruebas de carga como código con k6, Gatling o Locust y mantenlas en el mismo repositorio que el servicio. - Modela tráfico realista a partir de registros de producción: la mezcla de endpoints, tamaños de payload y tiempo de pensamiento entre solicitudes. - Usa un modelo de carga abierto con una tasa de llegada fija al probar servicios que enfrentan internet, ya que los modelos cerrados ocultan retrasos de cola. - Ejecuta tipos de prueba separados a propósito: humo, carga en el pico esperado, estrés más allá del pico, pico repentino y una prueba de remojo prolongada para fugas de memoria. - Reporta latencia como percentiles, al menos p50, p95 y p99, y nunca te bases solo en el promedio. - Define umbrales de aprobación o fallo en el script de prueba para que CI pueda fallar la compilación automáticamente. - Ejecuta pruebas de carga contra un entorno similar a producción con los mismos tamaños de instancia, volumen de datos y configuración. - Siembra datos de prueba que coincidan con la cardinalidad de producción, porque una base de datos pequeña hace que cada consulta parezca rápida. - Calienta cachés y grupos de conexiones antes de medir, y excluye el período de calentamiento de los resultados. - Genera carga desde máquinas con suficiente CPU y margen de red, y observa las métricas del propio generador de carga. - Correlaciona los resultados de la prueba con métricas del lado del servidor, trazas y registros para encontrar el cuello de botella real en lugar de adivinar. - Rastrea la tasa de error y los tiempos de espera junto con la latencia; una respuesta rápida que devuelve un error no es un éxito. - Cambia una variable por ejecución y registra el commit, la configuración y el entorno con cada resultado. - Ejecuta una prueba de humo de rendimiento corta en cada merge a main y la suite completa antes de lanzamientos importantes. - Compara resultados con una línea base almacenada y marca regresiones mayores que un porcentaje acordado. - Simula o aísla APIs de terceros que cobran por llamada o imponen límites de tasa, pero prueba tus propias dependencias de verdad. - Encuentra el punto de ruptura y documenta cómo falla el sistema: rechazo elegante con 429 o 503 es mejor que colapso. - Verifica que el escalado automático reaccione a tiempo aumentando la carga gradualmente y midiendo cuánto tarda la nueva capacidad en ayudar. - Anuncia las pruebas de carga al equipo y a los ingenieros de guardia, y nunca las dirijas a sistemas de producción compartidos sin aprobación. - Convierte los hallazgos en planes de capacidad con objetivos claros de margen, como operar a no más del 60 por ciento del límite probado.