La gerencia de Ingeniería de Sistemas, encuadrada en la dirección general de Organización y Sistemas de Información de Telefónica de España, es la responsable de la evolución y mantenimiento de las plataformas tecnológicas sobre las que corren los diferentes aplicativos de producción y gestión de la compañía.
Dicho de otra manera, este departamento se ocupa de controlar las plataformas mainframe, Unix y Windows implantadas en la compañía y decidir no sólo qué tecnología es necesario integrar, si no cómo se tienen que interrelacionar los diferentes elementos dentro de la arquitectura de sistemas global. Una tarea que, según Pedro Romera, gerente de Ingeniería de Sistemas, obliga a agudizar el ingenio para adaptarse permanentemente a una compañía donde los ritmos se crecimiento son muy elevados y en la que el time to market es un factor esencial. Ingeniería de Sistemas tiene que estar a la altura de estas demandas porque ya no es válida la estrategia de crecimiento vegetativo de los sistemas, sino que tenemos que ir por delante para ser capaces de atender cualquier necesidad de negocio.
Pero Telefónica no sólo demanda una evolución tecnológica que la sitúe en la vanguardia de su sector. La implantación de nuevos recursos tecnológicos debe además asegurar la alta disponibilidad de su arquitectura y la recuperación rápida de sus sistemas de información en caso de un hipotético desastre. Este es el motivo que impulsó el desarrolló del proyecto de Alta Disponibilidad de Negocio (ADN), cuya finalización está prevista a comienzos de este segundo trimestre, tras de dos años de intensos trabajos.
Con anterioridad a la puesta en marcha del ADN, Telefónica disponía de sistemas de recuperación de desastres que estaban soportados en algunas de las mejores tecnologías disponibles en aquellas fechas. Pero los acontecimientos provocados por el atentado de las Torres Gemelas y la disponibilidad de nuevas herramientas y soluciones, llevaron a la compañía a diseñar un proyecto con un objetivo realmente ambicioso: recuperar todos sus sistemas de información en un plazo máximo de cuatro horas. Los atentados del 11 de septiembre conmocionaron la vida de todos nosotros y también de las empresas. Telefónica y otras compañía se dieron realmente cuenta de la vulnerabilidad de sus sistemas y dieron el paso decisivo para construir sistemas eficaces de recuperación de desastres. Nuestro proyecto se ha desarrollado de forma muy rápida, utilizando las tecnologías más avanzadas del mercado y, en muchos casos, con una capacidad de innovación que ha sorprendido en ocasiones a nuestros propios suministradores. El objetivo es recuperar nuestros sistemas en un plazo máximo de cuatro horas, pero tal y como está avanzando la tecnología y nuestros conocimientos no descartamos la posibilidad de romper esta barrera, comenta Romera.
Cuando Telefónica propuso al mercado su proyecto causó lógicamente una enorme expectativa. Todas las grandes firmas – fabricantes y desarrolladores – ofrecieron sus soluciones y sus estrategias para desarrollar un proyecto de recuperación de desastres tan exigente como el que planteaba la compañía. Todas las ofertas se centraron en una arquitectura activo-pasivo que no convencía a Telefónica, hasta que la compañía decidió atacar el proyecto con sus propios recursos.
El área de Ingeniería de Sistemas tenía muy claro que su arquitectura de recuperación de desastres debía basarse en un modelo activo-activo innovador en aquellas fechas: pensamos que un esquema activo-pasivo adolece de cierta debilidad al no asegurar que en caso de desastre todo lo que tienes en producción en un centro pueda correr en el otro.
La arquitectura finalmente adoptada se soporta, por tanto, en dos centros activos donde la producción está repartida entre ambos y con balanceo de carga, de forma que si se cae uno, el otro entra inmediatamente en acción. Un modelo que implica, en palabras de Romera, que si tenemos, por ejemplo, 140 bases de datos en nuestro Unix, 70 están en un centro y 70 en el otro, que si tenemos tres máquinas mainframe, como es el caso, están repartidas en ambos centros con una capacidad de proceso similar, y también que nuestro data sharing está repartido de la misma manera. Para entender la dificultad del proyecto, pensemos por ejemplo en que nuestro DB2 era y es el más grande de Europa y que su distribución geográfica se convirtió en un auténtico reto tecnológico.
Por supuesto, los costes se evaluaron concienzudamente. No había referencias en el mercado de una instalación similar a la que se quería acometer y tampoco los suministradores parecían estar convencidos de una solución poco probada en aquellos momentos. Ante esta tesitura, Telefónica optó por desarrollar el proyecto por sí misma basándose en dos factores principales: suponía un ahorro de costes importante y nadie mejor que ellos podía conocer tan profundamente su arquitectura. Es cierto que en casos puntuales nos hemos tenido que dotar de recursos adicionales, de expertos en determinadas áreas, pero fundamentalmente hemos sido nosotros los que hemos montado la arquitectura, asegura el gerente de Ingeniería de Sistemas. Un modelo de arquitectura que ya está siendo empezado a evaluar por otras grandes empresas de nuestro país.
El comienzo del proyecto ADN, supuso también la puesta en marcha de un proyecto de consolidación en las áreas mainframe, Unix y Windows.
Con el de consolidar sus ordenadores centrales, Telefónica adquirió un nuevo servidor corporativo de IBM, el eServer z990. Esta máquina, la de mayor potencia instalada hasta la fecha en nuestro país, ha permitido a la compañía culminar su proyecto ADN. El nivel de criticidad de la instalación, así como su continuidad y futuras actualizaciones de versión a Z/OS aconsejaron la alternativa de IBM que viene a consolidar cinco servidores, con el consiguiente ahorro en administración, gracias a la reducción de la complejidad en las operaciones y a la mayor flexibilidad en la asignación dinámica de los recursos.
Este nuevo modelo incorpora una arquitectura de 64 bits de direccionamiento, que posibilita la reducción de los recursos necesarios de CPU para gestionar la migración de páginas de memoria central a expandida. Y además aporta un mayor ancho de banda de entrada/salida gracias a la conectividad FICOM y Gigabit Ethernet, que permiten una mayor flujo de información y minimiza la dependencia de establecer conexiones paralelas en las LANs. Asimismo exige menores costes en la interconexión entre centros (DWDM) al permitir conectar directores FICM en cascada.
Con esta adquisición, Telefónica de España ha duplicado prácticamente la capacidad de proceso de hace tan sólo un año.
En lo que respecta al
mundo UNix, también se plantearon diversas estrategias hasta que
finalmente se decidió realizar una consolidación por servicios, es
decir, por servicios de bases de datos, servidores web, servidores de
aplicaciones, LDAP, etc. Ahora tenemos todos los servicios consolidados
y siempre por parejas, es decir, cualquiera de los servicios están
repartidos en dos máquinas y ambas son activas. De los más de
seiscientos servidores Unix que tenía la compañía, quedan cerca de
trescientos; el resto se ha consolidado alrededor de cuatro servidores
SunFire 15000.
El mundo Windows está a la espera de un proyecto
similar, aunque vamos más despacio. La estrategia en este caso es
montar servidores centrales capaces de integrar los equipos actualmente
distribuidos entre los diferentes edificios de la compañía.</em><br />
