2.6 ¿Cuándo actualizar? (II)

Quedarse con sistemas obsoletos no actualizados durante años no suele ser una buena opción, especialmente en sistemas conectados a Internet, ya que, en este caso, seremos mucho más vulnerables, perderemos compatibilidad con otros sistemas y formatos, no tendremos resolución de errores ni nuevas funcionalidades, etc. Aunque lo peor de no actualizar es precisamente el riesgo de quedarse estancado en el pasado, ya que todo cambia muy rápido. Imaginemos el caso de una empresa que no ha actualizado sus sistemas desde que los pusieron en funcionamiento hace quince años. Eso es muchísimo tiempo desde el punto de vista informático. Puede que las herramientas que use ya estén incluso descontinuadas (abandonadas), es decir, sin soporte, pero ahora necesitan evolucionar sus sistemas… Aquí hay un problema, y gordo: ¿quién es el valiente que toca un sistema tan viejo, con tecnologías obsoletas, hecho por vete a saber quién y sin documentación? Estos casos son un verdadero infierno y, como acabo de decir, puede salir más a cuenta desarrollar sistemas nuevos que sustituyan los antiguos porque intentar modificarlos sería aún más costoso. Lo malo es que a veces estos nuevos sistemas no se desarrollan, no se terminan, no funcionan correctamente (y no pueden usarse en un entorno real) o, por la razón que sea, no se acaban poniendo en producción, pero mientras tanto los sistemas antiguos se vuelven cada vez más y más obsoletos con el paso del tiempo.

Una alternativa para migrar aplicaciones antiguas consiste en usar el patrón Strangler, mediante el cual se migra gradualmente de una aplicación monolítica a otra nueva basada en microservicios. Es decir, en vez de hacer la migración completa de un sistema por otro, se van migrando de forma incremental las distintas funcionalidades al nuevo sistema, hasta que llega un punto en el que se puede prescindir de la aplicación inicial. Por supuesto, esto puede conllevar riesgos y tampoco es trivial, pero en determinadas circunstancias puede sernos muy útil. Al fin y al cabo, se trata, una vez más, de dividir un problema grande en distintas partes más pequeñas para que su resolución sea más sencilla.

Una medida de contingencia para casos excepcionales en los que no exista una alternativa viable más moderna para el software arcaico que se esté utilizando puede ser la virtualización. Por ejemplo, si dependemos de un programa que hace una tarea muy específica y solo funciona con una versión de sistema operativo muy antigua en un equipo que prácticamente funciona a pedales, podríamos crear una máquina virtual para que ese programa pueda seguir funcionando en un equipo moderno y actualizado. Si es posible, otra alternativa a valorar es el uso de contenedores (Docker o similar) para ejecutar este tipo de aplicaciones. En ambos casos, estaremos encapsulando el problema en vez de solucionarlo de raíz, pero al menos podremos tener el sistema operativo anfitrión (host) actualizado, con todas las mejoras y parches de seguridad. Además, también podremos usar hardware actual en vez de quedar atados a equipos antiguos, lentos y sin piezas de repuesto disponibles.

Una empresa no se puede permitir el lujo de no actualizar sus sistemas informáticos, aunque estos no sean su fuente de ingresos porque a la larga su negocio se puede hundir por falta de mantenimiento informático. Puede darse el caso que su expansión quede limitada porque el sistema informático no esté preparado y eso es muy malo. Me he encontrado casos donde hay grandes superficies que aún trabajan con MS-DOS, ¿en serio? Que esto lo haga una pequeña tienda de zapatos local porque ya le va bien y lo ha hecho así «toda la vida», aún puede pasar si realmente no necesita nada más. Pero no creo que sea la mejor opción para grandes empresas con tiendas en muchísimas ciudades e incluso en varios países.

También creo que es muy importante preguntar a la gente que usa los sistemas informáticos (compañeros, empleados, clientes, etc.) si realmente les son útiles o, por el contrario, les dificultan el trabajo. Cuando voy a tiendas u oficinas y la persona que me atiende interactúa con un ordenador delante de mí durante varios minutos (mientras espero pacientemente), tengo por costumbre preguntar si les funcionan bien los programas. A veces, más que una pregunta real es una pregunta retórica porque puedo ver cómo se están peleando con el ordenador. Es decir, están esperando durante unos minutos porque «está pensando», están reintroduciendo los datos porque «se pierden al cambiar de ventana», están escaneando archivos que el mismo programa ha generado o lo han tenido que reiniciar porque «se ha colgado».

