|
5.3.
Buena práctica número 14. Respalde sus
datos y su entorno de producción
Debería
tener precaución extrema cuando trabaje con máquinas
de producción. Hay pocas cosas que causen un daño mayor
que hacer cambios a un entorno de producción. Se puede evitar
mucho sufrimiento si se hacen copias de respaldo. Planifique respaldar
sus entornos de producción y de desarrollo. Es fácil
de hacer y es lo que se debe hacer.
Asegúrese
de que sus copias de respaldo incluyan archivos de aplicación,
de configuración y de datos. Respalde con regularidad y también
antes de cada despliegue. Así, en caso de problemas, podrá recuperar
fácilmente el último estado bueno.
6.
AFINACIÓN (TUNING)
Quizás
la etapa más descuidada en la mayoría de los proyectos
de desarrollo es la de afinación. Esto es sorprendente, pues
una de las causas más comunes de fracaso en grandes proyectos
de software es un pobre rendimiento. Aunque muchos programadores
llevan a cabo algo de afinación no estructurada, muy pocos
construyen y ejecutan un plan de rendimiento que funcione. Aunque
parte del problema se debe a la falta de buenas herramientas de afinación,
esta situación está cambiando. Algunos vendedores están
comenzando a incluir buenos servicios de perfilado en Java así como
ayudas para la resolución de problemas.
6.1.
Buena práctica número 15. Construya un plan de rendimiento
Es
necesario comenzar con un plan sólido de rendimiento. A continuación
se detallan los componentes clave de dicho plan:
-
Criterios. Se
debe asegurar que se capturan todos los criterios
importantes de rendimiento. Se debería ser
lo más específico posible sobre cargas,
tiempos y configuraciones.
-
Interesados. Se
debería determinar las personas que deben
aprobar el plan y las que deben aprobar el producto
acabado. Se debería nombrar a un director
del plan para que alguien sea responsable del rendimiento
de la aplicación.
-
Mitigación
de riesgos. El plan de rendimiento es
un buen lugar para comenzar a planificar cómo
se mitigan los riesgos cuando algo sale mal.
-
Cronograma. Se
necesita reservar tiempo suficiente para implementar
el plan de rendimiento. Se debería reservar
un poco de tiempo durante cada iteración de
diseño para solucionar los cuellos de botella
asociados a cada caso de uso. También se debería
reservar un periodo de tiempo al final del ciclo
de desarrollo, normalmente combinándolo con
las pruebas.
-
Herramientas. Se
debería definir qué herramientas se
usarán para analizar y afinar el rendimiento.
Estas herramientas ayudarán a simular cargas,
perfilar el rendimiento de la aplicación,
analizar los resultados y afinar servidores de software
individuales como, por ejemplo, motores de bases
de datos.
-
Entornos. Si
se necesitan simular cargas grandes, se necesitará una
red extensa para hacerlo y un software para ejecutarlo.
Otra opción es alquilar a consultores tiempo
en este tipo de entornos.
-
Personal. Necesita
asegurarse de que cuenta con los recursos humanos
necesarios para el plan, desde personal de programación
a administradores de bases de datos y especialistas
en hardware.
-
Casos
claves de prueba. Se deberían construir
los casos críticos de prueba por adelantado.
Después
de que se ha construido el plan de rendimiento, éste debe
ser aprobado por los interesados, se debe asegurar que se contará con
los recursos y se debe ejecutar el plan. Normalmente las metodologías
iterativas incluyen etapas que enfatizan el diseño de una
solución, su construcción, pruebas y despliegue. Un
análisis de rendimiento sólido se extiende por todas
estas etapas.
Resumiendo,
los problemas tardíos de rendimiento han hecho fracasar muchos
proyectos, pero si se cuenta con un plan sólido, se tendrá más
probabilidades de salir ileso. La planificación de rendimiento
es costosa pero las alternativas pueden ser catastróficas.
|
