Licence CC BY

Retour sur une semaine compliquée pour Zeste de Savoir

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

Publié :
Auteur :
Catégorie :

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

D'abord, un grand bravo à l'équipe technique pour votre temps donné à tout remettre en place. Vous avez sacrifié beaucoup de votre temps libre (ou pas) pour faire revenir ZdS et c'est vraiment super !

J'aurais 2 questions suite à tout ça :

  1. Est-ce que le nécessaire a été fait pour communiquer toutes les données critiques à l'association ?
  2. Est-ce qu'on a déjà une idée du gain sur les performances avec le nouveau tout beau serveur ?
+4 -0
Staff

Je suis sidéré du coup de la console OVH qui ne fait pas son boulot.

Merci pour le rétablissement, et aussi de nous donner des nouvelles aussi claires que précises !

Hier, dans le parc, j'ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+0 -0

@Andr0: Perso je peux pas te répondre pour le point 1, mais pour le point 2, disons que les graphs de temps de chargement des pages parlent d'eux-même:

Pareil pour les stats CPU & load average: la charge serveur a globalement chutée

En gros, d'un point de vue utilisateur, c'est surtout un temps de génération de page beaucoup plus stable/constant, et divisé par deux :)

Édité

"I also don't trust Caribou anymore." — Joss Whedon

+11 -0

@Sandhose : Je pense que l'on a moins de visiteurs que sur l'ancien serveur (à cause des moments où le site n'était pas accessible) donc il faut relativiser un peu. Néanmoins, il y a eu une amélioration, c'est clair !

(Je remarque au passage qu'on ne peut pas suivre un article ou un tutoriel sans être obligé de commenter)

La ZEP 24 sur les notifications (qui est en cours de développement) résoudra ça ! ;)

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+0 -0
Staff

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.

Ça me fait penser aux bons gros échecs de mise à jour de distribution, et qu'on ne répète jamais assez de faire de sauvegarde avant toute chose qui peut tourner mal (même si elle ne devrait pas) ! À vrai dire là, ça reste surprenant.

Enfin bon, l'équipe a gagné en expérience dans l'histoire, c'est cool.

+1 -0
Staff

Salut,

Par curiosité, pourquoi ne pas avoir choisi de l'auto-hébergement au moment de la mise en place du site ? S'agissait-il d'un problème de coût lié à l'achat/obtention du serveur ?

Édité

+0 -0
Staff

Bon bah RIP les quelques heures de travail passées sur mes tutos :|.

Espérons que ça se reproduise pas … c'est super démoralisant :'(. Même si j'aurais du moi-même faire une sauvegarde, j'avais pas estimé ça important vu que c'était un tas de corrections et pas des ajouts massifs de texte.

Ce n’est pas en répétant « Hom, Hom », qu’on démontre des théorèmes sérieux - Siegel Mon Twitter

+0 -0

D'autant qu'avec le système de gestion de versions, on pense clairement pas à faire des sauvegardes intermédiaires de l'avancement du tuto. Peut-être qu'à l'avenir il ne serait pas inutile que cet aspect des choses soit géré sur un serveur différent ou quelque chose d'équivalent…

Grâce à Taurre qui avait (loué soit-il) conservé une copie de son message de remarques, j'ai réussi à me souvenir de tous les changements effectués mais c'est passé à pas grand chose : la sauvegarde automatique générale aurait eu lieu 2h plus tôt, je perdais tout mon boulot de la nuit… :(

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0

On pourrais pas, par-exemple, toutes les heures, faire un rsync des dossiers Git. Si on fait ça, toutes les heures avec juste un rsync, ça devrait pas prendre des années à ce copier. On se sert de la bêta pour la sauvegarde de secours des tutoriels, dans un dossier crypté avec une clés que seul l'association a.

Édité

+0 -0

@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 ;) )

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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