Los bancos tienen características especiales que diferencian sus sistemas informáticos de los demás. La seguridad y la fiabilidad son fundamentales. Sin olvidar la velocidad de respuesta.
Cliente: un banco
Necesidad: mantener el sistema informático recién creado mientras se formaban a los técnicos del banco en las nuevas tecnologías introducidas.
Situación previa: el soporte del sistema antiguo lo llevaban los técnicos del banco pero al introducir un nuevo sistema que dependía menos del mainframe del banco del que eran filial, las tareas de mantenimiento se ampliaron y se determinó que por un tiempo transitorio haría falta nuevo personal.
Integrantes del proyecto: yo como jefe del proyecto y cuatro técnicos de sistemas más, uno de los cuáles seguiría en el banco cuando el proyecto finalizase.
Descripción del sistema: Principalmente un cluster HA de dos máquinas Sun, con un servidor de aplicaciones Tuxedo, un SGBD Oracle y un gestor de colas MQSERIES. Además Veritas Netbackup con un robot para backups y el planificador de procesos controlM de BMC.
Implementación: El sistema todavía estaba desarrollándose cuando llegamos. Hubo que ponerlo en producción, diseñar la planificación de tareas y definir la política de backups. La administración de las BBDD, la parametrización, la optimización de las consultas, las migraciones de versiones, el control de usuarios, la llevaba yo tanto la de producción como la de desarrollo. Aparte del mantenimiento diario de los procesos, había que introducir cambios frecuentes en el sistema para incluir los nuevos módulos que se iban desarrollando. Llevábamos un soporte 24h. con un sistema rotatorio de guardias. Durante nuestro proyecto hubo que migrar el sistema a otra ubicación, al centro de datos del banco matriz y redimensionarlo tras una fusión del banco con otro.
Coste del proyecto: 300 días x 5 técnicos
Posts Tagged UNIX
Mantenimiento del sistema informático de un banco de negocios
Organización de un equipo de soporte 24h
En el cambiante mundo de la informática, cada técnico ha recibido una formación distinta y va pasando por experiencias diferentes que le van especializando progresivamente. Pero el soporte de sistemas complejos necesita de personas polivalentes que tengan conocimientos en un amplio abanico de temas aunque no necesariamente muy profundos. La cuestión de las guardias complica el desempeño de su labor. Ante la imposibilidad de tener de guardia a todo el equipo es necesario que cada uno de ellos tenga los conocimientos mínimos para resolver el mayor número de incidencias posibles.
Cliente: una empresa de servicios
Necesidad: crear un equipo de soporte con personal joven sin experiencia o con poca, que pudiera mantener un sistema de atención de averías y proporcionar soporte de 24h.
Situación previa: el soporte estaba repartido entre la empresa que había diseñado el sistema y la empresa que lo mantenía. Se quería dejar de depender en cuestiones de mantenimiento de la empresa desarrolladora.
Descripción del sistema: el núcleo del sistema estaba formado por un cluster de HP con Service Guard. Con un SGBD Oracle distribuido, aplicaciones cliente en Windows y servidores web basados en servlets Java.
Implementación: A cada uno de los técnicos se le responsabilizó de unas tareas en función de su formación y experiencia. Desde el principio fui organizando unos talleres en los que expliqué cómo funcionaba desde el punto de vista del mantenimiento el sistema: los clusters, la BBDD Oracle, las tablas replicadas, las consultas distribuidas, los servidores Unix, etc. Al mismo tiempo fui documentando todos los problemas que iban surgiendo y les acostumbré a que lo consultaran y lo mantuvieran. Desarrollé una serie de consultas a la BBDD. y de scripts en Unix que comprobaban que todo iba bien. Les puse como tarea que todas las mañanas comprobaran el resultado, para asegurarme que todos lo comprendían. Cada uno de ellos tenía que conocer lo que hacían los demás por lo que se iban rotando para intercambiarse las tareas. Para facilitar las guardias nocturnas diseñe con BMC Performance Manager (Patrol) un sistema de consultas automático basado en las consultas anteriormente citadas que incansablemente exploraba el sistema y enviaba mensajes al móvil de guardia en cuanto se detectaba algo anormal. Quizás el principal problema fue el estrés inicial de los técnicos de llevar solos por la noche la responsabilidad de todo el soporte del sistema, pero el hecho de haber pasado durante el día por todas las posibles tareas les fue confiriendo progresivamente la suficiente confianza para reducirlo.
Coste del proyecto: 400 días x 14 técnicos
Soporte 24h con BMC Performance Manager
El soporte de 24 horas es fundamental para algunas empresas y no es factible en muchos casos tener a alguien comprobando periódicamente si todo va bien. Es mucho mejor tener un proceso automático que compruebe con la frecuencia necesaria aquello que nosotros consideremos apropiado.
Cliente: una empresa de telecomunicación
Necesidad: Llevar el soporte 24h. de un sistema crítico del que dependen miles de trabajadores y cientos de miles de clientes.
Situación previa: los tiempos de respuesta eran pésimos. Podían pasar horas hasta que alguien daba el aviso de que algo marchaba mal o por el contrario se avisaba por cuestiones puntuales que no requerían intervención.
Condicionantes del proyecto: el sistema era muy complejo. Y durante las guardias sólo una persona debía llevar el soporte de todo.
Descripción del sistema: Se utilizaban ordenadores personales (cientos), servidores UNIX en cluster, redes complicadas, bases de datos Oracle distribuidas.
Solución elegida: Patrol de BMC, ahora Performance Manager.
Implementación: Se analizaron los problemas más comunes y se vio la mejor manera de detectarlos. Se diseñaron consultas a la BBDD, tanto al diccionario de datos como a las tablas de las aplicaciones para ver si se trabajaba correctamente. Por otra parte se crearon scripts en UNIX que exploraban los ficheros de mensajes de errores de las aplicaciones más importantes y comprobaban si ejecutaban las tareas necesarias. También se analizaban los tiempos de respuesta de determinadas tareas. El resultado de todo esto era gestionado por Patrol que mandaba alertas en forma de SMS y correos cuando se sobrepasaban los umbrales definidos. Por otra parte los resultados se podían consultar posteriormente para evaluar el rendimiento del sistema. Ahora el soporte no era el último en enterarse sino que en muchas ocasiones solucionaba los problemas antes de que se produjeran o era el primero y nadie se daba cuenta de que realmente hubiera llegado a producirse una incidencia. Por otra parte, la tarea de soporte se simplificaba porque se sabía donde fallaba el sistema, o al menos donde no fallaba, aparte de las opiniones contradictorias de los usuarios.
Coste del proyecto: 100 días x hombre + licencia de BMC Patrol.
Eduardo Casais Padilla 