El análisis "post-morten" del apagón de Google

El día 2 de junio de 2019 demuestra la gran dependencia que tenemos de la nube

El domingo 2 de junio, durante 4 horas y 25 minutos, millones de personas en todo el mundo no pudieron acceder a Gmail, Youtube, SnapChat o incluso Google Cloud (del cual de sus servicios de computación en la nube dependen miles de clientes) provocando un impacto casi incalculable a diversas empresas y servicios. Esas más de 4 horas sólo fueron el tiempo contabilizado por Google, pero se extendió durante prácticamente todo el día y la noche, ya que los ingenieros tuvieron que deshacer todas las múltiples nuevas rutas que configuraron para poder mantener el servicio funcionando mientras reparaban el problema.

Dejando aparte la terrible sensación de inquietud que nos deja la dependencia absoluta que tenemos de los servicios en la nube, la causa de este apagón no fue un ataque, sino como suele ocurrir en muchos otros accidentes, un cúmulo de errores e imprevistos en cadena. Vamos a repasar lo ocurrido. Sobre las 2:45 am del domingo 2 de junio, se ejecutó una simple y habitual tarea de mantenimiento que en principio no tenía nada de especial. Para no dejar sin servicio a esa zona geográfica que se va a recibir dicho mantenimiento, los datos y los trabajos pendientes se enrutan hacia otras regiones para no afectar a los usuarios.

De repente, muchos de los clientes de estos servicios de Google detectaron varios problemas como alta latencia y errores de conexión en instancias ubicadas en las zonas us-central1, us-east1, us-east4, us-west2, northamerica-northeast1 y southameria-east1. Pero además, los servicios Google Compute Engine, App Engine, Cloud Endpoints, Cloud Interconnect, Cloud VPN, Cloud Console, Cloud Storage y un largo etcétera, dejaron de funcionar. Pero ¿qué había ocurrido? ¿cómo es posible que Google cometa estos errores y deje sin servicio a tantas empresas?

Figura 1. Errores detectados y su localización durante el incidente. Fuente.

En un centro de datos físico de Google (al final del artículo puedes encontrar un vídeo donde se visita uno de estos datacenters), todas las máquinas se reorganizan  dentro clústers lógicos los cuales tienen su propio software de gestión, para de esta forma ofrecer resilencia en caso de fallo de unos de estos gestores de clústers. Este software de gestión juega un rol muy importante dentro del mantenimiento automático de eventos, como la infraestructura que gestiona los cambios en la energía, por ejemplo. Cuando se ejecuta un trabajo (job) de este tipo en uno de estos clústers lógicos gestionado por un software de gestión, el resto de tareas que están en ejecución se mueven hacia otros clústers  que no están en mantenimiento o simplemente, se detiene el proceso hasta que termina dicha tarea de mantenimiento.

Parece ser que un par de configuraciones erróneas y un bug en un software específico fueron los principales culpables de este apagón tecnológico. El primero de los errores de configuración provocó que las regiones afectadas se pararan ya que pensaban que estaban bajo mantenimiento. El segundo error de configuración es un poco más extraño ya que afectó a los programas que antes hemos comentado de administración de clústers haciendo posible el apagado relacionado con el evento provocado por el primer fallo de configuración. Es decir, se incluyeron en la secuencia de apagado cuando esta no debería de estar habilitada por defecto. Finalmente, para añadir dramatismo al incidente, el programa que iniciaba los eventos de mantenimiento tenía un bug que afectó a la programación de las tareas.

Figura 2. Endpoints afectados. Fuente.

Resumiendo, la planificación de mantenimiento de los clústers de Google provocó toda una cadena de fallos, modificando y alterando por un lado las tareas de mantenimiento y por otro su programación. Google además de redirigir todo el tráfico de red hacia otros datacenters, también tuvo que parar todos estos procesos de mantenimiento prácticamente en todos sus centros de datos, una tarea realmente compleja y laboriosa. Google no cuenta demasiado detalle técnico en el informe que ha publicado sobre el incidente, así que sólo nos queda especular un poco sobre lo que ha podido ocurrir basándonos en dicha información.

El problema del cambio de configuración (detonante principal de la cadena de errores) puede haber sido provocado por una gran cantidad de factores, que pueden ir desde el humano (el más plausible) hasta otros más complejos como por ejemplo un cambio en algún flag de configuración de los GFE (Google Front End) o incluso una modificación en el tipo de cifrado que afectó a la seguridad de transporte de la capa de aplicación (ALTS) de la red interna, podrían haber provocado esta acción errática de eventos. Google debe de tomar nota de cómo se hace un buen análisis post-mortem de este tipo de eventos como por ejemplo este de

Muchas empresas han migrado todos sus centro de datos a servicios en la nube. Es una práctica muy habitual debido al considerable ahorro en costes de tener la infraestructura en la nube respecto a una solución hardware propia. Pero este incidente muestra el tremendo riesgo que también corremos el día que esa nube deje de funcionar, algo que ya hemos visto que puede ocurrir. Así que queda claro que migrar nuestro servicio a la nube no nos asegura al 100% que un día deje de funcionar. Por lo tanto, es importante que todas las empresas o servicios en la nube empiecen a pensar en un plan de contingencia para minimizar el impacto en la organización en caso de que un evento similar pueda repetirse. Y estamos seguro que volverá a pasar, porque la nube, al fin y al cabo, no es más que el ordenador de otro que está almacenando tus datos ;)

Fuente: Flu-project