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 :

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.

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…


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