GitLab se remet péniblement d’un accident qui a vu la disparition de nombreuses informations. Pendant six heures, des problèmes se sont succédé, suite à une mauvaise manipulation d'un administrateur.
GitLab, une alternative open source à GitHub, se remet péniblement d’un incident majeur dans ses bases de données. Un administrateur système a supprimé par erreur un dossier contenant 300 Go de données diverses : bugs, merge requests, métadonnées utilisateurs, commentaires, snippets et autres. Une action qui a pris place dans le cadre d'une lutte contre un phénomène détecté de spam.
Environ 5 000 projets ont été touchés
Si l’on connait en détails les raisons de cet accident, c’est que GitLab a choisi de jouer la carte de la transparence complète. Et si ce point est particulièrement appréciable, c’est que l’éditeur assume pleinement sa faute dans le déroulement de l’incident. Et pour cause : sur les cinq mécanismes mis en place pour gérer et restaurer les sauvegardes, aucun n’a fonctionné pleinement.
Les erreurs constatées par les administrateurs sont à la fois surprenantes et assez « amusantes ». On trouve pêle-mêle des sauvegardes qui ne se faisaient que toutes les 24 heures, des données sauvegardées à des emplacements inconnus, des informations parfois irrécupérables à cause d’erreurs dans la configuration, des snapshots Azure qui n’étaient activés que pour le serveur NFS, des sauvegardes qui n’ont pas du tout fonctionné avec les serveurs S3 (Amazon), une réplication des données générant des incohérences, des fichiers de quelques octets à peine...
Les problèmes ont commencé mardi soir. Ils se sont enchainés pendant environ six heures, GitLabs constatant au fur et à mesure que ses techniques de sauvegarde et de duplication ne fonctionnaient pas, ou alors très mal. Un véritable feuilleton puisque l'éditeur a ouvert pour l'occasion un flux vidéo en direct sur YouTube, suivi par des milliers de personnes.
GitLab indique que seuls 1 % des utilisateurs ont été touchés par le problème, ce qui représente précisément 707 comptes. En tout, 5 037 projets, 74 forks et 350 importations environ ont été supprimés. Environ 5 000 commentaires sont également perdus. Ces informations correspondent en fait aux données non prises en charge par la dernière sauvegarde, qui dataient de six heures auparavant.
La transparence d'un côté, l'étonnement de l'autre
Si la suppression malencontreuse n'avait laissé que 4,5 Go de données sur les 300 Go initiaux, presque tous ont pu finalement être restaurés hier soir après une longue lutte. Signalons par ailleurs que les données centrales des dépôts Git n’ont pas été touchées. GitLab indique en effet que seules des « métadonnées périphériques » ont été perdues « pendant une fenêtre de six heures ». Cependant, même si GitLab a montré une transparence exemplaire en ne cachant rien de ses problèmes et de sa propre responsabilité, les développeurs concernés pourraient ne pas être d’accord avec cette notion de « périphériques ».
Le fait qu’aucun des cinq mécanismes de sauvegarde et de réplication n’ait correctement fonctionné représente évidemment un sérieux problème. De fait, GitLab est à la fois félicité pour ses informations précises données aux utilisateurs et condamné pour ne pas avoir suffisamment testé ses propres outils. GitLab servant de carrefour pour la gestion de projets, la fiabilité et la confiance sont en effet primordiaux.
Actuellement, tous les services fonctionnent normalement, après une interruption d'environ 24 heures. GitLab assure que des mesures ont été prises et continueront de l’être pour que ce type d’incident ne se reproduise plus, y compris sur les mécanismes fautifs de sauvegarde.
