Facebook descartó, el martes 5 de octubre de 2021, que el apagón mundial de sus servicios el lunes durante seis horas fuera provocado por un ataque informático y lo achacó a un error técnico causado por la propia compañía.
En una entrada en el blog corporativo, el vicepresidente de infraestructura de Facebook, Santosh Janardhan, aseguró que la caída de los servicios “no fue causada por actividad maliciosa, sino por un error causado por nosotros mismos”.
La caída de Facebook y las plataformas de su propiedad (Instagram, WhatsApp y Messenger) dejó sin servicio a millones de cibernautas en todo el planeta, que acudieron a portales especializados como Downdetector para denunciar la situación.
Horas más tarde, el propio consejero delegado y cofundador de la red social, Mark Zuckerberg, pidió disculpas públicamente.
Según la firma de Menlo Park, los esfuerzos que la propia empresa ha venido realizando durante los últimos años para restringir el acceso a los sistemas y protegerla así ante posibles atacantes externos fueron una de las causas que ralentizaron el tiempo de respuesta para solucionar la caída.
“Creo que si el precio a pagar por una mayor seguridad del sistema en el día a día es una recuperación más lenta de los servicios, merece la pena”, apuntó Janardhan en el blog.
Este mismo martes, justo un día después del apagón de los servicios, una exempleada de la compañía testificó ante un subcomité del Senado de EE.UU. después de las filtraciones que ella misma hizo en los últimos días al diario The Wall Street Journal y tras revelar su identidad en una entrevista emitida el domingo pasado durante el programa 60 Minutos del canal CBS.
Frances Haugen dijo ante los senadores que Facebook antepone sus beneficios a la seguridad de los usuarios y oculta que sus plataformas son nocivas para los menores, fomentan la división social y debilitan la democracia.
Así la explicación íntegra de lo que en realidad pasó el lunes con Facebook y con las plataformas de su propiedad.
“Ahora que nuestras plataformas están funcionando como de costumbre después de la interrupción de ayer, pensé que valdría la pena compartir un poco más de detalles sobre lo que sucedió y por qué, y lo más importante, cómo estamos aprendiendo de ello.
Esta interrupción 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áticas, que consta de decenas de miles de millas de cables de fibra óptica que cruzan el mundo y conectan todos nuestros centros de datos.
Esos centros de datos vienen en diferentes formas. Algunos son edificios masivos que albergan millones de máquinas que almacenan datos y ejecutan las cargas computacionales pesadas que mantienen nuestras plataformas en funcionamiento, y otros son instalaciones más pequeñas que conectan nuestra red troncal a Internet en general y a las personas que usan nuestras plataformas.
Cuando abre una de nuestras aplicaciones y carga su feed o mensajes, la solicitud de datos de la aplicación viaja desde su dispositivo a la instalación más cercana, que luego se comunica directamente a través de nuestra red troncal a un centro de datos más grande. Ahí es donde la información que necesita su aplicación se recupera y procesa, y se envía de vuelta a través de la red a su teléfono.
El tráfico de datos entre todas estas instalaciones informáticas se gestiona mediante enrutadores, que determinan dónde 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ínea para el mantenimiento, tal vez reparando una línea de fibra, agregando más capacidad o actualizando el software en el enrutador.
Esta fue la fuente del apagón de ayer. Durante uno de estos trabajos de mantenimiento de rutina, se emitió un comando con la intención de evaluar la disponibilidad de la capacidad de la red troncal global, que accidentalmente cortó todas las conexiones en nuestra red troncal, desconectando efectivamente los centros de datos de Facebook a nivel mundial. Nuestros sistemas están diseñados para auditar comandos como estos para evitar errores como este, pero un error en esa herramienta de auditoría no detuvo correctamente el comando.
Este cambio provocó una desconexión completa de nuestras conexiones de servidor entre nuestros centros de datos e Internet. Y esa pérdida total de conexión provocó un segundo problema que empeoró las cosas.
Uno de los trabajos que realizan nuestras instalaciones más pequeñas 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íficas. Esas consultas de traducción 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és de otro protocolo llamado protocolo de puerta de enlace fronteriza (BGP).
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ón de una conexión de red no saludable. En la interrupción reciente, toda la red troncal se retiró de la operación, 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ía estaban operativos. Esto hizo imposible que el resto de Internet encontrara nuestros servidores.
Todo esto sucedió muy rápido. Y mientras nuestros ingenieros trabajaban para averiguar qué estaba sucediendo y por qué, se enfrentaron a dos grandes obstáculos: primero, no era posible acceder a nuestros centros de datos a través de nuestros medios normales porque sus redes estaban caídas, y segundo, la pérdida total de DNS se rompió. muchas de las herramientas internas que normalmente usamos para investigar y resolver interrupciones como esta.
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ó tiempo, porque estas instalaciones están diseñadas con altos niveles de seguridad física y del sistema en mente. Son difíciles de acceder y, una vez que estás dentro, el hardware y los enrutadores están diseñados para ser difíciles de modificar incluso cuando tienes acceso físico a ellos. Por lo tanto, tomó más tiempo activar los protocolos de acceso seguro necesarios para que las personas estén en el sitio y puedan trabajar en los servidores. Solo entonces podríamos confirmar el problema y volver a poner nuestra columna vertebral en línea.
Una vez que se restauró la conectividad de nuestra red troncal en las regiones de nuestro centro de datos, todo volvió a funcionar. Pero el problema no había terminado: sabíamos que volver a activar nuestros servicios de una sola vez podría causar una nueva ronda de accidentes debido a un aumento en el tráfico. Los centros de datos individuales informaban caídas en el uso de energía en el rango de decenas de megavatios, y revertir repentinamente tal caída en el consumo de energía podría poner en riesgo todo, desde sistemas eléctricos hasta cachés.
Afortunadamente, este es un evento para el que estamos bien preparados gracias a los simulacros de “tormenta” que hemos estado realizando durante mucho tiempo. En un ejercicio de tormenta, simulamos una falla importante del sistema desconectando un servicio, un centro de datos o toda la región”, concluyó Santosh Janardhan en su extenso mensaje.
Con información de Noticieros Televisa