Licence CC BY

Retour sur une semaine compliquée pour Zeste de Savoir

Quand ça ne veut pas, ben ça ne veut pas…

Salut les agrumes !

Vous l'avez sans doute remarqué, mais la semaine passée a été compliquée sur Zeste de Savoir : lenteurs généralisées, site inaccessible, bugs dans tous les sens, etc. Maintenant que le gros de la tempête est passé, voici venir le temps du bilan…

L'état actuel du site

Commençons par là, puisque c'est sans doute le plus important pour vous, visiteurs. La première chose que vous devez savoir, c'est ceci :

Toutes les données du mardi 18 août 2015, de 3h00 à minuit, heure de Paris, sont hélas définitivement perdues.

Toute l'équipe du site (moi le premier) vous présente ses excuses, en particulier à tous ceux qui ont perdu du travail dans cette histoire.

Quant au reste, le site est maintenant presque rétabli dans son état normal. « Presque » car il peut subsister quelques bizarreries. À la publication de cet article, deux sont connues :

  1. L'envoi d'images au format JPEG dans les galeries ou ailleurs sur le site (notamment dans les avatars) ne fonctionne pas.
  2. Le serveur n'a pas d'IPv6 et donc n'est accessible qu'en IPv4. Parce que mi 2015, un hébergeur lance de nouvelles offres sans cette technologie.

N'hésitez pas à nous signaler (par exemple dans les commentaires) toute étrangeté que vous croiseriez.

Mais comment en est-on arrivés là ?

En bref : par un épouvantable concours de malchances et de problèmes en tous genres.

Acte 1 : Un hébergement inadapté

Depuis son premier jour, Zeste de Savoir était hébergé sur un VPS Classic 3 2014. Cette offre avait pour principal intérêt son rapport puissance / prix, et deux inconvénients majeurs. Le premier, une technologie qui n'offrait aucune garantie de performances. Le second, qui découle du premier, c'est que OVH considérait que ces offres ne devaient servir qu'à des fins de tests[^tests].

Or donc avec la montée en charge de Zeste de Savoir, bien plus importante que dans nos prévisions initiales, cette offre a montré ses limites. On cherchait bien une solution de rechange depuis le mois d'avril, mais le marché est complexe et très vite très cher…

Et voilà donc que début août arrivent deux nouveaux protagonistes :

  1. Notre serveur décide d'avoir des performances vraiment minables, alors que le trafic reste stable (nous sommes au cœur de l'été). D'ordinaire ce genre de ralentissement cesse en quelques heures, mais là l'hébergeur ne semble rien faire. Et des temps d'accès entre quelques secondes et plusieurs dizaines de secondes, c'est vraiment trop.
  2. OVH sort une nouvelle offre VPS très intéressante, et surtout avec des garanties de performances.

Donc, décision est prise de commander un de ces nouveaux serveurs, de l'installer tranquillement et une fois stabilisé, de basculer.

Acte 2 : Quand les outils vous haïssent

Nous sommes donc mardi 18 août 2015 vers 21h17 quand votre serviteur a la console OVH ouverte sur 2 onglets, l'ancienne et la nouvelle prod, pour comparer les configurations. Le moment est venu d'installer l'OS. Je vérifie l'onglet, clique sur le bouton de formatage, vérifie encore que je suis sur le nouveau serveur, confirme… et là c'est la page de l'ancien serveur qui s'affiche. Horreur.

La nouvelle console OVH (obligatoire) ne supporte pas correctement le multi-onglet.

La prod est formatée.

Les données des utilisateurs sont perdues.

L'opération ne peut pas être annulée ou arrêtée.

Une seule solution : réinstaller le serveur dans son intégralité, et du coup sur la nouvelle machine… Heureusement, on a des sauvegardes ; hélas on ne peut pas se permettre mieux que des sauvegardes quotidiennes, les VPS sont déjà « naturellement » tolérants à toutes sortes de pannes sur une telle architecture. Mais ces sauvegardes sont faites à 3h00 du matin, et il est 21h00 passées, autant dire qu'on est dans le pire des cas : une journée presque complète est perdue !

Pendant la soirée, j'ai aussi constaté que cette console d'administration est globalement d'une fiabilité douteuse : interface de gestion des DNS qui ne correspond pas à la configurations sous-jacente (heureusement éditable en mode texte), messages d'erreurs plus ou moins aléatoires, …

Acte 3 : Bis repetitas ne placent pas toujours

Donc voilà, on réinstalle, tout se passe bien, on a hélas perdus des données et quelques heures de sommeil, fin de l'histoire.

Fin ? Non, parce que quelques grains de sable sont venus se rajouter à cette machine déjà passablement grippée.

