![]() |
Figura 1. Errores detectados y su localización durante el incidente. Fuente. |
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 ;)
UPDATE: Google Calendar ha sufrido un corte de servicio alrededor del mundo por más de tres horas. Los usuarios que pretendían acceder se encontraron con el típico error 404.
0 comentarios:
Publicar un comentario