Résumé

  • Une commande lancée pendant une maintenance de routine pour évaluer la capacité du réseau dorsal a coupé toutes les connexions de ce réseau et isolé les centres de données de Meta, selon la description de l'exploitant lui-même.
  • L'audit automatisé censé bloquer précisément cette catégorie de commande ne l'a pas bloquée ; le groupe attribue la défaillance à un bogue dans l'outil d'audit.
  • Les ingénieurs ont rétabli le service en se rendant physiquement dans les installations, l'accès habituel, l'accès réseau principal et l'accès hors bande étant indisponibles en même temps.

Une commande qui efface d'un coup le réseau dorsal d'une entreprise est une faute d'exploitation grave. Un garde-fou conçu pour intercepter exactement cette commande, et qui ne l'a pas fait, appartient à une autre catégorie d'événement. La distinction n'est pas rhétorique : la première est une erreur, le second est une information sur les contrôles que l'organisation croyait détenir.

Meta Platforms, l'exploitant consigné dans le répertoire BTW sous Meta Platforms, a publié son récit dès le lendemain. Le groupe y décrit le déclencheur sans l'adoucir : « During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all connections in our backbone network, effectively disconnecting Facebook data centers globally. » Autrement dit, une commande destinée à mesurer la capacité disponible du réseau dorsal a supprimé ce réseau. Le compte rendu d'ingénierie de l'exploitant est le seul document de première main du dossier examiné qui décrive la manière dont le changement a été exécuté.

La phrase suivante porte l'essentiel de la question de responsabilité. « Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command. » Le groupe affirme quatre choses en une : un garde-fou existait ; il visait cette catégorie de commande ; il devait l'arrêter ; il ne l'a pas arrêtée, parce qu'il était lui-même défectueux. La confiance placée dans l'approbation automatisée des changements de dorsale était donc, au vu de cette pièce, une confiance mal placée dans un contrôle dont personne n'avait découvert le défaut.

La défaillance est ensuite devenue autoreférentielle : le même événement qui a retiré le réseau de production a retiré la capacité de le voir. L'exploitant nomme deux obstacles. « It was not possible to access our data centers through our normal means because their networks were down, and the total loss of DNS broke many of the internal tools we'd normally use to investigate and resolve outages like this. » Le DNS n'est pas un accessoire du réseau : c'est par lui que les outils internes trouvent leur cible.

Quand la résolution de noms tombe, les tableaux de bord, les consoles et la découverte de services tombent avec elle, et la surface de diagnostic disparaît au moment précis où elle serait utile.

La réponse tient en une phrase qui mérite plus d'attention qu'on ne lui en accorde d'ordinaire. « Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. » L'accès hors bande existe précisément parce que le chemin de production peut tomber : c'est le canal construit pour survivre à la panne qu'il doit réparer. Ici, il se trouvait dans le périmètre de la panne.

Il ne restait donc que la présence physique : des équipes en route vers des bâtiments, franchissant les contrôles de sécurité physiques et systèmes, travaillant sur des consoles indépendantes du réseau disparu.

Ce que le monde extérieur a vu peut être daté. Un observateur indépendant, placé à l'extérieur du groupe, a publié une séquence d'observations : un pic de changements de routage « at around 15:40 UTC » ; l'arrêt des annonces de routes vers les préfixes DNS « at 15:58 UTC » ; un nom de domaine indisponible « at around 15:50 UTC » et revenu « at 21:20 UTC » ; une reprise de l'activité de routage « at around 21:00 UTC », culminant « at 21:17 UTC » ; et, « as of 21:28 UTC », une reconnexion au réseau mondial avec un DNS de nouveau fonctionnel. Ce sont des mesures d'effet, prises depuis une position réseau extérieure à l'entreprise, et c'est la corroboration non-opérateur la plus solide du dossier : le retrait a eu lieu, le nom a cessé de résoudre, et le retour s'est fait par étapes plutôt que d'un seul mouvement. L'analyse réseau indépendante ne peut pas, et ne prétend pas, voir ce que les ingénieurs du groupe pouvaient observer de l'intérieur.

