La problemática de la actualización de las infraestructuras

En el mundo de los Sistemas de Información, cuando hablamos de las infraestructuras hardware o software, éstos son elementos que nunca se valoran lo suficiente. Se trata de piezas de los que se asume un correcto funcionamiento pero que, en el caso de que fallen, es cuando realmente adquieren el valor que les corresponde. Parece una contradicción pero es así.

Aunque para los legos en esta materia esta afirmación puede resultarles sorprendente , estas infraestructuras están basadas en productos y máquinas que, por lo general, deberían tener un ciclo de vida como el de cualquier otro aplicativo. Pero cuando hablamos de infraestructuras, al tratarse de servicios “core” y sin los cuales los sistemas de información que se basan sobre los mismos dejarían de funcionar, la gestión de estos ciclos de vida se complica sobremanera. Generalmente existen dos orientaciones para llevarla a cabo:

• Orientación “si algo funciona no lo toques”. Es algo que se ve circular en algún correo electrónico de tono jocoso (al menos entre los informáticos, esa rara avis cada vez más extendida entre los que me incluyo) pero realmente es la orientación más extendida entre todos los departamentos de Sistemas. Este modo de pensar y actuar es muy conservador y, a la larga, termina de ser contraproducente. Las sustituciones y/o evoluciones terminan por darse y suelen ser traumáticas. Además, las infraestructuras, aunque estén estables, nunca terminan de dar todos los servicios, ni por lo general de igual calidad, de las versiones de plataformas más evolucionadas. No obstante, para ciertos casos, es posible que esta orientación sea la más adecuada.
• Orientación “vamos a estar siempre a la última”. Esta orientación es muy arriesgada en la mayoría de los casos. Las infraestructuras, por lo general, están sujetas a excesivas actualizaciones y nunca terminan de quedar estables. Por el contrario, las ventajas que aporta esta situación son plataformas “a la última” con lo que ello implica: mayor nivel de seguridad, de corrección de errores o “bugs” y una mayor funcionalidad aportada. Existen organizaciones que, para su escenario de negocio, esta opción es más adecuada.

No obstante, para los sistemas de información de la mayor parte de las empresas, lo ideal es encontrar un equilibrio. Como suele decirse, en el medio está la virtud. Los responsables de las infraestructuras deberían realizar un seguimiento de la evolución de las mismas y tener una política de actualización. Esta política será más o menos conservadora pero deberá existir siempre. Aunque suene un poco ridículo en un blog de tecnología el hablar de valentía, una de las cualidades más deseables en los responsables de las infraestructuras es la no carencia de valentía. El motivo principal por la que los responsables son reacios a realizar actualizaciones de infraestructuras es por la complejidad que posee esta acción de actualización.

Las infraestructuras son servicios “always on” para el conjunto de los sistemas de información. Un mecanismo de trabajo habitual y muy recomendable para llevar a cabo las actualizaciones es diseñar un entorno de laboratorio donde se lleva a cabo una simulación del upgrade. El juego de ensayo para validarlo puede ser más o menos complejo y, cuanto más completo sea, mayor será su coste y su eficacia. Aun y todo, la validación de una actualización en base a las conclusiones sacadas de un entorno de laboratorio, no es fidedigna del todo. No es más allá que una orientación más o menos precisa. El entorno real de prueba de la actualización termina por ser el entorno productivo con todas las implicaciones que esto lleva consigo: posibles caídas del servicio en caso de fallo, quejas a todos los niveles tanto del usuario final de los aplicativos como de los responsables de los mismos dentro de la organización, etcétera. Se dice que uno no valora algo hasta que deja de tenerlo y esto se aplica perfectamente para el caso de las infraestructuras.

A la hora de la verdad, la de realizar la actualización de una infraestructura en un entorno productivo, el contar con una copia de seguridad de todos los elementos afectados en el caso de las infraestructuras software, o un procedimiento de contingencia en el caso de las hardware es, si cabe, lo más importante del proceso. Además, en función de la infraestructura concreta, la recuperación del entorno inicial debe realizarse lo más rápidamente posible. Esta presteza implica que:

• Las copias de seguridad deben realizarse de aquello que garantice una recuperación rápida (incluso una imagen del disco puede ser aplicable en muchos casos).
• Siempre debe existir un procedimiento definido para llevar a cabo la actuación. Esto evita que indecisiones de última hora se den en momentos inconvenientes.
• Las decisiones tienen que ser extremadamente rápidas en caso de fallo. Son servicios que no pueden dejar de funcionar y hay que tener un procedimiento perfectamente acotado además de una persona con la capacidad necesaria de tomar esta decisión con la presteza requerida.

Creo que, con lo anterior, la falta de valentía extendida en los responsables de infraestructuras podría quedar justificada en parte. Pero, no nos engañemos, nunca del todo.

Para terminar con esta gota en el mar de la tecnología, un consejo para aquellos en los que os encontráis en la complicada situación de afrontar este proceso: armaos de valentía (no es tontería) y sed meticulosos y exactos en los pasos a seguir. Tened preparado un procedimiento de marcha atrás por mucho que los entornos de laboratorio hayan sido completos y sed eficaces y rápidos en su aplicación en caso de que sea necesario. Son decisiones complejas en algún caso pero que han de tomarse rápidamente. Eso sí, la frontera entre la valentía y el ser temerario es difusa en muchos casos, y únicamente en el juicio de cada uno esto tiene un matiz claramente diferente.

Un saludo, navegantes del mar tempestuoso