Le jour où j'ai supprimé beaucoup de données en production

On parle souvent de ses réussites mais beaucoup moins de ses erreurs et de ses échecs. Pourtant, outre le fait qu’ils nous permettent parfois de redescendre un peu sur Terre (il faut le dire, le melon peut vite s’attraper), ils sont également source d’apprentissage et de remise en question. Dans la douleur, certes, mais passé l’incendie, ces échecs restent des expériences très formatrices. Prendre le temps d’y réfléchir permet de s’améliorer et aussi de savoir quoi répondre à ses prochains entretiens d’embauches ;)

Pour ma part, voici une bonne grosse boulette de stagiaire qui m’est arrivée lors de mon premier stage en entreprise.

(photo de couverture : Proceed With Caution Sign - State Farm - CC By 2.0)

L’histoire

La commande SQL partie trop vite

Pour ma première expérience en entreprise en tant que développeur, je devais revoir une application d’intranet dans une administration départementale. Très classique, l’application web (en Coldfusion, ça ne rigole pas !) proposait des formulaires à remplir et des tableaux de données à afficher.

Il existait déjà une application qui proposait de le faire mais suite à des mises à jour de version (et de je ne sais plus quoi), elle ne fonctionnait plus depuis quelques semaines. Mon sujet de stage était d’en refaire une neuve tout en gardant les grandes lignes et en y important également l’historique (à peu près 3-4 années de données).

Tout se passait bien, ça faisait un mois et demi que j’étais en poste, bonne prise en main du sujet, ça avançait bien et je commençais l’import des données. Donc script de migration, on copie-colle les données de l’ancienne base vers la nouvelle, classique. Et comme il arrive en général sur ce genre de procédure, au fur et à mesure des tests d’imports, on efface des données importées, on corrige le script et on recommence.

Je venais de lancer un import sur un échantillon de 1000 lignes qui s’était bien passé et, tout confiant, j’allais lancer l’import sur l’intégralité des lignes pour voir si ça fonctionnait. Tout naturellement, je décidais de nettoyer ma table importée avant :

DELETE * FROM rapports

qui m’affiche donc 125 000 lignes supprimées. Ok, cool, continu…

Attends, comment ça se fait que 125 000 lignes sont supprimées alors que je n’en ai importé que 1 000 ?

Pérégrinations d’un stagiaire dans une administration

Vous l’avez peut-être deviné : j’avais lancé la commande sur la base de données à importer et pas sur ma base de données de dev. Je venais donc accidentellement de supprimer 4 années d’historique.

Bien entendu, j’ai d’abord essayé de la réparer moi-même. J’ai cherché si, à tout hasard, il n’y avait pas une fonction “corbeille” quelque part pour restaurer rapidement : non. Est-ce qu’il n’y aurait pas eu une table d’export quelque part qui aurait permis de récupérer les données : non.

Le petit vent de panique s’installait. D’autant que nous étions le vendredi 18 mai, lendemain de l’Ascension. Autant vous dire qu’il n’y avait pas grand monde dans les locaux à part les stagiaires. Je suis allé trouvé la personne du service informatique qui était de garde ce jour-là (la “nounou” des stagiaires) en lui racontant ma connerie.

Manque de bol pour moi, lui s’occupait du réseau et les bases de données, à part de vagues souvenir téhoriques, il n’y touchait pas et en pouvait pas m’aider. Il me conseillait de voir ça lundi avec le reste de l’équipe parce que lui ne pouvait pas faire grand chose. Autant dire que je n’ai pas passé un très bon week-end.

Lundi matin, j’apprends que ma responsable de stage était en congés toute la semaine et que l’autre personne qui était à même de m’aider avec les bases de données était en déplacement : ça allait attendre le mardi au mieux. 4 années de données perdues, je le rappelle.

Mardi matin, fin du calvaire : le responsable du service est présent et il connait les bases de données. Je vais donc lui en parler et sa réaction ne s’est pas faite attendre : il a foncé vers la salle serveur et a réinstallé la sauvegarde. Parce que oui, il y avait des sauvegardes, heureusement. Sauf qu’il n’y avait que 5 jours de sauvegarde et qu’une journée de plus en on perdait une bonne partie des données (on serait retomber sur des sauvegardes beaucoup plus anciennes avec le risque de ne pas tout avoir).

Tout est bien qui fini bien mais j’aurais pu sacrément mettre le bazar avec ma petite commande SQL tout bête.

Bilan

Que retenir de cette expérience ?

Très clairement, les sauvegardes, c’est la vie. Votre système peut tomber ou recontrer un stagiaire maladroit, il faut pouvoir récupérer ce qui a été perdu. Là où on a frôlé le drame, c’est du côté de la durée de rétention des sauvegardes : 5 jours avant de tomber de vieilles sauvegardes, c’est trop court. Un week-end trop long et pouf, on a tout perdu. Il faut vraiment avoir quelques sauvegardes des dernières semaines puis des derniers mois histoire d’être plus serein. Et bien evidemment des sauvegardes hors-ligne, si des fois vos machines sont compromises.

L’autre grande leçon que j’ai apprise, c’est que base de données de production, ça se manipule comme si on manipulait des isotopes radioactifs. Aujourd’hui encore, j’ai toujours une appréhension lorsque je dois lancer des commandes sur une base en production (heureusement, je fais du front et ça m’arrive assez peu). Il y a quelques règles auxquelles j’essaye de m’astreindre, si possible :

• limiter le nombre de connexion à la base de production : c’est une zone radioactive, je ne dois m’y connecter qu’en dernier recours, si je n’ai pas le choix.
• ne pas se connecter à deux bases de données en même temps, surtout sur des environnements différents : c’est le meilleur moyen de se tromper de fenêtre. C’est peut-être long/compliqué de se déconnecter/reconnecter de l’une sur l’autre mais ça reste un bon moyen de cloisoner. En pratique, sur des serveurs de développement, il n’y a pas trop de risques, c’est plus quand on mixe les environnements.
• avoir des mots de passe différents selon les environnements. La encore, pour éviter la connexion automatique au mauvais environnement. Si les mots de passe sont différents, on sait que si le mot de passe ne passe pas, c’est peut-être que le paramètre d’environnement n’est peut-être pas celui qu’on pense. On évite de se connecter par mégarde.

Si possible, je préfère avoir également un compte limité en production. Ce que j’aurais d’ailleurs dù avoir ici : un compte qui m’aurait interdit les DELETE et les UPDATE sur la production m’aurait éviter la mésaventure. En pratique, même aujourd’hui, un compte limité m’empêche de faire des bétises et améliore la sécurité de la base : si jamais je me fais pirater mon compte, l’attaquant ne pourra pas modifier/supprimer les données. Il pourra les lire (ce qui est déjà énorme) mais ses possibilités seront limitées. Et soyons honnête : devoir modifier des données en production, c’est souvent le signe d’un bogue dans l’application et ça arrive assez peu. Donc avoir des accès restreint pour le développeur en production, ce n’est pas déconnant.

Au final, j’ai pu finir l’application et ma note de stage n’a pas été mauvaise. Mais ça m’aura aussi vallu une belle frayeur !