Pour commencer, si les données étaient sauvegardées, ce n'était pas le cas des configurations générales (celles dans /etc).
« Pas grave, ce ne sont que des configurations, il faut les refaire, c'est long et chiant, mais c'est tout.
— Ha. Et le certificat SSL pour HTTPS, il se refait peut-être ?
— Ben oui. Il suffit de se connecter chez le fournisseur et de le régénérer.
— Et, comment on s'y connecte ?
— Il faut un certificat de connexion. Ça date d'avant l'association, on va devoir chercher, il faut trouver une solution en attendant.
— Un certificat auto-signé ?
— Oui… mais on a mis en place HSTS. Qui est précisément une protection contre ce genre de manœuvre. Donc tout membre qui s'est déjà connecté ne peut plus se connecter sauf à faire des manipulations compliquées.
— Bon, et ce certificat de connexion ?
— Ben… on l'a perdu. Personne dans l'asso ou le CA n'a pensé à le demander quand on a créé l'association…
— Et si on crée un autre compte, qu'on prouve qu'on est propriétaires du domaine et qu'on génère un autre certificat ?
— Ah, ça ne marche pas. Il détecte l'existence de l'ancien certificat. Il faut se connecter avec l'ancien compte pour pouvoir le résilier…
— Il n'y a plus le choix : allons voir un autre fournisseur.

Et c'est aussi quand on réinstalle le serveur que l'on découvre que l'ancien a vécu, a été modifié plein de fois, et que donc il existe des tas de détails de configuration à prendre en compte, et qui ne sont documentés nulle part.

La suite des événements

Bon, pour les bugs des outils tiers, on ne pourra pas faire grand-chose, si ce n'est minimiser les pertes en cas de catastrophe. Ce qui implique :

  • De sauvegarder les configurations qui vont bien
  • De s'assurer que l'association est bien propriétaire de tous les accès techniques liés au site
  • De documenter l'installation de production (la version actuelle est complètement obsolète)

Hélas, pour des raisons techniques et de coût, nous ne pourrons probablement jamais garantir une récupération de données garantie inférieure à une journée : ceci impliquerait une architecture haute disponibilité bien au-delà de nos moyens, à base de deux serveurs au moins synchronisés en permanence (je rappelle que les VPS sont très tolérants aux pannes).


Voilà, j'espère que tout ça est plus clair pour vous. N'hésitez pas si vous avez la moindre question !


  1. Ce qui n'était pas clair au moment de l'achat et a été précisé par la suite. 


64 commentaires

@Hugo et @artragis: ce serait relativement plus simple à mettre en place dans le cadre de la ZEP-08, dont l'effet est entre autre "d'ouvrir" les dépôts (de manière contrôlée, on se comprend) à des modifications externes. Ça serait aussi plus simple dans le cadre d'une API ;)

(parce que on l'as vu, coder des solutions en vitesse, ça va bien un temps mais pas toujours, c'pas à vous deux que je vais le répéter ;) )

+0 -0

N'oubliez pas de prendre en compte les données suivantes dans votre réflexion :

  • Tutos non publiés : 231 460 fichiers pour 1.8 Gio
  • Tutos publiés : 93 022 fichiers pour 2.0 Gio (avec images et exports)
  • Articles : 17 828 fichiers pour 143 Mio
  • Il faut gérer les images, et les galeries ne permettent pas de dissocier les images de tutos en rédaction des autres images.
  • Galeries : 43 521 fichiers pour 2.4 Gio
  • Total : 385 777 fichiers pour 6.3 Gio

Hélas, pour des raisons techniques et de coût, nous ne pourrons probablement jamais garantir une récupération de données garantie inférieure à une journée : ceci impliquerait une architecture haute disponibilité bien au-delà de nos moyens, à base de deux serveurs au moins synchronisés en permanence (je rappelle que les VPS sont très tolérants aux pannes).

SpaceFox, il y a quand même de la place entre la haute disponibilité et l'état actuel des choses. Que les VPS soient tolérants aux pannes n'est pas très important, les erreurs matérielles ne sont pas la première cause indisponibilité d'un site, comme vous venez d'en faire l'expérience.

Plutôt que de dire pourquoi tout est difficile à faire, pourquoi ne pas regarder ce qui peut être fait pour améliorer les choses et éviter cette situation à l'avenir ? Versionner la configuration non secrète, avoir des hooks git pour pusher les modifications sur un serveur externe, faire des tests de restauration des sauvegardes pour remonter plus vite un site down, utiliser Docker pour rapprocher dev, staging et prod… Maintenant que le site attend surtout du contenu, il me semble que ce sont des bons investissements, plutôt que d'empiler les features.

M'enfin ce n'est qu'un regard extérieur.

