Le Cyber Monday est arrivé ! Créez une application et profitez de 50% de réduction dès maintenant !
Retour

Explications sur l'incident de cette nuit

le 

De 2:00 AM à 09:30 AM CEST, GoodBarber et WMaker ont été fortement perturbés.
Notre équipe en charge des serveurs, 5 personnes (Greg, Pierre-Laurent, Sébastien, Jérôme et Dumè) était sur Paris toute la semaine afin de mettre en service de nouveaux équipements dans un second data center, Global Switch, situé en périphérie de Paris. Cela fait partie d'un projet d'extension de notre infrastructure, initié depuis plusieurs mois par l'équipe technique, sur lequel nous avons prévu de communiquer une fois le déploiement complet achevé. Cette intervention n'est pas liée au problème que nous avons rencontré cette nuit.

Toutefois, paradoxalement, la présence de nos ingénieurs à Paris à beaucoup ralenti notre capacité d'intervention, car ils étaient sur le chemin du retour vers Ajaccio durant l’incident. De plus, pour effectuer l’intervention à Global Switch, nous avons suspendu une partie de notre système d'alerte. Cela a engendré plusieurs heures de retard pour identifier le dysfonctionnement. Nos clients dans le pacifique nous ont signalé le problème via message privé dans Facebook et Twitter.

Parallèlement à l'intervention chez Global Switch, nous avons effectué dans notre data center DC1, situé lui dans le 19ème arrondissement de Paris, une viste de routine. Nous nous sommes rendu compte lors de l’inspection d’une machine que APC-21, un des systèmes de gestion de l'alimentation (PDU), rencontrait un dysfonctionnement, au niveau de son système de management à distance. 

Nous avons commandé un nouveau matériel auprès de notre fournisseur et nous l'avons installé pour remplacer APC-21. Nous avons rebranché sur ce nouveau matériel, APC-24, toutes les machines qui étaient alimentées par APC-21, à l'exception de switch-nas11. 

Les PDU sont des systèmes conçus pour continuer d'alimenter les machines même si leur système de management est H.S. C'est la raison pour laquelle nous n'avons pas débranché switch-nas11 d'APC-21. Si nous l'avions fait, cela aurait engendré un downtime conséquent. Il était hors de question de faire ce genre de manipulation dans l'urgence, sans planifier l'intervention et prévenir nos utilisateurs.

Dans la nuit, pour une raison encore inconnue, APC-21 a cessé d'alimenter switch-nas11. Lorsque le technicien d'OVH est venu pour déplacer l'alimentation de switch-nas11 de APC-21 vers APC-24, le switch n'a pas booté. Il s'agit d'un switch Cisco. Ce matériel est réputé pour sa fiabilité. Nous n'avons pas encore d'explication quant à son dysfonctionnement.

Nous avons indiqué au technicien d'utiliser un switch de secours qui étaient en attente dans la baie. L'installation de ce switch a rallongé l'intervention car il a fallu re-cabler toutes les machines dans un premier temps. Lorsque le switch de backup a été allumé, nous avons constaté un problème sur deux cartes réseaux du serveur principal (master sql). Dans un second temps, il a donc fallu ré-écrire toutes les règles de routage. Il est fort probable que le problème sur APC-21 ait entrainé les pannes en cascade sur switch-nas11 et les 2 cartes réseaux. 

Depuis 9:30AM, tous les services sont up. Si nous n'avions pas remplacé APC-21 hier matin, la panne qu'il a subi cette nuit aurait pu avoir des conséquences encore plus graves. Une grande partie de la baie aurait cessé d'être alimentée de façon brutale. Cela aurait pu être terrible (pertes de données temporaire, machines hors d'usage, ...) et provoquer un downtime encore plus long (replacement de machines, re-configuration, reprise de backups de données, ...)

Nous allons planifier dans les semaines à venir une intervention complémentaire pour re-construire dans la baie le stock de matériel de backup. Nous allons également en profiter pour anticiper le remplacement des matériels de la même génération que ceux qui ont été défectueux cette nuit.
Conseils pour créer une app