Retour sur une semaine compliquée pour Zeste de Savoir

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à.

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 phrase¹, 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.

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.

Et puis c'est un non-problème. un dev' n'est pas forcément bon pour rédiger un contenu pédagogique et un bon rédacteur n'est pas forcément un bon dev' non plus. Il y a bien sur des exceptions, mais ils se gèrent je suppose.

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

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.

ça reste le seul truc lourd à faire à la main quand on passe d'un fichier markdown local au site

Bientôt, y'aura une option, promis juré, je l'ai développée moi-même de mes petits doigts

EDIT: preuve en est :

NIce ! Je vais te couvrir d'or de clémentines !

Je peux manger les clémentines pour te libérer si besoin est.

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

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 ?!?

C'est encore plus vrai si c'est un manchot

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

_{Désolé, je viens de regarder un Star Wars, je n'ai pas pu m'en empêcher...}

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).

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.

Bravo à vous pour la gestion de tous ces soucis. Dormez un peu de temps en temps

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 ?

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).

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

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).

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).

Si, c'est le vrai delta…

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 !).