Digital Ocean supprime accidentellement sa base de données de production
Et parvient à la restaurer, avez-vous déjà été confronté à un tel accident ?

Le , par Olivier Famien, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de arond arond - Membre éclairé https://www.developpez.com
le 11/04/2017 à 9:18
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
Avatar de Gecko Gecko - Membre éprouvé https://www.developpez.com
le 11/04/2017 à 9:47
É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.
Avatar de Cedvano Cedvano - Futur Membre du Club https://www.developpez.com
le 11/04/2017 à 9:51
Je fais systématiquement un backup avant toutes modifications importantes.
J'ai aussi eu des surprises dans le passé.
Avatar de tanaka59 tanaka59 - Membre confirmé https://www.developpez.com
le 11/04/2017 à 10:00
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
Avatar de akoho akoho - Membre régulier https://www.developpez.com
le 11/04/2017 à 10:30
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.
Avatar de _FLX_ _FLX_ - Membre du Club https://www.developpez.com
le 11/04/2017 à 12:24
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...
Avatar de Alanis Alanis - Membre habitué https://www.developpez.com
le 11/04/2017 à 12:44
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
Avatar de hotcryx hotcryx - Membre émérite https://www.developpez.com
le 11/04/2017 à 12:55
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
Avatar de CaptainDangeax CaptainDangeax - Membre averti https://www.developpez.com
le 11/04/2017 à 16:34
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.
Avatar de tchatm tchatm - Nouveau Candidat au Club https://www.developpez.com
le 11/04/2017 à 16:34
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.
Contacter le responsable de la rubrique Accueil