Reprise après sinistre: que faire en cas d’incendie dans votre centre de données?

Mais cela nous rappelle que les catastrophes, cela existe. Un incendie, une inondation, un attentat, mais tout aussi bien une banale coupure de câble ou un rançongiciel (ransomware) peuvent très vite paralyser une entreprise et dans un monde envahi par les services numériques, le fait de pouvoir esquiver ou réparer rapidement est le principal espoir de s’en sortir. Tout cela figure dans ce qu’on appelle le Disaster Recovery Planning (DRP). Un plan que vous devez élaborer dans l’espoir de ne jamais en avoir besoin.

Le DRP, c’est plus qu’une composante d’un contrat de service. Par où commencer? Existe-t-il des règles? Et tous les meubles peuvent-ils être sauvés? Nous avons demandé l’avis de quelques experts qui nous ont tous affirmé qu’il s’agit d’un plan on ne peut plus individuel avec pour chaque entreprise un autre centre de gravité et un autre coût. ‘La base est assez standard, mais le contenu est différent d’une organisation à l’autre’, déclare Johan Van Grieken, partner chez Deloitte et spécialisé en gestion numérique des risques.

‘La partie la plus pénible consiste à convaincre la direction d’y investir’, prétend Peter Witsenburg, information security auditor indépendant et fondateur de Belgium Cloud. C’est une assurance omnium, qui ne vous viendra à point qu’en cas de sinistre.’

L’inventaire

Initialement, le DRP doit savoir comme fonctionnent vos processus d’entreprise, où se trouvent quelles données et comment tout cela interagit. Outre votre architecture IT, il vous faut aussi indiquer les différents rôles et responsabilités. Détaillez plusieurs incidents possibles, évaluez le facteur risque qu’ils se produisent et leur impact sur votre entreprise.

Il est important aussi de savoir quand il convient d’activer le plan de reprise après sinistre. ‘Il y a quelques mois, un client s’est posé la question de savoir s’il devait passer en mode reprise après sinistre dans le cas d’un incident déterminé’, explique Andy Van Der Eeken, Head of Customer Service Management chez Fujitsu. ‘Vu l’impact relativement limité et la possibilité d’une solution à court terme, cela me parut superflu, car en cas de passage à un scénario de reprise après sinistre, divers éléments doivent être pris en compte. Cela n’est requis qu’en cas de véritable nécessité. A ce moment-là, il était clair qu’il n’y avait pas de descriptif signalant à partir de quand un basculement (failover) devait être effectué. En cas d’incendie, on le sait. Mais il existe suffisamment de situations qui sont moins claires. Il en va de même pour qui est autorisé à prendre la décision.’

Le but final est que pour toute une série de scénarios, on peut se fier à un plan signalant ce qui doit se passer, comment et quels choix effectuer.

Witsenburg: ‘Initialement, il faut prendre en compte les… joyaux de la couronne. Quel est votre coeur de métier? Ensuite, examinez au niveau des applications ce qui arrive, lorsqu’une d’elles n’est plus disponible et ici, la première question à se poser est la suivante: pendant combien de temps peut-on s’en passer?’

‘Nous, nous partons davantage des données’, déclare Van Der Eeken (Fujitsu). ‘Quelles données sont les plus cruciales pour votre entreprise? Quelles données provoquent-elles de graves problèmes à votre entreprise en cas de non-disponibilité? Mais il faut aussi considérer tout ce qui les entoure. Chez OVH, il s’agissait d’un centre de données, mais en cas de graves incidents, il y a peut-être également des gens ayant une certaine connaissance qui ne sont plus directement disponibles.’

‘Chez beaucoup de nos clients, la reprise après sinistre fait partir d’un pack. Surtout en outsourcing, nous recevons des exigences en matière de RPO et RTO (Recovery Time Objective et Recovery Point Objective). Mais souvent, cela reste assez général. Si nous sollicitons davantage de détails, par exemple en matière de performances, nous ne recevons pas toujours une réponse.’

