Une panne de Microsoft Azure DevOps dans la région du sud du Brésil, qui a duré plus de 10 heures, a été causée par une faute de frappe dans le code qui a entraîné la suppression de 17 bases de données de production.
Après s’être excusé auprès des clients concernés par la panne, Microsoft a maintenant publié un post-mortem complet, partageant les détails de l’enquête qui a eu lieu depuis le moment où la panne a été remarquée pour la première fois à 12h10 UTC le 24 mai, jusqu’à son remède à 22h31. UTC le même jour.
Eric Mattingly, responsable principal de l’ingénierie logicielle chez Microsoft partagé détails de la mise à niveau de la base de code qui faisait partie du Sprint 222. À l’intérieur de la demande d’extraction se trouvait un bogue caché dans la tâche de suppression d’instantané, qui a fini par supprimer le serveur SQL Azure plutôt que la base de données SQL Azure individuelle.
Erreur de codage
Mattingly a expliqué : « lorsque le travail a supprimé Azure SQL Server, il a également supprimé les dix-sept bases de données de production pour l’unité d’échelle », confirmant qu’aucune donnée n’avait été perdue au cours du processus accidentel.
La panne a été détectée dans les 20 minutes, moment auquel les ingénieurs de garde de l’entreprise se sont mis au travail, mais selon le journal des événements, la cause profonde a été identifiée à 16 h 04, près de quatre heures après le début de la panne.
Microsoft a imputé le temps de réparation de plus de dix heures au fait que les clients eux-mêmes ne sont pas en mesure de restaurer les serveurs Azure SQL, ainsi qu’aux complications de la redondance des sauvegardes et à un «ensemble complexe de problèmes avec [its] serveurs Web.
Ayant appris de son erreur, Microsoft n’a pas promis de déployer Azure Resource Manager Locks sur ses ressources clés, dans le but d’empêcher une future suppression accidentelle.
Malgré une solution le jour même, les clients de la région se sont retrouvés sans accès à certains services pendant plusieurs heures, soulignant à quel point il est facile que les choses tournent mal et l’importance d’avoir des plans de secours pour réduire la dépendance à un seul fournisseur de services, y compris stockage en ligne et d’autres infrastructures hors site.