Mercredi dernier, une partie du nuage Azure brésilien a été paralysée pendant dix heures. Dans un communiqué posté sur son blog, un ingénieur de Microsoft explique aujourd’hui comment une petite faute de frappe a eu de si sérieuses conséquences.
Il s’agit d’Azure DevOps qui a été interrompu pendant 10 heures et demie dans la South Brazil Region (SBR). Le software engineering manager principal Eric Mattingly explique que le problème était dû à une mise à niveau de la base du code. Concrètement, les packages Microsoft.Azure.Managment.* obsolètes ont été remplacés par des packages Azure.ResourceManager.* NuGet.
L’opération impliquait plusieurs adaptations manuelles, au cours desquelles une faute de frappe a été commise dans l’une des requêtes de suppression des instantanés (une sorte de photo numérique de l’état d’une base de données à un moment spécifique). Normalement, l’Azure SQL Database devait être supprimée, mais en lieu et place, ce fut l’Azure SQL Server dans lequel la base de données tourne, qui fut supprimé.
Microsoft reconnaît qu’il s’agit là d’un événement rare, qui n’a pas été suffisamment testé précédemment. C’est ainsi que le nouveau code a d’abord été déployé sur ‘Ring 0’, l’organisation interne Azure DevOps, où il n’y avait pas de base de données d’instantanés, ce qui fait que rien n’a donc été exécuté. Au bout de quelques jours, Ring 1 (couvrant le région du sud du Brésil) fut également été mis à niveau, où se trouvait une base de données d’instantanés suffisamment ancienne pour activer le bug et c’est ainsi que l’Azure SQL Server a été supprimé. Cela entraîna à son tour la suppression des 17 bases de données de production, ce qui fait qu’aucune donnée de client ne put être traitée. Il n’y a cependant pas eu de perte de données client, selon Microsoft.
Découverte rapide, mais restauration longue
Microsoft insiste sur le fait que les problèmes avaient été découverts dans les vingt minutes et que tout a été rapidement éclairci. Mais pourquoi a-t-il par conséquent fallu attendre dix heures de plus? A cause de plusieurs complexités. Il a ainsi déjà fallu une heure pour que l’équipe Azure SQL restaure le serveur. Ensuite, plusieurs heures furent nécessaires, parce que les bases de données durent être copiées dans une région associée. Enfin, les clients éprouvèrent également des difficultés d’accès à cause d’une série de difficultés techniques complexes. C’est ainsi que dans certains processus, il existe une tâche qui répertorie et connecte toutes les bases de données. Mais durant la restauration, il y eut des problèmes à ce niveau, ce qui fait que ce processus, qui prend normalement moins d’une seconde, a duré nonante minutes. Le tout combiné a fait en sorte que le service a été indisponible pendant plus de dix heures.
Vous avez repéré une erreur ou disposez de plus d’infos? Signalez-le ici