@SpaceFox : d'accord, mais combien de ces fichiers sont modifiés chaque heure, même en période faste ? Parce que, par exemple, ce tuto, ce tuto et ce tuto représentent certainement un grand nombre de fichiers chacun, mais les deux premiers n'ont pas bougé depuis plus d'un an, et le troisième depuis bientôt 9 mois. Du coup, quel poids représenteraient les seuls fichiers ayant été modifiés au cours de la dernière heure ? Ce serait plus pertinent comme métrique.

En outre, je sais que c'est tabou, mais on a aussi des auteurs qui viennent, créent un tuto, éventuellement travaillent dessus… puis disparaissent de la circulation (par exemple lui, qui a fait une demande d'aide pour un tuto de HTML/CSS mais n'est jamais revenu sur le site). Tout cela fait aussi du volume, qu'il serait intéressant d'évaluer (par exemple, quelle place prennent les tutos non-publiés d'auteurs qui ne sont pas venus depuis 3 mois ou plus ?), et il pourrait être intéressant de ne pas laisser s'accumuler un fatras de tutos abandonnés. Il faudrait bien évidemment prévenir l'auteur, pour qu'il puisse se reconnecter et signifier ainsi que le tuto n'est pas abandonné, toussa, mais bref, l'idée est là.

+6 -0

Pour ce qui est des statistiques sur les tailles des tutoriels et articles, passez donc par ici, Spacefox nous a justement fait un topo. Autrement dit, c'est du lourd.

Bien entendu, une sauvegarde incrémentale via rsync serait probablement une bonne idée, le volume de fichier modifié par heure n'étant probablement pas très important, mais voir point ci-dessous.

Maintenant que le site attend surtout du contenu, il me semble que ce sont des bons investissements, plutôt que d'empiler les features.

C'est peut être pas le but, mais je me sens énormément touché par cette phrase1, que je trouve très mal formulée. ZdS en lui-même a sorti sa dernière grosse feature avec la ZEP-04 après un travail de longue haleine. En plus, ne s’improvise pas sysadmin qui veut, que du contraire. On manque probablement de personnes ayant les compétences techniques pour faire ce que tu décris, et si j'ai bien suivi, nos ressources serveurs sont loin d'être infinie (par exemple, la bêta n'appartient pas à l'association, elle est gracieusement prêtée, pareil pour le système de statistique et l'analyseur Sentry).

Et non, on empile pas les features. On manque de développeurs, par contre.


  1. peut-être parce que je suis co-auteur de la prochaine feature en question 

+7 -0

Désolé pierre_24, je n'ai pas suivi les ZEPs, je disais ça comme ça sans connaître la réalité du site. Je ne voulais vexer personne. Je dis juste que des choses, plus ou moins petites, sont envisageables. Facile de parler quand on ne contribue pas, mais on ne peut pas contribuer partout.

Maintenant que le site attend surtout du contenu

Sans features pour aider les auteurs à rédiger dans les meilleures conditions et améliorer le processus de publication, le format du contenu publié (etc.), pas de contenu. Ce sont deux éléments d'une même équation et je pense que jusqu'à présent, ça ne nous a jamais fait défaut. Si le site s'est développé aussi rapidement, c'est pas pour rien. ^^

+5 -0

Désolé pierre_24, je n'ai pas suivi les ZEPs, je disais ça comme ça sans connaître la réalité du site. Je ne voulais vexer personne. Je dis juste que des choses, plus ou moins petites, sont envisageables. Facile de parler quand on ne contribue pas, mais on ne peut pas contribuer partout.

Quentin

Et moi je me suis probablement énervé un peu fort, donc tords partagés.

+2 -0

Maintenant que le site attend surtout du contenu, il me semble que ce sont des bons investissements, plutôt que d'empiler les features.

En tant qu'auteur occasionnel, je peux dire que si le système de rédaction du site est globalement correcte, il reste certains points assez lourd (notamment les galeries – ça reste le seul truc lourd à faire à la main quand on passe d'un fichier markdown local au site).

Après, c'est le genre de chose pas vraiment prioritaire et assez lourd à faire. De la même manière, il y a encore un peu de travail sur le markdown.

En passant, je rappelle qu'un sujet (un peu enterré depuis) a été fait pour les retours d’expérience des auteurs.

+0 -0

@Quentin : Pour ce qui est de Docker, Sandhose travaille dessus. Il faudra faire pas mal de tests pour éviter tout incident, mais si on arrive à utiliser Docker, on pourrait réduire diablement le temps de mise en production (et donc faire en sorte que le site soit inaccessible seulement 5-10 minutes).

+1 -0

Oh bon sang !

Je ne sais que dire.

C'est merveilleux, magistrale, magique !

