Hemos hablado de una serie de aspectos en las entregas anteriores, que tal vez, dependiendo del conocimiento de cada uno de ustedes, podrían verlas, como meros formalismos.
Pero lo cierto del caso, es que no es así. La gran parte de los proyectos y ambientes de pruebas que se crean, no dejan resultados satisfactorios, porque no se planifican de manera adecuada. "Nos gusta muchísimo hacer varias veces las cosas, para estar más seguros de que entendemos bien lo que debemos hacer". Incluso, en muchas ocasiones, por la situación en que se presentan las cosas, adquirimos tecnología sin dimensionar adecuadamente. Resultado, en pocos meses, nos hace falta cpu, memoria, disco ó escalabilidad.
Uno de los aspectos más importantes en el proceso de "Planificación", es el dimensionamiento. Para el dimensionamiento, necesitamos tener información actualizada, sobre los requerimientos de hardware del software a utilizar. Las matrices de cumplimiento, por lo general, nos proporcionan información relevante con este punto.
Necesitamos también, conocer que tipo de pruebas van a ser realizadas con el servidor. Si son pruebas de características lineales o proceso en lote ( uno a uno de los usuarios van realizando en fila las pruebas o grandes lecturas o escrituras aisladas) o si son pruebas de esfuerzo y capacidad de procesamiento.
Para las primeras posiblemente el mínimo de hardware podría ser suficiente. Para las segundas, deberíamos tomar en consideración, la cantidad de usuarios involucrados en la prueba, el consumo probable de memoria por usuario en el sistema, la cantidad de bloques de lectura y escritura que se vayan a realizar ( I/O ), etc.
Cada caso es único y en muy pocas veces los resultados obtenidos en una misma prueba, son los mismos. Por eso, no se preocupe si la primera vez le fue muy bien con las pruebas y la segunda todo fallo.
A manera de reseña, hago el comentario en ocasiones, cómo en una presentación de un partner de negocios de la gente del lado oscuro de la luna ( Microsoft ), tenía todo bien planeado. Había hecho mil y una pruebas, para que el día de la presentación todo saliera bien. Ese día era el lanzamiento de Windows NT 4.0 y demostraría, como el potente nuevo, Active Directory, podía sin dificultad, migrar los usuarios de Windows NT 3.5, así como los usuarios de un servidor Macintosh y un Novell.
Las pruebas realizadas en laboratorio habían concluído satisfactoriamente. El día del evento y ante unas 200 personas, con una excelente comida y una guapísima presentadora, las pruebas de migración fracasaron una a una. El servidor NT 4.0, generó un pantallazo azul y se reinició un par de veces durante la presentación.
Para terminarla de hacer, como digo popularmente, el partner de negocio del evento, presentó lo último en servidores full redundancia, para aquella época. El orador afirmó equivocadamente: "A este servidor nada lo puede hacer fallar"., doble fuente de poder, doble procesador, doble abanico, doble precio -- no, esto no lo dijo ---.
Un asistente al evento, levantó la mano y solicitó subir a la tarima de la presentación. Con el visto bueno por parte del presentador, marchó directo a la parte trazera del servidor y desconectó los dos cables de AC del servidor de la fuente de poder. Adivinen que sucedió.? Extrañamente, el servidor se apagó.
Nunca podemos cubrir cada uno de los aspectos que pueden fallar en una prueba o una puesta en marcha en producción. Lo que si podemos, es mitigar el efecto de algún imprevisto que pueda darse.
Así que la planificación es sumamente importante.
Invité a personas ajenas al departamento de TI a participar en el proyecto, ellos podrán aportar aspectos que para nosotros, tal vez sean ilógicos, pero que al final, pueden hacer la gran diferencia.