Discussion :

[Stéphane le calme]

Un développeur efface accidentellement la base de données de son entreprise.
Il raconte son expérience et tire des leçons qui pourraient être utiles aux équipes techniques

Anton Zaides est un développeur qui écrit de temps en temps sur les défis auxquels sont parfois confrontés les chefs d'équipe.

L'épisode s'est déroulé un samedi. La journée avançait sans particularité lorsque l'équipe d'assistance lui a envoyé un message pour l'informer qu'un de leurs clients a un problème. Il a estimé que c'était suffisamment important pour commencer le débogage. Après 15 minutes, il a compris le problème : des commandes corrompues avaient été créées dans la base de données et il fallait les supprimer.

Cela semble trivial, n'est-ce pas ?

La base de données effacées

Il y avait quelques centaines de commandes à supprimer, Anton a donc décidé de ne pas le faire manuellement mais d'écrire une courte requête SQL (drapeau rouge 🚩 )

C'était un peu plus complexe que ça, mais pour simplifier :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    UPDATE orders
    SET is_deleted = true
 
    WHERE id in (1, 2, 3)

On mesure déjà l’ampleur du désastre…

J'ai appuyé sur CTRL+Entrée et j'ai exécuté la commande. Quand cela a pris plus d'une seconde, j'ai compris ce qui s'était passé. Le programme que j'ai utilisé (DBeaver) a vu la 3^ème ligne vide et a ignoré la 4ème ligne.

Oui, j'ai supprimé toutes les commandes dans la base de données 😢

Je me sentais physiquement malade et impuissant.

Comment a-t-il pu récupérer les données ?

Après une profonde inspiration, Anton savait qu'il devait agir, et vite. Il n’y avait aucune place pour faire plus d’erreurs ou perdre du temps.

La reprise s'est bien mieux faite :

• Arrêt des systèmes - ~5 minutes
• Création d'un clone de notre base de données avant le changement (heureusement, nous avions configuré une récupération ponctuelle) - ~ 20 minutes
• J'ai appelé mon manager pendant l'attente 😨
• J'ai mis à jour des informations de la base de données de production en fonction du clone* - ~15 minutes
• J'ai démarré nos systèmes - ~5 minutes

* J'ai décidé de ne pas restaurer l'intégralité de la base de données, car je ne pouvais pas arrêter TOUS les systèmes, car nous en avons plusieurs indépendants. Je ne voulais pas perdre les modifications apportées lors du processus de récupération. Nous utilisons PostgreSQL géré par GCP, j'ai donc créé un nouveau clone avant la mise à jour. Ensuite, j'ai exporté uniquement les colonnes « id » et « is_deleted » du clone et j'ai importé le résultat dans la base de données de production. Ensuite, il s’agissait d’une simple requête update+select.

Donc 45 minutes d’arrêt facilement évitables…

Qu'est ce qui n'a pas marché ?

Cela peut sembler une erreur très stupide que vous ne ferez jamais (ou même que vous ne pourrez pas commettre – dans les grandes entreprises). C'est peut-être vrai. Le problème ne vient pas d'une mauvaise commande SQL. Une petite erreur humaine n’est jamais le vrai problème. Le fait que je lance cette commande n'est que la fin de toute une chaîne d'échecs.

1. Travailler sur la production le week-end – pourquoi ? Dans ce cas-ci, ce n’était même pas si urgent. Personne ne m'a demandé de le réparer immédiatement. J'aurais facilement pu attendre lundi.
2. Qui diable exécute quelque chose sur une base de données de production sans l'exécuter d'abord sur le contrôle qualité ?
3. Pourquoi ai-je modifié manuellement la base de données et n'ai-je pas utilisé d'appel API ?
4. Et s'il n'y avait pas d'API, pourquoi n'ai-je pas appelé un coéquipier et n'ai-je pas eu « 4 yeux » sur une action aussi sensible ?
5. Et le pire : pourquoi n’ai-je pas utilisé les transactions ? C'est aussi simple que d'écrire « Begin », puis d'utiliser Rollback en cas d'erreur.

Les erreurs se superposent les unes aux autres. Si au moins l’une d’entre elles avait été évité, tout cela ne serait jamais arrivé. La réponse à la plupart des questions est que j’étais tout simplement trop confiant.