Ces deux pièces répondent à des questions différentes, et c'est là que se situe l'analyse de responsabilité. Le récit de première main établit le chemin de contrôle interne : un garde-fou devait arrêter la commande et ne l'a pas fait. L'observation externe établit l'effet sur le service et sa chronologie. Ni l'une ni l'autre n'établit de faute personnelle. Le dossier examiné n'identifie pas qui a émis la commande ni qui l'a approuvée, ne décrit pas d'avertissement antérieur, et ne contient aucun instrument de régulateur, aucune décision de justice, aucune enquête formelle sur cet événement.

Désigner un individu serait une invention.

La responsabilité peut néanmoins être répartie par couches, et ces couches ne se comportent pas de la même façon. La commande est le déclencheur immédiat ; un déclencheur n'est pas une culpabilité, et les confondre est la manière habituelle de tirer la mauvaise leçon d'un incident. L'outil d'audit est le contrôle préventif défaillant, et son défaut constitue le fait organisationnel central.

La conjonction de la perte de la dorsale, de la perte du DNS, de la perte du diagnostic interne et de la perte des deux chemins d'accès distants forme une défaillance de confinement et de reprise, distincte du déclencheur et bien plus lourde de conséquences. Enfin, l'exploitant porte la responsabilité de la pile de contrôle et de l'architecture de résilience qu'il faisait tourner, parce que ces choix étaient les siens.

Sur la réparation, le dossier est plus mince que l'événement. Meta a formulé son intention : « From here on out, our job is to strengthen our testing, drills, and overall resilience to make sure events like this happen as rarely as possible.

» Face à cet engagement, le matériel examiné ici — le compte rendu publié par l'exploitant, l'analyse publiée par un observateur réseau indépendant, et une recherche ciblée de documentation ultérieure sur les contrôles correctifs, qui n'a renvoyé aucun candidat — ne montre aucune mise en œuvre datée d'un correctif de l'outil d'audit, aucun élément établissant que l'accès de secours a été séparé du réseau défaillant, et aucun exercice observé par une partie extérieure. Sur ce matériel, aucun contrôle post-incident n'est attesté comme testé.

Cette lacune décrit le dossier, non l'entreprise : elle n'établit pas qu'aucune réparation n'a eu lieu.

La différence mérite d'être présentée comme une échelle, car c'est ainsi qu'un lecteur devrait peser tout récit post-incident d'exploitant. Un engagement public est le premier barreau. Une mise en œuvre datée est le deuxième. Un contrôle exercé, avec résultats, est le troisième. Une observation ou une attestation indépendante est le quatrième. Le matériel examiné n'étaye que le premier.

Un enregistrement de mise en œuvre daté, un résultat de test montrant le garde-fou d'audit rejetant la catégorie de commande pour laquelle il a été construit, ou un exercice observé de l'extérieur feraient basculer cet événement dans une autre classification — et chacun de ces documents est un document qu'un exploitant compétent possède déjà.

C'est le point que la couverture antérieure de cette entreprise n'atteignait pas. Les travaux publiés sur Meta ont examiné les permissions accordées aux développeurs et la gouvernance des données de plateforme après l'affaire Cambridge Analytica, la mécanique d'appariement des ordres qui a échoué lors de son introduction en bourse de 2012, et le travail d'ingénierie d'infrastructure qui sous-tend son échelle, aux côtés de brèves notules sur des interruptions de service ultérieures et sans lien.

Aucun de ces textes n'examinait comment un changement sur une dorsale acquiert son autorisation, ce qui se passe quand la vérification d'autorisation est cassée, ni si la reprise peut survivre à la panne qu'elle doit réparer. L'apport de cet article est la chaîne de contrôle, non un nouveau récit de la panne.

La leçon de l'événement n'est pas qu'un grand réseau peut tomber. C'est qu'un contrôle placé à l'intérieur de ce qu'il protège n'est pas un contrôle au sens utile. Un audit qui s'exécute sur l'infrastructure dont il doit empêcher le retrait partage le sort de cette infrastructure. Un accès de secours qui résout son nom par un DNS défaillant n'est pas un accès de secours.

La conception durable est celle qui se tient hors du rayon d'impact : un garde-fou qui rejette la commande sans avoir besoin du réseau de la commande, un chemin de diagnostic qui ne résout pas de noms via le système qu'il diagnostique, et un exercice dont une partie extérieure peut voir les résultats. Sur les pièces publiques examinées ici, la première leçon est documentée et la seconde seulement promise.