Mercredi 10 mars matin, ma journée débute par la lecture des nouvelles du jour. Mon attention est alors attirée par trois lettres bien connues : OVH. Et pour cause, j’utilise les services de cette entreprise depuis des années, voire des décennies, aussi bien à titre personnel que professionnel. Il est cependant pour le moins inhabituel de voir l’hébergeur français, devenu un géant mondial, faire la une de la presse généraliste.

Qu’avait-il bien pu se passer pour qu’une telle chose arrive ? Les médias sont en effet friands des déboires que peuvent subir les mastodontes de la tech. Ils se délectent de l’énième panne de Facebook, Microsoft ou encore Gmail. Nous pouvons certes leur concéder que ces fournisseurs de service ont un impact non négligeable sur nombre d’entre nous. Mais tout de même, cela ne présageait rien de bon.

Un incendie d’une ampleur sans précédent

Le titre des articles est assez évocateur. Un incendie assez important se serait déclaré dans un datacenter OVH. Je m’empresse alors d’en ouvrir le détail, tout en jetant un oeil sur la supervision TimSoft, qui me rassure. Aucun site de production n’est touché, je peux alors reprendre ma lecture ! Le détail de ces articles est assez édifiant. 44 engins sont mobilisés, dont un bateau pompe. Une centaine de pompiers sont dépêchés, dont des forces allemandes en renfort ! Fort heureusement, aucun blessé n’est à déplorer. En revanche, les dégâts matériels sont immenses. La conséquence directe est la mise à l’arrêt de plusieurs millions de serveurs Web, avec plus de 10000 clients touchés. Coïncidence troublante, la veille, OVH annonçait sa volonté d’entrer en Bourse afin de financer son développement. L’enquête conclura cependant à une cause accidentelle, dûe à un incendie d’onduleurs.

L’heure des questions…

L’évènement qui vient alors de se produire est hautement improbable. Je ne vois guère que l’accident nucléaire ou l’astéroïde au-delà ! Cet incident majeur pose d’innombrables questions. Les premières qui viennent sont des réactions immédiates. Mon serveur est-il touché ? Ai-je bien des sauvegardes de tous mes projets ? Où sont-elles situées, sont-elles bien accessibles ? Si mon serveur est touché, ai-je une possibilité de récupérer mes données, combien de temps restera-t-il hors service ?Ceux qui ne connaissaient pas les infrastructures et datacenters OVH doivent maintenant les connaître un peu mieux ! Outre la localisation de ses données, il faut également prendre en compte le type de service / produit. Le temps d’intervention et de déploiement est en effet inégal selon les gammes.

Puis des réflexions ! Où est mon PRA / PCA ?

Puis d’autres questions sont venues dans un second temps, qui ouvrent la piste à certaines réflexions. Nous les avons eues à l’époque lorsque chacun d’entre nous a déployé son infrastructure. Nous pensions tous faire au mieux en fonction de nos contraintes et de celles de nos clients. Il est nécessaire que le tout à chacun prenne en compte la possibilité que ces évènements peuvent bel et bien survenir. Et adapter en conséquence son Plan de Reprise d’Activité (PRA) ou Plan de Continuité d’Activité (PCA). Est-on en capacité de pouvoir restaurer un certain nombre de sauvegardes ? Cette notion de capacité est à prendre dans son intégralité car elle englobe plusieurs éléments : 

1/ Matérielle

Si mon serveur est touché, où puis-je restaurer mes sauvegardes ? Sur quelle gamme OVH jeter son dévolu ? Suite à l’incendie, le stock de serveurs dédiés immédiatement disponibles a en effet fondu (si vous me permettez l’expression !) comme neige au soleil. Le délai de mise à disposition est d’ailleurs très rapidement passé de 120 secondes à 72 heures. Puis à 10 jours… Certes, OVH s’est surement gardé un peu de stock sous le coude pour ses clients lésés puisque plusieurs milliers de serveurs dédiés ont été livrés dans les jours qui ont suivi à titre gracieux. Ayant moins d’expérience avec la gamme Public Cloud, je n’ai pas pu comparer la disponibilité de cette gamme. Celle des Hosted Private Cloud (clusters de serveurs ESXi) nécessitent une mise en place manuelle par l’intervention de techniciens OVH. Or, ceux-ci devaient être légèrement occupés. Il n’est pas rare d’attendre plusieurs heures voire quelques jours en temps normal, soit une éternité pour une application de production indisponible. Cela dit, vu les centaines de Private Cloud livrés aux clients lésés, OVH a certainement été vigilant et a joué le jeu.

2/ Technique

