Le vérificateur de configuration auto-réparateur de Facebook a transformé une valeur erronée en une panne de 2,5 heures

En septembre 2010, Facebook est resté inaccessible pendant environ deux heures et demie. L'équipe d'ingénierie de l'entreprise, dans un rare post-mortem public publié le jour même par le directeur de l'ingénierie logicielle Robert Johnson, l'a qualifié de pire panne subie par le site en plus de quatre ans. Chaque visiteur, sur chaque page, a rencontré des erreurs jusqu'au rétablissement du site.

La cause profonde était un système automatisé censé maintenir la santé des valeurs de configuration : il comparait les valeurs mises en cache à un magasin persistant et remplaçait tout ce qu'il jugeait invalide. Ce jour-là, une modification a laissé une valeur erronée dans le magasin persistant lui-même. Chaque client a vu la valeur « invalide » et a tenté de la réparer, et comme la réparation impliquait d'interroger un cluster de bases de données, celui-ci a été submergé par des centaines de milliers de requêtes par seconde.

La gestion des erreurs a aggravé la situation. Lorsqu'une requête d'un client échouait, celui-ci interprétait l'échec comme « valeur toujours invalide » et supprimait la clé de cache correspondante — générant ainsi une nouvelle requête de réparation. Même après la correction de la valeur erronée d'origine, la boucle continuait à s'alimenter elle-même. La seule issue était de couper tout le trafic vers le cluster de bases de données, ce qui signifiait éteindre entièrement le site, laisser les bases de données récupérer, puis laisser les utilisateurs revenir progressivement.

Site entièrement hors service pendant environ 2,5 heures — les propres ingénieurs de Facebook l'ont qualifié de pire panne en plus de quatre ans

Le vérificateur supposait que le magasin persistant était toujours correct ; lorsqu'il contenait la valeur erronée, chaque client recevait la même instruction de réparation empoisonnée.

La gestion des erreurs confondait « base de données surchargée » et « valeur invalide », si bien que chaque échec générait davantage de charge — une boucle de rétroaction amplificatrice.

La suppression des clés de cache en cas d'erreur a éliminé la seule couche qui aurait pu absorber la tempête de nouvelles tentatives.

Il n'y avait aucun disjoncteur entre les clients et le cluster, de sorte que le seul levier restant était un arrêt total du site.

Un code auto-réparateur qui traite chaque erreur comme un « va la corriger » amplifie les défaillances au lieu de les absorber. Limitez les nouvelles tentatives par client, amortissez les boucles de rétroaction et conservez un levier de récupération avant d'en arriver à un arrêt total.

Facebook a désactivé le système de configuration autocorrecteur le jour même et a déclaré le reconcevoir autour de modèles tolérant les pics transitoires et les boucles de rétroaction. Le service a été entièrement rétabli ce jour-là et l'entreprise, alors le plus grand réseau social du monde, a publié les détails techniques en quelques heures. L'incident est encore cité comme un cas d'école de gestion des erreurs qui transforme une petite défaillance en une tempête auto-entretenue.