Written by

Ce lun­di 7 février, entre 15h48 et 21h, les mails, les accès FTP, WebDAV et notre propre site ont été lar­ge­ment indis­po­nibles. L’ensemble des autres ser­vices n’a pas été impac­té, notam­ment les sites Web et bases de don­nées de nos clients, les ser­veurs DNS, l’ac­cès SSH. Aucune don­née n’a été perdue.

Le dérou­le­ment pré­cis de cette panne excep­tion­nelle – la plus longue de notre his­toire – est détaillé dans la suite de ce billet. Nous revien­drons éga­le­ment sur les mesures qui seront prises pour évi­ter que cela ne se pro­duise à nouveau.

Ce qui s’est passé

Vers 15h45, j’en­tre­prends de mettre à jour les outils PostgreSQL (com­pre­nant notam­ment pg_dump) en ver­sion 9.0 sur le ser­veur héber­geant les sites *.alwaysdata.com (nos propres sites, donc, pas les sites de nos clients) et notre base de don­nées de production.

Pour ce faire, je dois préa­la­ble­ment sup­pri­mer les outils de la ver­sion 8.4 ; or la sup­pres­sion de ces outils entraîne la sup­pres­sion de PostgreSQL lui-même (le ser­veur). Malgré la demande de confir­ma­tion, je valide, croyant à tort qu’il s’a­git de fichiers com­muns et non de la par­tie ser­veur de PostgreSQL. De cette ter­rible erreur humaine décou­le­ront 5h de panne.

MISE À JOUR : Plusieurs per­sonnes nous ont fait remar­quer qu’il serait pré­fé­rable d’ef­fec­tuer les mises à jour sen­sibles la nuit, et de les tes­ter aupa­ra­vant. Je me suis donc mal expri­mé : il ne s’a­gis­sait pas d’une mise à jour de PostgreSQL, mais sim­ple­ment d’un paquet annexe et tota­le­ment secon­daire. Ce genre d’o­pé­ra­tion est effec­tuée quo­ti­dien­ne­ment et ne pose aucun risque. Sans cette erreur humaine, j’au­rais sim­ple­ment annu­lé la com­mande au moment de confir­mer. Les mises à jour pré­sen­tant le moindre risque sont, elles, bien tes­tées sur un ser­veur de test puis effec­tuées la nuit.

Hélas, la sup­pres­sion de PostgreSQL entraîne – sous Debian – la sup­pres­sion des don­nées elles-mêmes, et non sim­ple­ment du logi­ciel (ce qui est à mon sens une très mau­vaise idée). Malgré une CTRL+C qua­si­ment immé­diat, une par­tie des fichiers de notre base de don­nées de pro­duc­tion a été sup­pri­mée. Pour maxi­mi­ser les chances de res­tau­ra­tion, j’ar­rête tout ce qui tourne sur le ser­veur et démonte la partition.

À cet ins­tant – 15h48 – notre base de don­nées de pro­duc­tion est inac­ces­sible. Or cette base, en plus d’être uti­li­sée par nos sites et notre inter­face d’ad­mi­nis­tra­tion – est éga­le­ment uti­li­sée pour l’au­then­ti­fi­ca­tion SMTP, IMAP/POP, FTP et WebDAV. C’est pour­quoi il est désor­mais impos­sible de se connec­ter à une boîte mail, d’envoyer/recevoir un mail, ou de se connec­ter en FTP/WebDAV. Les uti­li­sa­teurs déjà connec­tés (en IMAP ou en FTP par exemple) ne sont pas concernés.

Je réa­lise rapi­de­ment que le conte­nu de notre base de pro­duc­tion est intact, mais que les fichiers de la base sys­tème de PostgreSQL sont tou­chés. Dans ce cas de figure, il n’y a mal­heu­reu­se­ment pas de méthode sys­té­ma­tique pour pou­voir réac­cé­der aux don­nées ; il faut mettre les mains dans le cam­bouis. Il est impos­sible de don­ner une esti­ma­tion d’heure pour le retour à la nor­male : cela peut prendre 15 minutes, ou beau­coup plus.

Après presque deux heures sans suc­cès, et voyant que la situa­tion risque de per­du­rer, nous déci­dons de remettre une sau­ve­garde en ligne, acces­sible en lec­ture seule uni­que­ment, et ser­vant au FTP, WebDAV et POP/IMAP. À 17h38, donc, ces ser­vices sont de nou­veau opé­ra­tion­nels, sauf pour les comptes récem­ment créés (ne se trou­vant pas dans la der­nière sau­ve­garde). Le SMTP est exclu pour évi­ter de refu­ser (et donc perdre) des emails entrants pour les nou­veaux comptes.

