Facebook outage global de 6 horas: anatomía del error BGP/DNS y lecciones operativas
El lunes 4 de octubre, alrededor de las 10:40 de la mañana hora de la Ciudad de México, Facebook, Instagram, WhatsApp y Oculus desaparecieron de internet. No fue una caída parcial, no fue degradación. Desaparecieron. Durante casi seis horas miles de millones de personas no pudieron acceder a las plataformas, los empleados de Facebook no podían entrar a sus propias oficinas con sus credenciales digitales y, según múltiples reportes internos, ni siquiera el equipo de respuesta podía coordinarse porque las herramientas internas dependían de la misma infraestructura caída.
La coincidencia con la entrevista de Frances Haugen en 60 Minutes la noche anterior y su comparecencia ante el Senado de Estados Unidos al día siguiente alimentó toda clase de teorías. La causa real, sin embargo, fue mucho más prosaica y mucho más instructiva: un comando mal ejecutado durante un mantenimiento de red rutinario.
Para cualquier empresa mexicana que opere infraestructura crítica, el episodio es un caso de estudio que conviene leer con frialdad.
Qué pasó técnicamente
La explicación oficial de Facebook, publicada esa misma semana por su equipo de ingeniería, se puede resumir así. Durante un mantenimiento programado, un comando intentado para evaluar la capacidad de la red troncal global tuvo el efecto no intencionado de desconectar todas las conexiones de la red troncal. Eso, a su vez, provocó que los servidores DNS autoritativos de Facebook se aislaran de internet.
La pieza clave es BGP, el Border Gateway Protocol, el protocolo que los grandes operadores usan para anunciar al resto del mundo qué bloques de direcciones IP son alcanzables a través de su red. Cuando los servidores DNS de Facebook perdieron conectividad con la troncal, el sistema interpretó que ya no debía anunciar esos prefijos al resto de internet y los retiró. Ese momento, el del BGP withdrawal, fue el visible: de un instante a otro, los resolvedores DNS del mundo entero respondieron que facebook.com, instagram.com y whatsapp.com simplemente no existían.
A partir de ahí, el problema dejó de ser solo de red y se volvió de acceso. Los sistemas internos de Facebook que sirven para diagnosticar la red estaban detrás de la misma red caída. Las herramientas para autenticar a los empleados en los edificios dependían de servicios que también estaban inalcanzables. La recuperación tomó horas porque hubo que enviar gente físicamente a los centros de datos para revertir los cambios manualmente.
Por qué importa más allá de Facebook
A primera vista uno podría pensar que esto solo le pasa a empresas con redes privadas globales. La realidad es que el patrón se repite a menor escala todo el tiempo: un cambio que parece controlado tira un servicio del que dependen otros, y esos otros incluyen las herramientas con las que se diagnostica y se recupera.
En México lo hemos visto en bancos, en operadores de telecomunicaciones y en plataformas de comercio electrónico. La forma exacta cambia, la dinámica no. Tres elementos suelen coincidir:
- Un cambio aprobado dentro de la ventana de mantenimiento, que en el papel parece de bajo riesgo.
- Una dependencia circular entre el servicio caído y las herramientas para repararlo.
- La ausencia de un canal de acceso fuera de banda que permita operar cuando lo principal no responde.
Las cuatro lecciones operativas que conviene llevarse
Más allá de la curiosidad técnica, el episodio deja recordatorios concretos para cualquier área de operaciones.
Acceso fuera de banda real, probado y vigente. Tener una consola de salto en un proveedor distinto, con credenciales que no dependan del directorio principal, no es paranoia: es lo único que permite recuperar un sistema cuando el sistema mismo es la falla. Y conviene probarlo cada trimestre, no cuando ya hay un incidente.
Change management que asuma que los cambios fallan. No basta con la ventana de mantenimiento y la lista de verificación. Cada cambio significativo debería declarar explícitamente cómo se revierte, en qué tiempo, y quién tiene autoridad para detenerlo si las métricas se mueven en la dirección equivocada. Ese plan de reversión debería estar documentado antes de que se ejecute el cambio, no improvisado durante la caída.
Monitoreo BGP y DNS independientes del proveedor. Si su monitoreo corre dentro de la misma nube que está cayendo, no le va a avisar de la caída. Servicios externos de monitoreo BGP y DNS, baratos comparados con el costo de no enterarse, son una capa básica que muchas empresas en México todavía no tienen.
Runbooks que asuman pérdida de herramientas. El runbook clásico empieza con "abrir la consola de monitoreo y revisar". Un buen runbook empieza con "si la consola no responde, hacer esto otro". Pensar en degradaciones en cascada es trabajo aburrido pero es exactamente el trabajo que paga en el peor día.
Lo que el incidente no fue
Vale la pena aclarar dos cosas para no caer en lecturas equivocadas. No fue un ataque cibernético, aunque la coincidencia con Haugen alimentó esa narrativa. Y no fue un fallo de hardware ni un evento natural: fue un error humano amplificado por el diseño del sistema. Esto último es la parte importante, porque significa que es prevenible y, por lo tanto, también repetible en otras organizaciones que no tomen las lecciones.
Para cerrar
La infraestructura a escala global no se cae por las razones espectaculares que uno imagina. Se cae por comandos rutinarios ejecutados en momentos rutinarios cuando alguien, en algún lado, asumió que la dependencia A no afectaba al servicio B. La defensa no es contratar más herramientas: es revisar con honestidad qué dependencias circulares existen en su operación y qué pasaría si la herramienta principal de diagnóstico fuera la que cayera.
Hacer ese ejercicio cuesta tiempo. No hacerlo cuesta horas de servicio caído frente al cliente, y eso, en México, también se traduce en confianza perdida y en titulares incómodos.
¿Tu empresa tiene plan out-of-band? Conversemos. En ALCA acompañamos a equipos de operaciones en México a revisar dependencias críticas y a poner a prueba sus runbooks antes del próximo incidente. Agenda una conversación.
