6h du matin le 10 Mars, en ouvrant un œil, on s'aperçoit que nos boîtes mail sont inondées de centaines de notifications mail de défaillances de sites, d’applications et de 4 serveurs domiciliés chez OVH (nous en testons la disponibilité chaque minute).
Premier réflexe, se rendre sur le compte Twitter du grand manitou de l’hébergement français Octave Klaba qui annonce en anglais l’information suivante “We have a major incident on SBG2. The fire declared in the building. Firefighters were immediately on the scene but could not control the fire in SBG2. The whole site has been isolated which impacts all services in SGB1-4.”
Nous avons d’abord identifié et localisé nos serveurs précisément chez OVH car le DataCenter de Strasbourg est découpé en 5 parties SBG1, SBG2, SBG3, SBG4, SBG5.
Nous avons utilisé pour cela l’API d’OVH (https://api.ovh.com/console/) car les serveurs n’étant plus disponibles, les informations via les consoles d’administrations ne répondaient plus.
Après cette identification, nous avons attendu les premières nouvelles d’OVH qui nous informait que SBG2 était entièrement brûlé et SBG1 partiellement et que l’ensemble du DATA center était coupé (12.000 serveurs). Dans un second temps, l’annonce d’une à deux semaines pour la relance des machines non concernées par l'incendie nous a décidés à commander de nouvelles machines : 2 chez OVH ( avec un délai de livraison de 8h30) et 3 autres chez un autre prestataire chez qui la livraison a été instantanée.
Notre recette concluante de DATARESCUE :
1/ “Ne pas mettre tous ses oeufs dans le même panier”
Nous avons toujours multiplié les emplacements et les prestataires qui gèrent nos serveurs au fil des années et nous allons accentuer ce phénomène sur les 20 machines que nous gérons aujourd’hui. Grâce à cette démarche, seulement 4 machines ont été impactées sur les 20 que nous gérons.
2/ Doubler les sauvegardes dans des emplacements physiques différents
Nous avions 2 sauvegardes de données toutes les 3 heures : 1 dans le Cloud OVH et 1 chez un autre prestataire français (les premières sauvegardes ont malheureusement disparu dans le nuage noir de l’incendie…#blackcloud)
3/ Tester régulièrement les sauvegardes
Nous testons chaque mois la réintégration des données des sauvegardes automatiques afin de nous assurer que nos backup sont viables.
4/ Multiplier les ressources humaines allouées aux serveurs
Notre politique est de s’appuyer exclusivement sur les infrastructures des hébergeurs mais de gérer nous mêmes nos machines.
Mais également doubler les compétences sur la gestion de nos serveurs (interne + externe)
5/ Etre à jour…
Avec nos 20 ans d’ancienneté, nous avons certains projets pour lesquels les clients ne sont pas toujours motivés pour faire une mise à jour de version de Php ou Symfony de leurs applicatifs Web car cela représente un investissement parfois conséquent et “cela fonctionne bien comme ça”.
Aujourd’hui notre souplesse et notre indulgence nous ont ralentis dans la remontée des données sur des serveurs neufs.
Pour illustrer ce propos, je vous invite à essayer d’installer un logiciel qui tourne sur Windows 95 sur un ordinateur neuf…
En conclusion, il s’agit d’une première expérience de cette envergure pour nous en 20 ans. Nous avons travaillé le 10 mars jusqu’à minuit et le 11 soit 120 heures avec 7 collaborateurs mobilisés et superbement impliqués pour remonter environ 10 Millions de lignes de données en base provenant de nos sauvegardes datant du 09/03 à 23h00 avec un incendie annoncé par OVH le 10/03 à 3h42.