Une réplique a pris du retard — et la production en a fait les frais
En janvier 2017, GitLab.com s'appuyait sur une base PostgreSQL primaire, db1.cluster.gitlab.com, et une réplique en direct, db2.cluster.gitlab.com, pour assurer sa résilience. Cette architecture, courante pour les configurations à haute disponibilité, visait à maintenir db2 synchronisé pour le basculement, une défense cruciale mais souvent fragile.
Ce soir-là, un pic de charge a provoqué un retard tel que db2 a cessé de se répliquer. La solution standard : réinitialiser db2 en effaçant son dossier de données et en copiant tout depuis db1. Une procédure simple, en théorie.
Cependant, lors de cette réinitialisation, un ingénieur a exécuté par erreur la commande rm -rf non pas sur db2, mais sur db1, la base de production primaire. La commande n'a tourné que pendant une seconde ou deux avant d'être arrêtée, mais les dégâts étaient faits : environ 300 Go de données ont été supprimés. Ce n'était pas une corruption lente ; c'était un effacement soudain et catastrophique de données de production en direct. Les conséquences de cette commande mal dirigée allaient bientôt se révéler, exposant un problème bien plus profond.
Chaque sauvegarde semblait plus sûre qu'elle ne l'était en réalité
Le désastre de GitLab ne découlait pas seulement d'un faux pas, mais d'un château de cartes bâti sur des hypothèses non vérifiées. L'organisation pensait disposer d'une stratégie de sauvegarde robuste, pourtant chaque couche s'est révélée fatalement défaillante, démontrant qu'une sauvegarde non testée n'est qu'une hypothèse, et non une protection.
La confiance placée dans une exportation quotidienne pg_dump vers Amazon S3 était mal placée. La tâche, destinée à protéger la base de données PostgreSQL 9.6, utilisait bizarrement un outil pg_dump provenant d'une version beaucoup plus ancienne, PostgreSQL 9.2. Cette incompatibilité a provoqué une erreur silencieuse lors de l'exportation, laissant le bucket S3 vide.
Surtout, personne n'a détecté cette défaillance systémique. Les e-mails de notification, censés signaler l'échec de la tâche de sauvegarde, étaient systématiquement rejetés par le serveur de messagerie en raison de problèmes d'authentification. Pour aggraver le tout, les snapshots de la base de données de production, une couche fondamentale de résilience, n'avaient jamais été activés. Les snapshots LVM n'existaient que pour la pré-production, et les snapshots Azure Cloud couvraient les disques OS mais pas les volumes critiques de la base de données.
Avec la base de données primaire compromise et la réplique déjà effacée lors de la tentative de récupération, GitLab a fait face à une réalité terrifiante : aucune sauvegarde récente viable n'existait. Le seul chemin de retour était un snapshot manuel vieux d'environ six heures, pris par un ingénieur pour un test de charge sans rapport. Ce coup de chance, plutôt qu'une solution ingénieuse, a souligné la précarité de toute leur philosophie de sauvegarde. La copie de ce snapshot depuis des disques lents a pris environ 18 heures, reflétant la durée totale de l'interruption et soulignant le coût réel d'une préparation négligée à la récupération de données.
La réparation s'est déroulée devant 5 000 spectateurs
La gestion de crise de GitLab a été une leçon de transparence radicale. Les ingénieurs ont partagé des mises à jour en temps réel et le dépannage publiquement via un Google Doc, les réseaux sociaux et un livestream YouTube. Cette décision a transformé une défaillance technique catastrophique en un test de confiance hautement visible, avec plus de 5 000 personnes en train de regarder au pic de l'événement.
La réparation, douloureusement lente, reposait sur un snapshot créé manuellement six heures plus tôt, résidant sur des disques de stockage lents. La restauration de ce snapshot a consommé environ 18 heures, soit la durée de toute l'interruption. Cette récupération lente signifiait que GitLab.com était hors service pendant une période significative.
Au final, GitLab a perdu environ six heures d'enregistrements de base de données. Cela incluait approximativement :
- 5 000 projets
- 5 000 commentaires
- 700 comptes utilisateurs
Les données du dépôt, heureusement, sont restées intactes sur un stockage séparé. Bien que le résultat ait été douloureux, l'affichage public de résilience et d'honnêteté a suscité un respect considérable. Pour une analyse plus approfondie des détails, consultez le Postmortem of database outage of January 31 - GitLab. Cet incident a fondamentalement changé la façon dont beaucoup dans l'industrie perçoivent la gestion des incidents et la transparence radicale.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
La leçon était la responsabilité, pas le blâme
Le post-mortem de GitLab n'a pas cherché de bouc émissaire ; il a diagnostiqué une défaillance systémique de responsabilité. Le problème central n'était pas l'erreur d'un ingénieur, mais l'absence d'un rôle dédié à la fiabilité des sauvegardes et à la vérification routinière des restaurations. Personne n'était responsable, donc les mesures de sécurité critiques se sont atrophiées.
L'incident a catalysé d'importantes réformes internes. GitLab a mis en œuvre des tests de restauration automatisés, garantissant que les sauvegardes n'étaient pas seulement présentes mais fonctionnelles. Ils ont également renforcé les garde-fous d'accès à la production, rendant les actions destructrices plus difficiles à effectuer accidentellement, et ont assigné une responsabilité explicite pour la database reliability à une équipe dédiée.
Pour toute organisation d'ingénierie, la leçon est claire : assignez un responsable spécifique pour l'intégrité des sauvegardes. Établissez des canaux d'alerte vérifiés pour les échecs de sauvegarde — ne comptez pas sur des e-mails qui passent inaperçus. Surtout, testez régulièrement les restaurations pour valider votre stratégie de récupération, et mettez en place des garde-fous robustes pour empêcher la perte accidentelle de données. Vos sauvegardes ne valent que ce que vaut votre dernière restauration vérifiée.
Foire aux questions
Quelle est la cause de la panne de base de données de GitLab en 2017 ?
En réparant un réplica qui avait pris du retard, un ingénieur a accidentellement supprimé des données de la base de données de production au lieu du réplica.
Pourquoi GitLab n'a-t-il pas pu restaurer à partir de ses sauvegardes ?
L'exportation quotidienne a échoué car elle utilisait une version incompatible de l'outil Postgres, et les e-mails d'échec ont été rejetés. Les instantanés de production étaient également indisponibles.
Combien de temps GitLab a-t-il été hors service ?
La récupération a pris environ 18 heures, en grande partie parce que la restauration d'un instantané créé manuellement à partir d'un stockage lent a pris du temps.
Combien de données GitLab a-t-il perdues ?
GitLab a perdu environ six heures de données de base de données, incluant environ 5 000 projets, 5 000 commentaires et 700 comptes utilisateurs.
Quelle est la leçon principale à tirer de cet incident ?
Une sauvegarde n'est fiable que lorsque les équipes testent régulièrement qu'elles peuvent la restaurer — et que quelqu'un est responsable de ce processus.