Como administrador de sistemas, uno de tus mayores activos (que mejora aún más cuanto más experiencia tienes) es la capacidad de seguir tus corazonadas. A veces se trata de un presentimiento sobre dónde puede estar el problema. O tal vez sea una idea para una solución que no puedes justificar del todo, pero que crees que funcionará. En esta historia de administrador de sistemas, una corazonada llevó a encontrar la causa raíz de un error crítico que amenazaba con costar mucho dinero a una empresa de materiales de construcción.

Ya sabes lo que pasa cuando ocurre un problema: empieza el juego de las culpas. Si la causa del problema no está clara, cada departamento intentará trasladar la culpa a otro. Tal vez el equipo de TI crea que el software del proveedor es el problema, mientras que los proveedores creen que el problema está en la configuración del sistema operativo. Hasta que no haya pruebas contundentes e indiscutibles sobre la causa del problema, puede haber muchas idas y venidas entre los equipos.

Este fue exactamente el caso de Matija, que trabajaba como administrador de sistemas en una empresa de materiales de construcción. Y al final, una corazonada ayudó a Matija no sólo a dejar de señalar con el dedo, sino también a encontrar una solución al problema. Pero antes de entrar en materia, demos un paso atrás en la historia y entendamos cuál era el problema.

Procesos de carga automatizados

La empresa para la que trabajaba Matija producía cemento y tenía un proceso de carga automatizado para cargar los camiones con cemento. La zona constaba de cuatro carriles, por lo que se podían cargar cuatro camiones al mismo tiempo.

Cómo funcionaba: los camiones llegaban a la zona de carga, aparcaban en la zona designada y los conductores colocaban una tarjeta RFID en un lector. A continuación se inicia el proceso de automatización y se carga el cemento en el camión. Las básculas situadas debajo del camión miden la cantidad de producto que se ha cargado en él y, cuando se alcanza un peso determinado, la carga se detiene. El tiempo de carga es de aproximadamente 15 minutos, por lo que cada 15 minutos se carga un camión con unos cuantos miles de euros de cemento. El proceso de automatización que controla la carga de los camiones era fundamental para que todo funcionara sin problemas, y cualquier problema podía tener resultados costosos.

El problema

Para mantenerse al día con las nuevas tecnologías, la empresa había actualizado recientemente el hardware y el software que utilizaba. El proyecto incluía la instalación de nuevos servidores y nuevos controladores PLC y SCADA y la conexión de todo. Mientras que los proveedores externos se encargaron del nuevo software, el aprovisionamiento del nuevo hardware y del sistema operativo fue tarea del departamento de TI.

Sin embargo, poco después de la actualización, el nuevo sistema de carga automatizada empezó a ir más lento. Poco a poco se fue volviendo más y más lento hasta que se detuvo. Tras reiniciar el servidor, el problema parecía haberse resuelto. Pero fue entonces cuando Matija tuvo su primera corazonada: creía que el problema volvería a producirse.

El juego de la culpa y la búsqueda de la causa raíz

Matija habló con los proveedores del software para describirles el problema. Como suele ocurrir con estas cosas, la conversación fue de ida y vuelta. La respuesta de los proveedores responsables del software fue que tal vez se trataba de un problema de configuración del sistema operativo, o tal vez de un problema de escaneo del software antivirus. ¿Tal vez era el sistema de gestión de eventos e información de seguridad que Matija había implantado el que causaba las ralentizaciones y los retrasos?

En este punto, Matje tuvo la segunda de sus corazonadas: no creía que nada de lo mencionado por los proveedores de software estuviera causando el problema. Así que decidió utilizar el software de monitorización PRTG de Paessler para vigilar el sistema. Primero identificó los procesos que se ejecutaban en el servidor de Windows y que estaban relacionados con el sistema de carga automática, y luego añadió sensores en PRTG para supervisarlos.

Y así, cuando el problema se repitió (tal y como Matija pensaba que ocurriría), pudo comprobar los contadores de rendimiento. Lo que descubrió fue que la solución de software estaba acumulando un gran número de asas que no se liberaban. Esto provocaba una fuga de memoria y acababa provocando la ralentización del sistema.

La solución

Al saber que el software del proveedor era el responsable de la acumulación de asas, Matija pudo volver al proveedor para investigar más. Resultó que el problema no estaba en el propio código del proveedor, sino en un componente de terceros que éste utilizaba para implementar el sistema. El socio del proveedor tenía que parchear su componente, pero mientras tanto, Matija tenía que encontrar una solución al problema. Un reinicio del servidor cada fin de semana despejaría las asas y evitaría el costoso tiempo de inactividad. Luego, durante la semana, PRTG podría asegurarse de que no se produjera una acumulación inesperada de asas.

Sigue tus corazonadas

Como dice el propio Matija: “Sigue tus corazonadas, por muy extrañas que parezcan en ese momento, y por mucha gente que te rodee que intente convencerte de lo contrario”. Quién sabe: si no hubiera supervisado los procesos de Windows Server y descubierto el problema de las asas, tal vez las discusiones con el proveedor seguirían vigentes. Lo que sí sabemos con certeza es que una corazonada y algo de monitorización ahorraron a todos tiempo y dinero.

Contrólalo todo y simplifica tu trabajo diario monitorizando tu red con Paessler PRTG

¡Descarga tu Evaluación Gratuita!