Le bug de clé d'accès d'Alibaba Cloud a fait tomber sa console dans le monde entier — puis la scission est morte

Le dimanche qui a suivi son festival shopping Double 11, le 12 novembre 2023, les consoles produit et les API de contrôle d'Alibaba Cloud sont tombées dans toutes les régions. Le panneau de santé de l'entreprise elle-même affichait les 92 produits cloud en état anormal, et des applications grand public, dont Taobao, Xianyu, DingTalk et AliDrive, ont cessé de fonctionner pour les utilisateurs, de même que des services tiers s'exécutant sur Alibaba Cloud.

Le rapport officiel d'incident a attribué la panne au service Access Key (AK), le composant qui authentifie les requêtes du plan de contrôle. En lisant ses données de liste blanche, le service a rencontré une anomalie de lecture, et le code censé gérer cette exception présentait un défaut de logique : au lieu d'échouer en mode sûr, il a généré une liste blanche incomplète, si bien que des requêtes valides absentes de la liste ont été rejetées. Le stockage objet, le stockage de tables, le service de journaux et le service de messagerie dépendaient du service AK et ont partiellement échoué ; les charges de calcul et de bases de données déjà en cours d'exécution n'ont pas été affectées.

Les ingénieurs ont corrigé la version de la liste blanche et redémarré le service AK par lots. Les consoles sont revenues région par région à partir de 18 h 35, la plupart des régions étaient rétablies à 19 h 20 — 1 heure et 41 minutes après le début de l'incident à 17 h 39 — et les derniers produits affectés ont été restaurés à 21 h 11.

Il s'agissait de la deuxième défaillance majeure d'Alibaba Cloud en un an, après la panne de la région de Hong Kong en décembre 2022. Quatre jours plus tard, Alibaba a annulé la scission complète et l'introduction en bourse prévues de son unité cloud, en invoquant officiellement les contrôles américains sur les exportations de puces. Le 27 novembre, la plateforme a subi une deuxième panne en un mois, touchant des produits de bases de données dans huit régions.

Console et API de contrôle indisponibles pendant 1 h 41 ; le rétablissement complet a pris 3,5 heures ; les bons de compensation au titre du SLA sont estimés à plus de 100 millions de yuans — environ un mois de profit de l'unité.

L'authentification est une dépendance partagée : le service de clés d'accès se trouve sous chaque produit, si bien qu'une défaillance à cet endroit les fait tous échouer simultanément.

Le défaut de logique du gestionnaire d'exceptions a transformé une anomalie de lecture en liste blanche incomplète au lieu de revenir à une copie de référence saine.

Le rétablissement a été manuel — réparation de la liste blanche et redémarrage du service AK par lots — faute de mécanisme de retour arrière automatique.

Cela est survenu après une année de turbulences : deux changements de PDG et des réductions de coûts dans l'unité cloud, que des analystes du secteur en Chine ont associés à une discipline opérationnelle affaiblie.

Un cloud n'est aussi solide que son plan d'identité partagé : un seul gestionnaire d'exceptions défectueux dans le service de clés d'accès a fait échouer tous les produits à la fois. Les fondations partagées ont besoin de canaris et de solutions de repli.

Alibaba Cloud a versé à ses clients des bons de compensation au titre de son SLA, qui promet 30 % d'un abonnement mensuel dès que l'indisponibilité dépasse 43 minutes ; les développeurs individuels ayant accumulé moins ont été complétés à hauteur de 50 yuans. Des estimations du secteur en Chine situent le total au-dessus de 100 millions de yuans, soit environ un mois de profit de l'unité. La décision de scission a suivi le 16 novembre, le PDG Eddie Wu déclarant qu'une scission complète « pourrait ne pas produire l'effet escompté ». La panne du 27 novembre a touché les consoles de bases de données et l'OpenAPI dans huit régions, dont Pékin, Shanghai, Hong Kong et la Virginie, pendant près de deux heures.