Le schéma qui ne vit que dans la base en service
Tout ce que fait ce service est en gestion de versions. Le code, du moins. La base sur laquelle il tourne, ce sont 32 tables, et 15 d'entre elles n'ont de définition nulle part dans le dépôt — pas de CREATE TABLE, pas de fichier de schéma, rien. Si le serveur était perdu, le code reviendrait à l'identique et la forme des données devrait être reconstituée à partir de ce que le code se trouve demander.
Ces chiffres viennent d'une comparaison entre la base en service et 736 fichiers, 5 671 710 caractères de dépôt. Ce ne sont pas des estimations.
Comment la moitié d'un schéma disparaît
Ce n'est pas de la négligence, et c'est ce qui vaut la peine d'être noté. Chaque étape prise isolément était raisonnable.
Les tables créées avant le code actuel n'ont jamais été écrites, parce qu'à l'époque elles étaient simplement là. Les tables ajoutées depuis sont arrivées par des scripts de migration, et ceux-là sont dans le dépôt — d'où les 17 définitions. Les colonnes ajoutées plus tard sont arrivées par un ALTER TABLE d'une ligne tapé dans un terminal, parce que le taper allait plus vite qu'écrire un script pour un changement d'une seconde.
Les index sont le pire cas. Un index s'ajoute quand quelque chose est lent, au moment où c'est lent, et cela règle le problème sur-le-champ. Il ne reste aucun artefact, rien à relire, rien qui échoue si on oublie. Onze des trente-deux index secondaires d'ici existent exactement pour cette raison et ne sont consignés nulle part.
La table où se trouvent les compteurs eux-mêmes, 166 438 lignes, fait partie des quinze sans définition dans le dépôt.
Ce qui casse vraiment
Pas grand-chose, jusqu'à un moment précis : quand la base est restaurée depuis une sauvegarde.
Une sauvegarde emporte la structure, une restauration directe se passe donc bien. Le danger, c'est tout chemin qui reconstruit une table au lieu de la restaurer — un déménagement vers une autre machine, l'import de tables choisies, la recréation depuis un script. Les données reviennent, les index silencieusement non. Rien n'échoue. Les requêtes renvoient les bonnes réponses. Elles mettent seulement plus de temps, et la cause est invisible, car le seul enregistrement de ce qu'était l'index se trouve sur la machine qui ne l'a plus.
C'est le mode de défaillance à nommer : un index manquant ne produit pas d'erreur, il produit une bonne réponse plus lente. Aucun test ne l'attrape, puisque les tests passent.
Ce que nous faisons en attendant
La position honnête, c'est que ce n'est pas réglé. Le schéma n'est pas dans le dépôt aujourd'hui. Ce qui existe est plus petit qu'une correction et vaut mieux que rien :
Une sauvegarde avant toute opération destructrice, gardée hors de la racine web. Une restauration réellement effectuée au moins une fois, plutôt que supposée. Et une courte liste, vérifiée après chaque restauration, des index dont on sait qu'ils n'existent que dans la base en service — car on peut demander à la machine quels index elle a, et comparer la réponse à celle de la dernière fois.
La version générale vaut pour plus que les bases de données. Si une partie du système n'est que dans le système en service, vous n'en avez pas une copie, vous en avez un otage. La question qui vaut la peine d'être posée pour n'importe quelle infrastructure n'est pas « est-ce sauvegardé » mais « si cette machine disparaissait, qu'est-ce qui ne pourrait pas être reconstruit depuis le dépôt ». Ici la réponse est quinze tables et onze index, et il a fallu un après-midi pour le savoir.