Vous êtes dans : Accueil > Tribunes libres >

PRA, fois 2 ou fois 4 ?

Cédric Cartau, LUNDI 26 SEPTEMBRE 2016 Soyez le premier à réagirSoyez le premier à réagir

Le PRA – ou Plan de reprise d’activité – est l’ensemble des dispositifs techniques ou organisationnels qu’il est nécessaire de mettre en œuvre, non seulement pour s’assurer que l’IT ne tombera presque jamais en panne (volet technique), mais également pour que, si d’aventure cela se produit, les métiers pourront continuer une activité minimale sans mettre en jeu la vie des patients. Il existe de subtiles différences entre le PRA et le PCA (Plan de continuité d’activité) que j’ai développées dans le chapitre V de mon premier ouvrage[1], et si vous voulez mettre le bazar dans une réunion de RSSI, les lancer sur ce sujet est aussi efficace que d’évoquer la peine de mort ou l’affaire Dreyfus dans un dîner en ville.  

Bref, inutile de se lancer dans une analyse Ebios et faire des dessins pendant des heures sur un paperboard aux métiers et à votre DG, concernant le volet technique du PRA, on peut résumer les mesures en deux mots : tout dédoubler. Un serveur est critique ? En mettre un second. Un switch peut tomber en panne ? Idem. Un serveur Web peut se planter ? Le dédoubler. Les adresses IP sont en dur ? Déployer un boîtier de répartition de charge, qu’il faut aussi dédoubler. Et ainsi de suite, les liens WAN, le cœur de réseau, les baies de disques, etc.

Évidemment la facture est salée : au lieu d’acheter un serveur chef, faut en acheter deux, souriez, c’est vous qui payez. Mais bon, après tout, ils veulent de l’informatique et ils ne veulent pas de pannes, rien n’est cadeau en ce bas monde. On a bien dédoublé les réacteurs sur les avions de ligne, je ne vois pas pourquoi l’informatique échapperait à la règle.

Prenons maintenant l’exemple de la climatisation. Un datacenter est critique ; si la climatisation tombe en panne, la montée de la température laisse à peine deux heures de fonctionnement avant que les équipements ne s’arrêtent (mise en sécurité automatique), sans parler des dégâts occasionnés sur les composants électroniques. Alors on déploie une seconde climatisation, et tout le monde dort sur ses deux oreilles.

Mais voilà, un jour, l’une des deux climatisations tombe en panne. Pas grave, la seconde est là, qui fait bien le job. Mais la pièce de rechange de la climatisation en panne se fait attendre. D’autant qu’on est en été (forcément), que le commercial de votre prestataire de maintenance est en congé (forcément), qu’il n’est pas joignable, que son remplaçant est Kevin le stagiaire et que la météo annonce un coup de chaud pour la semaine suivante. Forcément. C’est ce qu’on appelle le théorème de la tartine beurrée, tartine qui commence à vous rester au fond de la gorge, surtout que cela dure depuis quatre semaines, et que la climatisation bis tombe en panne au beau milieu de la nuit, un dimanche 14 août au soir (le RSSI qui aura le toupet de prétendre que ce genre de mésaventure – pas forcément pour la clim – ne lui est jamais arrivé est un fieffé menteur).

J’aurais pu vous narrer aussi l’histoire du lien WAN intersite dédoublé : on fait une opération de maintenance sur les liens, on envoie deux gugusses, un à chaque bout, téléphone portable vissé à l’oreille, le premier qui dit : « Ça y est je coupe le fil bleu, tu peux aussi couper le fil bleu », et le second qui se trompe de couleur et coupe le fil rouge. Résultat, vos deux sites sont dans le noir pendant tout un après-midi. C’est du vécu.

Une seule solution à ce problème : ne pas dédoubler, mais quadrupler. C’est le moment où votre directeur financier manque de s’étrangler en avalant son croissant du matin : « C’est vraiment nécessaire ? C’est cher. Y en a vraiment besoin ? On peut pas faire autrement ? »

Kévin, va couper le fil bleu pour montrer au monsieur.


[1] La Sécurité du système d’information des établissements de santé, Presses de l’EHESP, 2012.

 

pra, rssi, sécurité