Il nous fau­dra encore près de 3h avant de par­ve­nir à res­tau­rer inté­gra­le­ment la base de pro­duc­tion, sans aucune perte de données.

Éviter que cela ne se reproduise

À chaque panne que nous ren­con­trons, de la plus petite à la plus impor­tante, nous nous inter­ro­geons sys­té­ma­ti­que­ment sur les moyens à mettre en place pour éli­mi­ner – ou du moins lar­ge­ment atté­nuer – les risques qu’elle ne se reproduise.

Commençons par évo­quer l’o­ri­gine du pro­blème : l’er­reur humaine. Il est pos­sible, dans cer­tains cas, de mini­mi­ser les chances de faire une erreur. Nous avions ain­si ins­tau­ré l’an­née der­nière cer­tains chan­ge­ments : dis­tinc­tion des machines de déve­lop­pe­ment et de pro­duc­tion en rajou­tant de la cou­leur au prompt, ins­tal­la­tion d’un outil empê­chant de sup­pri­mer (via rm) des don­nées vitales. Dans le cas pré­sent, mal­gré la demande de confir­ma­tion, ma confu­sion m’a fait prendre une déci­sion désas­treuse. À ce niveau-là, je ne vois pas de moyen miracle d’empêcher que cela ne se reproduise.

La solu­tion est donc d’ordre tech­nique. Notre base de pro­duc­tion, cru­ciale pour le fonc­tion­ne­ment de plu­sieurs de nos ser­vices, repré­sente un évident SPOF (Single Point of Failure). La solu­tion, tout aus­si évi­dente, est donc de la dupli­quer. Triste iro­nie, nous avions déjà pré­vu cette amé­lio­ra­tion qui devait inter­ve­nir très prochainement…

Depuis PostgreSQL 9.0, un méca­nisme de syn­chro­ni­sa­tion des don­nées en temps réel est inclus en stan­dard. C’est ce que nous allons uti­li­ser pour avoir une base miroir, acces­sible en lec­ture seule, sur un second ser­veur indé­pen­dant (situé dans un data­cen­ter dif­fé­rent du pre­mier). Ainsi, en cas de sup­pres­sion sau­vage de la base – ou de tout autre pro­blème sur le ser­veur pri­maire – le ser­veur secon­daire pren­dra immé­dia­te­ment le relai, et aucun des ser­vices cru­ciaux ne sera perturbé.

Cette syn­chro­ni­sa­tion en temps réel ne résout tou­te­fois pas un autre pro­blème poten­tiel : celui d’une sup­pres­sion des don­nées au niveau SQL (via un DELETE ou un DROP). Toute modi­fi­ca­tion de la base sur le ser­veur pri­maire se fait ins­tan­ta­né­ment sur le ser­veur secon­daire, donc les don­nées seraient défi­ni­ti­ve­ment perdues.

Pour pal­lier ce pro­blème poten­tiel, nous allons ren­for­cer notre fré­quence des sau­ve­gardes de cette base. Aujourd’hui quo­ti­dienne, nous allons la pas­ser à une fré­quence plus éle­vée – pro­ba­ble­ment chaque heure. Notre ser­veur secon­daire sera basé sur EC2, où le sys­tème de snap­shot per­met­tra de gérer ces sau­ve­gardes auto­ma­tiques de manière très simple.

En conclusion

Nous pré­sen­tons natu­rel­le­ment nos plus sin­cères excuses à tous nos clients pour cette panne excep­tion­nelle. Sachez qu’à aucun moment vos don­nées n’ont été menacées.

Nous tra­vaillons main­te­nant depuis plu­sieurs semaines exclu­si­ve­ment sur le ren­for­ce­ment de notre sta­bi­li­té géné­rale, concer­nant tous les ser­vices – c’est la rai­son pour laquelle les nou­veau­tés sont peu nom­breuses en ce moment. Le déploie­ment de notre nou­velle archi­tec­ture, pre­mière source d’in­dis­po­ni­bi­li­té en 2010, est désor­mais bien der­rière nous, et 2011 s’an­nonce sous les meilleurs aus­pices, à tous points de vue.

À très bien­tôt pour des nou­velles plus agréables :)