El fallo de la clave de acceso de Alibaba Cloud tumbó su consola en todo el mundo, y luego murió la escisión

El domingo posterior a su festival de compras del Doble 11, el 12 de noviembre de 2023, las consolas de productos y las API de control de Alibaba Cloud se apagaron en todas las regiones. El propio panel de estado de la compañía mostró los 92 productos en la nube en estado anómalo, y aplicaciones de consumo como Taobao, Xianyu, DingTalk y AliDrive fallaron para los usuarios, junto con servicios de terceros que se ejecutaban sobre Alibaba Cloud.

El informe oficial de la avería atribuyó la caída al servicio de clave de acceso (Access Key, AK), el componente que autentica las solicitudes del plano de control. Al leer sus datos de lista blanca, el servicio sufrió una anomalía de lectura, y el código destinado a gestionar esa excepción tenía un defecto lógico: en lugar de fallar de forma segura, generó una lista blanca incompleta, de modo que se rechazaron solicitudes válidas que no figuraban en la lista. El almacenamiento de objetos, el almacenamiento de tablas, el servicio de registros y el servicio de mensajes dependían del servicio AK y fallaron parcialmente; las cargas de trabajo de cómputo y bases de datos que ya estaban en ejecución no se vieron afectadas.

Los ingenieros corrigieron la versión de la lista blanca y reiniciaron el servicio AK por lotes. Las consolas volvieron región por región a partir de las 18:35, la mayoría de las regiones se recuperaron a las 19:20 —1 hora y 41 minutos después de que la avería comenzara a las 17:39— y los últimos productos afectados se restauraron a las 21:11.

Fue el segundo fallo emblemático de Alibaba Cloud en un año, tras la caída de la región de Hong Kong en diciembre de 2022. Cuatro días después, Alibaba canceló la escisión total y la OPI previstas de su unidad de nube, citando oficialmente los controles estadounidenses a la exportación de chips. El 27 de noviembre la plataforma sufrió una segunda caída en un mes, que afectó a productos de bases de datos en ocho regiones.

Consola y API de control caídas 1 h 41 min; la recuperación completa llevó 3,5 horas; vales de compensación por SLA estimados por encima de ¥100 M, aproximadamente un mes de beneficio de la unidad.

La autenticación es una dependencia compartida: el servicio de clave de acceso está por debajo de todos los productos, de modo que un fallo allí los hace fallar a todos simultáneamente.

El defecto lógico del gestor de excepciones convirtió una anomalía de lectura en una lista blanca incompleta en lugar de recurrir a una copia buena conocida.

La recuperación fue manual —reparar la lista blanca y reiniciar el servicio AK por lotes— porque no había una vía de reversión automática.

Vino tras un año de turbulencias: dos cambios de CEO y recortes de costes en la unidad de nube, que analistas del sector chino vincularon a una menor disciplina operativa.

Una nube es tan fuerte como su plano de identidad compartido: un solo gestor de excepciones defectuoso en el servicio de clave de acceso hizo fallar todos los productos a la vez. Las bases compartidas necesitan canarios y mecanismos de reserva.

Alibaba Cloud pagó a los clientes vales de compensación conforme a su SLA, que promete el 30 % de la cuota mensual cuando el tiempo de inactividad supera los 43 minutos; a los desarrolladores individuales que acumulaban menos se les completó la compensación hasta ¥50. Estimaciones del sector chino situaron el total por encima de ¥100 millones, cerca de un mes de beneficio de la unidad. La decisión de escisión se produjo el 16 de noviembre, y el CEO Eddie Wu dijo que una escisión total «puede que no logre el efecto previsto». La caída del 27 de noviembre afectó a las consolas de bases de datos y a OpenAPI en ocho regiones, entre ellas Pekín, Shanghái, Hong Kong y Virginia, durante casi dos horas.