Les services cloud sont loin d'être exempts de panne et d'interruption de services. Les clients de Microsoft utilisant les instances Azure DevOps dans la région sud du Brésil (SBR) le savent, ces derniers ayant été confrontés à une indisponibilité de cet environnement pendant près de 10h30 le mercredi 24 mai. Vendredi dernier, des explications ont été fournies sur l'origine et l'étendue de cette panne montrant à quel point le moindre grains de sable peut enrayer une machine bien huilée.

« Nous sommes conscients de l'impact que peuvent avoir les pannes d'Azure DevOps et nous nous excusons sincèrement auprès de tous les clients concernés », a écrit dans un billet de blog d'analyse post mortem Eric Mattingly responsable de l'ingénierie logicielle chez Microsoft. « Les ingénieurs Azure DevOps ont parfois besoin de prendre un snapshot d'une base de données de production pour enquêter sur les réclamations des clients ou évaluer les améliorations potentielles des performances. Pour s'assurer que ces bases de données instantanées sont nettoyées, une tâche d'arrière-plan s'exécute chaque jour et les supprime une fois qu'elles ont dépassé un certain temps ».

Une panne détectée dans les 20 minutes

Dans le cadre d'un sprint, une mise à jour d'un code a été effectuée pour remplacer des paquets obsolètes (Microsoft.Azure.Managment.*) par d'autres plus récents (NuGet Azure.ResourceManager.*) ayant nécessité des modifications d'appels API. « Cette requête cachait un bogue de typographie dans la tâche de suppression des snapshots, qui remplaçait un appel de suppression de la base de données Azure SQL par un appel similaire sur le serveur Azure SQL qui héberge la base de données », a prévenu Microsoft. « Les conditions dans lesquelles ce code est exécuté sont rares et n'ont pas été bien couvertes par nos tests ». Avec pour conséquence de déboucher sur un beau bazar. « Lorsque la tâche a supprimé le serveur Azure SQL, elle a également supprimé les dix-sept bases de données de production de l'unité d'échelle. À partir de ce moment, l'unité d'échelle n'a plus été en mesure de traiter le trafic des clients ».

Plus de peur que de mal cependant pour Microsoft qui indique qu'aucune donnée n'a été perdue dans cet incident. Mais il aura donné du fil à retordre à ses équipes ayant mis près de 10h30 pour le résoudre. « Nous avons détecté la panne dans les 20 minutes qui ont suivi le début des suppressions de bases de données et nos ingénieurs d'astreinte sont intervenus immédiatement. Le problème a été rapidement compris et nous nous sommes attelés à la restauration du serveur SQL et de toutes les bases de données, ainsi qu'à la désactivation de la tâche de suppression des instantanés afin d'éviter que le bogue n'ait un impact sur d'autres clients », poursuit Eric Mattingly. Plusieurs causes ont été avancées pour expliquer ce délai inhabituel dont l'impossibilité des clients de restaurer eux-mêmes, des configurations de sauvegarde multiples débouchant sur des soucis de réconciliation, sans compter de multiples erreurs de traitements au niveau des serveurs web de Microsoft.

Des mesures pour éviter un incident de cette ampleur

Pour éviter de revivre une pareille mésaventure, la firme de Redmond indique avoir pris plusieurs mesures incluant un test pour la tâche de suppression des snapshots, ajout de garde-fous pour Azure Resource Manager afin d'empêcher toute suppression accidentelle, création de snapshots de bases de données créées sur des instances Azure SQL Server différentes des bases de données de production de Microsoft, correction de la logique de la tâche d'échauffement du serveur web pour permettre un démarrage réussi même si les bases de données sont hors ligne. « Nous créons une nouvelle cmdlet pour la restauration des bases de données supprimées afin de garantir que les restaurations utilisent les mêmes paramètres qu'avant la suppression y compris la redondance des sauvegardes », indique Eric Mattingly.