{"id":32365,"date":"2019-10-11T14:13:59","date_gmt":"2019-10-11T17:13:59","guid":{"rendered":"https:\/\/test.planexware.com\/?p=32365"},"modified":"2019-10-11T14:13:59","modified_gmt":"2019-10-11T17:13:59","slug":"como-superar-un-desastre-informatico-en-la-empresa-y-vivir-para-contarlo","status":"publish","type":"post","link":"https:\/\/test.planexware.com\/es\/como-superar-un-desastre-informatico-en-la-empresa-y-vivir-para-contarlo\/","title":{"rendered":"C\u00f3mo superar un desastre inform\u00e1tico en la empresa y vivir para contarlo"},"content":{"rendered":"

La semana pasada hablamos sobre la importancia de que un proveedor de IT cuente con un Disaster Recovery Plan<\/a> que permita recuperar datos, hardware y software ante eventualidades inesperadas. Tambi\u00e9n contamos c\u00f3mo las soluciones de Planexware<\/strong> garantizan la continuidad de los negocios al tener un DRP y un Sistema de Gesti\u00f3n de la Calidad certificado bajo las normativas ISO 9001:2015.<\/strong><\/p>\n

Para continuar en tema, decidimos compartir una nota de Sebasti\u00e1n de Toma, publicada en Infotechnology:<\/p>\n

\u00abLos planes para recuperaci\u00f3n de desastres \u2014palabra ominosa si las hay\u2014 se trazan ‘por las dudas’, seg\u00fan el decir popular. Pero los inconvenientes son m\u00e1s comunes de lo que podr\u00eda pensarse. No solo involucran un problema externo como un incendio, un terremoto o un corte de luz masivo, sino que adem\u00e1s incluyen ataques de ransomware y el no tan improbable error humano azaroso.<\/em><\/p>\n

El\u00a072% de los consultados por el Instituto Ponemon este a\u00f1o, \u201csienten que son m\u00e1s ciber resistentes que el a\u00f1o pasado\u201d<\/strong> pero, aclaran, se trata de una \u201cfalsa sensaci\u00f3n de seguridad\u201d ya que, para 77% de ellos,\u00a0 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\u00f3n no sobreviven a largo plazo.<\/em><\/p>\n

Este hecho en particular tiene una incidencia directa en la actitud que se toma una vez que el incidente tiene lugar. Hablar de\u00a0Disaster 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\u00e9s pero poco de ‘manejo de crisis’.<\/em><\/p>\n

Quiz\u00e1 haya razones de peso para no querer hacerlo: las estad\u00edsticas 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\u00f3n de desastres y de continuidad de negocio<\/strong>, informa Diego Jim\u00e9nez Torres,\u00a0 l\u00edder Regional de Producto de IFX Networks. ‘Sin embargo \u2014agrega\u2014, se ha incrementado la importancia de estos temas, por inconvenientes presentados en la regi\u00f3n como ataques de negaci\u00f3n de servicio o ransomware’.<\/em><\/p>\n

\n
\n

Si sucede, conviene<\/em><\/h4>\n<\/div>\n<\/article>\n

Si todo falla, \u00bfqu\u00e9 ocurre? \u00bfCu\u00e1les 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?\u00a0 Algunos y algunas se animan a la impiedad del on the record. Son, claro, los casos de \u00e9xito, donde todo vuelve a la normalidad gracias a la pericia del equipo de IT. Es el caso de\u00a0Gustavo Dom\u00ednguez, ingeniero de\u00a0Citrix\u00a0para Am\u00e9rica latina de habla hispana. Le toc\u00f3 vivir varios casos de cat\u00e1strofe pero recuerda especialmente uno, hace m\u00e1s de siete a\u00f1os cuando tuvo lugar un terremoto en Chile y todos tuvieron que dejar de trabajar durante un tiempo. Esto inclu\u00eda a los bancos y hubo algunos que estuvieron fuera de l\u00ednea hasta una semana, aunque Dom\u00ednguez prefiere no dar nombres. En el que \u00e9l trabajaba con Citrix, colocaron un Data Center en remolques y a las 24 horas ya estaban atendiendo usuarios finales con conectividad 3G.<\/em><\/p>\n

La falla puede llegar desde diferentes lugares, casi infinitos. Sandra Boidi, CIO de la empresa de Recursos Humanos Randstad, cuenta que tuvieron una \u201cfalla importante\u201d no hace muchos meses. En sus palabras: ‘Vinieron a poner los UPS. Al otro d\u00eda empez\u00f3 a caerse todo, el del storage y el de la contingencia. Pusimos ticket enIBM y justo cuando nos est\u00e1bamos por ir a contigencia nos dimos cuenta de que no hab\u00edan energizado una de las dos fuentes y como trabaja con fuentes redundantes se ca\u00eda. A la hora estaba solucionado’, relata.<\/em><\/p>\n

Incluso puede fallar cuando se cree que se hizo todo bien. Eso es lo que le sucedi\u00f3 a una importante telco del norte de Am\u00e9rica del sur en 2011, seg\u00fan le relata a Infotechnology una fuente cercana a la situaci\u00f3n. Estaban realizando un upgrade de versi\u00f3n del sistema que gestiona todos los dispositivos en el pa\u00eds: cable m\u00f3dems, l\u00edneas de tel\u00e9fonos IP, etc\u00e9tera. Intentaron aprovechar el fin de semana largo, \u201ccon media ciudad de Bogot\u00e1 de viaje, momento ideal\u201d. El planeamiento de la migraci\u00f3n se realiz\u00f3 con meses de anticipaci\u00f3n, trabajando al un\u00edsono equipos de all\u00e1 y de la Argentina. \u201cA las dos,\u00a0 bajamos todas las palancas y se desconectaron los equipos. Para las cinco ten\u00edamos todo hecho y subimos las palancas: se reiniciaron los cablem\u00f3dems, y los tel\u00e9fonos, pero ninguno se conectaba a internet. Media Bogot\u00e1 sin conexi\u00f3n. A las siete de la tarde empiezan las quejas en el Call Center.\u201d Los equipos se quedaron pidiendo IP en loop y saturaron la red. \u201cLa bola de nieve se hizo inmanejable. A las ocho, apareci\u00f3 un gerente de Telmex a golpear las mesas, el Call Center estaba incendiado y no hab\u00eda un roll back planeado porque todo se hab\u00eda testeado antes y hab\u00eda salido OK. Fuimos Trending Topic\u00a0global\u201d, dice la fuente. Lograron reponer el servicio el domingo y el lunes estaba todo funcionando correctamente.\u00a0 Al final, \u00bfqu\u00e9 fue lo que fall\u00f3? \u201cA alguien se le ocurri\u00f3 aplicar un patch de seguridad en el CMTS, el dispositivo a donde se conectan los cablem\u00f3dems, sin avisarle al resto. Esta versi\u00f3n no hab\u00eda sido testeada, y por eso sucedi\u00f3 lo que sucedi\u00f3\u201d, cierra el entrevistado.<\/em><\/p>\n

Tambi\u00e9n est\u00e1n los imponderables, esas cosas que no deber\u00edan ocurrir, por las que nadie planea. Los centros de c\u00f3mputos est\u00e1n preparados para incendio y cortes de luz,\u00a0 pero no para inundaciones… en un piso 10. Esto pas\u00f3 no hace mucho en una compa\u00f1\u00eda dedicada al\u00a0Oil & Gas. El plan de contingencia exist\u00eda pero result\u00f3 insuficiente y no estaba preparado para una inundaci\u00f3n, dice uno de los protagonistas del proceso. \u201cPor suerte el ERP estaba en la nube pero se da\u00f1\u00f3 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\u201d, cuenta otro voluntario.<\/em><\/p>\n

Otro ejemplo llamativo y corto, se\u00f1al de que \u201cla capa ocho\u201d, es decir, el error humano, est\u00e1 a la vuelta de la esquina. Cual cuento de hadas,\u00a0Juan D\u2019Alessandro, director de Servicios de\u00a0Softtek para Am\u00e9rica Latina, relata el caso de una empresa que ten\u00eda una nube h\u00edbrida, 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. \u201cB\u00e1sicamente, dejaron de pagar. Lo ten\u00edan en una tarjeta de cr\u00e9dito que se venci\u00f3, los avisos de falta de pago cayeron al spam y les terminaron por cancelar la suscripci\u00f3n.\u201d Lo malo es que Microsoft \u201cles pis\u00f3 el espacio\u201d y los datos se perdieron. La historia, m\u00e1s all\u00e1 de la moraleja, tiene final feliz: lo terminaron recuperando por unas herramientas propias de backup que tiene los de Redmond.\u00a0 \u201cHicieron un backup de una m\u00e1quina virtual que se hab\u00eda levantado una semana antes. Pr\u00e1cticamente no se perdieron datos.\u201d<\/em><\/p>\n

\u00a1Socorro!<\/em><\/h4>\n

Uno de los problemas, al menos dentro de la Argentina es que \u201cla inversi\u00f3n en contingencia es por regulaci\u00f3n y no por business value directo, posiblemente porque el ambiente de negocios es muy chato\u201d. La persona que hace este lapidario juicio es un vendedor consultivo de Seguridad de la Informaci\u00f3n con m\u00e1s de 20 a\u00f1os de experiencia que prefiere que su nombre no se publique. \u201cAc\u00e1 hay un tema cultural. En Chile, por ejemplo, conviv\u00eda 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\u201d, dice\u00a0Juan Santos<\/strong>, especialista de \u00e1rea de Soporte global de\u00a0Red Hat.<\/strong>\u00a0Todas las empresas tienen que pensar que su core es IT, aunque no lo sea, porque como m\u00ednimo todas necesitan de sistemas para facturar, dice el especialista.<\/em><\/p>\n

Un ejemplo global pero con toque argentino. Una empresa l\u00edder en turismo, con fuerte presencia en la Argentina, experiment\u00f3 un evento de caracter\u00edsticas catastr\u00f3ficas durante el a\u00f1o 2016. Cuenta alguien que trabaj\u00f3 all\u00ed que su Disaster Recovery Plan era\u00a0\u201cAWS-dependiente\u201d.<\/strong> \u201cMuchos lo sab\u00edamos pero era dif\u00edcil llevar el tema hacia arriba. Adem\u00e1s, 99% del tiempo Amazon tiene uptime. \u00bfC\u00f3mo convenc\u00e9s de gastar miles de d\u00f3lares para tener una infraestructura replicada en otro \u2018por las dudas\u2019?\u201d. Hasta que un d\u00eda AWS fall\u00f3, puntualmente en los Data Center donde ten\u00edan sus sistemas cr\u00edticos. El relato oral transmite la gravedad de la situaci\u00f3n. \u201cAtamos todo con alambre y el sitio funcionaba a medias, casi no hubo ventas, y todos estaban desesperados. En Sistemas \u00e9ramos tres personas para mantener corriendo 600 sistemas, y no exagero. \u00cdbamos tapando agujeros del barco con las manos para que no se vaya a pique.\u201d En la Argentina, dice la fuente, no hay tiempo para \u201cbrainstormear\u201d el DRP. \u201cSiempre hay cosas m\u00e1s urgentes.\u201d<\/em><\/p>\n

24 horas despu\u00e9s, el sistema continuaba err\u00e1tico y comenzaron a discutir cambiar de regi\u00f3n. En ese momento descubrieron un nuevo problema: esa parte del DRP tampoco estaba pulida. \u201c\u00bfC\u00f3mo recreamos toda la infraestructura r\u00e1pidamente y sin errores? Hoy, lo har\u00edamos con herramientas como Terraform pero en esa \u00e9poca estaba todo muy verde; tambi\u00e9n pod\u00e9s usar el VPC Peering, donde AWS te conecta a nivel redes dos regiones para que funcionen a alta velocidad, algo que entonces tampoco exist\u00eda.\u201d Pero, incluso ahora, la posibilidad de migrar a otro sitio no existe cuando se trata de grandes aplicaciones. Hoy en d\u00eda, este especialista trabaja con otro cliente, m\u00e1s grande a\u00fan que le permite \u201cgranularizar\u201d los sistemas, por lo que \u00e9l tiene a su cargo solo 30 servidores. \u201cTampoco voy a llorar, por algo se nos paga lo que se nos paga\u201d, afirma.<\/em><\/p>\n

\u00bfQu\u00e9 tienen que hacer las empresas y las instituciones para evitar que todo esto no pase? \u00bfO, por lo menos, para minimizar sus efectos? Dice Jim\u00e9nez, de IFX: \u201cLa conectividad, el plan de comunicaci\u00f3n, la seguridad y el hecho de evitar falsos positivos a la hora de levantar el esquema de contingencia es lo m\u00e1s importante. Las compa\u00f1\u00edas deben tener claro cu\u00e1les son sus ambientes cr\u00edticos y deben seleccionar qu\u00e9 servicios deben tener s\u00ed o s\u00ed en caso de presentarse un desastre.\u201d<\/em><\/p>\n

En este sentido, Santos menciona que se encuentra \u201cseguido\u201d con empresas que no suelen estar preparadas para una eventualidad. \u201cNo tienen una pol\u00edtica definida m\u00e1s all\u00e1 de solucionar el problema\u201d. Es por esto que desde Citrix Dom\u00ednguez argumenta que el negocio de los planes de recuperaci\u00f3n seguir\u00e1 creciendo en las industrias \u201ctradicionales\u201d, como las manufacturas y el retail, empresas donde el core del negocio pasa \u2014a priori\u2014por otro lado. Una posibilidad es ir hacia opciones de DRP como servicio, soluciones cada vez m\u00e1s populares y algo muy factible desde el punto de vista de Jim\u00e9nez por las razones que expone a continuaci\u00f3n. \u201cEn un mercado donde todo se comercializa por servicio, no es l\u00f3gico que una empresa est\u00e9 invirtiendo un alto capital en soluciones que no van a ser escalables.\u201d<\/em><\/p>\n

Jorge Abreu, DevOps en Edrans, cuenta que hay empresas que hacen simulacros de ataques de ransomware \u201cpara ver qui\u00e9nes de sus empleados pican\u201d. Y, dice, \u201clos resultados son siempre nefastos\u201d. Es que parte de un DRP exitoso es la pr\u00e1ctica recurrente y el chequeo de todos los componentes (grupos electr\u00f3genos, backups, etc\u00e9tera): ya lo dice el antiguo adagio del mundo art\u00edstico, para llegar al\u00a0Carnegie Hall, una sala de conciertos enNueva York, un m\u00fasico necesita \u201cpr\u00e1ctica, pr\u00e1ctica, pr\u00e1ctica\u201d. Y, la realidad es que por m\u00e1s completo y practicado que est\u00e9 el DRP, siempre hay algo que se puede escapar, seg\u00fan Abreu.<\/em><\/p>\n

Por eso es que no hace mucho apareci\u00f3 una nueva rama de sistemas llamada\u00a0Chaos Engineering<\/strong>. As\u00ed lo explica el entrevistado: \u201cUno puede decir \u2018bueno, hicimos todos estos monitores y automatizaciones, as\u00ed que se supone que no importa lo que se caiga, la empresa tiene que poder vender el producto igual\u2019, y entonces pon\u00e9s en marcha herramientas que sirven para generar caos o lo pod\u00e9s hacer a mano, apagar, desconectar o romper alg\u00fan equipo o sistema. Ah\u00ed pod\u00e9s ver si realmente ten\u00e9s los procedimientos o las automatizaciones preparadas para un caso real\u201d. Cuando una empresa u organizaci\u00f3n logra ejecutar este tipo de acciones \u201ces porque est\u00e1 jugando en ligas mayores en cuanto a \u2018estabilidad\u2019 y \u2018resiliencia\u2019\u201d, subraya Abreu. Por citar un ejemplo, Netflix ha sido pionero con este tipo de iniciativas con su \u201cmono revienta sistemas\u201d y como lo desarrollaron en Open Source, se puede encontrar en GitHub.<\/em><\/p>\n

Hay una frase que dijo\u00a0Reed Hoffman<\/strong>, el fundador de Linkedin, sobre c\u00f3mo funcionan muchos departamentos de Sistemas y que resume la sensaci\u00f3n que queda despu\u00e9s de encarar esta breve investigaci\u00f3n. \u201cSalt\u00e1s de un precipicio y arm\u00e1s el avi\u00f3n mientras vas camino al piso.\u201d\u00a0<\/em><\/p>\n

 <\/p>\n

Ir a la nota original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u00e9n contamos c\u00f3mo las soluciones de Planexware garantizan la continuidad de los negocios al tener un DRP y un Sistema de Gesti\u00f3n de la Calidad certificado […]<\/p>\n","protected":false},"author":7,"featured_media":32366,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[19],"tags":[],"posts_flags":[],"class_list":["post-32365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-novedades"],"acf":[],"_links":{"self":[{"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/posts\/32365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/comments?post=32365"}],"version-history":[{"count":0,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/posts\/32365\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/media\/32366"}],"wp:attachment":[{"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/media?parent=32365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/categories?post=32365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/tags?post=32365"},{"taxonomy":"post_flag","embeddable":true,"href":"https:\/\/test.planexware.com\/es\/wp-json\/wp\/v2\/posts_flags?post=32365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}