Résumé

  • Le 25 janvier 2023 à 07 h 08 UTC, une opération d'ajout de capacité à Madrid a exécuté une commande dont l'effet, local chez deux constructeurs, s'étendait par défaut à tous les routeurs reliés par l'IGP sur une troisième plateforme. Le recalcul de l'IGP puis la réannonce des préfixes par BGP ont déclenché une première vague d'impact.
  • Trente-trois minutes plus tard, l'opération a été effectuée manuellement sur le second routeur de Madrid. La personne chargée du changement n'avait pas été informée des alertes actives. Cette seconde exécution, et non une répétition automatique établie, a produit une deuxième vague.
  • La plupart des équipements, régions et services avaient récupéré à 09 h 05 UTC, puis le dernier équipement réseau à 09 h 25. Des systèmes de santé du WAN et d'ingénierie de trafic restés en pause ont toutefois dû être redémarrés manuellement avant la mitigation complète à 12 h 43.

Une tâche locale a atteint le domaine de routage mondial

L'intervention devait ajouter de la capacité au réseau étendu mondial de Microsoft. À Madrid, un ingénieur modifiait les adresses IP de nouveaux routeurs avant de les intégrer aux domaines de routage interne et externe, IGP et BGP. Le périmètre matériel était une paire d'équipements. Le périmètre logique de la commande incluse dans la procédure était beaucoup plus vaste.

Le rapport final de Microsoft indique que la procédure opératoire avait été modifiée avant l'incident, sans être de nouveau testée, et qu'elle ne comportait pas les contrôles préalables et postérieurs requis. Elle contenait une commande de purge de la base IGP. Sur les routeurs de deux constructeurs, l'effet restait local. Sur la plateforme d'un troisième constructeur, le comportement par défaut s'étendait à l'ensemble des routeurs connectés par l'IGP. Le système d'autorisation des commandes de Microsoft n'avait pas classé cet effet global propre à la plateforme parmi les comportements à bloquer.

Le code en fonctionnement a donc imposé une réalité différente de celle suggérée par l'intitulé de la tâche. Les routeurs du WAN ont recalculé la topologie interne. Les routeurs BGP ont ensuite réannoncé et validé les préfixes Internet. Au fil de cette convergence, les chemins ont changé et les clients ont rencontré, selon leur origine et leur destination, de la latence, des délais d'attente dépassés, des pertes intermittentes de paquets ou, sur certains chemins, une perte complète de connectivité.

Cette chaîne distingue l'événement d'une interruption de cloud générique. Sans la purge IGP à portée élargie, les réannonces BGP et l'instabilité des chemins de transfert, l'explication centrale disparaît. La question de responsabilité n'est pas de savoir pourquoi une personne a saisi une commande prise isolément. Elle consiste à demander pourquoi la procédure, la qualification multi-constructeur et les garde-fous d'autorisation n'ont pas établi l'étendue effective de cette commande avant son entrée dans le domaine de routage actif.

Une autorisation répond à une question d'identité et de droit d'action. Une qualification opérationnelle doit répondre à une autre question : que fera exactement le réseau lorsque cette action atteindra telle plateforme, tel rôle d'équipement et tel contexte logiciel ? L'incident montre le coût de la confusion entre ces deux niveaux.

Les sémantiques multi-constructeurs étaient le point de rupture

Une bibliothèque de commandes approuvées peut empêcher des opérations déjà connues comme dangereuses. Elle ne démontre pas que tout ce qui n'est pas bloqué possède une portée bornée. Dans un WAN hétérogène, une même formulation peut recouvrir des valeurs par défaut différentes. Ici, le contraste entre un effet local et un effet propagé à tous les routeurs reliés par l'IGP n'était pas un détail documentaire : il changeait entièrement le rayon d'impact possible.

Le dossier public ne nomme ni les constructeurs, ni les modèles, ni les versions logicielles, ni le texte exact de la commande. Il serait donc abusif d'attribuer la panne à une marque ou à une version précise. Ce que le rapport final établit suffit néanmoins à une conclusion de contrôle : le système n'avait pas qualifié un comportement global propre à l'une des plateformes déployées.

Les contrôles manquants avant et après l'opération ont amplifié cette lacune. Avant l'exécution, un contrôle pertinent aurait dû rendre explicites les équipements, les adjacences et les domaines de routage censés évoluer. Après l'exécution, l'état observé de la topologie, des annonces et des chemins aurait dû pouvoir être comparé à cette enveloppe déclarée. Il s'agit d'implications de conception tirées de l'incident, pas de la preuve qu'un contrôle particulier aurait empêché toute défaillance.