Witsenburg ‘On peut cocher beaucoup de SLA, mais il faut aussi pouvoir les tester dans la pratique. Lorsque votre fournisseur ‘cloud’ promet 99,999 pour cent de durée de fonctionnement, est-ce par exemple sur une base annuelle ou mensuelle? Car il y a une grande différence dans la pratique.’

‘Et quelles sont les amendes en cas de problème? Nombre de contrats se limitent alors à 10-15 pour cent du montant que vous payez, parfois encore pondéré sur base de la date dans le mois. Cela ne représente rien eu égard aux coûts nettement plus élevés auxquels vous devrez faire face. Mais peu d’acteurs paient pour obtenir 100 pour cent en retour. Un SLA peut sembler impeccable sur papier, mais ce sera peut-être la douche froide, lorsque vous devrez démarrer votre plan de reprise sur sinistre.

Marnix Vrambout, Technical Sales Manager chez Westpole, parle lui aussi de RTO et RPO. ‘Le premier porte sur la vitesse à laquelle vous serez de nouveau opérationnel, et le second concerne la quantité de données que vous pouvez perdre. Si vous effectuez un backup toutes les 24 heures, vous ne perdrez tout au plus que 24 heures de données. Pour beaucoup d’entreprises ou d’applications, c’est plus que suffisant. Mais si Bol.com ou Coolblue perdent 24 heures de commandes, il y a un gros problème.’

‘Ici, un bon architecte d’entreprise a son pesant d’or’, affirme Koen Magnus, lui aussi partner chez Deloitte et spécialisé en gestion de crise et en ‘business continuity’. ‘Lors de l’identification des processus d’entreprise, mais aussi des joyaux de la couronne, il faut établir le lien vers le volet technique IT, etc. Souvent, on ne sait par exemple pas clairement qui est responsable d’une composante spécifique. Si cela passe par des tiers, il est alors possible qu’une entreprise n’aille pas assez loin dans ses SLA. Si certaines choses ne sont pas claires lors de l’élaboration de votre plan, ce sera d’autant plus difficile en période de crise.’

Enfin, il convient que votre plan soit prêt dans les temps pour permettre à d’autres d’aller de l’avant. Van Grieken (Deloitte): ‘Veillez à ce que le plan se trouve sur plusieurs sites. Ce ne serait en outre pas la première fois que le responsable DRP ne travaille entre-temps plus pour l’entreprise. Votre plan peut certes être rédigé pour des gens ayant une connaissance IT, mais assurez-vous quand même que quelqu’un qui n’a pas une connaissance approfondie de votre environnement, puisse s’y retrouver.’

Jusqu’où aller?

Si nous demandons aux spécialistes jusqu’où un plan de reprise après sinistre peut aller, nous percevons à chaque fois deux choses qui reviennent: cela diffère d’un cas à l’autre et il faut faire des choix. Le DRP porte du reste aussi sur des éléments tels les postes de travail et la communication aux clients, partenaires et membres du personnel. Mais ici, nous nous focaliserons uniquement sur l’IT.

‘Il n’y a pas de directives précises’, prétend Johan Van Grieken (Deloitte). ‘Cela dépend spécifiquement du secteur. Dans une entreprise de construction, il est peut-être possible de poursuivre quelques jours sans certains processus numériques. Mais chez un détaillant en ligne, un jour d’indisponibilité d’un outil est parfois nettement plus sérieux.’

‘Nous examinons surtout les processus qui exercent un impact direct sur les clients. Si votre service se dégrade, il doit être prioritaire. Plus en recul, on pourrait par exemple trouver la comptabilité fournisseurs. En même temps, il y a également des entreprises qui se retrouvent directement sans livraisons et connaissent de sérieux problèmes, si la comptabilité fournisseurs est mise au frigo.’

‘Tout cela engendre parfois d’intéressantes discussions. Un employeur jugera catastrophique le fait que cent personnes ne peuvent travailler quelques jours. Mais est-ce plus important que de ne pas pouvoir recevoir des commandes une journée durant?’

Mais il y a plus que le volet financier direct. ‘Pensons aussi à l’impact sur la réputation. Il peut se passer quelque chose qui exerce peu d’impact sur vos processus d’entreprise, mais qui peut par ailleurs nuire à votre réputation et que vous allez peut-être faire de la sorte la une des médias de manière négative. Vous devez également tenir compte de cet aspect’, ajoute Koen Magnus (Deloitte).

Et sur le plan technique: un fournisseur ‘cloud’ ayant une infrastructure sur plusieurs sites suffira-t-il ou opterez-vous ici encore pour un second fournisseur? Van Der Eeken (Fujitsu): ‘La plupart des acteurs en vue offrent une redondance suffisante. Rappelez-vous que tout doit de nouveau fonctionner. La façon dont une fonctionnalité déterminée est remplie, peut diverger selon la solution ou l’environnement ‘cloud’. Même avec un setup identique dans deux centres de données, il n’est pas toujours simple de remettre tout en ordre.’

Accepter les risques

Indépendamment des choix de qualifier quelque chose de prioritaire (ou pas), il y a aussi des choses qu’on ne peut pas maîtriser. ‘Il y a un centre de données belge sous le couloir aérien de Brussels Airport. Si jamais un avion atterrit trop tôt, c’en est terminé’, déclare Witsenburg. ‘Lorsque nous y avons effectué un exercice, nous avons décidé d’accepter le risque, simplement parce que le coût de déplacement de ce centre est trop élevé. Parfois, il faut simplement l’accepter.’

‘Parfois, c’est bien obligé’, complète Van Der Eeken (Fujitsu). ‘On analyse le risque que cela puisse se passer, le coût de la limitation de l’impact et puis pour certaines choses, il faut simplement accepter que cela puisse arriver.’

La portée est de nouveau une affaire très individuelle et une pondération du coût et de la probabilité. Vrambout (Westpole): ‘Si nous demandons à un client quels RPO et RTO il veut, la réponse est souvent ‘zéro’, car il veut continuer d’être opérationnel. C’est possible sur le plan technologique jusqu’à ce que vous calculiez les efforts à consentir, les moyens et les coûts qui y sont liés et comment ils vont évoluer sur une base mensuelle. Dans la pratique, les entreprises examineront alors l’impact d’un incident ou d’une solution et où la pondération se fera. On observe cependant que les clients veulent souvent les mêmes RPO et RTO pour leurs applications critiques en entreprise.’

Tests

Il y a un plan. Les choix et les investissements ont été effectués. Il est à présent temps de les tester. Allez-vous le faire progressivement ou, comme dans la vraie vie, arrêter le moteur de votre entreprise et voir si le plan génère une reprise directe?

‘Il y a des entreprises qui le font. Mais la plupart s’en tiennent à un galop d’essai’, précise Vrambout (Westpole). ‘Elles font tourner l’environnement et leur applications, mais sans les connecter à internet ou avec un échange actif de données.’

‘Effectuez des tests’, indique Magnus (Deloitte). ‘Nous ne vous conseillons pas de tester le plan élaboré en débranchant la fiche. Procédez par phases, transférez les tests d’un environnement vers un autre et convenez avec vos utilisateurs et des tiers que vous allez procéder à plusieurs tests IT, avant de vérifier si l’ensemble fonctionne bien. Si vous agissez ainsi pour chaque maillon de la chaine, vous pouvez envisager ensuite de tester tout complètement.’

‘Dans la pratique, on le voit très rarement, mais il y a des entreprises qui vont extrêmement loin et en reviennent quasi entièrement à leur plan de reprise après sinistre. Certaines communiquent même pro-activement et informent leurs clients sur un exercice d’urgence et que cela risque d’impacter temporairement les services. C’est parfois plus fort que de le faire à un moment aléatoire, mais cela diffère d’une entreprise à l’autre.’

‘Si vous ne testez jamais, il y a peu de chances que cela se passe sans anicroche’, ajoute Van Grieken (Deloitte). ‘En testant, vous découvrez ce qui ne va pas. La réalité, c’est que la plupart des systèmes ne sont pas autonomes. Même une solution dans le nuage se compose de diverses intégrations avec d’autres composantes. Donc si vous devez changer subitement d’environnement ‘cloud’, il y a un risque que quelque chose cloche.’

Chez Fujitsu, on recommande même d’effectuer des tests quelque peu plus étoffés. Van Der Eeken (Fujitsu): ‘Si vous procédez à un test de repli, essayez quand même d’opérer quelques jours ou semaines sur ce second environnement. Souvent, ce genre de basculement (‘failover’) simulé se déroule le week-end, lorsque l’entreprise ne tourne pas à pleine capacité. Tous les petits obstacles ne se manifestent alors que le lundi.’

Retour à la planche à dessin

Le plan existe, toutes les procédures sont testées, tout le monde sait ce qu’il faut faire, mais combien de temps ce plan sera-t-il valable? Ici, le progrès technologique représente un inconvénient. ‘Le désavantage de la virtualisation, c’est qu’aujourd’hui, votre environnement IT évolue nettement plus vite. On atteint rapidement de nouvelles charges de travail non seulement avec la virtualisation, mais aussi avec la containerisation. Si tel est le cas, il convient aussi d’adapter le plan de reprise après sinistre. Il en résulte qu’il faut à présent nettoyer plus rapidement les serveurs et procéder à de la gestion du cycle de vie’, signale Vrambout (Westpole)

Plus facile ou plus compliqué qu’avant?

L’évolution technologique fait que la reprise après sinistre peut ou doit aujourd’hui se faire d’une autre manière. Si nous demandons à nos experts si cela s’avère plus facile ou plus compliqué qu’avant, les réponses sont équilibrées.

Vrambout (Westpole): ‘Certaines choses ont été améliorées. Avant, la reprise après sinistre était une copie conforme de votre environnement actif. C’était complexe, cela exigeait beaucoup de moyens et s’avérait par conséquent conéreux. Aujourd’hui, la virtualisation permet de rapatrier un maximum sur quasiment n’importe quelle plate-forme. Du matériel identique est nettement moins nécessaire, et les lignes de communication sont meilleures, ce qui fait que les données sont conservées en temps réel sur un second site.’

‘Il existe également des services spécialisés capables de dupliquer vos applications héritées ou du contenu sur le mainframe, mais c’est nettement plus coûteux qu’un environnement basé x86 virtuel. Là où c’est possible, on constate heureusement que la plupart des applications tournent aujourd’hui sur du matériel standard, ce qui facilite les choses.’

Vrambout fait observer ici que les services SaaS conservent en général leurs données sur plusieurs sites physiques. ‘Etablissez une distinction entre IaaS (location d’un serveur virtuel) et SaaS (progiciel en ligne). Si vous louez une machine virtuelle chez AWS ou chez Google, il vous appartiendra de rapatrier cet environnement en cas de problème. Mais ici encore, vous pourrez dupliquer sur un second site moyennent un peu d’argent en plus.’

Privilégiez la simplicité

Witsenburg est moins enthousiaste: ‘Il y a 15 ans, c’était plus simple, car il y avait moins de choix. Aujourd’hui, il existe tant d’acteurs sur le marché que votre RFP s’en trouve nettement plus complexe.

Van Der Eeken (Fujitsu): ‘Il y a aujourd’hui nettement plus de possibilités, mais il vient s’y ajouter une couche de complexité qui n’arrange pas les choses. Si des clients – consciemment ou pas – disposent d’un environnement ‘multicloud’ sur site, chez AWS, chez Azure, etc., cela devient un véritable puzzle. ‘Keep it simple’: c’est encore et toujours un principe qui prévaut, surtout en matière de reprise après sinistre.’