Cet article fait partie de notre guide: Guide pour réussir son Plan de Reprise d’Activité

Incendie dans le datacenter : histoires vraies de PRA qui s'envolent en fumée

Cela a commencé par une alarme et s'est terminé en catastrophe : un incendie dans le datacenter a failli détruire toute une entreprise. Au bout du compte, la faiblesse de la conception et de mauvais choix budgétaires étaient en cause.

A 3 heures du matin, mon smartphone m'envoie une alerte. J'en recevais une dizaine chaque nuit depuis que nous avions installé le nouveau système de gestion de l'infrastructure du datacenter. Mais jusque-là aucune n'était grave. Cette fois-là, la température dans notre datacenter principal était conforme à la plage autorisée par « l'American Society of Heating, Refrigerating and Air-Conditioning Engineers », mais supérieure à la limite de fonctionnement de la société. Et elle ne cessait d'augmenter.

Le service financier avait décidé du nouveau budget de notre datacenter avant que quiconque ne dispose de critères ou de modèles établis. Nous devions constamment rogner sur nos procédures de reprise d’activité pour rester dans les clous.

J'avais réclamé des climatiseurs supplémentaires, ainsi qu'une redondance de notre onduleur UPS. Mais malgré tout, les concepteurs nous avaient assurés que nous étions conformes au Tier III de l'Uptime Institute. Il n'y avait donc aucune raison de gaspiller de l'argent que nous n'avions pas pour nous faire certifier, m’avait-on dit.

Cette nuit-là, j'ai appelé la sécurité. Ils avaient reçu la même alarme. Mais personne n'était disponible pour aller vérifier. Après avoir réveillé un responsable qui m'a affirmé qu'il allait envoyer quelqu'un, je me suis habillé et j'ai pris le chemin de nos bureaux.

Impuissant et sous pression

Une heure plus tard, je pénétrais dans un datacenter qui ressemblait au désert de la Vallée de la Mort.

Des lumières clignotaient de partout, les ventilateurs des serveurs fonctionnaient à plein et seuls deux de nos dix climatiseurs fonctionnaient encore. Certains serveurs étaient déjà en train de s'arrêter. Les politiques de reprise après incidents que nous avions mises en place partaient en vrille.

L'écran de gestion de l'infrastructure prêtait à confusion. Il n’avait plus aucun sens une fois le premier menu passé. Un tableau de chiffres indiquait que la température augmentait depuis plusieurs heures. Mais pourquoi n'avais-je pas reçu une alerte plus tôt ?

J'ai trouvé un schéma électrique qui ressemblait à des hiéroglyphes, mais j'ai pu voir qu'il concernait nos onduleurs. Je savais où trouver les panneaux des armoires de nos serveurs, mais je ne connaissais absolument pas les commandes mécaniques. Il y avait des tableaux électriques sur les murs, mais les étiquettes ne me disaient rien. « LBTA-3 » pouvait désigner n'importe quoi et, de toute façon, les portes des tableaux étaient fermées à clé.

Lorsque les services généraux et le service informatique ne sont pas en phase, le datacenter est en danger, surtout en cas d'urgence. Une solution à ce conflit est qu'un membre de l'équipe informatique soit également responsable de la gestion des installations. Une autre solution consiste à rationaliser la communication entre les deux services.

Quand l'employé des services généraux est arrivé, il n'a pu que confirmer ce que je savais déjà. La plupart de nos unités n'étaient plus alimentées en courant.

Il a vérifié les disjoncteurs qu'il a pu localiser et n'a rien trouvé d'anormal. Il ne pouvait pas en faire plus sans l'aide d'un électricien. Il a donc fallu rappeler le responsable des services généraux et attendre qu'un électricien arrive.

J'ai arrêté les serveurs les uns après l'autre pour éviter un plantage catastrophique. Quand l'électricien est arrivé, il savait où se trouvaient les tableaux électriques : dans un local fermé à double tour auquel nous n'avions pas accès sans sa clé spéciale. Il a ouvert la porte. Il faisait frais à l'intérieur. C'était aussi le local de l'onduleur… dont le climatiseur dédié fonctionnait. Mais un seul climatiseur voulait dire que notre onduleur redondant dépendait d'un système de refroidissement non redondant.

Ça commence à chauffer

Dès que l'électricien a réarmé le disjoncteur principal, les climatiseurs se sont remis en marche. Pas pour longtemps.

Des flammes sont sorties des interstices autour des panneaux du boîtier électrique. Notre détecteur de fumée était censé nous alerter avant que les choses tournent mal pour de nous permettre d'intervenir avant que le système principal de protection incendie déclenche une émission de gaz.

Effectivement, il a vite détecté la fumée qui pénétrait dans le datacenter, faisant retentir des alarmes assourdissantes. Mais au lieu de déclencher une alerte précoce, le système principal commençait déjà le compte à rebours qui précède la libération du gaz.

Comme il n'y avait pas d'incendie dans le datacenter, j'ai appuyé sur le bouton d'annulation. Mais cela n'a fait que réinitialiser le compte à rebours. C'est alors que les pompiers sont arrivés.

C'était l'alimentation du climatiseur qui posait problème. Pas celle de l'onduleur ni du serveur. Mais ils ont immédiatement appuyé sur le gros bouton rouge d'arrêt d'urgence. J'ai hurlé, mais ils l'ont fait quand même.

Quelques secondes plus tard, le gaz a été libéré. L'électricien a foncé au sous-sol pour couper l'alimentation principale du local, tandis que les pompiers répandaient de la mousse sur le boîtier enflammé.

Un accueil glacial au centre de secours

Lorsque nos bureaux à l'étranger m'ont appelé en demandant pourquoi ils n'arrivaient pas à nous joindre par téléphone, je leur ai assuré que, selon nos politiques de reprise d'activité, ils devraient être redirigés vers notre centre de secours. Cependant, bien qu'ayant signé un contrat avec ce centre, nous n'avions jamais vraiment effectué de transfert d'exploitation. C'est-à-dire que nous ne leur avions pas transféré notre infrastructure informatique (ni physiquement ni virtuellement).

Quand j'ai appelé le fournisseur du centre de secours pour déclarer une urgence, ils m'ont informé que le centre n'était pas maintenu ni opérationnel et qu’il n'était donc pas prêt à prendre le relais. Malgré les sauvegardes quotidiennes que nous effectuions sur leur datacenter, le transfert de nos services utilisateur allait prendre du temps.

Et en plus, nous allions devoir envoyer notre propre personnel pour le faire.

Moralité : lorsqu'un désastre se produit dans le datacenter, il est essentiel de communiquer avec le reste de l'entreprise. Pour éviter que la situation ne s'aggrave, créez une chaîne téléphonique d'urgence ou installez un système de notification automatisé.

Epilogue

Dans le local électrique, le feu était éteint. L'alimentation était coupée et nous travaillions avec un éclairage de secours. Quand l'électricien a retiré les panneaux du tableau électrique, il s'est aperçu que le jeu de barres avait explosé, entraînant également la destruction du deuxième jeu.

Je savais que la seule solution était de rétablir l'activité de nos services IT sur le site de secours, puis de réévaluer notre plan de reprise après désastre.

Les études montrent que jusqu'à 75 % des pannes dans les datacenters sont dues à des erreurs humaines. Cela signifie que nous pouvons tirer des leçons de l'expérience d'autrui, par exemple de l'incident que je viens de décrire.

Note de l'auteur : Ce récit est inspiré d'événements réels. Chaque partie provient d'une vraie situation dont mes étudiants ou moi avons été directement témoins.

Pour approfondir sur Continuité d’activité, Sécurité physique

Close