Escribí las siguientes observaciones sobre la realización de pruebas efectivas de pre-producción para mi columna "VOS Corner" en el boletín del Grupo de Usuarios Stratus de diciembre de 1996. Siguen siendo relevantes hoy, casi 13 años después.
Si pudiera hacer una sugerencia a nuestros clientes (¡sólo una petición!), sería asegurarse de que realiza una prueba de estrés de los nuevos lanzamientos de su aplicación antes de ponerlos en producción. Recientemente he estado involucrado en varias situaciones en las que el cliente desplegó una aplicación que pasó todas las pruebas funcionales pero que falló poco después de ser puesta en producción porque no pudo manejar la carga de producción.
Como estoy seguro que entiendes, el software puede ser impredecible y difícil de probar. Saber que un programa funciona a 10 transacciones por segundo no es lo mismo que saber que funciona a 100 transacciones por segundo. Saber que funciona con 10 circuitos virtuales no es lo mismo que saber que funciona con 1000 circuitos virtuales. En cada caso que he visto, el programa funcionó bien en el laboratorio o en el ambiente de prueba, pero falló miserablemente en la producción debido a algún defecto subyacente del software o a un límite de capacidad. Generalmente, si me involucro, el límite estaba dentro del VOS, no de la aplicación, pero no importa dónde esté, el efecto es el mismo en sus clientes. Si quiere saber si su aplicación funcionará en producción, debe probarla como si estuviera en producción.
He escuchado muchas excusas a lo largo de los años por las que no se puede probar el software hasta los mismos límites que en la producción. No creo en ninguna de ellas. Puedes capturar el flujo de datos de producción y los archivos para usarlos en las pruebas. Puedes montar generadores de pruebas sintéticas para simular la entrada de datos buenos y malos. Puedes evitar el código de interfaz sensible al dispositivo para alimentar los flujos de datos de alta velocidad a los servidores. Hay muchos trucos que puede utilizar para que el 90% de su aplicación funcione a pleno rendimiento, incluso si no puede conseguir que el 100% funcione en modo de prueba. Deja de pensar que el problema es simular la producción y empieza a pensar que es simplemente conseguir que la mayor parte de tu código se ejecute lo más rápido posible. Asegúrate de llevar tu sistema al 100% de utilización de la CPU; ahí es donde los problemas "interesantes" tienden a aparecer.
Al ejercitar su software de aplicación hasta sus límites, también está ejerciendo VOS. Encontrarás problemas de capacidad en tu laboratorio, no en la producción. Sabrás qué y dónde están tus límites de capacidad. Saldrá de la fase de prueba con un grado mucho mayor de confianza en que el despliegue de su aplicación tendrá éxito. Mantendrá a su jefe y a sus clientes contentos. ¿No son esas buenas razones?
Empresa