Au moins la reprise organisée a stoppé la chaîne. Imaginez le désastre si je ne parvenais pas à restaurer la base de données dans le bon état…

Anton Zaides

Qu’est-ce que Tchernobyl a à voir là-dedans ?

Il y a quelques mois, j’ai fini de lire « Tchernobyl : l’histoire d’une catastrophe nucléaire ». L'enchaînement d'erreurs là-bas m'a rappelé ce week-end maudit (sans sous-estimer ni comparer aux dimensions de la catastrophe de Tchernobyl).

• Il y avait un problème technologique fondamental dans le réacteur RBMK.
• Cela n’a pas été communiqué correctement. Il y a eu des incidents antérieurs impliquant ce problème, mais l’équipe de Tchernobyl ne les connaissait pas.
• L’équipe n’a pas suivi la procédure lors d’un contrôle de sécurité.
• Après l'explosion, le gouvernement soviétique a tenté de la cacher, ce qui a considérablement accru la gravité des dégâts.

Qui est responsable?

Les concepteurs du réacteur ? Les équipes des autres centrales électriques qui n’ont pas communiqué sur les problèmes qu’elles rencontraient ? L'équipe de Tchernobyl ? Le gouvernement soviétique ?

Tous. Les catastrophes ne sont jamais causées par une seule erreur, mais par une chaîne d’erreurs. Notre travail consiste à faire de notre mieux pour couper la chaîne le plus tôt possible.

Les conséquences

Je ne savais pas à quoi m’attendre de la discussion avec mon manager lundi.

Il m’a surpris : « Assurez-vous que cela ne se reproduise plus. Mais je préfère que ce soit ainsi : vous avez commis une erreur parce que vous êtes dévoué et que vous aimez aller vite. Les gens qui ont un penchant pour l’action cassent les choses ».

C'est exactement ce que j'avais besoin d'entendre. Une approche trop « câline » disant « Ce n’est pas grave, ne vous inquiétez pas, merci d’avoir réparé ! » aurait semblé fausse. D'un autre côté, je me sentais déjà comme une merde, donc inutile de m'humilier davantage.

Depuis lors:

• Nous nous efforçons de supprimer le besoin d'accès à la base de données, en créant les appels API pertinents
• J'exécute toujours des requêtes sur le contrôle qualité en premier (je sais... évident, n'est-ce pas ? Rien ne fait plus tenir une leçon qu'un désastre)
• Je consulte le Premier ministre pour comprendre ce qui est vraiment urgent et ce qui peut attendre.
• Toute requête de mise à jour/insertion/suppression en production est effectuée par 2 personnes. Celui-ci a en fait évité d’autres erreurs !
• J'ai commencé à utiliser les transactions 🤦 ♂️

Appliquer les leçons dans votre équipe

Après l'incident, j'ai partagé une explication détaillée avec mon équipe. Je ne cache rien et ne minimise pas ma faute.

Il y a un équilibre fragile entre faire honte aux gens et ne pas leur demander de rendre des comptes. Lorsque VOUS faites des erreurs, c’est une excellente occasion d’envoyer le bon message.

Si vous vous excusez 1000 fois, ils penseront que vous attendez la même chose d’eux.

Si vous vous moquez de l’incident, en ignorant les implications, ils penseront que ce n’est pas grave.

Si vous êtes responsable, apprenez et améliorez-vous, ils se comporteront de la même manière.

Pour résumer, voici ce qu'il propose:

• Encouragez les gens à agir, à se soucier du client et à résoudre les problèmes. C’est ainsi que les startups réussissent.
• Lorsque des erreurs sont commises, tenez la personne responsable. Ensemble, comprenez comment cela aurait pu être évité.
• Pas besoin de faire en sorte que les gens se sentent plus mal qu’ils ne le font déjà. Certaines personnes ont besoin de plus de responsabilités, d’autres de plus d’encouragements. Je préfère toujours pécher par excès d’encouragement.

D'autres conseils

Certains professionnels du secteur ont rajouté quelques éléments qui sont susceptibles d'aider des collègues dans la situation. Par exemple :

