Réseau : les enseignements tirés de la panne géante de Facebook
Même chez les géants d’Internet, une faute de saisie peut vous rayer de la carte. Cet article fait le point sur les causes de la panne géante subie par Facebook en 2021 et sur les méthodes pour l’éviter.
Le 4 octobre 2021, Facebook – entretemps devenu Meta – et ses filiales, dont Messenger, Instagram et WhatsApp, ont disparu d’Internet et sont restés indisponibles pendant environ six heures. Le public a rapidement spéculé – en grande partie sur Twitter, où les utilisateurs de médias sociaux ont afflué en l’absence de Facebook – sur le fait que la panne pourrait provenir d’une erreur sur les routeurs BGP.
Mais, selon Facebook, les problèmes liés à BGP et aux DNS n’étaient que des symptômes du véritable incident, à savoir une mauvaise configuration qui a déconnecté les routeurs du réseau dorsal de l’entreprise, alias le backbone. En d’autres termes, l’erreur était humaine.
« Au cours d’une maintenance de routine sur le backbone, un administrateur qui tentait de mesurer le débit en cours s’est trompé de commande et cela a déclenché une cascade de problèmes techniques », indique désormais Santosh Janardhan, le responsable de Facebook qui chapeaute l’ingénierie et l’infrastructure.
Selon lui, un outil de monitoring interne aurait dû automatiquement stopper la défaillance avant qu’elle prenne les proportions que l’on connaît. Mais un bug dans son code l’en aurait empêché et c’est ainsi que la mauvaise commande saisie par l’administrateur aurait déconnecté du backbone tout ce qui passait par lui, en l’occurrence les datacenters de Facebook.
Une cascade d’événements
C’est la déconnexion de ces datacenters qui a provoqué les problèmes identifiés sur les DNS et le protocole BGP. Lorsque les serveurs DNS de l’entreprise n’ont pas pu communiquer avec les datacenters, ils ont automatiquement invalidé leurs déclarations de routes BGP, retirant les itinéraires vers Facebook et ses filiales de la carte routière d’Internet. Soudain, c’était comme si Facebook, Instagram et WhatsApp n’existaient plus.
Mais il y a pire. Les outils internes qu’utilise Facebook dépendent de ces routes et de ces DNS pour fonctionner. En clair, les salariés de l’entreprise ne pouvaient pas accéder aux systèmes qu’ils utilisent habituellement pour travailler et se coordonner. Et le personnel en charge du réseau ne pouvait pas non plus investiguer la panne à distance ni la résoudre avec ses méthodes habituelles.
« En gros, Facebook a fermé sa porte en laissant les clés à l’intérieur » résume John A. Paulson, le spécialiste de ces questions à l’université de Harvard.
En définitive, l’équipe informatique n’a eu d’autre choix que pénétrer physiquement dans les datacenters pour dépanner puis réinitialiser manuellement les routeurs et les serveurs. Sauf que, par un incroyable mauvais alignement de planètes, le système de badges électroniques ne fonctionnait plus non plus. Santosh Janardhan raconte que les centres de Facebook étant particulièrement bien protégés contre les intrusions, il a fallu faire intervenir une équipe de démolisseurs pour pénétrer dans les bâtiments.
Quatre règles de base que personne ne suit
Suite à ces événements, le bureau d’analystes Gartner aurait été abondamment sollicité par les entreprises pour prodiguer les bonnes pratiques qui évitent une telle super-panne. « Cela témoigne d’un problème de fond. Car, avant de s’inquiéter de telles pannes géantes, les entreprises auraient dû nous solliciter sur la manière de maintenir une bonne hygiène dans leurs réseaux. Et, franchement, la majorité des entreprises que je rencontre omettent juste d’appliquer les règles de base », lance l’analyste Andrew Lerner, de Gartner.
Selon Andrew Lerner, les règles de base comprennent :
le suivi régulier et la sauvegarde des configurations des équipements réseau dans une base de données centrale,
la mise en place d’un plan de retour vers une configuration antérieure,
des tests fréquents concernant la bonne marche du réseau.
D’après lui, il faut ensuite tirer trois enseignements de la panne de Facebook.
Enseignement 1 : toujours s’attendre au pire
Andrew Lerner l’assure : être pessimiste rend créatif ! Il suggère aux équipes informatiques de rechercher tous les points de défaillance possibles au sein de leurs réseaux et d’imaginer comment ils pourraient déclencher des pannes en cascade.
Par exemple, si une entreprise s’appuie sur une plateforme particulière de gestion des informations et des événements de sécurité pour le dépannage du réseau, elle doit envisager ce qui se passerait si cette plateforme tombait elle-même en panne, ou était juste indisponible.
Parmi les autres points de défaillance courants figurent l’authentification et, comme dans le cas de la panne de Facebook, le DNS.
Enseignement 2 : planifier le pire
Les consultants le martèlent : les entreprises doivent se livrer régulièrement à des exercices sur table, où elles simulent la façon dont elles réagiraient à une panne de réseau comme celle qu’a connue Facebook.
« La panne de Facebook suggère que les entreprises devraient maîtriser sur le bout des doigts le scénario d’une véritable reprise après sinistre. C’est-à-dire qu’elles savent exactement quoi faire, comment, en combien de temps, avec quelle organisation, quand leur infrastructure n’est plus utilisable », lance Terry Slattery, l’expert réseau de la société de conseil NetCraftsmen.
Il ajoute qu’un plan d’urgence viable pourrait s’articuler autour d’un accès réseau indépendant des potentiels points de défaillance précédemment identifiés (le DNS…), avec des procédures essentiellement manuelles, qui ne risquent pas de buter sur la panne d’un logiciel censé réagir de manière automatique.
On notera que Facebook a déclaré posséder un tel réseau indépendant de secours. Pour autant, il serait lui aussi tombé en panne. L’éditeur n’a pas expliqué pourquoi.
Enseignement 3 : s’entraîner au pire
« Si vous ne pouvez pas maîtriser une panne que vous avez vous-même orchestrée, il vous sera difficile de gérer une véritable urgence lorsqu’elle se produira. »
Terry SlateryExpert réseau, société de conseil NetCraftsmen
Scénariser ne suffit pas. Terry Slattery engage les entreprises à procéder à des tests de défaillance active. À l’instar du Chaos Monkey de Netflix ou des tests d’intrusion en cybersécurité, les tests de défaillance active consistent à introduire délibérément une défaillance réelle – bien que contenue et contrôlée – dans le réseau. Il peut s’agir de mettre hors service un lien ou un routeur pour découvrir les vulnérabilités architecturales, puis de tester les processus de récupération.
Problème, la plupart des entreprises n’aiment pas et évitent instinctivement les tests de défaillance. En effet, ces exercices nécessitent une préparation préalable importante et les équipes réseau craignent souvent que les exercices n’entraînent des pannes réelles.
« Et pourtant ! C’est bien dans la panne réelle que réside la plus grande valeur de ces tests. Si vous ne pouvez pas maîtriser une panne que vous avez vous-même orchestrée, il vous sera difficile de gérer une véritable urgence lorsqu’elle se produira », prévient Terry Slattery.
Andrew Lerner, qui a lui-même piloté une version réseau du Chaos Monkey de Netflix, raconte que les entreprises mènent généralement leurs tests lorsqu’elles ont déployé toutes leurs mesures de haute disponibilité, celles que l’on déploie lors des pics d’activité (pendant les fêtes pour le commerce électronique, par exemple) pour que rien ne casse.
Il estime toutefois que cette stratégie est malavisée, car ces mesures masquent souvent une instabilité et une fragilité profondément enfouie dans les systèmes. « Or, c’est lorsqu’un problème arrive sur ces fragilités que cela crée des pannes en cascade », conclut-il.
