Retour sur une semaine compliquée pour Zeste de Savoir
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 :
- L'envoi d'images au format JPEG dans les galeries ou ailleurs sur le site (notamment dans les avatars) ne fonctionne pas.
- 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 :
- 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.
- 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 !
-
Ce qui n'était pas clair au moment de l'achat et a été précisé par la suite. ↩
