Written by

Hier vers 12h40, une erreur humaine nous a fait perdre un petit nombre de bases de don­nées clients. Nous avons été contraints de res­tau­rer les bases concer­nées à par­tir des der­nières sau­ve­gardes. Tous les clients concer­nés ont reçu un email indi­quant les bases tou­chées ain­si que la date de la sau­ve­garde pré­cé­dente uti­li­sée. Nous vous pré­sen­tons nos plus sin­cères excuses, et reve­nons en détail dans ce billet sur ce qui s’est pas­sé, ain­si que les mesures que nous allons prendre pour évi­ter que cela ne se repro­duise à nouveau.

Ce qui s’est passé

Une com­mande de sup­pres­sion (rm ‑fr) a été exé­cu­tée sur le ser­veur de pro­duc­tion alors qu’elle était des­ti­née à un ser­veur de déve­lop­pe­ment. Cette com­mande a eu le temps de tour­ner envi­ron une seconde avant d’être arrê­tée, mais cela a suf­fi à sup­pri­mer une par­tie des bases de don­nées. Nous avons alors immé­dia­te­ment com­men­cé à faire la liste des bases dis­pa­rues. Une fois cette liste obte­nue, nous avons recréé les bases à par­tir des der­nières sau­ve­gardes (effec­tuées chaque jour).

Et la redondance ?

Comme vous le savez, nos ser­veurs sont sys­té­ma­ti­que­ment redon­dés dans un second data­cen­ter. Mais ce méca­nisme n’est utile que lors des pannes de ser­veur ou de data­cen­ter, pas pour les erreurs humaines. La syn­chro­ni­sa­tion entre les data­cen­ters se fait en temps réel, et les don­nées modi­fiées sont immé­dia­te­ment réper­cu­tées sur le ser­veur de secours.

Sitôt un fichier sup­pri­mé sur le ser­veur prin­ci­pal, il l’est éga­le­ment sur le ser­veur secon­daire. Ce der­nier ne nous est donc d’au­cune aide dans ce cas pré­cis, et seules les sau­ve­gardes régu­lières peuvent nous aider à récu­pé­rer une ver­sion pré­cé­dente des bases et fichiers.

Comment éviter un nouvel incident ?

Disons-le tout de suite : on ne pour­ra jamais exclure com­plè­te­ment l’er­reur humaine, et cet inci­dent n’a pas pour ori­gine une négli­gence par­ti­cu­lière de notre côté. Mais ça ne veut pas dire qu’on ne va rien faire suite à cet incident.

Il y a deux axes sur les­quels nous allons tra­vailler : com­ment évi­ter une nou­velle erreur humaine, et com­ment être mieux pré­pa­ré si elle devait se reproduire.

Éviter l’erreur humaine

À nou­veau, il y a deux com­po­santes pour atteindre cet objec­tif : par la tech­nique, et par la pré­ven­tion humaine.

Techniquement, nous allons réflé­chir à mettre en place :

  • un sys­tème de pro­tec­tion des sup­pres­sions sur les ser­veurs en pro­duc­tion. safe-rm pour­rait être une pre­mière solution ;
  • un sys­tème de dis­tinc­tion visuelle (par exemple, des prompts de cou­leur dif­fé­rente) entre les ser­veurs en pro­duc­tion et les autres.

Humainement, nous allons réflé­chir à édic­ter des règles d’u­ti­li­sa­tion pour limi­ter les risques, par exemple :

  • se décon­nec­ter sys­té­ma­ti­que­ment d’un ser­veur en pro­duc­tion une fois qu’on a effec­tué ce qu’on avait à faire des­sus, pour évi­ter qu’une ses­sion inutile ne reste ouverte ;
  • si on doit mal­gré tout gar­der une ses­sion ouverte, s’o­bli­ger à dif­fé­ren­cier le ter­mi­nal, par exemple en évi­tant de res­ter sur le shell mais en démar­rant une com­mande de type top ou nano.