La distinction compte aussi pour l'organisation. Approuver une chaîne de caractères ne suffit pas lorsque le risque réside dans son effet exécutable. La qualification doit suivre les changements de procédure et les différences de plateforme. Si une procédure est modifiée, le statut antérieur de la commande ne peut pas être repris sans nouvelle preuve. La précision de l'état de routage et la continuité opérationnelle deviennent alors des critères d'acceptation, et non des vérifications facultatives après coup.

Cette primauté du comportement réel fournit une règle simple : en cas de désaccord entre le nom de la tâche, la documentation et l'effet constaté sur le réseau, c'est l'état produit par le code en fonctionnement qui définit le risque. Un changement dit « local » ne reste local que si les observations le démontrent.

Les données BGP publiques ont montré les effets, pas la cause interne

Les observateurs externes ont vu le réseau se transformer. ThousandEyes a relevé des retraits et des réannonces de préfixes Microsoft, des déplacements de trafic depuis des interconnexions directes vers des opérateurs de transit et d'importantes pertes de paquets. Kentik a observé deux chutes agrégées de trafic, ainsi qu'un impact très variable selon les préfixes, les régions et les chemins. Certains préfixes étaient perturbés alors que d'autres continuaient d'acheminer du trafic.

Ces mesures indépendantes sont essentielles parce qu'elles décrivent la panne depuis la frontière visible par les clients et les réseaux voisins. Elles ne révèlent toutefois pas, à elles seules, la commande interne ni la chaîne de décision qui l'a autorisée. Kentik a explicitement averti que l'instabilité BGP publique devait être comprise comme un symptôme probable de la défaillance interne, et non comme sa cause première.

Les retraits, les annonces et le recours accru au transit ne prouvent ni un détournement BGP malveillant, ni une attaque externe, ni un défaut intrinsèque du protocole BGP. Le mécanisme interne de référence vient du rapport final de Microsoft : une commande de purge IGP à portée inattendue a imposé un recalcul de topologie, après quoi les routeurs BGP ont dû réannoncer et valider les préfixes Internet.

Les deux couches de preuve remplissent donc des fonctions différentes. Le compte rendu de l'opérateur décrit l'opération, les systèmes internes et la séquence de rétablissement. ThousandEyes et Kentik vérifient que des routes, des chemins et du trafic ont effectivement changé de la manière visible depuis Internet. Leur accord renforce la cohérence du récit causal. Les confondre affaiblirait l'analyse : l'observation extérieure ne doit pas être élevée au rang de cause interne, et le compte rendu interne ne doit pas effacer l'expérience mesurable des utilisateurs.

La même discipline s'applique aux explications provisoires. Une hypothèse extérieure initiale envisageait que l'automatisation ait répété le changement. Cette question pouvait être légitime pendant l'incident. Elle n'est plus la conclusion de référence une fois le rapport final disponible. Celui-ci indique que la même opération a été effectuée sur le second routeur. L'événement comporte donc deux opérations manuelles sous une procédure non qualifiée, et non une répétition automatique établie.

Trente-trois minutes ont créé une seconde vague

La surveillance a détecté des symptômes DNS et WAN quelques minutes après le début de l'incident et a généré des alertes à 07 h 11 UTC. Pourtant, la personne qui poursuivait le travail à Madrid n'a pas été informée de ces alertes. Trente-trois minutes après la première opération, la même action a été exécutée sur le second routeur, créant une deuxième vague de perturbation.

Les mesures de ThousandEyes et de Kentik distinguent elles aussi deux épisodes de routes ou de trafic. Elles ne permettent pas d'identifier l'opérateur ni le circuit de communication interne, mais elles corroborent la séparation entre les deux effets. Le rapport final fournit la cause organisationnelle pertinente : l'information issue de l'incident n'a pas atteint la personne encore en mesure de répéter le mécanisme.

Ce délai met en évidence une frontière de contrôle entre exécution du changement et commandement de l'incident. La détection fonctionnait. Une réponse était en cours. Pourtant, l'état de la tâche n'a pas changé avant la seconde opération. Une alerte qui s'arrête dans un outil de supervision n'est pas encore un garde-fou ; elle le devient seulement si elle peut suspendre l'étape suivante, transférer l'autorité ou imposer une nouvelle preuve avant de continuer.

Le dossier ne détaille pas tous les contrôles internes ni l'ensemble des droits de décision. Il ne permet pas non plus de juger l'intention ou la compétence d'un individu non nommé. Il établit en revanche des propriétés du système : une procédure modifiée et non retestée, des vérifications absentes, une classification de commande incomplète et un chemin d'alerte qui n'a pas interrompu la poursuite du travail. C'est à ce niveau que la responsabilité peut être analysée sans personnalisation abusive.

