Hace unas semanas se produjo una falla global de los servicios de Facebook, Instagram y Whatsapp. Veamos qué pasó y qué lecciones podemos aprender. Lo primero es entender la automatización de procesos. En los servicios globales y distribuidos, importa mucho el uptime (una caída es noticia global y afecta el valor de la empresa en la bolsa). A medida que aumenta el número de nueves en el uptime, aumenta la complejidad, ya que se requieren servicios más robustos y distribuidos, y queda muy poco tiempo disponible para realizar cambios en el software (como mejoras o correcciones) o reemplazar servidores o equipos que fallen.
Por ejemplo, si un servicio tiene un uptime de 99,5%, podrá estar abajo como máximo 3 hrs y 39 minutos en el mes. Ahora, si el uptime es de 99,9%, esto equivale a una indisponibilidad máxima de 43 minutos y 49 segundos, y si necesitamos un 99,99%, esto implica solo disponer de 4 minutos y 22 segundos. El tiempo de indisponibilidad (la diferencia al 100%) se denomina "error budget", y es usado por estas empresas para introducir mejoras a sus sistemas, ya sean correcciones (parches) o nuevas funcionalidades.
Es decir, Facebook tiene menos de 4 minutos y 22 segundos para hacer todos los cambios. Esto es imposible de hacer por humanos, por lo que la automatización de los cambios es un requerimiento esencial del servicio.
Infraestructura
Otro aspecto aspecto importante es que Facebook tiene sus propios datacenters, globalmente distribuidos e interconectados por fibra por sus propios equipos de comunicación. El 4 de octubre recién pasado se produjo el apagón mundial de los servicios de Facebook, Instagram y Whatsapp (que son parte de la misma empresa). El causante del problema fue un sistema que administra la
capacidad de red de la empresa globalmente (este es el detalle publicado por la empresa).
En resumen, durante un trabajo rutinario de mantención se ejecutó un comando para determinar la
capacidad global del backbone de la red, lo que produjo la desconexión global de todos los datacenters de Facebook. Para hacer peor el problema, los DNS de Facebook se desconectan si no hay comunicación con sus datacenters (uso de protocolo de ruteo BGP). En otras palabras, los mismos ingenieros de la compañía no podían acceder a los sistemas de emergencia, ya que la
resolución de nombres no funcionaba. Además, los altos estándares de seguridad implementados están diseñados para hacer muy difícil que una persona tenga acceso a los equipos y, más aún, que tenga capacidad de manipularlos. Todo esto aumentó el tiempo de reparación (Mean Time To Recovery, MTTR).
Durante la caída, que tomó muchas horas en resolverse, el precio de la acción cayó fuertemente. En las redes circulaban todo tipo de teorías, que Facebook había sido víctima de un hackeo por parte de Rusia, China o Corea del Norte. Que la bases de datos de usuarios estaban a la venta en la dark web. Ambas falsas.
¿Qué podemos aprender de este caso?
- Primero, que en la medida que los servicios aumentan su disponibilidad, mayores serán las exigencias de automatizar procesos.
- Segundo, testing, testing, testing. La condición que generó la falla no había sido probada.
- Tercero, la dicotomía entre disponibilidad y seguridad. Como dice la historia, entre más seguridad, más tiempo se tardará en resolver un incidente (esto también lo vivió Google en una falla mundial), hay que tener en cuenta este escenario en el diseño de los servicios.
- Cuarto y último, la estrategia comunicacional. Si Facebook hubiese actuado tempranamente, se hubiesen acallado las especulaciones. Es necesario contar con una estrategia comunicacional para enfrentar escenarios de fallas severas.
