La semana pasada hablamos sobre la importancia de que un proveedor de IT cuente con un Disaster Recovery Plan que permita recuperar datos, hardware y software ante eventualidades inesperadas. También contamos cómo las soluciones de Planexware garantizan la continuidad de los negocios al tener un DRP y un Sistema de Gestión de la Calidad certificado bajo las normativas ISO 9001:2015.
Para continuar en tema, decidimos compartir una nota de Sebastián de Toma, publicada en Infotechnology:
“Los planes para recuperación de desastres —palabra ominosa si las hay— se trazan ‘por las dudas’, según el decir popular. Pero los inconvenientes son más comunes de lo que podría pensarse. No solo involucran un problema externo como un incendio, un terremoto o un corte de luz masivo, sino que además incluyen ataques de ransomware y el no tan improbable error humano azaroso.
El 72% de los consultados por el Instituto Ponemon este año, “sienten que son más ciber resistentes que el año pasado” pero, aclaran, se trata de una “falsa sensación de seguridad” ya que, para 77% de ellos, no existe hoy un plan de respuesta a incidentes aplicado de manera consistente en toda la empresa. Un estudio seminal del tema, realizado por Touche Ross, indica que el 90% de aquellas organizaciones que enfrentaron un desastre mayor sin tener un plan de recuperación no sobreviven a largo plazo.
Este hecho en particular tiene una incidencia directa en la actitud que se toma una vez que el incidente tiene lugar. Hablar de Disaster Recovery, los planes que hacen las empresas cuando todo sale mal, es el ‘cuco’ de la IT: nadie quiere confesar que ha fracasado. Se habla de lo que hay que hacer antes y lo que hay que hacer después pero poco de ‘manejo de crisis’.
Quizá haya razones de peso para no querer hacerlo: las estadísticas del sector hablan de que el 30% de todas las empresas no tienen preparados un Disaster Recovery Plan (DRP) por lo que, cuando suceden, las desgracias tienden a ser particularmente vergonzosas. Puntualmente, en la Argentina, solo 15 por ciento tienen en cuenta esquemas de recuperación de desastres y de continuidad de negocio, informa Diego Jiménez Torres, líder Regional de Producto de IFX Networks. ‘Sin embargo —agrega—, se ha incrementado la importancia de estos temas, por inconvenientes presentados en la región como ataques de negación de servicio o ransomware’.
Si sucede, conviene
Si todo falla, ¿qué ocurre? ¿Cuáles son las historias que nadie se anima a contar en voz alta, esas que se charlan en los pasillos y, de un tiempo a esta aparte, aparecen lentamente en publicaciones en redes sociales? Algunos y algunas se animan a la impiedad del on the record. Son, claro, los casos de éxito, donde todo vuelve a la normalidad gracias a la pericia del equipo de IT. Es el caso de Gustavo Domínguez, ingeniero de Citrix para América latina de habla hispana. Le tocó vivir varios casos de catástrofe pero recuerda especialmente uno, hace más de siete años cuando tuvo lugar un terremoto en Chile y todos tuvieron que dejar de trabajar durante un tiempo. Esto incluía a los bancos y hubo algunos que estuvieron fuera de línea hasta una semana, aunque Domínguez prefiere no dar nombres. En el que él trabajaba con Citrix, colocaron un Data Center en remolques y a las 24 horas ya estaban atendiendo usuarios finales con conectividad 3G.
La falla puede llegar desde diferentes lugares, casi infinitos. Sandra Boidi, CIO de la empresa de Recursos Humanos Randstad, cuenta que tuvieron una “falla importante” no hace muchos meses. En sus palabras: ‘Vinieron a poner los UPS. Al otro día empezó a caerse todo, el del storage y el de la contingencia. Pusimos ticket enIBM y justo cuando nos estábamos por ir a contigencia nos dimos cuenta de que no habían energizado una de las dos fuentes y como trabaja con fuentes redundantes se caía. A la hora estaba solucionado’, relata.
Incluso puede fallar cuando se cree que se hizo todo bien. Eso es lo que le sucedió a una importante telco del norte de América del sur en 2011, según le relata a Infotechnology una fuente cercana a la situación. Estaban realizando un upgrade de versión del sistema que gestiona todos los dispositivos en el país: cable módems, líneas de teléfonos IP, etcétera. Intentaron aprovechar el fin de semana largo, “con media ciudad de Bogotá de viaje, momento ideal”. El planeamiento de la migración se realizó con meses de anticipación, trabajando al unísono equipos de allá y de la Argentina. “A las dos, bajamos todas las palancas y se desconectaron los equipos. Para las cinco teníamos todo hecho y subimos las palancas: se reiniciaron los cablemódems, y los teléfonos, pero ninguno se conectaba a internet. Media Bogotá sin conexión. A las siete de la tarde empiezan las quejas en el Call Center.” Los equipos se quedaron pidiendo IP en loop y saturaron la red. “La bola de nieve se hizo inmanejable. A las ocho, apareció un gerente de Telmex a golpear las mesas, el Call Center estaba incendiado y no había un roll back planeado porque todo se había testeado antes y había salido OK. Fuimos Trending Topic global”, dice la fuente. Lograron reponer el servicio el domingo y el lunes estaba todo funcionando correctamente. Al final, ¿qué fue lo que falló? “A alguien se le ocurrió aplicar un patch de seguridad en el CMTS, el dispositivo a donde se conectan los cablemódems, sin avisarle al resto. Esta versión no había sido testeada, y por eso sucedió lo que sucedió”, cierra el entrevistado.
También están los imponderables, esas cosas que no deberían ocurrir, por las que nadie planea. Los centros de cómputos están preparados para incendio y cortes de luz, pero no para inundaciones… en un piso 10. Esto pasó no hace mucho en una compañía dedicada al Oil & Gas. El plan de contingencia existía pero resultó insuficiente y no estaba preparado para una inundación, dice uno de los protagonistas del proceso. “Por suerte el ERP estaba en la nube pero se dañó el acceso a los discos compartidos e hizo falta recuperar backups y armar un Data Center paralelo en otra oficina, sin las normas de seguridad pertinentes. De hecho, los accesos a esa oficina quedaron abiertos e hizo falta poner guardias de seguridad”, cuenta otro voluntario.
Otro ejemplo llamativo y corto, señal de que “la capa ocho”, es decir, el error humano, está a la vuelta de la esquina. Cual cuento de hadas, Juan D’Alessandro, director de Servicios de Softtek para América Latina, relata el caso de una empresa que tenía una nube híbrida, con datos en servidores propios y en la nube, y que estuvo a punto de perder los legajos de todos sus empleados, alojados en Microsoft Azure. “Básicamente, dejaron de pagar. Lo tenían en una tarjeta de crédito que se venció, los avisos de falta de pago cayeron al spam y les terminaron por cancelar la suscripción.” Lo malo es que Microsoft “les pisó el espacio” y los datos se perdieron. La historia, más allá de la moraleja, tiene final feliz: lo terminaron recuperando por unas herramientas propias de backup que tiene los de Redmond. “Hicieron un backup de una máquina virtual que se había levantado una semana antes. Prácticamente no se perdieron datos.”
¡Socorro!
Uno de los problemas, al menos dentro de la Argentina es que “la inversión en contingencia es por regulación y no por business value directo, posiblemente porque el ambiente de negocios es muy chato”. La persona que hace este lapidario juicio es un vendedor consultivo de Seguridad de la Información con más de 20 años de experiencia que prefiere que su nombre no se publique. “Acá hay un tema cultural. En Chile, por ejemplo, convivía con la posibilidad de tener terremotos y todo se hace pensando en eso. Y en la Argentina no hay nada de eso, al menos en los mayores centros urbanos”, dice Juan Santos, especialista de área de Soporte global de Red Hat. Todas las empresas tienen que pensar que su core es IT, aunque no lo sea, porque como mínimo todas necesitan de sistemas para facturar, dice el especialista.
Un ejemplo global pero con toque argentino. Una empresa líder en turismo, con fuerte presencia en la Argentina, experimentó un evento de características catastróficas durante el año 2016. Cuenta alguien que trabajó allí que su Disaster Recovery Plan era “AWS-dependiente”. “Muchos lo sabíamos pero era difícil llevar el tema hacia arriba. Además, 99% del tiempo Amazon tiene uptime. ¿Cómo convencés de gastar miles de dólares para tener una infraestructura replicada en otro ‘por las dudas’?”. Hasta que un día AWS falló, puntualmente en los Data Center donde tenían sus sistemas críticos. El relato oral transmite la gravedad de la situación. “Atamos todo con alambre y el sitio funcionaba a medias, casi no hubo ventas, y todos estaban desesperados. En Sistemas éramos tres personas para mantener corriendo 600 sistemas, y no exagero. Íbamos tapando agujeros del barco con las manos para que no se vaya a pique.” En la Argentina, dice la fuente, no hay tiempo para “brainstormear” el DRP. “Siempre hay cosas más urgentes.”
24 horas después, el sistema continuaba errático y comenzaron a discutir cambiar de región. En ese momento descubrieron un nuevo problema: esa parte del DRP tampoco estaba pulida. “¿Cómo recreamos toda la infraestructura rápidamente y sin errores? Hoy, lo haríamos con herramientas como Terraform pero en esa época estaba todo muy verde; también podés usar el VPC Peering, donde AWS te conecta a nivel redes dos regiones para que funcionen a alta velocidad, algo que entonces tampoco existía.” Pero, incluso ahora, la posibilidad de migrar a otro sitio no existe cuando se trata de grandes aplicaciones. Hoy en día, este especialista trabaja con otro cliente, más grande aún que le permite “granularizar” los sistemas, por lo que él tiene a su cargo solo 30 servidores. “Tampoco voy a llorar, por algo se nos paga lo que se nos paga”, afirma.
¿Qué tienen que hacer las empresas y las instituciones para evitar que todo esto no pase? ¿O, por lo menos, para minimizar sus efectos? Dice Jiménez, de IFX: “La conectividad, el plan de comunicación, la seguridad y el hecho de evitar falsos positivos a la hora de levantar el esquema de contingencia es lo más importante. Las compañías deben tener claro cuáles son sus ambientes críticos y deben seleccionar qué servicios deben tener sí o sí en caso de presentarse un desastre.”
En este sentido, Santos menciona que se encuentra “seguido” con empresas que no suelen estar preparadas para una eventualidad. “No tienen una política definida más allá de solucionar el problema”. Es por esto que desde Citrix Domínguez argumenta que el negocio de los planes de recuperación seguirá creciendo en las industrias “tradicionales”, como las manufacturas y el retail, empresas donde el core del negocio pasa —a priori—por otro lado. Una posibilidad es ir hacia opciones de DRP como servicio, soluciones cada vez más populares y algo muy factible desde el punto de vista de Jiménez por las razones que expone a continuación. “En un mercado donde todo se comercializa por servicio, no es lógico que una empresa esté invirtiendo un alto capital en soluciones que no van a ser escalables.”
Jorge Abreu, DevOps en Edrans, cuenta que hay empresas que hacen simulacros de ataques de ransomware “para ver quiénes de sus empleados pican”. Y, dice, “los resultados son siempre nefastos”. Es que parte de un DRP exitoso es la práctica recurrente y el chequeo de todos los componentes (grupos electrógenos, backups, etcétera): ya lo dice el antiguo adagio del mundo artístico, para llegar al Carnegie Hall, una sala de conciertos enNueva York, un músico necesita “práctica, práctica, práctica”. Y, la realidad es que por más completo y practicado que esté el DRP, siempre hay algo que se puede escapar, según Abreu.
Por eso es que no hace mucho apareció una nueva rama de sistemas llamada Chaos Engineering. Así lo explica el entrevistado: “Uno puede decir ‘bueno, hicimos todos estos monitores y automatizaciones, así que se supone que no importa lo que se caiga, la empresa tiene que poder vender el producto igual’, y entonces ponés en marcha herramientas que sirven para generar caos o lo podés hacer a mano, apagar, desconectar o romper algún equipo o sistema. Ahí podés ver si realmente tenés los procedimientos o las automatizaciones preparadas para un caso real”. Cuando una empresa u organización logra ejecutar este tipo de acciones “es porque está jugando en ligas mayores en cuanto a ‘estabilidad’ y ‘resiliencia’”, subraya Abreu. Por citar un ejemplo, Netflix ha sido pionero con este tipo de iniciativas con su “mono revienta sistemas” y como lo desarrollaron en Open Source, se puede encontrar en GitHub.
Hay una frase que dijo Reed Hoffman, el fundador de Linkedin, sobre cómo funcionan muchos departamentos de Sistemas y que resume la sensación que queda después de encarar esta breve investigación. “Saltás de un precipicio y armás el avión mientras vas camino al piso.”