Mes sauvegardes peuvent-elles être restaurées sur mon environnement cible ? Si mes environnements ne sont pas homogènes, cela peut poser certaines difficultés. Imaginons certains serveurs virtualisés fonctionnant sous ESXi/vSphere et d’autres sous Proxmox ou encore Hyper-V. Quel sera le délai pour transférer et restaurer mes sauvegardes ? Comment l’optimiser pour me prémunir d’un tel évènement ? Si nous pouvons considérer que nous avons majoritairement accès à du très haut débit, que ce soit en local ou chez OVH, la vitesse de transfert n’est en tout cas pas garantie, à moins d’avoir l’option idoine. Chez OVH, avoir du 1Gbps garanti coûte la bagatelle de 70€ HT par mois. Pas sûr que nous soyons nombreux à disposer d’une telle option. Et vous imaginez bien que dans une telle situation, vous êtes loin d’être le seul à vouloir transférer des données de serveur à serveur. Nous pouvons certes compter sur le réseau d’OVH, mais cela pourrait être la source de quelques ralentissements. De même, si toutes mes sauvegardes sont situées sur un seul et même serveur, dédié à cette tâche, j’aurai beau être en très haut débit, je ne pourrai pas espérer plus d’une certaine vitesse de transfert. Idem si je n’ai qu’un seul environnement cible où remonter mes sauvegardes.

3/ Humaine

Si beaucoup d’environnements sont touchés, combien suis-je à même d’en restaurer dans un délai de temps acceptable pour le client ? Seul, il y a fort à parier que la réponse soit très peu, ce chiffre se réduisant d’autant plus que la criticité est élevée. Il se pose alors la question des ressources potentiellement mobilisables sur un incident de cette ampleur. Restaurer une sauvegarde n’est pas complexe en soi. Tout le paramétrage autour est en revanche indispensable pour retrouver une disponibilité des applications. Le DNS devra certainement être modifié ou l’IP dédiée associée au nouveau serveur, la configuration des pares-feux ou autres reverse proxy devra être mise à jour et activée, l’adressage réseau sera peut-être à adapter… Le cumul de toutes les opérations nécessite une bonne coordination et une étape mal orchestrée peut retarder la remise en route.
Bien souvent, pour ces opérations sensibles, la logique qui prévaut niveau sécurité est de restreindre au maximum le nombre de personnes habilitées. Quand bien même un nombre suffisant de personnes y auraient accès, l’efficacité varie fortement entre un habitué de ces opérations d’un occasionnel. Dans la pire des configurations, les personnes appelées en renfort pourraient même ne rien connaître à l’infrastructure ou au système de sauvegarde. Les renforts coûteraient alors un temps précieux aux « sachants » et tout leur bénéfice pourrait alors s’avérer nul. Nous ne pourrions alors les blâmer car au fond, avant cet incident, pourquoi investir du temps à former des collaborateurs à être prêt pour le scénario du pire ? Il faudra néanmoins s’assurer de pouvoir disposer de ressources prêtes à intervenir. Si elles n’ont pas vocation à répéter leur partition en permanence, il faudra veiller à les tenir informées de tout changement et de documenter les procédures de reprise d’activité en apportant le plus de détail possible.

Une réaction de l’hébergeur à la hauteur de l’évènement

Globalement, l’hébergeur français a fait son maximum compte tenu de la situation. A commencer par la communication, assez détaillée et transparente. Son fondateur, personnage atypique à la façon d’un Xavier Niel, n’a pas hésité à utiliser son compte Twitter notamment. Devant l’impatience de certains, il a apporté davantage de détails, photos à l’appui. Car outre le travail colossal de devoir énergiser de nouveau les 3 bâtiments restants de Strasbourg, il a fallu refaire une bonne partie du réseau, envoyer nombre de serveurs au nettoyage suite aux traces corrosives de suie et de fumée… A tous les niveaux, ses commerciaux, service client, techniciens, managers, directeurs ont dû être sur le pont.
Sur le plan tarifaire, OVH a rempli sa part du contrat. L’entreprise a mis en oeuvre des solutions pour pouvoir offrir un remplacement de matériel aux clients impactés, et ce sur plusieurs mois. Ceux ayant subi une coupure de service bénéficient de trois mois gratuits, ceux ayant perdu des données de six mois. Certes, pour les petits clients, sur des gammes type VPS ou équivalentes, cela peut faire sourire, mais l’intention y est. Cette résilience et cette efficacité ne peuvent être que saluées. De par sa taille, OVH fut un temps troisième hébergeur mondial, l’entreprise a du répondant et a su le démontrer.

A l’impossible, nul n’est tenu. Un incendie de cette importance relevait avant le 10 mars 2021 de l’impossible. S’il laissera indéniablement des traces pour OVH, il a le mérite de remettre un peu tout le monde au travail, de l’entreprise française à tous les administrateurs. Au final, même s’il ne le percevra pas directement, c’est le client qui bénéficiera d’un meilleur service.