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

Actualités Discussion :

Digital Ocean supprime accidentellement sa base de données de production

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 554
    Points
    26 554
    Par défaut Digital Ocean supprime accidentellement sa base de données de production
    Digital Ocean supprime accidentellement sa base de données de production
    mais parvient à la restaurer ; avez-vous déjà été confronté à un tel accident ?

    Digital Ocean est une entreprise offrant des services de cloud computing. En 2015, elle a été classée numéro 2 par Netcraft (entreprise britannique qui suit les technologies utilisées sur la toile) après Amazon, car elle aurait hébergé plus de 163 000 sites web contre plus de 300 000 pour Amazon. Elle est soutenue par des investisseurs de renom et offre des machines virtuelles uniquement équipées de disques durs SSD afin de se démarquer de la concurrence.

    Le 5 avril dernier, l’accès à la plateforme cloud de Dital Ocean a été fermé aux clients de l’entreprise. En cause, un ingénieur de l’entreprise a accidentellement supprimé la base de données de l’environnement de production. Selon le rapport de l’entreprise, cela est survenu à cause d’une erreur de configuration effectuée par l’ingénieur en utilisant ses identifiants de l’environnement de production. Se croyant donc dans un autre environnement, l’ingénieur a lancé des tests automatisés qui ont eu pour effet de supprimer la base de données de production.

    En l’espace de trois minutes, Digital Ocean a commencé à recevoir des alertes de ses clients lui signifiant qu’aucun Droplet (serveur virtuel) supplémentaire ne pouvait être créé. Vu l’urgence du problème, Ocean Digital a pris la décision, après avoir constaté à 10 h 24 (heure de Paris) que sa base de données primaire avait été supprimée, de procéder à la récupération des données à partir des répliques de bases de données disponibles. L’opération de récupération a commencé à 16 h 34 pour s’achever à 19 h 31, heure de Paris. À cela, il a fallu ajouter environ 50 minutes pour remettre en route tous les systèmes dans la mesure où l’API et le panneau de configuration de Digital Ocean étaient complètement indisponibles. Les clients de Digital Ocean ont donc dû patienter pendant 4 h 56 min pour pouvoir à nouveau faire fonctionner leurs services sur la plateforme cloud de l’entreprise.

    Consciente que de nombreuses entreprises ne peuvent se permettre une indisponibilité de leurs services pendant un tel laps de temps, Ocean Digital a tenu à présenter ses excuses tout en prenant sur elle l’entière responsabilité de l’accident qui est survenu. Par ailleurs, pour éviter qu’un tel accident ne se reproduise, l’entreprise entend réduire l’accès au système primaire et améliorera le système de récupération des données afin de réduire drastiquement le temps de récupération en cas d’occurrence d’un évènement similaire.

    À travers l’accident qui a eu lieu, l’on réalise combien de fois les erreurs humaines peuvent mettre à mal les activités d’une entreprise tout en mettant le fautif dans de sérieux problèmes. À la fin du mois de janvier dernier, GitLab, la plateforme de gestion des développements collaboratifs a connu un incident similaire où un administrateur a supprimé plus de 300 Go de données de production. Cela a coûté à GitLab plusieurs heures d’indisponibilité pendant lesquelles les développeurs ne pouvaient pas avoir accès à leur code. GitLab est parvenue à restaurer les données supprimées, mais 6 heures de données n’ont pas pu être récupérées, ce qui a probablement lourdement impacté certains développeurs.

    Bien que ces accidents puissent paraître étonnants à première vue, certains développeurs expliquent avoir déjà vécu de tels incidents dans leur entreprise. Un développeur explique par exemple qu’un administrateur dans son entreprise a exécuté un script pour supprimer les données inutiles de la base de données. Malheureusement, après avoir achevé son travail, il a oublié de revenir à la configuration initiale et a exécuté des tests automatisés. Conséquence, il a supprimé la base de données d’intégration de son entreprise. Heureusement pour lui, il n’était pas dans l’environnement de production.

    Un autre explique qu’un développeur qui croyait travailler sur une base de données Hadoop (HBase) de développement a exécuté une commande HDFS MV afin de supprimer sa base de données. Malheureusement, il était déjà trop tard quand il a réalisé qu’il s’agissait de la base de données de production. Les activités de l’entreprise ont été à l’arrêt jusqu’à la restauration de la sauvegarde.

    Comme on peut le noter par ces témoignages, les erreurs humaines entraînant la suppression de bases de données de production sont légion. Avez-vous déjà été dans une telle situation ? Avez-vous déjà supprimé la base de données de l’environnement de production de votre entreprise accidentellement ? Ou avez-vous connu une personne dans une telle situation ? Que conseillez-vous pour éviter cela ?

    Source : Blog Digital Ocean

    Et vous ?

    Que pensez-vous de ces erreurs humaines occasionnant la suppression des données de production ?

    Avez-vous déjà été confronté à une telle situation ?

    Quels conseils préconisez-vous pour éviter ce type d’accidents ?

    Voir aussi

    Un administrateur système de GitLab supprime accidentellement 310 Go de données de production et rend le site indisponible depuis plusieurs heures
    GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne, mais 6 heures de données n'ont pas pu être récupérées

    Forum Actualités, Wiki Developpez.com, Débats Best of, FAQ Developpez.com
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Homme Profil pro
    Chargé de projet
    Inscrit en
    Novembre 2015
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Chargé de projet
    Secteur : Industrie

    Informations forums :
    Inscription : Novembre 2015
    Messages : 429
    Points : 1 684
    Points
    1 684
    Par défaut
    A première vue les conseils sont :

    1) Se serait peu être pas bête de coder un pop-up quand on se connecte à la BDD de production histoire que l'utilisateur humain se rende compte de son erreur ?
    (je dis sa puisque ce qu'on cherche à éviter c'est les erreurs humaines).

    2) Rien de sorcier : La Sauvegarde
    Pour ne pas passer pour un boulet :
    http://coursz.com/difference-entre-r...-et-gddr4.html

  3. #3
    Membre éprouvé
    Avatar de Gecko
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    Décembre 2008
    Messages
    499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur décisionnel

    Informations forums :
    Inscription : Décembre 2008
    Messages : 499
    Points : 1 277
    Points
    1 277
    Par défaut
    Étant donné que la majorité des devs utilisent leur terminal je pige pas que les mecs aient jamais pensés à colorer la prod en rouge.

    D'ailleurs tous les outils devraient avoir une différence notable selon l'environnement.
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    if ($toBe || !$toBe) echo 'That is the question';

    Mes projets: DVP I/O

  4. #4
    Futur Membre du Club
    Inscrit en
    Octobre 2006
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 2
    Points : 5
    Points
    5
    Par défaut Backup
    Je fais systématiquement un backup avant toutes modifications importantes.
    J'ai aussi eu des surprises dans le passé.

  5. #5
    Inactif  

    Profil pro
    Inscrit en
    Janvier 2011
    Messages
    3 064
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 064
    Points : 4 604
    Points
    4 604
    Par défaut
    Comment perdre la base de données client :

    - prenez un serveur qui tourne depuis plusieurs années
    - ne purgez jamais les logs
    - faites saturer la base
    - votre programme n'arrive pas à se lancer faute de place pour les logs
    - perdez 6 années d'historiques et un peu plus de 180 Go d'information

    Vécu , testé et approuvé lors d'une migration de serveur

  6. #6
    Membre régulier
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Mars 2017
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2017
    Messages : 52
    Points : 98
    Points
    98
    Par défaut
    Bah, c'est à ça que sert les site comme joiedusysadmin ou les joiesducodes. Même si on a des sauvegardes, il est très difficile de restaurer à temps, sauf si on a un réseau/infra haut débit.

  7. #7
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juin 2016
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2016
    Messages : 27
    Points : 57
    Points
    57
    Par défaut
    2) Rien de sorcier : La Sauvegarde
    Dans toutes ces affaires il y avait bien une sauvegarde, le problème c'est les 5h de récupération pendant lesquelles les clients sont bloqués...

  8. #8
    Membre habitué
    Inscrit en
    Avril 2006
    Messages
    62
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations forums :
    Inscription : Avril 2006
    Messages : 62
    Points : 181
    Points
    181
    Par défaut
    Citation Envoyé par Gecko Voir le message
    Étant donné que la majorité des devs utilisent leur terminal je pige pas que les mecs aient jamais pensés à colorer la prod en rouge.

    D'ailleurs tous les outils devraient avoir une différence notable selon l'environnement.
    Indeed, probablement qu'au début personne ne s'en est soucié et qu'après c'est tombé dans l'oubli. Tant que personne ne fait de bourde, la demande ne vas pas remonter. Dommage pour eux que la première (?) bourde pête toute la prod

  9. #9
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    non jamais eu, fort heureusement!
    Une autre équipe s'occupe de backuper la db, donc le problème serait chez eux

    Par contre un collègue qui était précédemment chez nous avait été informé qu'une application dont il était responsable à l'époque, ne fonctionnait plus.
    Il n'avait jamais backuper les codes sources alors que je lui avais donné 3 mini formations pour utiliser VSS.
    Mais je voyais qu'il ne comprenait rien
    Fort heureusement pour lui, on a pû "outphaser" l'application.
    Rem: son excuse est qu'il avait les codes en local mais qu'il avait dû changer de Windows depuis et donc la machine a été réinstallée
    Si la réponse vous a aidé, pensez à cliquer sur +1

  10. #10
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 414
    Points : 1 508
    Points
    1 508
    Par défaut Solutions simples
    Les solutions sont simples :
    1: sauvegarde. Un petit mysqldump fait ça très vite et très bien
    2: procédures. Un environnement de maquettes, un service de qualification indépendant, un environnement hors production, un environnement de production. On ne lance RIEN manuellement sur l'environnement de production, on produit des programmes en maquettes qui sont qualifiés par un service indépendant, puis une 3me équipe applique ces programmes sur l'environnement hors production. C'est long, c'est lourd, mais ça évite les "drop database" sur l'environnement de production. Et ça oblige à bien réfléchir à ce qu'on va faire, puisque ce sera indirect.

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Avril 2017
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2017
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Il est toujours possible d'avoir un spare master avec une réplication décalée pour ce genre de cas. Ça se fait partout depuis un moment :
    https://dev.mysql.com/doc/refman/5.6...n-delayed.html
    https://docs.mongodb.com/manual/tuto...ca-set-member/
    https://www.postgresql.org/docs/curr...plication.html
    https://docs.oracle.com/database/121...ter.htm#i46930

    Ça fait une perte de données moindre et on peut plus rapidement basculer sur le spare que lorsqu'on doit réimporter toute la DB, recalculer les indexs, etc.

  12. #12
    Membre expérimenté
    Homme Profil pro
    Chargé de projet
    Inscrit en
    Novembre 2015
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Chargé de projet
    Secteur : Industrie

    Informations forums :
    Inscription : Novembre 2015
    Messages : 429
    Points : 1 684
    Points
    1 684
    Par défaut
    Citation Envoyé par _FLX_ Voir le message
    Dans toutes ces affaires il y avait bien une sauvegarde, le problème c'est les 5h de récupération pendant lesquelles les clients sont bloqués...
    Et bien j'ai une proposition mais je sais pas si c'est possible ... donc

    3) Découper la BDD en plusieurs et avoir une sauvegarde par partie de la BDD. Permet de n'avoir un problème "que" sur un bout de la BDD et du coup de recharger une sauvegarde moins volumineuse ?
    Pour ne pas passer pour un boulet :
    http://coursz.com/difference-entre-r...-et-gddr4.html

  13. #13
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2015
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 104
    Points : 2 573
    Points
    2 573
    Par défaut
    Qu'un développeur ait des droits d'accès complets en production, jusqu'à pouvoir faire un drop database, il n'y a que moi que ça choque ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  14. #14
    Membre éprouvé Avatar de Bubu017
    Homme Profil pro
    Ingénieur validation
    Inscrit en
    Avril 2008
    Messages
    300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Deux Sèvres (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur validation
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2008
    Messages : 300
    Points : 1 002
    Points
    1 002
    Par défaut
    Il n'est pas dit que c'était un développeur mais un ingénieur de la boite. ça peut être tout et n'importe quoi. Mais en effet, il faut limiter au max au moins les droits de modification de la base de prod.
    L'arbre de la connaissance porte les fruits de l'arrogance.

    (\ _ /)
    (='.'=) Voici Lapinou. Aidez-le à conquérir le monde
    (")-(") en le reproduisant

  15. #15
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : Juillet 2010
    Messages : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    Tant qu'il y a une action de l' homme on est jamais à l' abri de surprises.

  16. #16
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juin 2016
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2016
    Messages : 27
    Points : 57
    Points
    57
    Par défaut
    Citation Envoyé par Grogro Voir le message
    Qu'un développeur ait des droits d'accès complets en production, jusqu'à pouvoir faire un drop database, il n'y a que moi que ça choque ?
    Euh, pour moi c'est normal. Qui d'autre qu'un développeur ?

  17. #17
    Membre régulier
    Profil pro
    Responsable développement
    Inscrit en
    Septembre 2007
    Messages
    67
    Détails du profil
    Informations personnelles :
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Responsable développement

    Informations forums :
    Inscription : Septembre 2007
    Messages : 67
    Points : 117
    Points
    117
    Par défaut
    J'ai déjà connu cela mais pas sur une base de données en production, c'était plutôt sur une BD de développement. Je manquais encore d'expérience et ça fait reprendre beaucoup de choses, perdre inutilement du temps, surtout qu'il est difficile parfois de pouvoir reprendre certains travaux exactement de la même manière.
    La seule solution est donc la sauvegarde.
    Practice makes perfect !
    C'est par la pratique que l'on parvient à la perfection !
    --------------------------------------------------------------
    Artificial Intelligence Ph.D. Student, Bircham International University (BIU) - Madrid
    Civilian in Côte d'Ivoire, Developer, Network Engineer & Machine Learning Engineer

  18. #18
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2015
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2015
    Messages : 75
    Points : 190
    Points
    190
    Par défaut
    Ça me rappelle des souvenirs Il y a environ 10-12 ans j'ai écrasé la BDD de prod par une ancienne sauvegarde (je voulais mettre à jour ma base en local).
    Ce qui m'a sauvé la mise c'est les logs binaires de mysql, j'ai donc pu reproduire toutes les requêtes qui avaient été faites depuis la dernière sauvegarde et restaurer la BDD sans perte.
    Depuis ce jour je vérifie toujours plusieurs fois chaque opération critique que je fais avec des BDD

  19. #19
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2015
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2015
    Messages : 75
    Points : 190
    Points
    190
    Par défaut
    Citation Envoyé par Gecko Voir le message
    Étant donné que la majorité des devs utilisent leur terminal je pige pas que les mecs aient jamais pensés à colorer la prod en rouge.

    D'ailleurs tous les outils devraient avoir une différence notable selon l'environnement.
    Ça ne sert à rien. Le cerveau s'habitue à ces différences et va en faire l'abstraction au bout d'un certain temps. Cela peut même donner une fausse impression de sécurité qui pourrait augmenter le risque de fausse manip selon mon humble avis.

    Le seul moyen de sécuriser totalement un serveur de prod contre une fausse manip, c'est que personne ne puisse jamais s'y connecter. Une fois qu'on autorise quelqu'un à s'y connecter le risque zéro n'existe plus, il faut prendre cet état de fait en compte et l'intégrer dans les plans de sauvegarde.
    D'autre part on n'est pas non plus à l'abri d'une malveillance volontaire, ou d'une crise de folie d'un employé par exemple. Ces cas rares mais au potentiel dévastateur devraient également être pris en compte dans les procédures de sauvegarde.

  20. #20
    Rédacteur/Modérateur
    Avatar de andry.aime
    Homme Profil pro
    Inscrit en
    Septembre 2007
    Messages
    8 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations forums :
    Inscription : Septembre 2007
    Messages : 8 391
    Points : 15 059
    Points
    15 059
    Par défaut
    Citation Envoyé par jean12 Voir le message
    La seule solution est donc la sauvegarde.
    Le problème n'a jamais été la sauvegarde, il faut être assez con pour ne pas avoir de sauvegarde. Le problème c'est comment empêché la suppression en masse de données sur un ou plusieurs serveur.
    Colorer différemment le console/text sur la prod? Perso j'ai différentes couleurs de textes sur les deux environnements pré-prod et prod sur le terminal. Une seule ligne sur les fichiers bashrc de chaque environnement suffit. Mais cela empêche une étourderie? Bon, c'est déjà un premier garde fou.

Discussions similaires

  1. Réponses: 7
    Dernier message: 23/09/2014, 16h17
  2. [MySQL] Supprimer dans une base de données à la fermeture de session
    Par User Name dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 27/03/2012, 18h13
  3. Réponses: 6
    Dernier message: 19/05/2010, 16h42
  4. Supprimer dans une base de donnée
    Par hugo7 dans le forum ASP.NET
    Réponses: 6
    Dernier message: 22/12/2008, 11h21
  5. [MySQL] Image pour supprimer dans une base de données
    Par fabpeden dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 18/07/2007, 16h21

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