Sistema de monitorización monotarea (Manolo V 1.0)
Hace ya algún tiempo, en una pequeña caja de ahorros provincial, de esas que ya no existen por la mala gestión y la crisis, trabajaba Manolo.
Manolo realmente era personal de IBM, y le habían contratado porque cumplía con dos requisitos fundamentales. Contaba con los rasgos característicos del personal subcontratado, al ser un hombre joven, graduado, con buen expediente y con muchas ganas de trabajar… por un sueldo limitado. Y además, vivía dos números más abajo de la ubicación del CPD de esta caja.
Parecía que los planetas se habían alineado.
Manolo empezó a trabajar y rápidamente se hizo con la dinámica de la Caja. Sus tareas eran de lo más diversas: se encargaba de que los servidores x86 responsables del correo electrónico estuvieran funcionando correctamente o daba de alta las nuevas cuentas y de baja a los que se iban quedando por el camino o pasaban a mejor vida (la jubilación). También estaba a cargo de otros servidores, como los que daban soporte a la virtualización, realmente dos, pero el CPD era pequeño y en x86 no había gran cosa. Sabía algo de redes, se encargaba de su mantenimiento y hacía pequeños apaños como dar de alta algún nuevo dispositivo o alguna nueva ruta.
En una pequeña capital de provincia, con un personal propio cada vez más limitado y cerca de la jubilación, Manolo cada día era más imprescindible.
Manolo también era el interlocutor principal con las oficinas centrales. Desde Madrid se controlaba la seguridad, las comunicaciones y la red de oficinas, todo a través del Mainframe de la caja. Y cada vez que se tenía que hacer una intervención ahí estaba Manolo, colgado de un teléfono, siguiendo las instrucciones que le daban, siempre al pie del cañón.
Pero Manolo no era un autómata y, al poco de llegar, empezó con sus trucos y experimentos. Que te llamen en horario de oficina para hacer una intervención es una cosa, y otra muy distinta es que te saquen de la cama a las tres de la mañana porque la red de cajeros está caída. Y sí, la crisis era grave, pero que te llamen para dar soporte a un director de oficina que no podía descargarse el correo electrónico, ya era el colmo. Así que Manolo empezó a descuidar las normas básicas de seguridad, y empezó a dar soporte desde su casa a través de una conexión remota que nadie conocía. Y montó un sistema de monitorización de libre distribución, que nadie había autorizado, pero que le simplificaba la vida.
Pasaron tres años y Manolo, ese chico tan imprescindible, asistía a las reuniones de planificación y atendía a los proveedores, pero no documentaba. La red, los servicios, las aplicaciones, estaban en sus servidores y solo él los conocía. A nadie más le interesaba esa información, nadie se la pedía, y por lo tanto, a nadie se la daba.
Como esto no es una historia con final feliz, por lo menos para el cliente, pasó lo que tenía que pasar. Manolo empezó a tener aspiraciones. El muy loco empezó a hablar de matrimonio con su novia de toda la vida. De ahí pasó a pensar en piso propio, que eso de vivir en casa de los padres ya está muy pasado. Y habló con su jefe de proyecto en Madrid. Una, dos, tres veces… y siempre la misma respuesta, el contrato está cerrado, los costes están muy apurados, cuando renegociemos el contrato con el cliente… Y Manolo se comenzaba a plantear dejar el trabajo, empezó a ver ofertas de trabajo y a faltar un par de veces al mes para hacer entrevistas.
Al poco tiempo, encontró un trabajo más excitante, más retador, más dinámico… Vamos, mejor pagado. Y provocó el efecto el denominado efecto “fontanero”. ¿Qué es lo primero que dice un fontanero cuando llega a solucionar una fuga de agua, un viernes a las 2 de la tarde?: “¿Quién te ha hecho esta chapuza?”
Entiéndame bien. Manolo no es un mal profesional. Solamente que tiene su manera de hacer las cosas. El personal interno de la Caja no son malos profesionales, solo que si no hay fuegos, ¿por qué apagarlos? IBM no hace mal su trabajo, pero al final son las personas las que ejecutan.
Y cuando el fontanero habla, sabes que te va a costar tiempo y dinero solucionarlo. Y el fontanero sabe que te tiene pillado.
Esta historia es válida para la mayoría de las actividades en IT, pero es útil si extraemos conclusiones en nuestro sector, que es la monitorización:
1.- Si desarrollas a medida un sistema de monitorización, sin soporte profesional de fabricante, en vez de una herramienta configurable, firmas un contrato en blanco. Solo un ser humano en todo el universo es capaz de entender cómo narices funciona, qué parámetros está controlando, y lo más importante, cuáles no.
2.- Si el sistema de monitorización te obliga a instalar algo en los servidores, más te vale estar 100% seguro de qué estas instalando, porque igual que extrae información, la puede meter. ¿O acaso no sabías que para extraer información a nivel de sistema operativo, lo más fácil es usar la contraseña del administrador?… ¿Asusta?
3.-Una herramienta de monitorización profesional no solo te debe dar información de lo que está pasando. Te debe informar de lo que ha pasado, cuándo ha pasado y a quién ha afectado.
4.- Una herramienta como Pandora FMS incorpora un sistema de conocimiento que te da información de TODOS los elementos que componen tu red.
5.- Como dice el doctor House, todo el mundo miente, y el primero en mentir es el paciente. ¿De verdad confías el estado de salud de toda tu infraestructura a “Manolo”? Una herramienta de monitorización debe incorporar sistemas de informes que permitan conocer el estado de tus sistemas, aplicaciones, servicios… en todo momento, según el perfil del usuario que la consulte. Igual el director de una oficina no necesita saber si el servidor de correo está o no caído, pero al jefe de sistemas sí le interesa ver en su móvil si hay algún semáforo en rojo dentro de su infraestructura, para poder contestar rápidamente al negocio en caso de incidencia.
Y por último, y para acabar bien la historia: Manolo trabaja en Madrid, trabaja para una gran compañía, se ha casado y vive de alquiler con su mujer. Esperan su primer hijo, y está hasta las narices de que le llamen de la Caja para pedirle un “pequeño favor”, porque no encuentran el contrato de unas licencias, el número de soporte de un hardware o cómo le arreglaba el correo al director de la oficina 2930, “al que se le sigue cayendo el correo” (el cenutrio todavía no maneja el wifi de su casa, y si no está su hijo, no se sabe conectar).