Vous avez manqué certains points clés par la suite.

• Apprenez les transactions de base de données et comment effectuer une restauration. N'exécutez rien d'autre que select to prod sans transaction.
• N'utilisez pas de client de base de données pour vous connecter à votre base de données de production, sauf si vous disposez d'un compte en lecture seule. Utilisez uniquement le propre client de la base de données lorsque vous effectuez des changements d'état en production.
• J'espère que vous utilisez un VPN lors de la connexion à votre base de données.

En fait, je blâme l'entreprise. Permettre aux développeurs de faire en production tout ce qui ne peut pas être facilement annulé est un défaut de gestion.

Il y a 100 % de chances que quelqu'un finisse par faire quelque chose de stupide et de terrible et qu'un rétablissement rapide soit nécessaire.

S'ils ne peuvent pas faire ça, allez trouver le responsable le plus proche et blâmez-le.

L'erreur n'était pas la requête mais le fait de ne pas avoir effectué de sauvegarde avant d'exécuter la requête

Je fais systématiquement des sauvegardes avant d'exécuter la suppression, la mise à jour, l'insertion d'une requête, etc. Si quelque chose ne va pas, je peux réimporter la base de données/la table en quelques secondes - viva adminer

Les transactions sont vos amies, quelle que soit la simplicité du changement

Source : billet Anton Zaides

Et vous ?

Quelle lecture faites-vous de cette situation ? De l'erreur du développeur à sa réaction ?
Que pensez-vous des leçons qu'il propose d'en tirer ? Laquelle/Lesquelles vous semble(nt) la/les plus pertinente(s) ?
Avez-vous déjà utilisé DBeaver ? Qu'en pensez-vous ?
Avez-vous des anecdotes à raconter sur une situation similaire ?

[codeAddict]

Je ne comprends pas quelle est l'erreur dans le code SQL ?

[smobydick]

Je ne comprends pas quelle est l'erreur dans le code SQL ?

Il n'y a pas d'erreur de code. Son client SQL à vu que la 3eme ligne était vide donc n'a pas été plus loin. Au lieu de supprimer certains ID (ligne 4 ignorée) tout à été supprimé (deux premières lignes).

[TotoParis]

J'hallucine complètement sur ce client d'accès à une base SQL...
Sous IBM Z/OS et TSO / SPUFI, l'interpréteur de commandes est plus rigoureux :
- Jamais une ligne blanche ne pose de problème.
- Chaque instruction SQL doit être terminée par un ";".
Il ne jamais faire une instruction de mise à jour ou de suppression avec une clause "where" un peu trop générique,
là on aurait du avoir les numéros de commandes des clients et le numéro de client en plus. C'est toujours vrai le plus souvent.
Jamais ce type de d'intervention ne devrait être possible en Production en dehors d'un contrôle par une équipe de DBA...
Le processus utilisé ainsi est l'exemple même de ce qu'il ne faut pas faire. Il est tout simplement hallucinant...Salarié dévoué ou pas !
Au minimum, on liste déjà les commandes impliquées, puisque l'on sait la colonne en cause, les valeurs valeurs invalides.
En important les colonnes pertinentes dans un fichier Excel, on peut générer facilement une commande SQL de mise à jour / suppression, et exporter le tout dans un fichier
utilisable par le client de DB, chaque ordre étant circonscrit à un client et une commande, quitte à avoir des centaines de lignes. Avec une gestion des commits toutes les 10 instructions par exemple.
Le tout en faisant une sauvegarde de la DB préalable avant toute action !!!
C'est un truc de fou furieux cette histoire !!! A foutre en l'air une entreprise.

[Pomalaix]

Dès qu'on se met à faire quelque chose, il y a toujours un risque de faire une erreur.
Mais pour moi la faute centrale, majeure et indiscutable du gars, c'est de ne pas avoir utilisé une transaction pour sécuriser son opération.
Les outils qui fonctionnent en mode "auto commit" sur une base de données sont une catastrophe. Un jour ou l'autre, on se tire un balle dans le pied.

[escartefigue]

Egalement, il faut toujours commencer par remplacer l'ordre de mise à jour UPDATE ou DELETE par un SELECT pour vérifier la portée de la requête, surtout sur la base de production !
Si le développeur avait procédé ainsi, il n'aurait pas eu tous ces déboires.

[SQLpro]

DBeaver est un logiciel bas de gamme... Mais en arriver là c'est plus que désastreux !
1) il aurait du gérer une transaction explicite, vérifier son DELETE et faire ROLLBACK si problème... Erreur de débutant !
2) le fait que DBeaver considère qu'une ligne vide est la fin d'une commande SQL prouve que ceux sui ont développé cet outil sont de dangereux imbéciles... Vive le libre !!!

Reste qu'avec une base de données comme Oracle ou SQL Server la réparation aurait pu être extrêmement rapide, car il existe des outils pour récupérer des données effacées par accident comme Apex SQL transaction log reader qui construit un script SQL d'INSERT à partir des données supprimée en analysant la journal des transactions...

Bien évidemment de tels outils n'existe pas pour les SGBDR "Libres"... C'est l'inconvénient d'utiliser PostGreSQL par exemple...

Je me souviens d'ailleurs que dans le cas du site web leboncoin l'administrateur de base de données avait été fier d'avoir pu réparé le système de haute disponibilité des "clusters" PostGreSQL (en fait on devrait parler de serveur PG ou d'instances PG... mais passons)... En moins de 5 jours !!!! Imaginez un hôpital ou une banque ou le serveur de secours serait en panne pendant 5 jours....
https://fr.slideshare.net/jlb666/pgd...ez-leboncoinfr



A +

[seikida123]

Pour moi ce developpeur a fait une erreur de debutant pour la simple et bonne raison qu'il aurait du:

1) mettre en place un systeme de backup (si possible automatique)

2) mettre en place un systeme de rollback automatique (pour restaurer les donnees le plus rapidement possible a partir d'un point de sauvegarde)

3) avant de manipuler la database, il doit faire un backup (snapshot, dump... appele ca comme vous voulez)

4) si la base de donnees et quelque chose de critique dans l'application, il faut mettre en place un replica puis faire ses modifications dessus, voir si ca fonctionne puis faire le changement. Et non pas attaquer la base de donnees directement comme ca.

[mach1974]

DBeaver est un logiciel bas de gamme... Mais en arriver là c'est plus que désastreux !
1) il aurait du gérer une transaction explicite, vérifier son DELETE et faire ROLLBACK si problème... Erreur de débutant !
2) le fait que DBeaver considère qu'une ligne vide est la fin d'une commande SQL prouve que ceux sui ont développé cet outil sont de dangereux imbéciles... Vive le libre !!!

Reste qu'avec une base de données comme Oracle ou SQL Server la réparation aurait pu être extrêmement rapide, car il existe des outils pour récupérer des données effacées par accident comme Apex SQL transaction log reader qui construit un script SQL d'INSERT à partir des données supprimée en analysant la journal des transactions...

Bien évidemment de tels outils n'existe pas pour les SGBDR "Libres"... C'est l'inconvénient d'utiliser PostGreSQL par exemple...

Je me souviens d'ailleurs que dans le cas du site web leboncoin l'administrateur de base de données avait été fier d'avoir pu réparé le système de haute disponibilité des "clusters" PostGreSQL (en fait on devrait parler de serveur PG ou d'instances PG... mais passons)... En moins de 5 jours !!!! Imaginez un hôpital ou une banque ou le serveur de secours serait en panne pendant 5 jours....

C'est surtout que les bases de données employées font des copies de toutes les instances et tables et qu'on peut récupérer les données historiques à date et pas besoin d'outil on peut faire des insert dans les tables et même des create table

[ILP]

Une erreur similaire à celle-ci c'était produite dans une entreprise dans laquelle je travaillais. Un administrateur de BD avait programmé un script SQL sur toutes les bases des clients. Ce script était censé mettre à jour des valeurs dans une table de paramètres. Sauf qu'une erreur de parenthèses dans la condition WHERE a fait que tous les paramètres sont passés à 1. Bloquant le démarrage des logiciels. Il a fallu pour essayer de récupérer le contenu de la table à partir de sauvegarde, quand il y en avait. Et, pour les autres, remettre les paramètres par défaut.