{"id":979,"date":"2011-02-09T17:27:53","date_gmt":"2011-02-09T16:27:53","guid":{"rendered":"http:\/\/blogdev.alwaysdata.com\/2011\/02\/09\/compte-rendu-de-la-panne-du-7-fevrier-2011\/"},"modified":"2018-02-01T16:33:32","modified_gmt":"2018-02-01T15:33:32","slug":"compte-rendu-de-la-panne-du-7-fevrier-2011","status":"publish","type":"post","link":"https:\/\/blog.alwaysdata.com\/fr\/2011\/02\/09\/compte-rendu-de-la-panne-du-7-fevrier-2011\/","title":{"rendered":"Compte-rendu de la panne du 7 f\u00e9vrier 2011"},"content":{"rendered":"
\n

Ce lundi 7 f\u00e9vrier, entre 15h48 et 21h, les mails, les acc\u00e8s FTP, WebDAV et notre propre site ont \u00e9t\u00e9 largement indisponibles. L\u2019ensemble des autres services n\u2019a pas \u00e9t\u00e9 impact\u00e9, notamment les sites Web et bases de donn\u00e9es de nos clients, les serveurs DNS, l\u2019acc\u00e8s SSH. Aucune donn\u00e9e n\u2019a \u00e9t\u00e9 perdue.<\/p>\n

Le d\u00e9roulement pr\u00e9cis de cette panne exceptionnelle \u2013 la plus longue de notre histoire \u2013 est d\u00e9taill\u00e9 dans la suite de ce billet. Nous reviendrons \u00e9galement sur les mesures qui seront prises pour \u00e9viter que cela ne se produise \u00e0 nouveau.<\/p>\n

Ce qui s\u2019est pass\u00e9<\/h2>\n

Vers 15h45, j\u2019entreprends de mettre \u00e0 jour les outils PostgreSQL (comprenant notamment pg_dump) en version 9.0 sur le serveur h\u00e9bergeant les sites *.alwaysdata.com (nos propres sites, donc, pas les sites de nos clients) et notre base de donn\u00e9es de production.<\/p>\n

Pour ce faire, je dois pr\u00e9alablement supprimer les outils de la version 8.4 ; or la suppression de ces outils entra\u00eene la suppression de PostgreSQL lui-m\u00eame (le serveur). Malgr\u00e9 la demande de confirmation, je valide, croyant \u00e0 tort qu\u2019il s\u2019agit de fichiers communs et non de la partie serveur de PostgreSQL. De cette terrible erreur humaine d\u00e9couleront 5h de panne.<\/p>\n

MISE \u00c0 JOUR : Plusieurs personnes nous ont fait remarquer qu\u2019il serait pr\u00e9f\u00e9rable d\u2019effectuer les mises \u00e0 jour sensibles la nuit, et de les tester auparavant. Je me suis donc mal exprim\u00e9 : il ne s\u2019agissait pas<\/strong> d\u2019une mise \u00e0 jour de PostgreSQL, mais simplement d\u2019un paquet annexe et totalement secondaire. Ce genre d\u2019op\u00e9ration est effectu\u00e9e quotidiennement et ne pose aucun risque. Sans cette erreur humaine, j\u2019aurais simplement annul\u00e9 la commande au moment de confirmer. Les mises \u00e0 jour pr\u00e9sentant le moindre risque sont, elles, bien test\u00e9es sur un serveur de test puis effectu\u00e9es la nuit.<\/em><\/p>\n

H\u00e9las, la suppression de PostgreSQL entra\u00eene \u2013 sous Debian<\/a> \u2013 la suppression des donn\u00e9es elles-m\u00eames, et non simplement du logiciel (ce qui est \u00e0 mon sens une tr\u00e8s mauvaise id\u00e9e). Malgr\u00e9 une CTRL+C quasiment imm\u00e9diat, une partie des fichiers de notre base de donn\u00e9es de production a \u00e9t\u00e9 supprim\u00e9e. Pour maximiser les chances de restauration, j\u2019arr\u00eate tout ce qui tourne sur le serveur et d\u00e9monte la partition.<\/p>\n

\u00c0 cet instant \u2013 15h48 \u2013 notre base de donn\u00e9es de production est inaccessible. Or cette base, en plus d\u2019\u00eatre utilis\u00e9e par nos sites et notre interface d\u2019administration \u2013 est \u00e9galement utilis\u00e9e pour l\u2019authentification SMTP, IMAP\/POP, FTP et WebDAV. C\u2019est pourquoi il est d\u00e9sormais impossible de se connecter \u00e0 une bo\u00eete mail, d\u2019envoyer\/recevoir un mail, ou de se connecter en FTP\/WebDAV. Les utilisateurs d\u00e9j\u00e0 connect\u00e9s (en IMAP ou en FTP par exemple) ne sont pas concern\u00e9s.<\/p>\n

Je r\u00e9alise rapidement que le contenu de notre base de production est intact, mais que les fichiers de la base syst\u00e8me de PostgreSQL sont touch\u00e9s. Dans ce cas de figure, il n\u2019y a malheureusement pas de m\u00e9thode syst\u00e9matique pour pouvoir r\u00e9acc\u00e9der aux donn\u00e9es ; il faut mettre les mains dans le cambouis. Il est impossible de donner une estimation d\u2019heure pour le retour \u00e0 la normale : cela peut prendre 15 minutes, ou beaucoup plus.<\/p>\n

Apr\u00e8s presque deux heures sans succ\u00e8s, et voyant que la situation risque de perdurer, nous d\u00e9cidons de remettre une sauvegarde en ligne, accessible en lecture seule uniquement, et servant au FTP, WebDAV et POP\/IMAP. \u00c0 17h38, donc, ces services sont de nouveau op\u00e9rationnels, sauf pour les comptes r\u00e9cemment cr\u00e9\u00e9s (ne se trouvant pas dans la derni\u00e8re sauvegarde). Le SMTP est exclu pour \u00e9viter de refuser (et donc perdre) des emails entrants pour les nouveaux comptes.<\/p>\n

Il nous faudra encore pr\u00e8s de 3h avant de parvenir \u00e0 restaurer int\u00e9gralement la base de production, sans aucune perte de donn\u00e9es.<\/p>\n

\u00c9viter que cela ne se reproduise<\/h2>\n

\u00c0 chaque panne que nous rencontrons, de la plus petite \u00e0 la plus importante, nous nous interrogeons syst\u00e9matiquement sur les moyens \u00e0 mettre en place pour \u00e9liminer \u2013 ou du moins largement att\u00e9nuer \u2013 les risques qu\u2019elle ne se reproduise.<\/p>\n

Commen\u00e7ons par \u00e9voquer l\u2019origine du probl\u00e8me : l\u2019erreur humaine. Il est possible, dans certains cas, de minimiser les chances de faire une erreur. Nous avions ainsi instaur\u00e9 l\u2019ann\u00e9e derni\u00e8re<\/a> certains changements : distinction des machines de d\u00e9veloppement et de production en rajoutant de la couleur au prompt, installation d\u2019un outil emp\u00eachant de supprimer (via rm) des donn\u00e9es vitales. Dans le cas pr\u00e9sent, malgr\u00e9 la demande de confirmation, ma confusion m\u2019a fait prendre une d\u00e9cision d\u00e9sastreuse. \u00c0 ce niveau-l\u00e0, je ne vois pas de moyen miracle d\u2019emp\u00eacher que cela ne se reproduise.<\/p>\n

La solution est donc d\u2019ordre technique. Notre base de production, cruciale pour le fonctionnement de plusieurs de nos services, repr\u00e9sente un \u00e9vident SPOF<\/a> (Single Point of Failure). La solution, tout aussi \u00e9vidente, est donc de la dupliquer. Triste ironie, nous avions d\u00e9j\u00e0 pr\u00e9vu cette am\u00e9lioration qui devait intervenir tr\u00e8s prochainement\u2026<\/p>\n

Depuis PostgreSQL 9.0, un m\u00e9canisme de synchronisation des donn\u00e9es<\/a> en temps r\u00e9el est inclus en standard. C\u2019est ce que nous allons utiliser pour avoir une base miroir, accessible en lecture seule, sur un second serveur ind\u00e9pendant (situ\u00e9 dans un datacenter diff\u00e9rent du premier). Ainsi, en cas de suppression sauvage de la base \u2013 ou de tout autre probl\u00e8me sur le serveur primaire \u2013 le serveur secondaire prendra imm\u00e9diatement le relai, et aucun des services cruciaux ne sera perturb\u00e9.<\/p>\n

Cette synchronisation en temps r\u00e9el ne r\u00e9sout toutefois pas un autre probl\u00e8me potentiel : celui d\u2019une suppression des donn\u00e9es au niveau SQL (via un DELETE ou un DROP). Toute modification de la base sur le serveur primaire se fait instantan\u00e9ment sur le serveur secondaire, donc les donn\u00e9es seraient d\u00e9finitivement perdues.<\/p>\n

Pour pallier ce probl\u00e8me potentiel, nous allons renforcer notre fr\u00e9quence des sauvegardes de cette base. Aujourd\u2019hui quotidienne, nous allons la passer \u00e0 une fr\u00e9quence plus \u00e9lev\u00e9e \u2013 probablement chaque heure. Notre serveur secondaire sera bas\u00e9 sur EC2<\/a>, o\u00f9 le syst\u00e8me de snapshot permettra de g\u00e9rer ces sauvegardes automatiques de mani\u00e8re tr\u00e8s simple.<\/p>\n

En conclusion<\/h2>\n

Nous pr\u00e9sentons naturellement nos plus sinc\u00e8res excuses \u00e0 tous nos clients pour cette panne exceptionnelle. Sachez qu\u2019\u00e0 aucun moment vos donn\u00e9es n\u2019ont \u00e9t\u00e9 menac\u00e9es.<\/p>\n

Nous travaillons maintenant depuis plusieurs semaines exclusivement sur le renforcement de notre stabilit\u00e9 g\u00e9n\u00e9rale, concernant tous les services \u2013 c\u2019est la raison pour laquelle les nouveaut\u00e9s sont peu nombreuses en ce moment. Le d\u00e9ploiement de notre nouvelle architecture, premi\u00e8re source d\u2019indisponibilit\u00e9 en 2010, est d\u00e9sormais bien derri\u00e8re nous, et 2011 s\u2019annonce sous les meilleurs auspices<\/a>, \u00e0 tous points de vue.<\/p>\n

\u00c0 tr\u00e8s bient\u00f4t pour des nouvelles plus agr\u00e9ables :)<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Ce lundi 7 f\u00e9vrier, entre 15h48 et 21h, les mails, les acc\u00e8s FTP, WebDAV et notre propre site ont \u00e9t\u00e9 largement indisponibles. L\u2019ensemble des autres services \u2026 Keep reading<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"wp_typography_post_enhancements_disabled":false,"footnotes":""},"categories":[1],"tags":[148,188],"class_list":["post-979","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-panne-fr","tag-postgresql-fr"],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/979","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/comments?post=979"}],"version-history":[{"count":0,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/posts\/979\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/media?parent=979"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/categories?post=979"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.alwaysdata.com\/fr\/wp-json\/wp\/v2\/tags?post=979"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}