Qué tener en cuenta antes de actualizar una plataforma de monitorización crítica

La igualdad es lo correcto cuando se trata de personas, pero cuando hablamos de aplicaciones… No podemos tratar a todas de la misma forma, especialmente, a la hora de actualizar. Hacer lo mismo con la plataforma de monitorización que con un plugin de navegador (que llevas tres semanas posponiendo) es la receta del desastre. Sobre todo, cuando los ingredientes de esa receta son darle al botón, cruzar los dedos y que sea lo que el Dios Máquina quiera.
Esto se debe a que la monitorización es el sistema nervioso del entorno, lo que nos dice que algo va mal antes de que el desastre sea irreversible.
Si durante el proceso de actualización ese sistema queda degradado, medio ciego o directamente fuera de servicio, hemos creado la peor situación posible:
Un momento de máximo riesgo operativo con mínima capacidad de respuesta.
Por eso, actualizar una plataforma de monitorización de infraestructura crítica exige algo más que darle a «Siguiente» en cada paso del instalador. Es necesario prepararse como si fuera una operación de continuidad de servicio en lugar de una tarea de mantenimiento rutinario.

El problema: Quedarnos ciegos cuando más necesitamos ver

En tecnología, los momentos de cambio son también momentos de vulnerabilidad. Que suena melodramático, pero cierto. Cuando se actualiza un servidor de aplicaciones y algo sale mal, el impacto es localizado: ese servicio cae, se revierte y se investiga, pero el resto del entorno sigue visible, monitorizado y bajo control.
Sin embargo, cuando es la propia plataforma de monitorización la que falla, o queda parcialmente operativa durante una actualización mayor, el escenario cambia radicalmente.
El equipo pierde visibilidad sobre el resto de la infraestructura en el momento exacto en que más la necesita: el momento en el que se están realizando cambios, reinicios y validaciones, de forma que nos topamos con:

• Un posible fallo en un nodo remoto.
• Una alerta que no llega.
• Un umbral que se supera sin que nadie lo vea…

Qué hace diferente a una actualización mayor de monitorización

Hay una diferencia importante entre una actualización incremental y una migración con cambios de arquitectura. Un parche de seguridad o una update menor no altera la forma en que los procesos se relacionan entre sí. Aplicas, reinicias y (con ese poco de suerte que hace falta para todo en la vida) listo. El sistema sigue funcionando como antes.
Una actualización mayor, sin embargo, puede implicar:

• Cambios en la arquitectura interna.
• Nuevos componentes que sustituyen a los anteriores.
• Modificaciones en la compatibilidad con el sistema operativo o las dependencias.
• Ajustes en cómo se distribuyen las tareas de procesamiento…

Lo anterior puede afectar, por ejemplo, a cómo se configuran los entornos distribuidos, las personalizaciones y retoques acumulados durante años o si las integraciones activas siguen funcionando igual o hay que revisarlas.
La gestión del cambio en IT establece que no todos esos cambios son iguales en términos de riesgo y alcance.
Y una migración de plataforma de monitorización es, por definición, un cambio de alto impacto. Por tanto, el criterio no puede ser el mismo que para una modificación estándar de bajo riesgo.

Qué cambia en Pandora FMS 800 LTS y por qué obliga a preparar bien la migración

Pandora FMS 800 LTS Aquarius introduce cambios relevantes que justifican una preparación cuidadosa de la migración, especialmente para quienes vengan de la anterior LTS 777 Andrómeda.
Los principales son:

1. La nueva arquitectura de servidores

El cambio más importante afecta a la arquitectura interna del servidor, donde se han redistribuido funciones entre componentes:

• El Network Server consolida ahora tareas que antes requerían procesos dedicados (WMI, scripts remotos, chequeos web o predicción, por ejemplo).
• El Network High Performance Server se especializa en el polling ICMP y SNMP a intervalos muy cortos.
• El Heavy Server, por su parte, hace honor a su nombre y asume el trabajo más exigente en cuanto a recursos: plugins, inventario, gestión de vulnerabilidades y exportación de datos.

Esto simplifica la arquitectura global y optimiza la operación de Pandora FMS, pero a cambio implica que los entornos que desplegaron servidores específicos para funciones minoritarias necesitan revisar cómo queda su configuración tras la migración.

2. Pandora_supervisor

Otro componente nuevo es pandora_supervisor, que actúa como responsable de la supervisión y reinicios de la plataforma, haciendo las actualizaciones más transparentes y reduciendo la intervención manual.
Menos intervención manual, menos margen para errores humanos en el proceso.

3. Mejora de compatibilidades

