Un error latente convirtió el mantenimiento rutinario del centro de datos de Gmail en una caída global de tres horas

El 24 de febrero de 2009, Gmail dejó de funcionar para usuarios de todo el mundo. El informe de incidente de Google para sus clientes de Apps situó la interrupción aproximadamente entre las 9:00 y las 12:00 GMT —unas tres horas—, con una recuperación escalonada de modo que cada usuario perdió el acceso durante periodos distintos. No se perdieron datos.

El mecanismo fue la interacción entre dos decisiones recientes. Google había desplegado un nuevo software para optimizar dónde residían los datos de los usuarios. Esa mañana, los ingenieros iniciaron un mantenimiento rutinario en un centro de datos europeo, una operación diseñada para pasar inadvertida, ya que el tráfico se desvía automáticamente a otro lugar. Pero el desvío activó un error latente en el nuevo código de localidad: el destino se sobrecargó y, a medida que el tráfico se redirigía automáticamente, las sobrecargas se propagaron en cascada de un centro de datos a otro. Los ingenieros tardaron alrededor de una hora en controlar la cascada y más tiempo en reequilibrarlo todo.

Google gestionó las consecuencias con una transparencia inusual para la época: Acacio Cruz, responsable de fiabilidad del sitio de Gmail, explicó la cascada en el blog oficial de Gmail ese mismo día, y Google publicó un informe formal de incidente para los clientes de Apps. También se comprometió a crear algo que aún no existía para el servicio —un panel público de estado—, reconociendo que un proveedor de nube debe a sus clientes información rápida durante una interrupción, no solo silencio y una solución.

Gmail inaccesible hasta tres horas el 24 de febrero de 2009, con una recuperación escalonada por centro de datos; no se perdieron datos

La ruta de conmutación por error —el desvío del tráfico a un segundo centro de datos— no se había probado contra el nuevo software de localidad de datos, por lo que el error latente solo se manifestó durante el mantenimiento.

La respuesta a la sobrecarga amplificó el fallo: a medida que los usuarios se redirigían automáticamente, cada destino alcanzaba la misma condición de sobrecarga, propagándola aguas abajo.

El diseño del mantenimiento daba por supuestos traspasos limpios entre centros de datos, pero el nuevo código de optimización cambió las premisas sobre las que se había construido la conmutación por error.

La comunicación llegó tarde respecto al incidente: el propio análisis posterior de Google admitió que debía reconocer las interrupciones con rapidez, lo que llevó directamente al panel de estado de Apps.

Las rutas de conmutación por error merecen tanta prueba como las principales: un nuevo código que reorganiza la ubicación de los datos convirtió un mantenimiento rutinario en una cascada. Y una interrupción en la nube exige un informe de incidente publicado.

Google corrigió el error y desplegó cambios, publicó el informe de incidente y lanzó el panel de estado de Google Apps semanas después, institucionalizando la comunicación pública de interrupciones. El episodio 'gfail' se convirtió en una plantilla temprana para la notificación de incidentes en la nube —un relato formal, dirigido a los clientes, de la causa y la remediación— en una época en la que la mayoría de los servicios web de consumo no ofrecían explicación alguna.