Desde que empecé he administrado BBDD de producción en Oracle 7, 8, 9, 10 y 11. He tenido que migrar bases de datos a todas estas versiones sin contar las migraciones entre revisiones que alguna que otra sorpresa me han dado, a pesar de todas las pruebas realizadas en entornos de desarrollo, sistemas y certificación. Las tareas de administración han variado poco en todos estos años, han ido apareciendo herramientas visuales cada vez más atractivas pero sigue siendo importante un conocimiento profundo del diccionario de datos y un dominio de sql para consultar de las mil maneras posibles la información almacenada allí. En todos estos años he tenido que recuperar bases de datos de muchas formas, de backups de ficheros en frío, de exportaciones, con Rman; configurar BBDD y optimizar consultas complejas para mejorar el rendimiento; administrar entornos distribuidos en los que las transacciones afectaban a varias BBDD y estaban vinculadas algunas tablas mediante réplicas; crear multitud de programas plsql para administración y necesidades diversas o auditoría; diseñar y mantener políticas de seguridad de usuarios y aplicaciones; desarrollar sistemas de vigilancia automática del funcionamiento de la BBDD…
Archive for sistemas
Creación de un entorno de certificación
Los entornos de certificación son fundamentales sobre todo en los sistemas que dependen de otros para funcionar. El desarrollo a menudo olvida algunas de las relaciones que existen con otros y muchas puestas en producción fracasan por no haber previsto las consecuencias que acarrearían. Suponen pérdidas importantes o por los gastos asociados por volver al sistema anterior o simplemente por la disfuncionalidad que implica en el negocio.
Cliente: una empresa de desarrollo de un grupo de telecomunicaciones
Necesidad: crear un sistema de certificación de varios servidores Unix interdependientes con varias BBDD Oracle distribuidas para poder llevar a cabo las tareas de certificación de la empresa.
Situación previa: se disponía de un sistema de certificación pero no se estaba seguro de que fuera exactamente igual que el entorno de producción y no funcionaba correctamente, entre otras cosas el sistema de réplicas entre las BBDD. Por lo que se decidió volver a crear el entorno desde cero.
Integrantes del proyecto: yo como administrador de BBDD y otro técnico de sistemas para la configuración de los servidores.
Descripción del sistema: Clusters de HP con BBDD distribuidas Oracle.
Implementación: A partir de los backups de las máquinas de producción se reprodujeron los servidores mientras que las BBDD hubo que crearlas de manera especial porque sino las replicas no funcionaban. Apuntaban a las tablas de producción en vez de las de certificación. La solución consistía en crear la BBDD, los distintos usuarios con sus esquemas y finalmente las tablas replicadas una por una apuntando a las de certificación.
Coste del proyecto: 40 días x 2 técnicos
Mantenimiento del sistema informático de un banco de negocios
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
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
Dimensionamiento de un sistema tras una fusión
Las fusiones de empresas conllevan muchos cambios y aparte de que puedan sobrar personas hay que redimensionar los sistemas y eliminar todo lo innecesario.
Cliente: un banco, antes dos
Necesidad: Comprobar si el sistema informático de uno de los bancos tendría capacidad suficiente para atender a los clientes de los dos.
Situación previa: uno de los bancos acababa de invertir mucho dinero en un sistema informático moderno y se quería ver si había que ampliarlo para alojar el negocio de los dos.
Condicionantes del proyecto: Se tenía mucha prisa para llegar a una conclusión.
Descripción del sistema: un cluster unix de Sun, funcionando con el gestor de transacciones Tuxedo sobre una BBDD de Oracle. Además se utilizaba MQseries para comunicación con el Mainframe del banco matriz.
Implementación: se llevaron en paralelo dos métodos de evaluación. Uno de ellos consistía en evaluar con la ayuda de un programa cuanto aumentaría la carga de los diversos parámetros del sistema cuando se tuvieran a todos los clientes que se estimaba (cuatro veces más). El otro consistía en hacer una simulación real de la nueva carga. Para ello creé una BBDD con cuatro veces más datos en clientes y en las tablas relacionadas. Sobre ella se inyectaron las transacciones que se estimaba que se producirían una vez fusionados y se midieron los tiempos de respuesta. El primer método, el de la estimación, determinó que había que aumentar el sistema. El segundo que había que aumentarlo aún más pero comprobé que la carga la producían un par de peticiones al sistema y tras optimizar las consultas Oracle que incluían, el resultado fue que había menos carga sobre el sistema que en la situación de partida con cuatro veces menos clientes. Con lo cual se llegó a la conclusión de que no hacia falta ninguna ampliación, pero como estaba aprobado el presupuesto de todas maneras se amplió por si acaso, aunque no en la medida que se había previsto.
Coste del proyecto: 15 días x 3 técnicos+consultoría de dos empresas
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.
Copias de seguridad con Veritas Netbackup
Los datos no se pueden perder. Es necesario tener un sistema fiable de copias de seguridad. Y esto no quiere decir que basta con elegir un buen programa, hay que llevar la política correcta de copias para cada empresa y comprobar que se recuperan los datos en el tiempo que se estime como adecuado para cada uno de los escenarios posibles de pérdidas de datos.
Cliente: un banco
Necesidad: Diseñar y operar un sistema de copias de seguridad para el cluster que iba a llevar la operativa del banco.
Situación previa: el sistema anterior dependía de un mainframe de IBM en el centro de datos del banco matriz, que llevaba su propio sistema de copias.
Condicionantes del proyecto: debería interferir lo menos posible con el funcionamiento normal del banco.
Descripción del sistema: un cluster de Sun con una base de datos Oracle en modo Archivelog.
Solución elegida: Veritas Netbackup, ahora de Symantec, con un robot de cintas y un agente para Oracle.
Implementación: Diseñé la política de copias en colaboración con los encargados del banco para definir la frecuencia de copias, el período de retención y los requisitos de recuperación. Así se estableció una copia completa los fines de semana y copias incrementales todas las noches por duplicado, una de las cuáles se enviaba a las instalaciones del banco central todos los días. Se hicieron pruebas de recuperación de datos con medición de tiempos y del sistema entero. Durante el proyecto hubo que migrar el cluster a otra ubicación y se puso a prueba una vez más el sistema de recuperación. Durante todo el proyecto trabajé en colaboración con un informático del banco para que pudiera continuar operando el sistema una vez que terminara.
Coste del proyecto: 100 días x hombre + licencia de Netbackup con agente de Oracle+robot de cintas.
Eduardo Casais Padilla 