Llegamos a ustedes gracias a:



Reportajes y análisis

Tras el desastre: Lecciones por aprender

[30/03/2010] Quizás suene mal decirlo, pero el terremoto que padeció Chile nos debe servir de oportunidad para aprender. El Perú puede pasar por un evento de igual magnitud, o superior, y debemos encontrarnos preparados para afrontar todos aquellos incidentes que se tenían previstos en los manuales de emergencias, charlas, y foros, pero también debemos encontrarnos preparados para afrontar aquellos problemas que no se previeron y que dejaron a la comunidad TI de Chile con un cierto descontento.

Era previsible que se fuera la energía eléctrica, y sin embargo los profesionales chilenos se quejan –sospechan- que algunas comunicaciones dejaron de funcionar por falta de energía. Las empresas tenían comunicaciones redundantes y, sin embargo, en los foros advierten que ambas -la principal y la redundante- se cayeron por igual. Internet, que nació de un proyecto militar que buscaba que las comunicaciones sobrevivieran a un ataque masivo, desilusionó en no pocos casos a la comunidad tecnológica.
A pesar de todo, la normalidad se reestableció poco a poco, pero no sin que se levantaran muchos cuestionamientos sobre si el sistema funcionó como debía funcionar. En base a esos testimonios recogidos en sitios chilenos y a la opinión de un ejecutivo TI de una de las instituciones financieras más grandes del país es que podemos esbozar algunas lecciones aprendidas a la luz -o penumbra- del 27 de febrero.
Las primeras horas
En el blog Bits, Ciencia y Sociedad de José Piquer, profesor del Departamento de Ciencias de la Computación de la Universidad de Chile, se hace un relato bastante pormenorizado de la forma en que se presentaron las fallas de Internet apenas producido el sismo.
Una característica muy extraña de cómo se comportó la Red en los primeros minutos de la tragedia, de acuerdo a Piquer, es que ésta trabajó bien hasta aproximadamente unos 30 minutos luego de producirse el terremoto. Luego las conexiones comenzaron a fallar. Prueba de este comportamiento es que en el NIC de Chile se registró un tráfico bastante bajo entre las 04:00 y 09:00 horas de aquel día, a pesar de que tenían una conexión permanente con los proveedores. Y, como señala el profesor, es relevante notar que los servidores de DNS secundarios de .cl en Estados Unidos, Brasil y Europa aumentaron enormemente su tráfico. Es decir, los servidores dentro de Chile se encontraban inalcanzables, tanto desde dentro como desde fuera del país.
Por el patrón de fallas, parece deberse a las muertes paulatinas de las UPS a medida que pasaba el tiempo y la energía eléctrica no se restablecía. La primera falla mayor ocurrió justo media hora después del sismo, hecho que hace muy improbable que haya sido un corte de fibra, lo que hubiera pasado a la misma hora del terremoto. La primera recuperación sucedió cerca del mediodía, que calza justo cuando la luz volvió al centro de Santiago, escribe en su blog. Reprobamos el test, añade.
Ahora ya con Internet reestablecida el hiperespacio y los sitios como el de Piquer se han convertido en lugares en los que los profesionales chilenos dan testimonio de lo que vivieron ese día y de lo que tuvieron que padecer incluso unos días después de la catástrofe.
Testimonios
Luego del sismo en la capital chilena, aquellos que no sufrieron daños personales o de infraestructura muy notorios, hicieron lo primero que hacen todos: tratar de comunicarse con la familia.
Obviamente las comunicaciones fueron imposibles para la mayoría pero no solo debido a la saturación de las líneas. Con el terremoto, los usuarios de los servicios de comunicaciones de una compañía chilena se dieron cuenta que su servicio telefónico (que incluye cable e Internet) depende de la misma conexión que su servicio de acceso a Internet, y que con la ausencia de energía eléctrica también se quedaron sin teléfono.
Otros, más ambientados con la tecnología, prendieron sus laptops e intentaron conectarse con sus servicios de correos electrónicos para enviar mensajes a sus familias. Aquí los testimonios son mixtos, algunos señalan que usando el servicio de Internet móvil pudieron conectarse, otros no lo lograron. En todo caso aquellos que sí pudieron conectarse se dieron con el chasco de que la mayoría de los sitios chilenos se encontraban caídos.
Al parecer todo fue obra de la falta de energía eléctrica y de una arquitectura que basa sus operaciones en sistemas de respaldo que funcionan durante unos 30 minutos.
Pero además se percibió que una de las fallas que desnudó el terremoto -y que dejó a varios sitios chilenos caídos- es la de tener el centro de datos principal y de respaldo en la misma ciudad.
Una de las instituciones financieras más grandes del país sufrió la caída de sus servicios debido a esto, e incluso uno de los ministerios del gobierno se vio obligado a comunicarse con sus usuarios -principalmente información sobre el estado de las carreteras- a través de un blog en Blogger y de su cuenta en Twitter. Sus servidores no funcionaron.
Con estos testimonios en la mano, decidimos preguntar a Carlos Herrera, gerente de Infraestructura y Operaciones de TI del Banco de Crédito, qué niveles de previsión se pueden tener para evitar estos problemas.
Soluciones
Creo que el problema sísmico que tiene el Perú nos hace enfrentar una de las peores cosas que le pueden pasar a un data center, que es que los equipos se muevan. El movimiento puede ocasionar que se dañen los equipos, que dejen de funcionar, que los cables se rompan, o que la conexión externa del data center con el resto del mundo se pierda. En general, mas que una tormenta o huracán creo que lo mas complicado para resguardar un data center son los sismos, sostiene el ejecutivo.
Ante estos eventos se pueden tener niveles de seguridad, dependiendo de cuánto uno se encuentre dispuesto a invertir y qué se desea proteger.
Un primer nivel de prevención sería el otorgado por las copias de respaldo. Uno podría crear cada cierto tiempo copias de respaldo y guardarlas en un lugar donde se encuentren seguras ante un gran sismo. Si este ocurriera y se dañaran los discos de datos se podría recuperar las copias.
¿Cada cuanto tiempo se puede hacer eso? Ello depende de la naturaleza de la información. Hay información que cambia mucho a la cual uno puede sacar respaldos diarios, o información que cambia menos y uno puede sacar un respaldo semanal o mensual.
Sin embargo, ese es un primer nivel básico de prevención contra el daño que puede causar un sismo. Uno puede tomar adicionalmente medidas un poco más caras.
Existen, por ejemplo, mecanismos de amortiguamiento de movimientos bruscos. Éstos son unas plataformas antisísmicas sobre los que uno coloca los equipos. Cuando se produce un sismo lo que malogra los equipos no es tanto el movimiento en sí sino la brusquedad del movimiento, entonces estas plataformas atenúan la brusquedad y permiten que los equipos se balanceen pero sin que haya un golpe contra los mismos. Lo normal es que esto ya sea suficiente para que los equipos sigan funcionando, sin embargo, esto representa un costo mayor.
Uno puede tener también otros niveles de contingencia y continuidad.
Uno puede tener otro centro de datos en otra zona de Lima, con diferentes características sísmicas. De esta forma uno de los data center se puede encontrar en la oficina principal y otro en otro en una zona que se vea menos afectada en caso de sismo, de manera que los riesgos se dividan. Tendría que ser muy fuerte el sismo para que ambos data center se vean dañados; y, nuevamente, esto implica una inversión adicional.
¿Otro data center?
El data center de contingencia no solo se podría encargar de almacenar los backups sino también de tener los equipos suficientes para levantar la operación en caso de que al data center principal falle. Herrera señala que los costos adicionales de este data center más seguro pueden ser divididos entre las empresas que lo utilicen, si lo utiliza más de una. Obviamente, si una firma fabrica un data center bastante seguro quizás éste también sea muy oneroso para cualquier empresa; sin embargo, si se dividen sus costos fijos entre varias empresas, éstas podrían gozar de esa posibilidad de contingencia.
Si se desea un nivel incluso más alto de seguridad se puede contar con un data center muy alejado de la zona sísmica. Si le ocurre algo a uno el otro puede seguir funcionando. Es una opción más costosa, porque necesita servicios de operación lejos de la sede central. Si los dos se encontraran dentro de Lima una empresa podría tener un equipo de operaciones que atienda a los dos; pero al encontrarse mas lejano el centro de contingencia, la firma tiene que contratar servicios de terceros o destacar personal en ese otro lugar, ya que en caso de desastre no necesariamente todas las personas de un centro pueden movilizarse al otro.
Cuando uno tiene operaciones que necesita que los equipos siempre se encuentren disponibles entonces el data center de contingencia tiene que estar preparado para asumir las funciones del otro en forma rápida y seguir operando por el tiempo que sea necesario, hasta que se reconstruya el anterior. ¿Cuándo puede ser? Depende de la falla que le haya ocurrido, si es una falla mayor es todo un problema porque construir un data center puede tomar medio año, entonces el de contingencia va a ser el primario durante bastante tiempo.
Si uno puede realizar sus operaciones sin mucho soporte tecnológico, la empresa podría tener un data center de contingencia que no de respuesta al minuto siguiente sino que tarde unos días en levantarse. En el fondo, el tiempo total que uno va a operar en el centro de contingencia va a depender de los daños al principal.
Al margen del nivel elegido hay algo que uno siempre debe hacer: hacer pruebas. Sea cual fuere la infraestructura que uno decida montar, uno tiene que tener procedimientos que va a activar cuando ocurra el desastre y que va a utilizar durante la recuperación del desastre, y éstos deben probarse una o dos veces al año. Uno no sabe cuándo van a ocurrir los desastres y ésta es la única forma de asegurarse que lo que uno implementó, funciona. Cierto que eso le añade un costo adicional, pero si uno quiere estar listo debe hacer estos ensayos, sostiene el ejecutivo.
Herrera se encuentra preparado. El banco tiene un centro de datos con estructuras muy sólidas, así que tendría que producirse un evento de gran magnitud para que sus data centers se vean afectados. Pero asumiendo que ocurra algo así, el banco cuenta con dos centros en Lima que pueden operar, cualquiera de ellos, todo el banco, eso hace que el riesgo lo tengan dividido. Sin embargo, asumiendo nuevamente, que el sismo sea de gran magnitud, el banco tiene un data center fuera de Lima que le sirve para operar en esa eventualidad. Y no hay forma de que un solo evento afecte a los tres centros.
Comunicaciones
Lo que falló en Chile además de la electricidad fueron las comunicaciones. No solo a nivel de hogar sino empresarial y gubernamental. Ese es un punto flaco en los planes ya que los data center pueden depender de la empresa, pero las comunicaciones dependen siempre de las operadoras.
En la práctica, uno puede tener centros bien preparados; pero si las comunicaciones se caen, es como que no estuvieran funcionando.
Ese es tal vez un siguiente nivel de seguridad, tener comunicaciones redundantes. Nosotros tenemos -a través de un servicio especial con los operadores- comunicaciones redundantes en todo el país. Si dejan de funcionar las comunicaciones en Lima nuestro data center fuera de Lima operaria con el resto del país sin pasar por Lima, pero ese es un servicio especial que no lo tiene nadie más, creo, sostiene el ejecutivo.
Sin embargo, en Chile algunos foristas señalaron que las comunicaciones de sus empresas se cayeron porque al parecer se compartía infraestructura.
Herrera señala que si uno tiene un enlace de datos y no dice para qué va a ser utilizado, los operadores pueden optimizar sus costos y usar la misma canaleta y la misma fibra y terminar con dos conexiones de diferentes operadores pero que corre por la misma infraestructura.
Sin embargo, si uno específicamente indica que lo que quiere son conexiones de contingencia que no coincidan en ningún punto, eso se puede conseguir. Uno puede pedir mapas y planos para saber por donde pasan cada una de las dos conexiones y se da cuenta si hay puntos de contacto o compromiso, pero es cuestión de que uno lo especifique así al momento de contratar el servicio, añadió.
¿Qué más se puede recomendar? Quería enfatizar en el tema de tener y ensayar planes de recuperación. Ya sea el nivel de redundancia y contingencia que elijan tener, tienen que ensayarlo; sino a la hora de usarlo no va a funcionar, finaliza Herrera.
Ensayar, ensayar y ensayar es la recomendación que podemos dar a partir de las lecciones aprendidas.
Jose Antonio Trujillo, CIO Perú