IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

Un développeur efface accidentellement la base de données de son entreprise


Sujet :

ALM

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 937
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 937
    Points : 207 003
    Points
    207 003
    Par défaut Un développeur efface accidentellement la base de données de son entreprise
    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…

    Nom : anton.png
Affichages : 100642
Taille : 355,2 Ko
    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 ?

  2. #2
    Membre à l'essai
    Inscrit en
    Juillet 2006
    Messages
    13
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations forums :
    Inscription : Juillet 2006
    Messages : 13
    Points : 21
    Points
    21
    Par défaut ????
    Je ne comprends pas quelle est l'erreur dans le code SQL ?

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mars 2011
    Messages
    126
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2011
    Messages : 126
    Points : 380
    Points
    380
    Par défaut
    Citation Envoyé par codeAddict Voir le message
    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).

  4. #4
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 626
    Points : 1 495
    Points
    1 495
    Par défaut
    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.

  5. #5
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    Décembre 2002
    Messages
    3 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 461
    Points : 8 079
    Points
    8 079
    Par défaut
    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.

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 365
    Points : 39 812
    Points
    39 812
    Billets dans le blog
    9
    Par défaut
    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.

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 915
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 915
    Points : 51 691
    Points
    51 691
    Billets dans le blog
    6
    Par défaut
    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

    Nom : PostGreSQL leBonCoin.jpg
Affichages : 9662
Taille : 14,8 Ko

    A +

  8. #8
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2024
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Japon

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Janvier 2024
    Messages : 1
    Points : 4
    Points
    4
    Par défaut
    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.

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    Février 2010
    Messages
    273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 273
    Points : 373
    Points
    373
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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

  10. #10
    ILP
    ILP est déconnecté
    Membre confirmé
    Avatar de ILP
    Homme Profil pro
    Analyste programmeur
    Inscrit en
    Mai 2002
    Messages
    258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Analyste programmeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 258
    Points : 610
    Points
    610
    Par défaut
    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.

  11. #11
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    827
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 827
    Points : 1 581
    Points
    1 581
    Par défaut
    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...
    Quelques nuances :
    • Lire le journal de transaction : cela dépend du mode de récupération et de la persistance des données dans ce(s) même(s) fichier(s)
    • "rapide" : à condition de l'avoir déjà installé et utilisé !


    Je suis convaincu qu'il n'existe pas d'accident intelligent ; Les accidents ne sont, malheureusement, pas rares.
    Avoir l'intelligence d'en faire le retour d'expérience, ça c'est rare. Merci pour ça.

Discussions similaires

  1. [c#] [dataadapter] effacer des ranger dans une base de donne
    Par mahboub dans le forum Accès aux données
    Réponses: 4
    Dernier message: 02/12/2005, 01h26
  2. base de donné sans avoir un serveur!!
    Par Sawbo dans le forum Bases de données
    Réponses: 7
    Dernier message: 30/07/2004, 09h08
  3. probleme construction base de donnes MySql...Help
    Par chakan dans le forum Requêtes
    Réponses: 7
    Dernier message: 21/07/2004, 11h27
  4. [Tomcat][Oracle] connexion base de donnes debutant....
    Par yogz dans le forum Tomcat et TomEE
    Réponses: 8
    Dernier message: 16/07/2004, 13h32
  5. connexion base de donné
    Par saidi dans le forum MFC
    Réponses: 3
    Dernier message: 07/08/2002, 22h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo