Un administrateur système de GitLab supprime accidentellement 310 Go de données de production
Et rend le site indisponible depuis plusieurs heures

Le , par Olivier Famien, Chroniqueur Actualités
La plateforme de gestion des développements collaboratifs GitLab est indisponible depuis hier 31 janvier. Sur son portail, on peut lire ouvertement que « GitLab.com est actuellement hors ligne en raison de problèmes avec notre base de données de production. Nous travaillons dur pour résoudre le problème rapidement. Suivez GitLabStatus pour les dernières mises à jour ».

Ce problème est survenu alors qu’un administrateur système de GitLab a entamé une procédure de réplication des données de production pour les utiliser à d'autres fins. Après avoir entamé la procédure de réplication, l’administrateur a dû l’interrompre pour régler un problème de spam et de surcharge de la base de données. Lorsque ce dernier a pu rétablir à la normale le chargement de la base de données PostgreSQL et est revenu sur la réplication de sa base de données, il a reçu une alerte du système qui refusait de répliquer la base de données. Après avoir essayé plusieurs solutions sans succès, l’administrateur s’est dit que le système doit certainement détecter un répertoire vide et décide de supprimer ce répertoire. Malheureusement pour ce dernier, après une ou deux secondes, il remarque qu’il a exécuté la requête sur la base de données de production. Il tente désespérément d’annuler la requête, mais sur les 310 Go de données contenues dans le répertoire, il ne reste plus que 4,5 Go de données.

Comme conséquences de ce fâcheux accident, l’entreprise indique qu’elle a perdu plus de 06 heures de données qui ont atterri sur sa plateforme, ce qui signifie qu’environ 4613 projets réguliers, 74 forks, et 350 importations sont effacés. L’entreprise ajoute que 707 utilisateurs sont affectés par cette perte et l’on peut également envisager une perte de tous les webhooks (fonctionnalités d’une application permettant de fournir des données en temps à une autre application), même si l’information reste encore non confirmée.

Depuis cet accident, l’entreprise se bat avec ses équipements pour récupérer les données perdues. La grosse difficulté pour GitLab est que les instantanés du gestionnaire des volumes logiques sont effectués par défaut une fois toutes les 24 heures. De même, les sauvegardes régulières sont également faites une fois toutes les 24 heures. Du côté d’Azure, ce sont les mêmes difficultés. Les instantanés de disque dans Azure sont activés pour le serveur NFS, mais pas pour les serveurs de base de données. En plus de ces problèmes répertoriés, GitLab souligne que « le processus de synchronisation supprime les webhooks une fois qu’il a synchronisé les données à la simulation. À moins que nous puissions les retirer d’une sauvegarde régulière des dernières 24 heures, elles seront perdues ». En envisageant de passer par la réplication, l’équipe de GitLab estime que « la procédure de réplication est super fragile, encline à l’erreur, repose sur une poignée de scripts de shell aléatoires et est mal documentée ». À ces maux, il faut adjoindre le fait que les sauvegardes sur le cloud Amazon S3 ne fonctionnent pas du tout, bucket, l’unité de logique de stockage sur Amazon Web Services (AWS) est vide. Les ingénieurs de GitLab expliquent qu’ils n’ont pas un système solide d’alerte et de pagination lorsque les sauvegardes échouent.

En fin de compte « sur les cinq techniques de sauvegarde/réplication déployées, aucune ne fonctionne correctement ni n’est configurée en premier lieu ». Le pire dans cette histoire est que l’entreprise a annoncé vers la fin de l’année dernière qu’elle abandonnait le cloud pour migrer vers Ceph FS, le nouveau système de fichiers utilisant des groupes de serveurs pour stocker ses données sur la plateforme Ceph afin d’améliorer les performances de l’accès aux données. Malheureusement, en privilégiant cette plateforme pour ses performances et la haute disponibilité des données, GitLab a négligé d’autres aspects ce qui lui coûte cher aujourd’hui.

Actuellement, l’entreprise essaye de restaurer la sauvegarde qui a été faite six heures avant la perte de données. Sur Tweeter, GitLab affirme qu’elle a pu restaurer ces données. Cela signifie donc que si les données sont restaurées avec cette sauvegarde, il y aura certainement des pertes de données qui se feront ressentir. Pour l’administrateur qui a occasionné cette perte, il retient « qu’il est préférable pour lui de ne plus rien exécuter aujourd’hui avec sudo ». Mais au-delà de cet incident, l’on peut également noter que GitLab a été véritablement transparent dans cet incident en communiquant énormément sur les différentes étapes des actions entreprises.

Gitlab Live Stream: working on restoring gitlab.com

Source : GitLab, GitLab Google docs détails sur l’incident, Tweeter

Et vous ?

Que pensez-vous de cet incident ?

Erreur, négligence ou incident inévitable ?

Voir aussi

