Han pasado más de 24 horas desde que internet se enfrentó a otro Apocalipsis. Durante aproximadamente 6 horas, Facebook, Instagram y WhatsApp estuvieron completamente inaccesibles en todo el mundo. Su caída, además, provocó que plataformas como Twitter y Telegram también presentaran problemas —por la enorme cantidad de usuarios que buscaban otra vía de comunicación—. Tras el desastre, Facebook ha salido a explicar exactamente qué provocó el fallo en su red.
Según Facebook, el desastre se produjo durante una sesión de mantenimiento de rutina en la «columna vertebral» de su red. Ingresaron un comando de configuración aparentemente inofensivo y, sorpresivamente, cortaron todas las conexiones en la red troncal, que a su vez desconectó los centros de datos que la compañía tiene repartidos por distintas partes del mundo. Sin embargo, este no fue el único inconveniente.
Facebook tiene un sistema para verificar que este tipo de configuraciones no provoquen fallos, pero no funcionó correctamente. «Nuestros sistemas están diseñados para auditar comandos como estos para evitar errores como este, pero un error en la herramienta de auditoría no detuvo correctamente el comando», mencionan. Una vez que la columna vertebral quedó desconectada, el siguiente en caer fue el protocolo de puerta de enlace de frontera (BGP), del que ya te hablamos en Hipertextual.
El BGP de Facebook, el gran perjudicado
¿Qué es el BGP? Básicamente, en un protocolo que anuncia a internet la existencia de una red. Si el BGP no funciona, internet no puede encontrarte. Esta es la razón por la que, durante varias horas, no hubo rastro de Facebook, desaparecieron. Los ingenieros de la compañía señalan que, cuando el protocolo no logra establecer conexión con los centros de datos (porque el comando provocó su caída previamente), los servidores DNS desactivan las tareas de anuncio del BGP.
Una vez que el BGP no puede cumplir sus funciones, el DNS sigue el mismo destino. Este último es un sistema que te permite acceder a una web desde su nombre de dominio —facebook.com, por ejemplo— en lugar de ingresar su dirección IP. ¿Serías capaz de aprenderte las direcciones numéricas de todas las webs que visitas diariamente? Por eso se creó el DNS, para traducir direcciones IP en nombres fácilmente reconocibles.
«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», añaden. Por otra parte, Facebook confirma que fue necesario enviar ingenieros para solucionar el problema con intervención manual, ya que, al estar caída toda su red, no era posible acceder a la configuración de manera remota.
Una experiencia de aprendizaje
Otra situación que quizá percibiste es que Facebook, Instagram y WhatsApp se recuperaron a paso lento tras solucionarse el problema en la red. ¿Por qué? Ellos mismos lo aclaran. «Sabíamos que volver a activar nuestros servicios de una sola vez podría causar una nueva ronda de accidentes debido a el aumento de tráfico. Los centros de datos individuales informaban caídas en el uso de energía en un 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 los cachés.»
Facebook concluye su reporte mencionando que esta experiencia es una mina de oro de aprendizaje que les permitirá evitarlo en el futuro. «Cada fracaso como este es una oportunidad para aprender y mejorar, y hay mucho que aprender de este. Después de cada problema, pequeño o grande, realizamos un extenso proceso de revisión para comprender cómo podemos hacer que nuestros sistemas sean más resistentes. Ese proceso ya está en marcha.»
Seguro que algún empleado nuevo quería la clave del internet y termino dañando todo
Exacto tu horrores digo tus errores te hacen más fuerte y mamadisimo !!! XD!!!
Fue un hacker
Pudo ser un héroe sin capa dentro de crapbook que quiso que el planeta sea un lugar mejor por algunas horas
Yo soy ingeniero en telecomunicaciones, y aunque Facebook quier dar a entender que sus sistemas de altera no funcionaron para auditar el comando, yo les puedo decir que he trabajado muchos años en NOCs, y tales sistemas automáticos no existen, normalmente una ventana de mantenimiento tiene asociado un change request el cual lleva un revisión interna para asegurarse que no tenga un afectación, seguro la persona a cargo de esto no reviso bien el change request
Es posible que no se revisara adecuadamente el RFC o bien que el impacto haya sido completamente subestimado por el Ingeniero de Telecom que iba a ejecutar el cambio .. o puedo ser un acto de desconocimiento del impacto del comando, aunque para mi es raro dado que quien administra las redes a ese nivel debe tener un conocimiento y experiencia muy alto…. pero, de todo hay en la viña del señor!!!!
Aprendieron una mamada, eso fue… Puro pinche faramaya, realmente un pendejo la cago en la config del DNS y se cago la conexión SSH. Lo que van hacer realmente es despedir a ese pendejo XD
Sin duda lo harán pero yo como programador si que me pongo a ver qué subrutina agregó o corrijo para tratar de evitar que ocurra ese error de nuevo. Cómo programador me encabrona una falla así. Y más si me van cagotear a mi y a mi equipo por qué por mi culpa perdieron un chingo de dinero. Y mi jefe quedó como pendejo.
En realidad fue un tema de routing y luego de DNS
Coincido con este diagnóstico. Después vino el tema de replicación de los DNS que es un proceso tardado.