{"id":31654,"date":"2021-10-05T21:15:32","date_gmt":"2021-10-05T21:15:32","guid":{"rendered":"http:\/\/noticiastelered.com\/PortalDNoticias\/?p=31654"},"modified":"2021-10-05T21:15:38","modified_gmt":"2021-10-05T21:15:38","slug":"falla-en-mantenimiento-de-rutina-la-causa-de-la-caida-de-facebook-whatsapp-e-instagram","status":"publish","type":"post","link":"http:\/\/noticiastelered.com\/PortalDNoticias\/falla-en-mantenimiento-de-rutina-la-causa-de-la-caida-de-facebook-whatsapp-e-instagram\/","title":{"rendered":"Falla en mantenimiento de rutina, la causa de la ca\u00edda de Facebook, WhatsApp e Instagram"},"content":{"rendered":"\n

Redacci\u00f3n<\/strong> <\/p>\n\n\n\n

Noticias Telered <\/p>\n\n\n\n

Ciudad de M\u00e9xico.-<\/strong><\/p>\n\n\n\n

Despu\u00e9s de que el fundador de Facebook, Mark Zuckerberg, se disculpara por la ca\u00edda de dicha red social, adem\u00e1s de Instagram, WhatsApp y Messenger, la compa\u00f1\u00eda detall\u00f3 la causa de la interrupci\u00f3n del servicio.<\/p>\n\n\n\n

De acuerdo con un comunicado de Facebook, las plataformas dejaron de funcionar durante m\u00e1s de seis horas debido a una falla en el mantenimiento de rutina que cort\u00f3 todas las conexiones en la red troncal.<\/p>\n\n\n\n

La compa\u00f1\u00eda asegur\u00f3 que cada \u2018fracaso\u2019 como el apag\u00f3n del 4 de octubre es una oportunidad para aprender y mejorar y que ya realizan un extenso proceso de revisi\u00f3n para hacer m\u00e1s resistentes sus sistemas.<\/p>\n\n\n\n

As\u00ed explic\u00f3 Facebook la ca\u00edda de sus redes sociales: <\/p>\n\n\n\n

Esta interrupci\u00f3n fue provocada por el sistema que administra la capacidad de nuestra red troncal global. La columna vertebral es la red que Facebook ha construido para conectar todas nuestras instalaciones inform\u00e1ticas, que consta de decenas de miles de millas de cables de fibra \u00f3ptica que cruzan el mundo y conectan todos nuestros centros de datos.<\/p>\n\n\n\n

Esos centros de datos vienen en diferentes formas. Algunos son edificios masivos que albergan millones de m\u00e1quinas que almacenan datos y ejecutan las cargas computacionales pesadas que mantienen nuestras plataformas en funcionamiento, y otros son instalaciones m\u00e1s peque\u00f1as que conectan nuestra red troncal a Internet en general y a las personas que usan nuestras plataformas.<\/p>\n\n\n\n

Cuando abre una de nuestras aplicaciones y carga su feed o mensajes, la solicitud de datos de la aplicaci\u00f3n viaja desde su dispositivo a la instalaci\u00f3n m\u00e1s cercana, que luego se comunica directamente a trav\u00e9s de nuestra red troncal a un centro de datos m\u00e1s grande. Ah\u00ed es donde se recupera y procesa la informaci\u00f3n que necesita su aplicaci\u00f3n, y se env\u00eda de vuelta a trav\u00e9s de la red a su tel\u00e9fono. <\/p>\n\n\n\n

El tr\u00e1fico de datos entre todas estas instalaciones inform\u00e1ticas se gestiona mediante enrutadores, que determinan d\u00f3nde enviar todos los datos entrantes y salientes. Y en el extenso trabajo diario de mantener esta infraestructura, nuestros ingenieros a menudo necesitan tomar parte de la red troncal fuera de l\u00ednea para el mantenimiento, tal vez reparando una l\u00ednea de fibra, agregando m\u00e1s capacidad o actualizando el software en el enrutador.<\/p>\n\n\n\n

Esta fue la fuente del apag\u00f3n de ayer. Durante uno de estos trabajos de mantenimiento de rutina, se emiti\u00f3 un comando con la intenci\u00f3n de evaluar la disponibilidad de la capacidad de la red troncal global, que accidentalmente cort\u00f3 todas las conexiones en nuestra red troncal, desconectando efectivamente los centros de datos de Facebook a nivel mundial. Nuestros sistemas est\u00e1n dise\u00f1ados para auditar comandos como estos para evitar errores como este, pero un error en esa herramienta de auditor\u00eda no detuvo correctamente el comando.<\/p>\n\n\n\n

Este cambio provoc\u00f3 una desconexi\u00f3n completa de nuestras conexiones de servidor entre nuestros centros de datos e Internet. Y esa p\u00e9rdida total de conexi\u00f3n provoc\u00f3 un segundo problema que empeor\u00f3 las cosas.<\/p>\n\n\n\n

Uno de los trabajos que realizan nuestras instalaciones m\u00e1s peque\u00f1as es responder a las consultas de DNS. DNS es la libreta de direcciones de Internet, lo que permite que los nombres web simples que escribimos en los navegadores se traduzcan a direcciones IP de servidor espec\u00edficas. Esas consultas de traducci\u00f3n son respondidas por nuestros servidores de nombres autorizados que ocupan direcciones IP bien conocidas, que a su vez se anuncian al resto de Internet a trav\u00e9s de otro protocolo llamado protocolo de puerta de enlace fronteriza (BGP).<\/p>\n\n\n\n

Para garantizar un funcionamiento confiable, nuestros servidores DNS desactivan esos anuncios BGP si ellos mismos no pueden hablar con nuestros centros de datos, ya que esto es una indicaci\u00f3n de una conexi\u00f3n de red no saludable. En la interrupci\u00f3n reciente, toda la red troncal se retir\u00f3 de la operaci\u00f3n, lo que hizo que estas ubicaciones se declararan insalubres y retiraran esos anuncios de BGP. El resultado final fue que nuestros servidores DNS se volvieron inalcanzables a pesar de que todav\u00eda estaban operativos. Esto hizo imposible que el resto de Internet encontrara nuestros servidores.<\/p>\n\n\n\n

Todo esto sucedi\u00f3 muy r\u00e1pido. Y mientras nuestros ingenieros trabajaban para averiguar qu\u00e9 estaba sucediendo y por qu\u00e9, se enfrentaron a dos grandes obst\u00e1culos: primero, no era posible acceder a nuestros centros de datos a trav\u00e9s de nuestros medios normales porque sus redes estaban ca\u00eddas, y segundo, la p\u00e9rdida total de DNS se rompi\u00f3. muchas de las herramientas internas que normalmente usamos para investigar y resolver interrupciones como esta.<\/p>\n\n\n\n

Nuestro acceso a la red principal y fuera de banda estaba inactivo, por lo que enviamos ingenieros al sitio a los centros de datos para que depuraran el problema y reiniciaran los sistemas. Pero esto llev\u00f3 tiempo, porque estas instalaciones est\u00e1n dise\u00f1adas con altos niveles de seguridad f\u00edsica y del sistema en mente. Es dif\u00edcil acceder a ellos y, una vez que est\u00e1s dentro, el hardware y los enrutadores est\u00e1n dise\u00f1ados para ser dif\u00edciles de modificar incluso cuando tienes acceso f\u00edsico a ellos. Por lo tanto, tom\u00f3 m\u00e1s tiempo activar los protocolos de acceso seguro necesarios para que las personas est\u00e9n en el sitio y puedan trabajar en los servidores. Solo entonces podr\u00edamos confirmar el problema y volver a poner nuestra columna vertebral en l\u00ednea.<\/p>\n\n\n\n

Una vez que se restaur\u00f3 la conectividad de nuestra red troncal en las regiones de nuestro centro de datos, todo volvi\u00f3 a funcionar. Pero el problema no hab\u00eda terminado: sab\u00edamos que volver a activar nuestros servicios de una sola vez podr\u00eda causar una nueva ronda de accidentes debido a un aumento en el tr\u00e1fico. Los centros de datos individuales informaban ca\u00eddas en el uso de energ\u00eda en el rango de decenas de megavatios, y revertir repentinamente tal ca\u00edda en el consumo de energ\u00eda podr\u00eda poner en riesgo todo, desde sistemas el\u00e9ctricos hasta cach\u00e9s.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n

\n<\/p>\n

\n
Loading…<\/div>\n