Panne GitLab : la société indique les mesures prises pour éviter que ce type de scénario se reproduise
Un administrateur système de GitLab supprime accidentellement 310 Go de données de production
et rend le site indisponible depuis plusieurs heures
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 ?
:fleche: Que pensez-vous de cet incident ?
:fleche: Erreur, négligence ou incident inévitable ?
Voir aussi
:fleche: 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
GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne
GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne,
mais 6 heures de données n’ont pas pu être récupérées
Le 31 janvier dernier aux environs de 18 h GMT, un administrateur chez GitLab a accidentellement supprimé plus de 300 Go de données de production. À la suite de cette erreur humaine, le site fut indisponible depuis cet incident jusqu’au lendemain aux environs de 18 h GMT.
Généralement, les entreprises qui stockent des données sensibles assurent leur résilience en faisant des sauvegardes régulières de leurs données et cela dans différents endroits. Par ailleurs, elles s’efforcent de suivre des codes de bonnes pratiques en testant de manière régulière l’intégrité de leurs sauvegardes afin de ne pas avoir de mauvaises surprises en cas de soucis. Toutefois, l’incident qui a frappé la plateforme GitLab a démontré que l’entreprise ne s’était pas préparée à tout cela. Toutes les tentatives de restauration de la base de données supprimée à partir des sauvegardes ont échoué.
Fort heureusement, les données supprimées ne concernaient que celles des utilisateurs, des commentaires, des snippets, des bogues, des demandes d’intégration de changements, etc. Les dépôts Git et Wiki des développeurs ainsi que les installations hébergées par l’entreprise n’ont pas été affectés par cet accident. Par ailleurs, GitLab souligne que seul 1 % des utilisateurs (707 en tout) sont concernés par ces données supprimées.
En fin de compte, GitLab a pu récupérer un instantané des données disponibles sur un serveur de tests afin de restaurer les données supprimées et est de retour sur la toile. Toutefois, GitLab explique que ces données restaurées proviennent d’une sauvegarde vieille de 6 heures. Ce qui signifie que toutes les données de projets, de problèmes, de demandes de fusion d’utilisateurs, de commentaires, de snippets comprises entre 17 h 20 et 23 h 25 GMT du 31 janvier sont perdues.
Consciente que la perte de données de production sans possibilité de les restaurer en totalité est inacceptable, GitLab entend publier dans les jours à venir les causes de l’occurrence d’un tel accident et la liste des mesures qu’elle a implémentées pour éviter que pareilles erreurs ne surviennent à nouveau.
Source : GitLab
Et vous ?
:fleche: Quelles leçons tirez-vous de l’accident qui a frappé GitLab ?
:fleche: Quels conseils pouvez-vous donner afin de permettre aux autres entreprises de mieux gérer de tels incidents ?
Voir aussi
:fleche: Un administrateur système de GitLab supprime accidentellement 310 Go de données de production et rend le site indisponible depuis plusieurs heures
:fleche: 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
:fleche: Forum Actualités, Wiki Developpez.com, Débats Best of, FAQ Developpez.com