GitHub : des utilisateurs de la plateforme se disent « frustrés » et « complètement ignorés » sur une pétition signée par des centaines d'entre eux


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Narann Narann - Membre habitué https://www.developpez.com
le 01/02/2017 à 21:40
Plus que transparent. C’était un live en continue dans les locaux de GitLab ou les différentes personnes intervenaient et expliquaient en détails les problèmes et solutions.
Avatar de mverhaeghe mverhaeghe - Membre habitué https://www.developpez.com
le 01/02/2017 à 22:49
Jolie communication, effectivement !
Au dela du fait que sur les cinq procédés de sauvegardes, aucune ne fonctionnait réellement (les bras m'en tombent ceci dit), je ne comprends pas trop la problématique de sauvegarde de base sur Azure. Je pensais, pour l'avoir vu, que les bases de données étaient sauvegardés en automatiques quasiment toutes les 15 minutes ? A moins que ce ne soit que pour certains types de base ?
Avatar de tmcuh tmcuh - Membre à l'essai https://www.developpez.com
le 01/02/2017 à 23:15
Y'a pas un mec qui a vu que les backup fonctionnait pas ou mal ? Hallucinant.
Au moins vérifier une fois par mois que les backup fonctionnent bien, qu'on peut les restaurer, etc. Mais là sur 5 plateformes à la fois LOL
Le pauvre administrateur, j'espère qu'il sera pas mis à la porte pour autant.
ça m'est déjà arrivé sur une grosse base de production client, heureusement que les backup m'ont sauvé la vie, je crois que j'aurais dûe revendre ma maison si j'avais pas eu ça
Avatar de Pierre Louis Chevalier Pierre Louis Chevalier - Expert éminent https://www.developpez.com
le 01/02/2017 à 23:40
Le coup des backups qui sont faits sans que personne n'ai jamais essayé de faire un recovery pour vérifier que tout est ok jusqu'au jour ou... c'est un grand classique, c'est très courant mais les gens évitent de crier ça sur les toits

Ceci combiné à la croissance des ransomwares ou autres catastrophes sécuritaires ca promets qu'on continue à avoir régulièrement des millions d'euros de dommages partis en fumée et des dépôts de bilans...
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 02/02/2017 à 1:13
Bah c'est du Git, les devs des projet au pire peuvent repousser tout ce qu'ils ont en local, c'est bien comme ça qu'on vends toujours git? Tout est local

Pour le reste, sans blamer qui que ce soit, les bourdes ça arrive. C'est bien facile de dire qu'il faut tester ses backup, mais c'est toujours face au désastre qu'on se rend compte qu'il y a un petit détails qui avait été oublié dans les scénarios testé, et qui fait qu'il faut tout improviser.

Genre le serveur LDAP mort et les backups inaccessible car impossible de s'authentifier sur le serveur distant qui a cloné le ldap foireux et qui s'en sert pour l'authentification
Les bandes hors site qu'on rapatrie en urgence et qui finissent dans un crash auto
Le backup accessible, testé régulièrement par sondage et qui, une fois lancé pour un full restore t'annonce joyeusement "do not stop process, restoring, estimated time: 120h"
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 02/02/2017 à 9:35
Gitlab est un bon produit (pour lequel je fais pas mal de promo) mais malheureusement cette histoire me surprend moyennement. Je ne pense pas que ce soit un simple accident mais symptomatique d'une rigueur / qualité perfectible. Entre autre, ils ont près de 6000 tickets ouverts sur leur produit...

Pour moi cette histoire est plutôt une bonne chose (pas de dégât vraiment sérieux) car c'est l'opportunité d'envoyer un signal aux responsables pour revoir leurs priorités et se focaliser un peu plus sur la finalisation de l'existant plutôt que la course à l’échalote en terme de nouvelles fonctionnalités. En tous cas c'est comme ça que je perçois l'ambiance vu de l'extérieur.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 02/02/2017 à 9:35
Normalement, c'est des copies. BitTorrent a la rescousse ? Encore faut-il que l' "E.D.I." soit du "Git I.D.E."...

Oui, sa se ressemble non ? "On regarde bien developpez.com a cette instant". Pourtant Labview et les autres, donc les outils d'émulation et simulation de circuits, y sont aussi parfois cité...

Bon courage à l'administrateur fautif, tous n'est pas perdu comme pour les "astronautes" en difficultés dans le film Gravity, il y aura peut-être des pertes (en avion, c'est pas pareil)...
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 02/02/2017 à 10:41
Ce moment de solitude quand tu te rend compte que la commande de suppression est lancée l'environnement de prod
Avatar de Narann Narann - Membre habitué https://www.developpez.com
le 02/02/2017 à 12:29
Les backups c'est quantique, ça existe jusqu’à ce que tu regarde ce qu'il y a dedans.
Avatar de ddoumeche ddoumeche - Membre éprouvé https://www.developpez.com
le 02/02/2017 à 13:19
Citation Envoyé par tmcuh Voir le message
Y'a pas un mec qui a vu que les backup fonctionnait pas ou mal ? Hallucinant.
Au moins vérifier une fois par mois que les backup fonctionnent bien, qu'on peut les restaurer, etc. Mais là sur 5 plateformes à la fois LOL
Le pauvre administrateur, j'espère qu'il sera pas mis à la porte pour autant.
ça m'est déjà arrivé sur une grosse base de production client, heureusement que les backup m'ont sauvé la vie, je crois que j'aurais dûe revendre ma maison si j'avais pas eu ça
Il faut espérer au contraire qu'il soit mis à la porte ou lourdement sanctionné, la sauvegarde doit rester l'alpha et l'oméga du travail de tout administrateurs système ou DBA.

Il n'y a pas de journaux de transaction dans Postgresql, qui puisse être rejoués depuis la dernière sauvegarde ?
Offres d'emploi IT
FR-ATS Rennes- Ingénieur Réseau (H/F)
Atos Technology Services - Bretagne - Rennes (35000)
Développeur fullstack senior H/F
Urban Linker - Ile de France - Paris (75000)
Chef de projets nouvelles technologies H/F
Sogeti France - Bretagne - Rennes (35000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil