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 :
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.
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…
648639
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).
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:
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:
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.
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 ?
:fleche: Quelle lecture faites-vous de cette situation ? De l'erreur du développeur à sa réaction ?
:fleche: Que pensez-vous des leçons qu'il propose d'en tirer ? Laquelle/Lesquelles vous semble(nt) la/les plus pertinente(s) ?
:fleche: Avez-vous déjà utilisé DBeaver ? Qu'en pensez-vous ?
:fleche: Avez-vous des anecdotes à raconter sur une situation similaire ?
Vous avez lu gratuitement 356 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par codeAddict