La seconde vague a aussi touché un réseau qui convergeait déjà après la première. Les sources ne quantifient pas la part de dommage imputable à chacune des deux vagues ; aucun chiffre ne doit être inventé. La conclusion admissible est plus étroite : le même mécanisme non qualifié a pu atteindre deux fois le domaine de routage, alors que des alertes existaient déjà.

L'impact était mondial mais non uniforme

Microsoft décrit des effets dynamiques selon la source et la destination du trafic. La connectivité entre Internet et Azure, le trafic interrégional ainsi que les liaisons hybrides utilisant ExpressRoute, VPN ou virtual WAN ont été touchés. Des services dépendant d'Azure, notamment des parties de Microsoft 365, Power Platform et Azure Government, ont également rencontré des perturbations.

La diversité des symptômes est cohérente avec des routes retirées, réannoncées, validées et déplacées entre plusieurs chemins. Certains clients ont subi de la latence ou des pertes intermittentes ; d'autres ont connu des délais dépassés ou une absence complète de connectivité sur certains parcours. L'Inde et certaines parties de l'Amérique du Nord ont compté parmi les trajectoires de reprise les plus longues.

Rien dans les quatre sources ne permet toutefois d'affirmer que chaque région Azure, chaque service, chaque client ou chaque route Internet a échoué de manière identique. Kentik a au contraire relevé des préfixes affectés et non affectés. Le dossier ne fournit pas non plus de décompte audité des utilisateurs, de perte financière certifiée ou d'inventaire exhaustif des services.

Cette variabilité est elle-même un enjeu de responsabilité. Un indicateur global peut signaler une amélioration tandis que certains couples source-destination restent dégradés. Une déclaration de rétablissement doit donc reposer à la fois sur des mesures d'ensemble et sur des preuves au niveau des chemins. La continuité ne se réduit pas au retour d'une moyenne satisfaisante.

Le rétablissement s'est déroulé par couches

Les ingénieurs ont examiné les changements récents et identifié la commande problématique à 08 h 20 UTC, alors que la convergence automatique du routage progressait. Presque tous les équipements réseau, régions et services avaient récupéré à 09 h 05. Le dernier équipement réseau a récupéré à 09 h 25. Ces jalons ne marquaient pas encore la fin complète de l'incident.

Des pertes de paquets localisées persistaient parce que les systèmes de santé du WAN et d'ingénierie de trafic étaient restés en pause. Ces fonctions ont nécessité des redémarrages manuels avant que Microsoft ne déclare la mitigation complète à 12 h 43. La fenêtre officielle d'impact s'étend donc de 07 h 08 à 12 h 43, même si la majorité des services était revenue beaucoup plus tôt.

Les informations contemporaines sur un retour arrière décrivaient une étape visible au moment où la situation évoluait. Elles ne remplacent pas la chronologie plus complète du rapport final : convergence des routes, récupération de la quasi-totalité des services, retour du dernier équipement, puis redémarrage manuel des systèmes de support. Présenter le rétablissement comme le résultat immédiat d'un seul rollback effacerait ces frontières.

L'incident montre ainsi que la joignabilité et la capacité à assurer cette joignabilité sont deux états distincts. Des paquets peuvent recommencer à circuler alors que les systèmes qui détectent les chemins dégradés et orientent le trafic ne sont pas revenus à un état connu. La clôture devrait donc exiger la preuve du retour des fonctions d'observation et d'ingénierie, pas seulement celle d'un accès largement restauré.

Une conclusion de système, pas un verdict juridique

Le dossier à quatre sources soutient une chaîne factuelle précise : une procédure modifiée et non retestée a inclus une commande dont la portée variait selon le constructeur ; l'effet global a déclenché un recalcul IGP, des réannonces BGP et des changements de chemins ; l'opération a été répétée manuellement avant que les alertes n'atteignent la personne chargée du changement ; le rétablissement a combiné convergence et redémarrages manuels.

Microsoft a annoncé des travaux portant notamment sur l'audit et le blocage des commandes à fort impact selon les constructeurs et les rôles, la visibilité pour les équipes d'astreinte des activités qualifiées ou non qualifiées, la formation et l'attestation obligatoires, ainsi que la revue des procédures en attente. Les sources utilisées ici ne prouvent pas indépendamment que ces mesures ont toutes été achevées ni qu'elles ont produit les résultats attendus. Elles restent des engagements de réparation, non des résultats vérifiés.

Le dossier n'établit ni activité malveillante, ni perte de données clients, ni nombre exact de personnes touchées, ni faute juridique, ni décision d'un régulateur ou d'un tribunal. Ces limites empêchent la surenchère, sans diminuer la conclusion d'infrastructure : un réseau mondial devient vulnérable lorsque procédure, autorisation et sémantique exécutable ne s'accordent pas sur la portée d'une commande.

Sources