Une faute de frappe responsable de la panne de Microsoft Azure DevOps au Brésil

Microsoft Azure DevOps, une suite de services de cycle de vie des applications, a cessé de fonctionner dans la région du sud du Brésil pendant une dizaine d’heures mercredi en raison d’une erreur de code de base.

Vendredi, Eric Mattingly, directeur principal de l’ingénierie logicielle, a présenté des excuses pour la perturbation et a révélé la cause de la panne : une simple faute de frappe qui a supprimé dix-sept bases de données de production.

Mattingly a expliqué que les ingénieurs Azure DevOps prennent parfois des instantanés des bases de données de production pour examiner les problèmes signalés ou tester les améliorations de performances. Et ils s’appuient sur un système d’arrière-plan qui s’exécute quotidiennement et supprime les anciens instantanés après une période de temps définie.

Au cours d’un récent sprint – un projet de groupe dans le jargon Agile – les ingénieurs Azure DevOps ont effectué une mise à niveau du code, remplaçant les packages Microsoft.Azure.Managment.* obsolètes par des packages Azure.ResourceManager.* NuGet pris en charge.

Le résultat a été une importante demande d’extraction de modifications qui a remplacé les appels d’API dans les anciens packages par ceux des packages plus récents. La faute de frappe s’est produite dans la demande d’extraction – un changement de code qui doit être examiné et fusionné dans le projet applicable. Et cela a conduit le travail de suppression d’instantané en arrière-plan à supprimer l’intégralité du serveur.

“Caché dans cette demande d’extraction se trouvait un bogue de faute de frappe dans le travail de suppression d’instantané qui a remplacé un appel pour supprimer la base de données Azure SQL par un autre qui supprime le serveur Azure SQL qui héberge la base de données”, a déclaré Mattingly.

Azure DevOps a des tests pour détecter ces problèmes, mais selon Mattingly, le code errant ne s’exécute que sous certaines conditions et n’est donc pas bien couvert par les tests existants. Ces conditions nécessitent vraisemblablement la présence d’un instantané de base de données suffisamment ancien pour être intercepté par le script de suppression.

Mattingly a déclaré que Sprint 222 a été déployé en interne (Ring 0) sans incident en raison de l’absence de bases de données d’instantanés. Quelques jours plus tard, les modifications logicielles ont été déployées dans l’environnement client (Ring 1) pour l’unité d’échelle du sud du Brésil (un cluster de serveurs pour un rôle spécifique). Cet environnement disposait d’une base de données d’instantanés suffisamment ancienne pour déclencher le bogue, ce qui a conduit la tâche en arrière-plan à supprimer “l’intégralité d’Azure SQL Server et les dix-sept bases de données de production” pour l’unité d’échelle.

Les données ont toutes été récupérées, mais cela a pris plus de dix heures. Il y a plusieurs raisons à cela, a déclaré Mattingly.

La première est que, puisque les clients ne peuvent pas relancer Azure SQL Server eux-mêmes, les ingénieurs Azure sur appel ont dû gérer cela, un processus qui a pris environ une heure pour beaucoup.

Une autre raison est que les bases de données avaient des configurations de sauvegarde différentes : certaines étaient configurées pour la sauvegarde redondante de zone et d’autres pour la sauvegarde redondante géographique plus récente. La réconciliation de cette inadéquation a ajouté de nombreuses heures au processus de récupération.

“Enfin”, a déclaré Mattingly, “Même après la remise en ligne des bases de données, l’ensemble de l’unité d’échelle est restée inaccessible, même pour les clients dont les données se trouvaient dans ces bases de données en raison d’un ensemble complexe de problèmes avec nos serveurs Web.”

Ces problèmes provenaient d’une tâche de préchauffage du serveur qui parcourait la liste des bases de données disponibles avec un appel de test. Les bases de données en cours de récupération ont généré une erreur qui a conduit le test d’échauffement “à effectuer une nouvelle tentative d’interruption exponentielle entraînant un échauffement prenant en moyenne quatre-vingt-dix minutes, contre moins d’une seconde dans une situation normale”.

Pour compliquer davantage les choses, ce processus de récupération était échelonné et une fois qu’un ou deux des serveurs recommençaient à prendre le trafic des clients, ils étaient surchargés et tombaient en panne. En fin de compte, la restauration du service a nécessité le blocage de tout le trafic vers l’unité à l’échelle du sud du Brésil jusqu’à ce que tout soit suffisamment prêt pour rejoindre l’équilibreur de charge et gérer le trafic.

Divers correctifs et reconfigurations ont été mis en place pour éviter que le problème ne se reproduise.

“Une fois de plus, nous nous excusons auprès de tous les clients touchés par cette panne”, a déclaré Mattingly. ®