Aún recuerdo cuando me tuvieron esperando durante más de quince minutos para hacer un simple cambio de nombre de un contrato porque el software que utilizan es lento, pierde información entre pantallas, tienen que rellenar formularios con la misma información una y otra vez, etc. Lo peor de todo es que tenía que hacer dos cambios de nombre y para hacer el segundo me dijeron que tenía que volver otro día porque el sistema no permitía hacer varios cambios de nombre para una misma persona en un mismo día, ¡no me lo podía creer! Pues, efectivamente, tuve que volver otro día, hacer otra larga cola y esperarme otros quince minutos a que el oficinista pudiera hacer el cambio en el segundo contrato. Este es un clarísimo ejemplo de cuello de botella en un sistema informático que provoca largas colas e insatisfacción a empleados y clientes. A sistemas como estos les hace falta una actualización muy urgente, pero vete a saber qué hay por detrás y si, como decía antes, se trata de sistemas tan viejos que no hay quien los toque…

Me gustaría acabar este apartado con una anécdota que me ocurrió poco después de darlo por finalizado, llámalo casualidad… El caso es que me llamó un compañero un viernes al mediodía diciéndome que había fallado el despliegue de unos cambios (actualización) en un proyecto importante. Mi primera pregunta fue: «Me estás hablando del entorno de preproducción, ¿verdad?». Así era, con lo cual respiré aliviado y le seguí escuchando. Lo preocupante era que, si volvía a la versión anterior, también fallaba. ¿Cómo podía ser esto? Después de mirármelo un rato con él al teléfono, descubrí que la semana anterior habían actualizado una dependencia de otra dependencia, lo que es lo mismo, una librería usada por otra. Ya era mala suerte porque la penúltima versión era de hacía más de un año. Como esta dependencia no estaba fijada en el proyecto, entonces se instalaba la última versión, que era incompatible, y petaba. ¿Cómo lo solucioné? Fijé la versión de la librería conflictiva a la versión anterior de la que provocaba el problema y al momento ya teníamos funcionando las dos versiones del proyecto: la actual y la nueva que quería desplegar.

¡No, ahora no!

Para mí, los peores momentos para hacer actualizaciones largas son al iniciar y al apagar un sistema. ¿Por qué? Muy fácil, cuando lo enciendo quiero o necesito usarlo a la menor brevedad de tiempo posible y cuando lo apago quiero que lo haga rápido sin tener que esperarme varios minutos, que se hacen eternos.

Una de las cosas que más odio en esta vida es encender o apagar un sistema y ver el siguiente mensaje: «Instalando actualización 1 de 100». ¿En serio? ¡No me fastidies, hombre! Imagínate la situación en la que acabas tu jornada laboral e intentas apagar el ordenador, tienes el tiempo justo para coger el tren y, si lo pierdes, entonces te tendrás que esperar media hora a que pase el próximo (sí, hay mala combinación, es un asco). Además, recuerda que forzar el apagado en medio de una actualización es una muy mala idea porque puedes tener graves problemas de corrupción de datos o incluso corromper el sistema entero, impidiendo que vuelva a arrancar.

Por si esto no fuera suficiente, hay sistemas que instalan las actualizaciones de una forma demasiado temeraria e intrusiva, ya que las aplican automáticamente en segundo plano y cuando han terminado informan al usuario de que se va a reiniciar en breve a no ser que este lo cancele o lo posponga. Por lo tanto, si has dejado el dispositivo ejecutando alguna tarea mientras tú te dedicas a otra cosa o en ese momento no prestas atención y no ves el aviso, el sistema se reiniciará y el trabajo quedará interrumpido bruscamente, con el consiguiente riesgo de pérdida de información o incluso de corrupción de datos.

Otra alternativa menos intrusiva consiste en sugerir la actualización y que sea el usuario el que voluntariamente haga la acción para instalarla. Esta estrategia se usa, por ejemplo, en Ubuntu Linux, aunque es cierto que se corre el riesgo de que no se apliquen nunca las actualizaciones pendientes. Por lo tanto, no digo que actualizar al iniciar o apagar un sistema sea siempre una mala idea (aunque sí hay que evitar los reinicios automáticos inesperados), sino que no me parece correcto forzar a los usuarios a hacer largas actualizaciones en estas situaciones, sin siquiera informarlos previamente de que van a tardar un buen rato.