GitLab.com, ou de l'importance de vérifier ses sauvegardes

Gitlab.com, concurrent de Github pour ceux qui ne connaîtraient pas, a été hors service du 31/01/2017 21h00 UTC au 01/02/2017 18h14 UTC. Pire : toutes les données du 31/01/2017 entre 17h20 et 23h25 UTC ont été définitivement perdues, comme quoi ça n’arrive pas qu’à Zeste de Savoir. Si dans le cas de notre association c’était chiant mais n’a pas provoqué de drame, on parle là d’un gros fournisseur de service utilisé par des entreprises, qui parfois paient pour avoir un support.

Pourtant les gars ne sont pas des amateurs, mais sont des être humains. Ils sont sujets aux erreurs, surtout sous l’effet de la routine et du stress. Jugez plutôt, si on regarde le rapport d’incidents :

Un employé s’est planté de serveur, et a supprimé la copie fonctionnelle de la base de prod. Oups. Que faire ?

1. C’est pas grave, il y avait des snapshots LVM automatiques. Mais non, parce qu’ils n’étaient pris que toutes les 24 heures (heureusement il y en avait un manuel de « seulement » 6 heures plus tôt). Et 24 heures de pertes pour ce genre de données, c’est trop.
2. Mais c’est pas grave, il y avait aussi les backups normaux. Mais en fait non : ils étaient HS et personne ne s’en était rendu compte.
3. Mais c’est pas grave, parce qu’ils y avait des dumps SQL. Sauf que les dumps échouaient silencieusement à cause d’une erreur de configuration que personne n’a vu.
4. Mais c’est pas grave, tout ça tourne sur du Azure, avec des snapshots des disques NFS. Sauf pour les disques des SGBD, vérification faite.
5. Mais c’est pas grave, parce que tout ça est sauvegardé sur du Amazon S3. Dont le compte est vide, en réalité.

5 systèmes de sauvegarde / tolérance de pannes ; les 5 étaient HS simultanément. Joli score non ?

Si vous avez eu une journée de merde, pensez aux admin sys de chez GitLab, et souriez

PS : je salue quand même la transparence de la boite, qui n’a pas cherché à planquer le problème, mais qui a communiqué de bout en bout sur les opérations en cours à l’aide d’à peu près tous les outils possibles.

En résumé :

1. Faites des sauvegardes.
2. Vérifiez vos sauvegardes.
3. Le SaaS c’est pratique, mais nous rends dépendants des erreurs des autres.
4. La virtualisation c’est pratique, mais ne permet pas de lancer un outil de récupération des données sur le disque en cas de suppression malencontreuse (en admettant que ça fonctionne avec les > 300 Go de BDD PostgreSQL).

Je vais peut être dire une connerie, mais GitLab héberge du contenu versionné sous Git, non ? Comme Git est décentralisé, les données hébergées sur Gitlab sont aussi dans les copies des repo de chaque développeur de chaque projet, ce qui limite pas mal la casse. (Bon, sauf les hooks et les données utilisateurs type clés publiques, mais enfin on en crée pas des milliers ni même des centaines par jour sur un même projet.)

Ils n’ont pas perdu de code, ni les wiki. Par-contre tous les commentaires de PR ou MR, les tickets (issues), utilisateurs enregistré ce jour là, … . Je pense surtout pour les tickets et les PR et MR qui sont chiant.

Team-member-1, doit mal dormir ce soir . Après c’est une faute collective quand les 5 back-up ne marchent pas.

Par-contre tous les commentaires de PR ou MR, les tickets (issues)

Ah oui, effectivement, je n’avais pas pensé à ça.

Beaucoup plus que ça en fait : c’est une forge logicielle complète. Donc là ils ont sauvé les dépôts Git, mais il y a bien plus. De ce que je vois de l’utilisation au boulot (sur une instance locale !) :

• Les webhooks dont il est question dans l’article,
• Les wikis qui sont au format Git (et que personne ou presque ne clone hors du serveur),
• Toute la gestion des utilisateurs (en BDD),
• Tous les tickets (en BDD),
• Tous les commentaires de Merge Request (en BDD),
• Toutes les méta-données et la configuration des runners de l’intégration continue (au moins en partie en BDD) (la configuration projet de l’intégration continue est dans le dépôt),
• Tous les snippets (en BDD),
• Toutes les méta-données dont les droits sur les organisations et projets (en BDD),
• PS : GitLab Omnibus vient avec MatterMost, un genre de Slack, en BDD aussi, mais je ne crois pas qu’il soit activé sur gitlab.com
• Et il m’en manque sans doute.

PS : comme ils ont bien réagit, personne ne sera viré – ça a déjà été annoncé.

PS : je salue quand même la transparence de la boite, qui n’a pas cherché à planquer le problème, mais qui a communiqué de bout en bout sur les opérations en cours à l’aide d’à peu près tous les outils possibles.

C’est bien la transparence, mais j’ai eu le sentiment qu’ils sont allés un peu trop loin là dedans. On se saurait presque cru dans une émission de téléréalité pour admin système. Je ne sasi pas, peut être le manque d’habitudes de cette pratique. Mais ils assument et c’est super.

PS : ma boîte utilise Gitlab pour les git distants, heureusement on n’a que le code là bas

On se saurait presque cru dans une émission de téléréalité pour admin système.

Pour moi, le flux vidéo était de trop (je ne vois pas ce qu’il pouvait apporter aux entreprises paralysées et aux admins sys qui bossaient sur le problème). Le reste me parait bien.

Le nom de l’opération de secours me plait bien  :

.

Git/wiki repositories and self hosted installations were not affected.

Ils ont sauvé les wiki, on sait tous que la doc, c’est le plus chiant à écrire.

Le fin mot de l’histoire : https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/