En cuanto a compatibilidades, la versión 800 LTS de Pandora FMS amplía el soporte a RHEL 9 y PHP 8.4, mejorando de paso el soporte de SNMPv3.
Para entornos que ya gestionan con esas versiones, es una buena noticia. Para los que no, hay que comprobar que las dependencias de la instalación actual no representen un problema.
Para orientarte, tienes la documentación de Pandora FMS, que recomienda revisar la guía de actualización desde 777 LTS a 800 y prestar especial atención a entornos con configuraciones personalizadas o despliegues distribuidos.
Este no es el típico aviso burocrático que hay que poner por trámite, es una advertencia técnica real y, si actualizas desde Pandora Andrómeda 777 a Pandora Aquarius 800, échale un vistazo para ver posibles pasos extra y detalles.

4. Otras mejoras y optimizaciones

Como por ejemplo, un equilibrado de carga automático en chequeos remotos. Este complementa el sistema ya existente desde hace años y que permite HA (High Availability o Alta Disponibilidad) en modo activo/pasivo.
Esa HA, además, también puede habilitarse o deshabilitarse para los agentes, aumentando la capacidad de configuración en entornos distribuidos.

Qué condiciona el riesgo: arquitectura de partida, personalizaciones y dependencias

El riesgo de una actualización de plataforma de monitorización no es uniforme. Podemos considerarlo un viaje y dicho riesgo depende de la distancia que tenemos que recorrer entre lo que tiene el entorno actual y lo que requiere la nueva versión.
Los factores que más condicionan ese riesgo son:

• La versión de partida, obviamente. Migrar desde la 777 LTS a la 800 LTS implica saltar por encima de un ciclo completo de cambios. Cuanto más antigua la versión de origen, más cosas debemos revisar para no caernos al precipicio a medio salto.
• La dimensión del entorno y lo crítico que sea. El tamaño siempre importa, así es la vida real. No es lo mismo actualizar una infraestructura con doscientos dispositivos monitorizados que otra con cincuenta mil que, además, tienen un SLA draconiano que no admite ventanas de ceguera operativa.
• Si el despliegue es centralizado o distribuido. Los entornos distribuidos, con nodos remotos y servidores satélite, requieren una planificación secuencial. No se puede actualizar el servidor central sin tener en cuenta qué pasa con los nodos que dependen de esa nave nodriza.
• Personalizaciones que hayamos realizado. Scripts propios, módulos desarrollados a medida, integraciones con herramientas externas… Este dolor de muelas es un clásico en estos procesos, porque todo eso puede verse afectado por cambios en la arquitectura interna, de modo que este factor necesita validarse explícitamente.
• Las propias dependencias del sistema. Como la versión del SO, la de PHP, MySQL, librerías SNMPv3… Si alguna de esas dependencias no es compatible con la nueva versión, hay que resolverlo antes de empezar la actualización, no durante.

Como la mejor batalla es la que no peleas y ya dice El Arte de la Guerra que esta se gana en la preparación, la mitigación de riesgos en IT parte de identificar con antelación esos factores.
De lo contrario, estaremos apostando a que somos hijos predilectos de la suerte y no lo somos, o estaríamos en una playa y no hablando de estas cosas, así que profundicemos en esto.

Qué debe incluir una buena preparación antes de actualizar

Para los que pensaban que por primera vez no iba a referenciar Star Trek en lo que escribo… apuesta perdida. Porque esa serie, como Los Simpsons, lo contiene y predice todo.
En el episodio Relics de La Nueva Generación, el legendario Scotty de la serie original le pregunta al ingeniero jefe La Forge que cuánto tiempo le ha dicho al capitán que tardará en una tarea. Este le responde que una hora y Scotty le pregunta que cuánto le costará en realidad. La Forge, entre mosqueado y extrañado, le replica que una hora, lo que horroriza a Scotty:
«¿Cómo vas a cultivar una reputación de obrador de milagros si le dices al capitán el tiempo real que te ocupará lo que te pide?», replica el legendario protagonista de la serie original.
La estrategia es, según Scotty, hinchar ese tiempo, una clave fundamental que debemos aplicar aquí, porque los sistemas críticos siempre presentan imprevistos y quien no los anticipa, los sufre.
En operaciones IT, el «Principio Scotty» es prioritario y debemos planificar con márgenes de seguridad de tiempo. Más que para quedar como genios (que a lo mejor también), para tener margen de maniobra cuando surjan los inevitables gremlins que, por naturaleza, son imprevisibles.
Y si luego no surgen (surgirán, recordemos que no somos los más afortunados del mundo), genial, seremos el mejor ingeniero de la Flota Estelar.
Partiendo de ese principio, una buena preparación para una actualización mayor de plataforma de monitorización debería incluir, como mínimo:

