menu_superior

Para qué sirven las pruebas de rendimiento (y V). Pruebas en producción.

Este post forma parte de una serie sobre pruebas de rendimiento. Aquí puedes acceder al cuarto post de la serie y aquí a todos los posts publicados hasta ahora.

Solo con escuchar el título de este post la mayoría de responsables de los departamentos de sistemas tendrán escalofríos y seguramente se les acelerará el pulso. Es cierto que estas pruebas suponen un riesgo muy evidente, como también lo es que no hacerlas nunca puede desembocar una pérdida de servicio. Así pues, lo mejor es conocer en qué circunstancias se pueden plantear, que aspectos hay que tener en cuenta para gestionar su realización y maximizar el valor añadido.Testing_dont_disturb

¿En qué circunstancias se pueden hacer estas pruebas?

En mi opinión hay que plantear las pruebas de rendimiento en producción con un enfoque amplio. Creo que hay muchas circunstancias que lo requieren y, aún en el caso de que el sistema no emita señales preocupantes, es muy aconsejable hacer pruebas de rendimiento para tener la máxima información sobre el rendimiento del sistema. Por lo tanto la lista que hago a continuación está abierta: las circunstancias que voy a describir son las más comunes pero no las únicas.

.- Aplicaciones que están dando problemas de rendimiento. Servidores que se caen, interrupciones de servicio, tiempos de respuesta que superan lo esperado, etc… El enfoque es mantener la aplicación en producción, extraer la máxima información disponible de logs, trazas y monitores del sistema y plantear unas pruebas de rendimiento fuera del horario de servicio de la aplicación. Atención especial a componentes hardware, arquitectura software y manejo que el software hace de los recursos del sistema (memoria, CPU, discos).

.- Aplicaciones que están teniendo un incremento en el número de usuarios. Si este incremento es algo previsto y planificado debería haber pasado pruebas de dimensionamiento previamente y este incremento no sería un problema. En caso que el incremento no sea algo planificado y/o no se hayan realizado pruebas previamente, lo aconsejable es realizar pruebas de rendimiento para encontrar los límites del sistema (software y hardware). Es importante saber dónde está el límite para que la ampliación no lo rebase.

.- Cambios o migraciones de componentes software y hardware. En este caso tiene que haber una ronda previa en preproducción que determine la compatibilidad y que nos aporte una primera impresión sobre el nuevo componente. En un paso posterior se haría una prueba que certifique que el componente sustituido se integra perfectamente y el rendimiento del sistema no disminuye.

.- Monitorización y seguimiento de tendencias. Este es un caso muy general para el caso que no haya problemas visibles con la idea de detectar problemas latentes. La idea es extraer información del rendimiento diario para analizar si hay tendencias que anuncian una degradación del rendimiento por sobrecarga de peticiones o si hay indicios de cuellos de botella por saturación de alguno de los componentes del sistema.

¿Qué aspectos hay que tener en cuenta?

El planteamiento de las pruebas en producción exige la máxima prudencia por que trastear en el entorno de producción tiene el riesgo evidente de cortar el servicio de los sistemas TI de la empresa. Yo planteo la posibilidad de hacer las pruebas en producción, creo que no es un entorno sagrado y que hacerlo proporcionará una información muy útil para mejorar el rendimiento. Esto no quiere decir que haya que plantearlas a las primeras de cambio, hay que hacerlo cuando nos aporten información que no podamos obtener de otra manera. Una vez que pensamos en las pruebas de rendimiento en producción hay que hacerse algunas preguntas antes de arrancar:

.- ¿Cuál es la robustez que tiene el sistema? Antes de sobrecargarlo debemos tener indicios muy serios sobre el mínimo de carga que el sistema es capaz de manejar. Podemos hacer una pequeña monitorización o lanzar pruebas con pocos usuarios y una sola transacción e ir incrementándolos muy poco a poco antes de probar con escenarios más ambiciosos…

.- ¿Qué riesgos potenciales implica su ejecución? Una pregunta que en el mundo del testing hay que hacerse todos los días: ¿Qué pasa si…? Por que no es lo mismo hacer pruebas contra sistemas de altísima capacidad en los que el impacto es menor (ralentizar un proceso batch o alargar minimamente una transacción) que hacer pruebas en sistemas en los que el riesgo sea la pérdida total del servicio. Es vital saber que puede pasar con cada prueba que hacemos antes de hacerla.

.- ¿Cuales son los puntos más sensibles? Muy relacionado con el anterior. En todos los sistemas hay componentes que están replicados y otros que no, servidores que trabajan en solitario, balanceadores, granjas, etc… Hay que conocer la arquitectura y los puntos sensibles para saber si están siendo atacados por las pruebas y en qué medida sufren ese ataque.

.- Agenda de días y horas punta y días y horas valle donde se pueden hacer las pruebas. Iba a caer en la tentación de decir que este es el punto más importante. Este punto es doblemente importante: por un lado tenemos una ventana horaria para hacer pruebas sin interferencias de los usuarios y, por otro, nos aseguramos que si el servicio finalmente se ve afectado el impacto sobre el negocio será muy inferior que en hora punta.

Espero que hayáis encontrado interesante este post, que ha sido el último de la serie sobre pruebas de rendimiento. Yo lo he pasado bien a ratos recordando algunas experiencias y no queriendo acordarme de otras. Por el camino he tenido la sensación de que en algunos de estos temas había que profundizar un poco más, así que seguiré publicando revisiones y nuevos contenidos… Para mí lo más importante es que te guste y que te sirva de ayuda.

Pincha aquí para ir al capítulo anterior.

, , , , , , ,