GitLab revient sur la panne qui l'a frappé le 31 janvier dernier

Et indique les mesures prises pour garantir que cela ne se reproduise plus

Le 31 janvier dernier, la plateforme de gestion des développements collaboratifs GitLab a été indisponible pendant plusieurs heures. Sur son portail, les utilisateurs pouvaient lire « ;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 ;».

Un problème qui 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. Un incident qui a conduit à la suppression de plus de 300 Go de données en production. GitLab a indiqué avoir perdu plus de 6 heures de données qui ont atterri sur sa plateforme, ce qui signifie qu’environ 4613 projets réguliers, 74 forks, et 350 importations ont été effacés. Elle s’est attelée à restaurer le maximum de données possible.

Dans un billet de blog, GitLab a reconnu que « perdre des données de production est inacceptable. Pour garantir que cela ne se reproduise plus, nous travaillons à de multiples améliorations à nos opérations et procédures de récupération pour GitLab.com ». Aussi, avant de présenter son analyse (notamment ce qui s’est mal passé, ce qui a été fait pour restaurer les données et les décisions prises pour éviter ce genre d’incident à l’avenir), le PDG de GitLab a tenu à présenter ses excuses à tous les utilisateurs personnellement et également au nom de toute l’équipe.

Pour analyser la cause première de ces problèmes, GitLab a utilisé la règle des « 5 why ». L’incident a été divisé en deux problèmes principaux : GitLab.com en panne et la grosse quantité de temps que cela a coûté pour restaurer GitLab.com.

Problème 1: GitLab.com était en panne pendant 18 heures environ.

1. Pourquoi GitLab.com était-il en panne ? Le répertoire de la base de données primaire a été supprimé par accident, au lieu de supprimer le répertoire de base de données secondaire.
2. Pourquoi le répertoire de base de données a-t-il été supprimé? La réplication de base de données s'est arrêtée, nécessitant la réinitialisation / reconstitution du secondaire. Ceci nécessite à son tour que le répertoire de données PostgreSQL soit vide. Sa restauration doit être faite en manuel, car le processus n’est pas automatisé. De plus ce processus n’a pas été convenablement documenté.
3. Pourquoi la réplication a-t-elle cessé ? Un pic de chargement de la base de données a provoqué l'arrêt du processus de réplication de la base de données. Cela était dû au retrait primaire des segments WAL avant que le secondaire ne puisse les reproduire.
4. Pourquoi la charge de la base de données a-t-elle augmenté ? Cela a été causé par deux événements se produisant en même temps : une augmentation du spam, et un processus visant à supprimer un employé GitLab et les données associées.
5. Pourquoi un employé de GitLab devait-il être retiré ? L'employé a été signalé par un troll pour abus. Le système actuel utilisé pour répondre aux rapports d'abus facilite la négligence des détails concernant ceux qui ont été signalés. Par conséquent, l'employé a été accidentellement programmé pour un retrait.

Problème 2 : la restauration de GitLab.com a pris plus de 18 heures.

1. Pourquoi la restauration de GitLab.com a-t-elle duré si longtemps? GitLab.com a dû être restauré en utilisant une copie de la base de données intermédiaire. Cette dernière était hébergée sur des machines virtuelles plus lentes d'Azure dans une région différente.
2. Pourquoi la base de données intermédiaire était nécessaire pour restaurer GitLab.com? Les snapshots de disque Azure n'étaient pas activés pour les serveurs de base de données et les sauvegardes de bases de données périodiques à l'aide de pg_dump ne fonctionnaient pas.
3. Pourquoi ne pas se tourner vers l'hôte de base de données secondaire ? Les données de la base de données secondaire ont été effacées dans le cadre de la restauration de la réplication de la base de données. En tant que telle, elle ne pouvait donc plus être utilisée pour la restauration.
4. Pourquoi ne pas utiliser une procédure standard de sauvegarde ? La procédure de sauvegarde standard utilise pg_dump pour effectuer une sauvegarde logique de la base de données. Cette procédure a silencieusement échoué, car elle utilisait PostgreSQL 9.2, tandis que GitLab.com s'exécute sur PostgreSQL 9.6.
5. Pourquoi la procédure de sauvegarde a-t-elle silencieusement échoué ? Des notifications ont été envoyées après l’échec. Cependant, à cause du rejet des courriels, il n'y avait aucune indication d'échec. L'envoi était un processus automatisé sans autre moyen de signaler des erreurs.
6. Pourquoi les courriels ont-ils été rejetés ? Les courriels ont été rejetés par le serveur mail à cause des courriels qui n’étaient pas signés en utilisant DMARC.
7. Pourquoi les snapshots de disque Azure n'ont-ils pas été activés ? Nous avons supposé que nos autres procédures de sauvegarde étaient suffisantes. En outre, la restauration de ces snapshots peut prendre des jours.
8. Pourquoi la procédure de sauvegarde n'a-t-elle pas été testée régulièrement ? Parce qu'il n'y avait pas de propriétaire assigné, par conséquent personne n'était responsable pour les tests de cette procédure.

L’entreprise a décidé de travailler à corriger et améliorer ses diverses procédures de restauration. Voici comment elle a réparti ses tâches :

• mettre à jour PS1 sur tous les hôtes pour différencier plus clairement les hôtes et les environnements (# 1094) ;
• surveiller les sauvegardes Prometheus (# 1095) ;
• Définir max_connections de PostgreSQL sur une valeur rationnelle (# 1096) ;
• étudier la restauration ponctuelle et l'archivage continu de PostgreSQL (# 1097) ;
• effectuer des snapshots LVM horaires des bases de données de production (# 1098) ;
• effectuer des snapshots de disque Azure des bases de données de production (# 1099) ;
• restauration des répliques de production (# 1101) ;
• tests automatisés de récupération des sauvegardes de bases de données PostgreSQL (# 1102) ;
• améliorer la documentation de réplication PostgreSQL (# 1103) ;
• recherchez pgbarman pour créer des sauvegardes PostgreSQL (# 1105) ;
• étudier l'utilisation de WAL-E comme moyen de sauvegarde de base de données et de réplication en temps réel (# 494) ;
• création de la restauration en continu de la base de données ;
• affecter un propriétaire pour la durabilité des données.

Source : GitLab

Et vous ?

Que pensez-vous de ces mesures ? Sont-elles suffisantes pour endiguer ce type de problème à l'avenir ?