• La revisión previa del entorno. Lo que implica un inventario de servidores desplegados, versiones de dependencias, personalizaciones documentadas, integraciones activas… Si dicha documentación no existe o está obsoleta, crearla es el primer paso, no una tarea opcional.
• Copia de seguridad completa. De la base de datos, de los ficheros de configuración, de los scripts y módulos personalizados… La copia debe ser verificada como funcional y recuperable. Y ya puestos, si seguimos el clásico «Principio 3-2-1», resultaría ideal.
• Probar en un entorno que no sea de producción, si es posible. No siempre será viable replicar un entorno de producción crítico y en IT nos gusta vivir peligrosamente (en realidad no), pero no nos lancemos de cabeza a la piscina. Incluso una prueba parcial en un entorno de laboratorio puede revelar incompatibilidades antes de que aparezcan en producción.
• Un plan de reversión claro. A nadie le gusta pensar que las cosas saldrán mal, pero como dijo Andy Grove de Intel: «Solo los paranoicos sobreviven». Antes de empezar, debemos tener claro qué haremos si la actualización es un desastre: qué pasos seguir, en qué tiempo razonable (más el «impuesto Scotty»), quién toma la decisión de revertir… El momento de crisis es de crisis, no de improvisar ni empezar a planear en ese momento.
• Una ventana de mantenimiento óptima. Que implica elegir el momento de menor impacto operativo, comunicarlo a los encargados de los servicios afectados y cumplirlo.
• Responsables claros. Especificando quién ejecuta, quién supervisa, quién valida y quién decide la marcha atrás. La ambigüedad en un momento crítico multiplica los errores y, en caso de fallo, perderemos tiempo y dinero señalando luego con el dedo durante el juego de la culpa.
• Validación posterior. Aquí, lo ideal es tener un checklist de comprobaciones que confirme que la plataforma ha quedado operativa: los módulos críticos están activos, las alertas llegan correctamente, los entornos distribuidos sincronizan, las integraciones responden, etc. Porque la actualización no termina cuando lo dice el instalador.

Qué cambia en nuestras operaciones después de actualizar

Por desgracia, los cambios en organizaciones hacen buena la canción de «La vida sigue igual». Ocurre con las decisiones en reuniones, los buenos propósitos anuales y, en ocasiones, tras actualizaciones como esta.
Pero una vez completada con éxito la migración a la nueva versión de Pandora FMS, y si hemos hecho esos deberes de dependencias y planificación, el entorno (y nosotros) no debería funcionar como antes, sino mejor, debido a que:

• La nueva arquitectura de Pandora FMS 800 LTS reduce el número de procesos dedicados, lo que se traduce en menos puntos de fallo y menos carga de mantenimiento para el equipo.
• Pandora_supervisor, por su parte, hace que las futuras actualizaciones sean más transparentes y menos disruptivas.
• El polling de red más frecuente mejora la granularidad de la visibilidad.
• La compatibilidad ampliada con RHEL 9 y PHP 8.4 elimina deuda técnica de dependencias.

Cuándo apoyarse en la guía oficial, el soporte y los recursos disponibles

Hay entornos donde la actualización puede abordarse de forma autónoma con suficiente preparación. Sin embargo, hay otros donde esa autonomía es un riesgo inasumible.
Los casos donde tiene más sentido apoyarse en recursos externos son:

• Migraciones desde versiones anteriores a la 777 LTS, donde los cambios acumulados son más amplios y las posibilidades de incompatibilidad aumentan.
• Entornos distribuidos complejos, con múltiples nodos y/o configuraciones personalizadas que requieren una secuencia de actualización específica.
• Instalaciones con integraciones críticas con sistemas de terceros, las cuales no admiten interrupciones ni períodos de degradación.
• Entornos donde no existe documentación actualizada del estado real de la plataforma. Sin saber con exactitud qué hay desplegado y cómo, cualquier migración mayor es una aventura.

La guía de actualización desde 777 a 800 que he enlazado más arriba es el punto de partida obligatorio en todos los casos, porque está diseñada para anticipar los escenarios más comunes de incompatibilidad y encauzar el proceso de forma ordenada.
Y por supuesto, el soporte oficial de Pandora FMS existe precisamente para estos escenarios.
Con él, una actualización compleja en un entorno crítico no dependerá exclusivamente del criterio del equipo interno bajo presión.
Con nuestro soporte, y como dice el famoso himno de fútbol, nunca caminarás solo y no creas que ese respaldo es una señal de debilidad técnica. Al contrario, es una decisión operativa sabia y que acudas a la actualización crítica con los Rohirrim cubriendo el flanco.
Al final, subir de versión es fácil en realidad. Hacerlo sin perder visibilidad, sin comprometer la operación (y sin dejar deuda técnica acumulada) es lo que distingue una actualización bien ejecutada de una que simplemente terminó sin desastre aparente.
Por todo esto, una migración de plataforma de monitorización crítica debe prepararse como una operación de continuidad de servicio con: análisis previo, copia verificada, plan de reversión, ventana planificada y validación posterior… No se trata de una tarea de mantenimiento que se despacha en un rato libre… A menos que queramos perder los de los siguientes días tratando de arreglar el desastre por no haber planeado.