je l'ai développée moi-même de mes petits doigts

Mais… Les pingouins n'ont pas de doigt ?!?

+1 -0

Il n'y a alors qu'une seule explication : c'est un Jedi et la force est avec lui !

Non non, hier c'était samedi (même si ça me disait pas trop). :-°

+2 -0

La sauvegarde me dit que chaque jour où elle fait un delta (modifications par rapport à la veille), elle récupère entre 1000 et 3000 fichiers pour environ 150 Mo.

SpaceFox

Comment est-ce que vous gérez les sauvegardes ? Chaque jour, tout le contenu est sauvé ailleurs ? Chaque sauvegarde est conservée combien de temps ?

Quand tu dis "150 Mo", c'est la taille complète des 1000/3000 fichiers je suppose. Auquel cas ce n'est pas le vrai delta, il n'y a pas 150Mo d'information en plus chaque jour. Vous devriez utiliser Tarsnap, qui déduplique puis compresse les données, ce qui permet de faire un backup toutes les heures en payant à peine quelques dollars par an.

À titre d'exemple, au bout de trois ans de backup toutes les heures du serveur tarsnap.com, la quantité totale de données était de 96 To, mais 56 Go après déduplication (qui se base sur des blocs, pas sur des fichiers), et 15.8 Go après compression, ce qui coûte 4$/mois à stocker. Tarsnap étant le service le plus sûr que je connaisse (utilisé par Stripe, par exemple), vous pouvez sauvegarder le serveur entier, en incluant vos secrets (ce qui évitera donc de les perdre).

Si vous mettez Tarsnap en place, je suis OK pour payer les frais.

Il est en tout cas clair qu'il y a de l'information redondante. Ce serait bien de préciser la nature de ces 150 Mo :).

Ne peut-on pas non plus imaginer une manière plus simple pour l'utilisateur de sauvegarder ses données (ses tutos et articles) et pouvoir les restaurer facilement. Actuellement on peut récupérer une archive, mais qu'est-ce qu'on en fait après ?

Actuellement on peut récupérer une archive, mais qu'est-ce qu'on en fait après ?

Holosmos

Tu peux la décompresser, faire des modifications, recompresser le dossier et importer l'archive obtenue. Plus ici.

+0 -0

N'oubliez pas non plus que les tutoriels et articles sont versionnés, donc évidement qu'il y a de l'info redondante, mais c'est ça ou y'a pas de versionnage. Et Git fait ça de manière relativement bien optimisée.

Archive qui, en plus, est en format zip, environ 2,5 fois plus gros qu'un tar.xz contenant strictement la même chose (ce format étant géré par la bibliothèque standard de Python, je précise).

Vrai.

À la base, on faisais du tar.gz. Sauf qu'à par les linuxiens (et encore) personne n'utilise le tar.gz dans la vie courante. C'est donc le format le plus utilisé qui a gagné (le même genre d'argument tient dans le domaine de la compression audio ou vidéo), malgré que les deux soient gérés par python. Mais j'ai pas l'impression que ce soit la plus grosse cause du poid des données aujourd'hui (d'ailleurs, les coupables, c'est probablement les images et le versionning).

+0 -0

La sauvegarde me dit que chaque jour où elle fait un delta (modifications par rapport à la veille), elle récupère entre 1000 et 3000 fichiers pour environ 150 Mo.

SpaceFox

Comment est-ce que vous gérez les sauvegardes ? Chaque jour, tout le contenu est sauvé ailleurs ? Chaque sauvegarde est conservée combien de temps ?

Quentin

https://zestedesavoir.com/forums/sujet/688/strategies-de-sauvegardes-des-donnees/?page=3#p25012

Depuis hier, ces sauvegardes sont en plus copiée de chez moi sur un serveur hors site (et qui m'appartient aussi).

Quand tu dis "150 Mo", c'est la taille complète des 1000/3000 fichiers je suppose. Auquel cas ce n'est pas le vrai delta,

Quentin

Si, c'est le vrai delta…

il n'y a pas 150Mo d'information en plus chaque jour.

Quentin

Non, parce que c'est pas ça que veut dire « delta » ici. C'est la quantité d'information qui a changé et que donc on doit sauvegarder. Il y a dedans du remplacement, surtout que ça comprends les dumps (compressés) de sauvegarde de la BDD.

D'une manière générale si tu pouvais poser des questions au lieu d'affirmer sur un ton péremptoire, ça améliorerait la sérénité du débat et ferait gagner du temps.


Attention aussi au développement nécessaire des idées que vous proposez, à leur utilisabilité et à l'effet « faits divers » (comme les politique : un faits divers ? vite, inventons un truc le plus rapidement possible sans prendre en compte l'existant et la réalité du problème !).

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte