Beaucoup d’entreprises sous-estiment la nécessité de mettre en place des stratégies de reprise après sinistre pour leurs applications basées sur le cloud. Cependant, celles qui en comprennent les enjeux rencontrent parfois des difficultés à mettre en place des plans efficaces.
Contrairement à la réalisation de simples tâches IT, ces plans nécessitent une étroite collaboration et un engagement certain de plusieurs parties pour être menés à bien. De nombreux services IT reposent désormais sur de multiples composants applicatifs, dont certains peuvent être exécutés sur le cloud et d’autres dans les datacenters. L’élaboration d’un plan de reprise après sinistre efficace nécessite donc une approche structurée et transversale qui se concentre sur la résilience de services informatiques dans leur ensemble, et non pas seulement sur les charges de travail individuelles.
Répondre aux questions difficiles
Pour aborder la planification de la reprise après sinistre, les entreprises doivent s’interroger sur leur approche, même si cela soulève des questions désagréables. Ce processus s’avère particulièrement utile puisqu’en soulevant les lacunes, les entreprises pourront réorienter les efforts et stimuler les parties prenantes qui ont négligé les risques.
Lorsqu’une charge de travail échoue, le service qu’elle prend en charge est interrompu, impactant alors la productivité des utilisateurs et entachant la confiance des clients. Le rétablissement du service nécessite une certaine coordination, et surtout d’être mené rapidement pour limiter l’étendue des dégâts. Rappelons, par ailleurs, qu’il est de la responsabilité des entreprises (et non pas des fournisseurs de services cloud) d’assurer la mise en place de procédures de reprise après sinistre.
Elaborer un plan de reprise après sinistre
Une planification efficace de la reprise après sinistre commence par une évaluation de l’impact d’un temps d’arrêt sur l’entreprise. Cet exercice transversal identifie tous les services informatiques utilisés par l’entreprise, détermine l’impact (opérationnel et financier) qu’une interruption de service pourrait avoir et, par conséquent, les exigences de reprise après sinistre pour chaque service. De nombreuses organisations IT tiennent un catalogue de services et ont une base de données permettant la gestion des configurations (CMDB), destinée à simplifier le processus d’identification d’une liste complète de services informatiques. En l’absence d’un tel catalogue, l’inventaire doit être établi dans le cadre d’un processus de découverte.
Afin de déterminer le niveau d’exigence en matière de reprise après sinistre, il est utile de prendre en compte deux paramètres essentiels : l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO). Le RTO représente le temps d’arrêt (généralement mesuré en heures, jours ou semaines) que l’entreprise peut tolérer pour un service informatique donné. De son côté, le RPO est la quantité de données perdues (généralement, entre presque zéro et quelques heures) que peut accepter l’entreprise pour chacun de ces mêmes services.
En pratique, il existe souvent un compromis entre ces deux objectifs : par exemple, les services IT peuvent être restaurés rapidement, mais faire l’objet d’une perte de données plus importante et vice versa. En toute logique, des RTO et RPO exigeants nécessitent généralement la mise en place de solutions technologiques plus coûteuses.
Cartographie des dépendances et évaluation des technologies
Après avoir déterminé les RTO, RPO et l’impact que peut avoir une cessation d’activité sur les différents services IT, l’étape suivante consiste à comprendre tous les composants applicatifs informatiques dont ils dépendent. Créer un mapping des dépendances pour chaque service informatique permettra de s’assurer que les mesures de récupération appropriées sont mises en place pour tous les composants applicatifs nécessaires, qu’ils soient exécutés dans les datacenters ou sur le cloud.
Ensuite, les entreprises doivent évaluer leurs capacités de protection de données et de résilience pour chacune des applications, pour notamment savoir si elles peuvent considérer les RTO et RPO collectivement. Cette évaluation doit être effectuée de manière holistique, en tenant compte de l’impact de la panne la plus grave. Par exemple, la bonne technologie peut être d’ores et déjà mise en place pour récupérer une seule application dans le délai de récupération requis, mais cette technologie permet-elle actuellement de récupérer des dizaines, des centaines ou même des milliers d’applications en parallèle ? Les entreprises peuvent-elles utiliser les mêmes solutions techniques dans les datacenters comme sur le cloud ? La nécessité de disposer de plusieurs outils compliquera indéniablement les procédures de reprise. Après avoir évalué les capacités technologiques actuelles, les entreprises peuvent ensuite identifier des solutions techniques supplémentaires pour combler les lacunes.
Documenter et tester les étapes de récupération
S’il est essentiel de déployer les bons outils de récupération, la technologie ne suffit pas à elle seule à garantir la reprise d’activité. Une étape essentielle consiste à créer un ensemble hiérarchique de plans de récupération qui peuvent être utilisés pour guider l’entreprise tout au long du processus de reprise. Les plans de niveau supérieur documenteront la manière dont les activités de reprise sont coordonnées, tandis que les plans de niveau inférieur comprendront des procédures étape par étape pour assurer la reprise de chaque service informatique. L’élaboration et la maintenance de ces plans représentent un investissement important, mais ils sont essentiels pour garantir une reprise efficace après un incident majeur.
Pour garantir que les plans fonctionneront bien dans la pratique, ils doivent être testés régulièrement. Les tests doivent être effectués au moins une fois par an, et encore plus fréquemment pour les applications critiques. Ils peuvent également constituer un risque d’incident s’ils impliquent l’utilisation de données en direct. Cependant, les tests sont une partie essentielle de la planification de la reprise après sinistre qui ne devrait pas être ignorée.
Renforcer la résilience
Le cloud public offre aux entreprises une plateforme hautement évolutive et résiliente pour l’hébergement des charges de travail. Utilisé correctement, il peut renforcer la résilience des services informatiques. Toutefois, l’adoption du cloud public ne dispense pas l’entreprise de sa responsabilité en matière de disponibilité des services et de reprise après sinistre. Bien que le cloud offre de nombreux éléments de base pour soutenir une stratégie de reprise, les entreprises doivent les utiliser en combinaison avec d’autres technologies et procédures, afin d’élaborer un plan cohérent.
Pour atteindre la résilience multicloud, il est nécessaire d’adopter une approche globale autour des actifs de données, dont certains éléments sont en commun avec le processus de reprise après sinistre. La reprise après sinistre dans le multicloud soulève d’autres problématiques autour de l’emplacement de stockage des données. Les dépendances existantes et la manière dont les données et les charges de travail peuvent être récupérées en cas de situation défavorable avec le fournisseur de cloud.
L’objectif de la planification et du test de reprise après sinistre est de s’assurer que la récupération est possible conformément aux objectifs RPO et RTO. Ceci donnera notamment l’assurance aux clients – tant internes qu’externes – des entreprises qu’ils ne seront pas affectés en cas de temps d’arrêt.
Cliquez ici pour lire l’article depuis sa source.