Avantages et limites du Disaster Recovery « as a service »
La planification de la reprise après sinistre et l'élaboration d'une infrastructure ennuient les responsables informatiques. Le Cloud propose des coûts inférieurs et davantage de flexibilité. Mais il n'est pas sans risque.
La reprise après sinistre « à la demande » (en Cloud) implique plus de flexibilité dans les déploiements et les tests, mais aussi une restauration plus incertaine.
La reprise après sinistre est source de nombreux maux de tête ; en effet, les systèmes de reprise sont coûteux, difficiles à configurer et à tester, et deviennent rapidement obsolètes.
Méthode fondée sur le Cloud, moins coûteuse et plus facile à déployer, la reprise après sinistre à la demande, ou DRaaS (Disaster Recovery-as-a-Service), permet de tester régulièrement les plans et suit le rythme des changements dans l'entreprise.
Le problème est que les options de reprise après sinistre en Cloud peuvent s'avérer indisponibles après un incident majeur. Autrement dit, des données et les ressources informatiques se retrouvent bloquées, entraînant une paralysie de l'activité.
Comment élaborer un plan de reprise après sinistre
Le personnel d'un datacenter consacre beaucoup de temps et d'efforts à élaborer et tester des scénarios de reprise après sinistre en collaboration avec les autres parties prenantes de l'entreprise.
En premier lieu, mettez en évidence les catastrophes potentielles qu'encourt le datacenter. Météo dangereuse, pannes de courant, systèmes des fournisseurs hors ligne, sabotage par les employés ou attaques depuis l'extérieur sont autant de possibilités.
Identifiez parmi des centaines d'applications celles que l'entreprise doit instantanément remettre en marche. Etudiez la liste et classez-les applications par ordre d'importance dans les opérations quotidiennes.
Ensuite, fournissez et installez une infrastructure de datacenter redondante – serveurs, logiciels, connexions réseau, stockage – qui prendra en charge les applications. Les plans de continuité d’activité n'échappent pas aux considérations financières ; un datacenter hors site coûte cher.
En général, le plan de reprise prévoit la duplication des composants d'infrastructure de chaque application. Parallèlement, la reprise après sinistre nécessite des connexions réseau depuis le site principal vers le site de secours, ainsi que des logiciels pour transmettre à ce dernier des informations à jour.
Les membres du personnel concernés doivent savoir comment déclencher les processus de sauvegarde. Un inventaire déterminera les systèmes utilisés et les employés qui doivent basculer le système défaillant vers le système de secours. En matière de reprise après sinistre, les responsabilités impliquent de notifier les fournisseurs des systèmes et des réseaux, et de s'assurer que les employés savent comment accéder au système de récupération. Dans l'idéal, les utilisateurs métier ne sont que légèrement affectés. L'équipe informatique a besoin de procédures pour mettre des informations de sauvegarde à la disposition des employés pendant la phase de récupération.
Les services informatiques passent souvent beaucoup de temps à mettre en place et à répartir l'environnement informatique de reprise physique, alors qu'ils devraient se consacrer à la programmation et aux tests qui ajoutent de la valeur. Pour tester un PRA, l'équipe chargée du datacenter réquisitionne, reçoit, met en racks, empile et configure le matériel, et s'occupe également des systèmes d'exploitation associés et des correctifs. Elle crée des comptes utilisateur, déploie l'infrastructure ou l'environnement serveur des applications, et elle installe des outils de test. Les programmeurs, quant à eux, consacrent la moitié de leur temps à résoudre des problèmes d'infrastructure terre-à-terre, plutôt que de tester réellement l'application.
Sachant que le processus est compliqué, les entreprises testent généralement leurs plans de reprise après sinistre de manière sporadique, une ou deux fois par an. Plus l'entreprise est grande, plus ce processus de planification se révèle complexe.
En outre, une fois les procédures en vigueur, elles deviennent rapidement obsolètes. Les combinaisons d'applications changent constamment. Aussi, l'équipe doit régulièrement passer en revue et mettre à jour les procédures.
Pour mettre en place les différents composants, les grandes entreprises peuvent consacrer des centaines d'heures de leur personnel et des sommes à plus de 7 chiffres (plus de 1 000 000 de dollars).
Enfin, garantir la pérennité des plans coûte encore davantage.
C'est pourquoi nombre d'entreprises s'intéressent peu à la reprise après sinistre. Consacrer beaucoup de temps à diminuer un risque de catastrophe s'élevant à 1 %, voire moins, ne semble pas constituer un retour sur investissement attractif. En outre, les responsables informatiques doivent traiter une longue liste de priorités quotidiennes qui va croissant.
Ainsi, souvent, la reprise après sinistre ne prend d'importance que le jour où un incident se produit.
Options DRaaS
Grâce à une exécution sur une infrastructure partagée, les services Cloud permettent d'économiser de l'argent. Et les avancées du Cloud en matière de virtualisation et d'automatisation accroissent la flexibilité. Les tests de reprise après sinistre s'effectuent facilement par le lancement d'instances temporaires.
Avec la reprise après sinistre en mode Cloud, l’IT n’a plus à s'échiner sur de menues tâches ; ils travaillent à un niveau supérieur à celui des interfaces du matériel et du système d'exploitation.
Conséquence : l'informatique automatise davantage, la productivité augmente et la durée des tests de reprise diminue. Le personnel du datacenter peut tester l'intégralité d'une fonctionnalité DRaaS de manière plus régulière, ou allouer davantage de ressources à des projets hautement prioritaires.
Forts de tous ces avantages, les services de reprise après sinistre en Cloud suscitent de plus en plus d'intérêt. Selon les prévisions du cabinet d'analystes Gartner, une évolution de 640,8 millions de dollars en 2013 à 5,8 milliards en 2018 conférera à ces services un taux de croissance annuel composé de 55,2 %.
Le secteur des fournisseurs DRaaS est multiple. En termes d'hébergement de solutions d'entreprise, les fournisseurs de Cloud horizontaux comme Amazon Web Services, IBM, sont en concurrence avec des spécialistes de la reprise après sinistre (Axcient, Bluelock, Seagate Evault, Net3 Technology, Unitrends PHD Virtual Technologies, Quorum, SunGard, Windstream Communications et Zerto)
Quand le nuage tourne à l'orage
La reprise après sinistre Cloud présente certaines limitations.
« Les fournisseurs de reprise après sinistre en Cloud ne disposent pas d'une redondance complète des systèmes », explique Rachel Dines, analyste spécialisée en reprise après sinistre chez Forrester.
Les fournisseurs ne peuvent pas justifier le coût de construction de datacenters qui reproduiraient les configurations d'infrastructure de chacun des clients. Ils optent donc pour certains raccourcis.
Un fournisseur DRaaS construit des systèmes pour gérer un nombre limité de pannes. En théorie, une entreprise procède à une reprise de son système si elle rencontre un problème spécifique sur son site, tel qu'une panne de courant au niveau du datacenter. Toutefois, si un sinistre majeur d'origine naturelle survient, il se peut que le site de reprise ne dispose pas de suffisamment d'espace pour exécuter les applications de tous ses clients.
Etant donné que les services informatiques concernés ne le découvriraient qu'au moment du sinistre, le niveau de risque est alors considérablement plus élevé dans l'approche à la demande que dans une reprise après sinistre traditionnelle.
En outre, la reprise après sinistre en Cloud accroît les besoins en bande passante de l'entreprise. La reprise après sinistre à la demande place des copies des applications et des images des machines virtuelles dans le Cloud du fournisseur. Sachant que ces images et applications sont constamment mises à jour, des informations font en permanence la navette entre le site de production de l'entreprise et le datacenter du fournisseur DRaaS.
Cette charge peut pressuriser la bande passante disponible. La DRaaS est efficace avec les applications simples mais peut dégrader les performances du réseau avec des systèmes sollicitant fortement les processus, tels que les applications de gestion de la relation client (CRM) et de planification des ressources d'entreprise (ERP).