Se préparer au pire

Une fois les fichiers sup­pri­més, nous avons dû tra­vailler à res­tau­rer au plus vite les bases de don­nées per­dues. Une telle sup­pres­sion sau­vage des fichiers internes aux bases de don­nées rend MySQL et PostgreSQL instables, et nous avons donc dû nous hâter de faire des tests sur un ser­veur tem­po­raire pour s’as­su­rer de la marche à suivre.

Par ailleurs, nous n’a­vions aucune méthode éprou­vée pour détec­ter les bases sup­pri­mées puis réins­tal­ler les der­nières sau­ve­gardes. Ce n’é­tait pas très com­pli­qué, mais cela a néces­si­té l’é­cri­ture de scripts et de tests pour s’as­su­rer du bon fonc­tion­ne­ment de la pro­cé­dure. C’est seule­ment ensuite que nous avons pu res­tau­rer pour de bon les bases sup­pri­mées, d’où envi­ron 2 heures de délai entre la sup­pres­sion des fichiers et la res­tau­ra­tion effec­tive des bases.

Nous avons déci­dé il y a quelques semaines de lan­cer un pro­gramme de simu­la­tion des dif­fé­rents pro­blèmes pos­sibles sur notre archi­tec­ture (panne de machine/réseau/datacenter, péné­tra­tion de nos sys­tèmes, sup­pres­sion de don­nées). Ce n’est pas encore en place parce qu’il y a tout un tra­vail tech­nique en amont pour pou­voir dupli­quer un ser­veur de pro­duc­tion et y faire des simu­la­tions, mais cet inci­dent nous montre une fois de plus l’in­té­rêt d’être pré­pa­ré à de mul­tiples scé­na­rios catastrophe.

Par ailleurs, nous sommes en train de tra­vailler sur un nou­veau sys­tème de redon­dance. Rien n’est encore fait, nous en sommes encore au stade de l’ex­pé­ri­men­ta­tion, mais ce sys­tème pour­rait nous per­mettre de faire des « snap­shots » régu­liers (par exemple, toutes les heures) de l’in­té­gra­li­té de nos don­nées. S’il avait été en place, ce sys­tème nous aurait per­mis non pas de par­tir sur des sau­ve­gardes datant de plu­sieures heures, mais maxi­mum d’une heure. Nous aurons l’oc­ca­sion de faire un billet à ce sujet si ce sys­tème se concrétise.

Ce qui a bien fonctionné

Terminons sur une note posi­tive : nous pou­vons rele­ver que notre poli­tique de com­mu­ni­ca­tion en temps réel et de trans­pa­rence, via notre compte Twitter, fonc­tionne bien en cas d’in­ci­dent. Il fau­drait encore l’a­mé­lio­rer en affi­chant, dans l’ad­mi­nis­tra­tion always­da­ta et sur notre forum, les inci­dents en cours (tout le monde n’est pas sur Twitter). Nous avons éga­le­ment pu contac­ter per­son­nel­le­ment cha­cun de nos clients par email en leur indi­quant pré­ci­sé­ment les bases tou­chées et la date de der­nière restauration.

En outre, les sau­ve­gardes ont été d’une grande uti­li­té. Ce n’est pas une sur­prise, et cha­cun peut d’ailleurs accé­der libre­ment à ses sau­ve­gardes via un réper­toire de son compte. Mais c’é­tait la pre­mière fois qu’elles ont été uti­li­sées à grande échelle.

Pour conclure, j’ai­me­rais pré­sen­ter une nou­velle fois toutes nos excuses au nom de l’é­quipe always­da­ta pour ce mal­heu­reux inci­dent. Merci à tous les mes­sages d’en­cou­ra­ge­ment que nous avons reçus, ils sont tou­jours très appré­ciés, a for­tio­ri en situa­tion de crise.