Ahora que nuestras plataformas están funcionando con normalidad tras la interrupción de ayer, queremos compartir más detalles sobre lo ocurrido, sus causas y, fundamentalmente, lo que estamos aprendiendo del caso.
El episodio de ayer fue generado por un sistema que administra nuestra red troncal global. Esta red troncal fue construida por Facebook para conectar entre sí a todas las instalaciones de computación, las cuales consisten en decenas de miles de cables de fibra óptica que cruzan el mundo y conectan a nuestros centros de datos.
Los centros de datos son diferentes entre sí. Algunos son edificios muy grandes que albergan miles de máquinas que guardan datos y procesan pesadas cargas computacionales que, a su vez, mantienen a nuestras plataformas en funcionamiento. Otros centros de datos son espacios más pequeños que conectan nuestra red troncal con Internet y las personas que usan nuestros servicios.
Cuando abres una de nuestras apps y cargas tu Sección de Noticias o mensajes, el pedido de datos de la app viaja de tu dispositivo al centro de datos más cercano, que luego se comunica a través de nuestra red troncal con un centro de datos más grande. Allí es en donde se recolecta y procesa la información que necesita tu app, y que luego es enviada a tu dispositivo a través de la red.
El tráfico de datos entre todas estas instalaciones de computación es administrado por routers, que identifican a dónde enviar los datos entrantes y salientes. Y durante el exhaustivo trabajo diario de mantenimiento de esta infraestructura, nuestro equipo de ingeniería a menudo necesita desconectar una parte de la red troncal para su mantenimiento – quizá para reparar una fibra, agregar más capacidad, o actualizar el software en el propio router.
Este fue el origen de la interrupción de ayer. Durante una de las rutinas de mantenimiento, se ejecutó un comando para evaluar la disponibilidad en la capacidad en la red troncal global. Esto, involuntariamente, cortó todas las conexiones en nuestra red troncal, desconectando asimismo a los centros de datos de Facebook a nivel global. Nuestros sistemas están diseñados para auditar comandos como este y prevenir estos errores, pero un error en esa herramienta de auditoría impidió que el comando fuera interrumpido.
Ese error derivó en una desconexión total de nuestras conexiones de servidor entre nuestros centros de datos e Internet. Y esa pérdida total de conexión causó un segundo problema que agravó la situación.
Uno de los trabajos ejecutados por nuestras instalaciones más pequeñas es responder a los comandos de DNS (Domain Name System). El DNS es el directorio de Internet que traduce los nombres simples que escribimos en nuestros navegadores, a direcciones de servidor IP específicas. Estas consultas de traducción son respondidas por nuestros servidores de nombres autorizados que ocupan direcciones IP conocidas, que a su vez se anuncian al resto de Internet a través de otro protocolo llamado Border Gateway Protocol (BGP).
Para asegurar una operación estable, nuestros servidores DNS desactivan esos anuncios BGP si estos no se pueden comunicar con nuestros centros de datos, ya que es un indicador de una conexión de red inestable. En la interrupción de ayer, toda la red troncal fue removida de la operación, haciendo que esas direcciones se declararan inestables y retiraron los anuncios BGP. El resultado fue que nuestros servidores DNS se volvieron inalcanzables aún estando operativos. Esto, a su vez, hizo imposible que el resto de Internet pudiera encontrar nuestros servidores.
Todo esto ocurrió muy rápido. Y mientras nuestro equipo de ingeniería trabajaba para entender lo que estaba ocurriendo y porqué, se encontraron con dos grandes obstáculos: primero, la imposibilidad de acceder a nuestros data centers a través de nuestros canales habituales porque sus redes estaban desconectadas; segundo, la pérdida total de DNS inhabilitó muchas de las herramientas internas que usamos normalmente para investigar y resolver interrupciones de servicio como el de ayer.
Nuestro acceso principal a la red y nuestro acceso fuera de banda estaban deshabilitados, y por eso enviamos a nuestros ingenieros a los centros de datos para depurar y reiniciar los sistemas. Pero esto llevó tiempo, porque estas instalaciones están diseñadas con altos niveles de seguridad física y de sistema. Son difíciles de acceder y, una vez que estás adentro, el hardware y los routers están diseñados para que sean difíciles de modificar aún cuando tienes acceso físico a ellos. Por ello, tomó un tiempo extra desactivar los protocolos de seguridad necesarios para acceder a las instalaciones y trabajar sobre los servidores. Solo entonces pudimos confirmar el problema y restablecer nuestra red troncal.
Una vez que nuestra red troncal fue restaurada en todos los centros de datos, todos los sistemas volvieron a funcionar. Pero el problema no terminó allí, porque sabíamos que volver a activar nuestros servicios al mismo tiempo tenía el potencial de causar nuevas interrupciones por el pico de tráfico. Centros de datos individuales estaban reportando bajas de uso de corriente en rangos de decenas de megavatios, y revertir esa baja repentinamente podía poner en riesgo desde nuestros sistemas eléctricos hasta los cachés.
Afortunadamente, estamos preparados para este tipo de eventos gracias a los simulacros que llevamos a cabo desde hace tiempo. Durante estos ejercicios simulamos una falla grave de sistema al desconectar un servicio, centro de datos, o una región entera, y así probamos toda la infraestructura y el software comprometidos. La experiencia con estos ejercicios nos ha dado la confianza y la ductilidad para restablecer nuestros servicios y administrar cuidadosamente las crecientes cargas. Al final, nuestros servicios se restablecieron relativamente rápido sin reportar fallas sistémicas a nivel global. Y si bien hemos hecho un simulacro de desconexión de nuestra red troncal, definitivamente analizaremos nuevas formas de simular episodios como el de ayer.
Cada falla es una oportunidad para aprender y mejorar, y hay mucho que aprender de esta interrupción. Después de cada situación, grande o pequeña, hacemos un proceso de revisión exhaustivo para comprender cómo podemos mejorar la resiliencia de nuestros sistemas. Este proceso ya está activo.
Hemos hecho un trabajo extensivo para endurecer nuestros sistemas y dificultar el acceso no autorizado, y fue interesante ver cómo ese trabajo dificultó la recuperación de nuestros sistemas tras un episodio que no fue causado por una actividad maliciosa, sino por un error propio. Creo que este intercambio vale la pena: más seguridad en el día a día vs. una recuperación lenta de lo que, esperamos, fue un evento poco común. De ahora en adelante, nuestro trabajo será fortalecer nuestras pruebas y simulacros, y construir resiliencia para que eventos como el de ayer ocurran lo menos posible.