La reprise après incident (DR) se compose de technologies et de bonnes pratiques informatiques qui visent à prévenir ou réduire la perte de données et les perturbations opérationnelles résultant d'événements catastrophiques, qu'il s'agisse de pannes d'équipement ou de pannes de courant localisées, de cyberattaques, d'urgences civiles, d'attaques criminelles ou militaires ou de catastrophes naturelles.

De nombreuses entreprises, en particulier les petites et moyennes entreprises, négligent le développement d'un plan de reprise après incident fiable et réalisable. Sans ce type de plan, elles sont faiblement protéger contre l'impact d'événements significativement perturbateurs.

Une panne d'infrastructure peut coûter jusqu'à 100 000 dollars par heure (lien externe à IBM), et une panne d'une application critique peut coûter entre 500 000 et 1 million de dollars par heure. De nombreuses entreprises ne peuvent pas se relever de telles pertes. Plus de 40 % des petites entreprises ne rouvriront pas après avoir connu un incident, et parmi celles qui le pourront, 25 % feront faillite au cours de la première année consécutive à la crise. La planification de la reprise après incident peut réduire considérablement ces risques.

La planification de la reprise après incident implique l'élaboration de stratégies, la planification, le déploiement de la technologie appropriée et des tests continus. La gestion des sauvegardes de vos données est un élément essentiel de la planification de la reprise après incident, mais un processus de sauvegarde et de récupération ne constitue pas à lui seul un plan complet de reprise après incident.

La reprise après incident consiste également à s'assurer que des ressources adaptées de stockage et de traitement sont disponibles pour maintenir des procédures solides de reprise en ligne et de reprise par restauration. Le basculement consiste à décharger les charges de travail vers des systèmes de sauvegarde afin que les processus de production et les environnements des utilisateurs finaux soient le moins perturbés possible. La reprise par restauration implique de revenir aux systèmes primaires d'origine.

Lisez notre article pour en savoir plus sur la différence essentielle entre la planification des sauvegardes et la planification de la reprise après incident.

La planification de la continuité des opérations crée des systèmes et des processus qui permettent à tous les secteurs de votre entreprise de maintenir les opérations essentielles ou de les reprendre le plus rapidement possible en cas de crise ou d'urgence. La planification de la reprise après incident est la sous-catégorie de la planification de la continuité des opérations, qui porte sur la récupération de l'infrastructure et des systèmes informatiques.

Analyse de l'impact sur les opérations

La création d'un plan de reprise après incident complet commence par l'analyse de l'impact sur l'activité. Lors de cette analyse, vous créez une série de scénarios d'incidents détaillés qui peuvent ensuite être utilisés pour prévoir la taille et l'étendue des pertes que vous pourriez subir en cas de perturbation de certains processus métier. Et si le centre d'appels du support client était détruit dans un incendie, par exemple, ou que votre siège social était frappé par un tremblement de terre ?

Ainsi, vous pourrez identifier les domaines et les fonctions de l'entreprise qui sont les plus critiques et déterminer la durée d'indisponibilité que chacune de ces fonctions critiques peut tolérer. En disposant de ces informations, vous pouvez commencer à créer un plan pour déterminer comment les opérations les plus critiques peuvent être maintenues dans divers scénarios.

La planification de la reprise après incident informatique doit suivre et soutenir la planification de la continuité des opérations. Si, par exemple, votre plan de continuité des opérations demande aux représentants du centre de support de travailler à partir de chez eux en cas d'incendie dans le centre d'appels, quels types de matériels, de logiciels et de ressources informatiques doivent être disponibles pour soutenir ce plan ?

Analyse des risques

L'évaluation des probabilités et des conséquences potentielles des risques auxquels votre entreprise est confrontée est également une composante essentielle de la planification de la reprise après incident. Comme les cyberattaques et les ransomwares sont toujours plus répandus, il est essentiel de comprendre les risques généraux de cybersécurité que toutes les entreprises rencontrent aujourd'hui, tout comme les risques propres à votre activité et à votre emplacement géographique.

Pour une multitude de scénarios, tels que les catastrophes naturelles, les pannes d'équipement, les menaces internes, le sabotage et les erreurs humaines, vous devrez évaluer vos risques et réfléchir à l'impact global sur votre entreprise. Posez-vous les questions suivantes :

• Quelles seraient les pertes financières résultant d'un manque à gagner ou des perturbations des activités génératrices de revenus ?
  
  
• Quel serait l'impact sur la réputation de votre marque ? Quel serait l'impact sur la satisfaction du client ?
  
  
• Quel serait l'impact sur la productivité des employés ? Combien d'heures de main-d'œuvre seraient perdues ?
  
  
• Quels risques l'incident pourrait-il présenter pour la santé ou la sécurité des personnes ?
  
  
• Les initiatives ou les objectifs de l'entreprise seraient-ils impactés ? Comment ?

Classer les applications par ordre de priorité

Les charges de travail ne sont pas toutes aussi essentielles à la poursuite des opérations de votre entreprise, et la durée d'indisponibilité est bien plus tolérable pour certaines applications que pour d'autres. Répartissez vos systèmes et applications dans trois niveaux, en fonction de la durée d'indisponibilité que vous pouvez supporter et de la gravité des conséquences d'une perte de données.

1. Stratégiques : il s'agit des applications dont le fonctionnement est essentiel à la survie de votre entreprise.
   
   
2. Importantes : il s'agit des applications pour lesquelles vous pouvez tolérer des indisponibilités de courte durée.
   
   
3. Non essentielles : il s'agit des applications que vous pouvez temporairement remplacer par des procédures manuelles ou dont vous pouvez vous passer.

Documenter les dépendances

L'étape suivante de la planification de la reprise après incident consiste à créer un inventaire complet de vos actifs matériels et logiciels. Il est essentiel de connaître les interdépendances des applications critiques à ce stade. Si une application logicielle est indisponible, quelles sont les autres qui seront affectées ?

La meilleure façon de gérer les interdépendances entre les applications est de concevoir des modèles de résilience et de reprise après incident dans la conception même des systèmes. Dans les architectures actuelles basées sur les microservices, il n'est que trop fréquent de découvrir des processus qui ne peuvent pas être lancés lorsque d'autres systèmes ou processus sont en panne, et inversement. Il s'agit d'une situation très critique. Il est donc essentiel de découvrir ces problèmes lorsque vous avez le temps de développer des plans de repli pour vos systèmes et processus, avant qu'un réel sinistre ne se produise.

Établir des objectifs de temps de récupération, des objectifs de point de reprise et des objectifs de cohérence de reprise

En tenant compte de vos analyses des risques et de l’impact sur l’entreprise, vous devez pouvoir établir des objectifs de délais de restauration des systèmes, le volume de données que vous pouvez utiliser et la quantité de données altérées ou l'écart que vous pouvez tolérer.

Votre objectif de temps de reprise (RTO) est la somme maximale de temps nécessaire à la restauration de l'application ou du système suite à une interruption de service.

Votre objectif de point de reprise (RPO) est l'âge maximal des données qui doivent être récupérées afin que votre entreprise puisse refonctionner normalement. Pour certaines entreprises, la perte de quelques minutes de données peut être catastrophique, tandis que d'autres dans d'autres secteurs peuvent tolérer des fenêtres plus longues.

Un objectif de cohérence de la reprise (RCO) est défini dans l'accord sur les niveaux de service (SLA) pour les services de protection des données en continu. Il s'agit d'une mesure qui indique le nombre d'entrées incohérentes dans les données d'entreprise provenant des processus ou des systèmes récupérés qui sont tolérables en cas de reprise après incident, et qui décrit l'intégrité des données d'entreprise dans des environnements d'applications complexes.

Problèmes de conformité réglementaire

Tous les logiciels et solutions de reprise après incident que votre entreprise a mis en place doivent répondre aux exigences de protection des données et de sécurité que vous devez respecter. Ainsi, les systèmes de reprise en ligne et de sauvegarde des données doivent pouvoir répondre aux mêmes normes de confidentialité et d'intégrité des données que vos systèmes primaires.

Parallèlement, plusieurs normes réglementaires stipulent que toutes les entreprises doivent maintenir des plans de reprise après incident ou de continuité des opérations. Le Sarbanes-Oxley Act (SOX), par exemple, stipule que toutes les entreprises cotées en bourse des États-Unis doivent conserver des copies de tous leurs dossiers commerciaux pendant au moins cinq ans. Le non-respect de cette réglementation (y compris le fait de ne pas mettre en place et de tester des systèmes appropriés de sauvegarde des données) peut entraîner des sanctions financières importantes pour les entreprises, voire des peines de prison pour leurs dirigeants.

Choisir les technologies

Un plan de reprise après incident digne de ce nom repose sur les sauvegardes. Auparavant, la plupart des entreprises utilisaient des bandes et des disques durs pour réaliser les sauvegardes, en conservant plusieurs copies de leurs données et en stockant au moins l'une d'entre elles hors site.

Dans le monde actuel en constante évolution numérique et toujours connecté, les bandes magnétiques dans les référentiels hors site ne permettent généralement pas d'atteindre les RTO nécessaires pour maintenir les opérations critiques. La création de votre propre solution de reprise après incident implique de répliquer un grand nombre des fonctionnalités de votre environnement de production et nécessite d'engager des coûts pour le personnel de support, l'administration, les installations et l'infrastructure. Pour cette raison, de nombreuses organisations se tournent vers des solutions de sauvegarde dans le cloud ou des fournisseurs complets de reprise après incident en tant que service (DRaaS).

Choisir les emplacements des sites de récupération

La construction de votre propre centre de données de reprise après incident implique d'équilibrer plusieurs objectifs antagonistes. D’une part, une copie de vos données doit être conservée dans un endroit suffisamment éloigné de votre siège social ou de vos bureaux pour qu’elle ne soit pas affectée par les mêmes événements sismiques, menaces environnementales ou autres dangers que votre site principal. D'autre part, les sauvegardes stockées hors site sont toujours plus longues à restaurer que celles situées sur le site principal, et le temps d'attente réseau peut être encore plus long sur de longues distances.

Tests et révisions en continu

En d'autres termes, si votre plan de reprise après incident n'a pas été testé, vous ne pouvez pas vous y fier. Tous les employés ayant des responsabilités pertinentes doivent participer aux exercices de test de reprise après incident qui peuvent inclure le maintien des opérations à partir du site de sauvegarde pendant un certain temps.

Si l’exécution de tests complets de reprise après incident n'est pas prévue dans votre budget ou n'est pas couverte par vos fonctionnalités, vous pouvez également planifier un « exercice de simulation théorique » pour passer en revue les procédures de test. Vous devez cependant savoir que ce type de test est moins susceptible de révéler les anomalies ou les faiblesses dans vos procédures de reprise après incident qu'un test complet, notamment s'il existe des interdépendances d'applications qui n'ont jamais été découvertes.

À mesure que vos actifs matériels et logiciels évoluent, vous devez vous assurer que votre plan de reprise après incident reste lui aussi à jour. Vous devez passer en revue et réviser le plan régulièrement et en continu.

IBM Knowledge Center fournit un exemple de plan de reprise après incident.

DRaaS est l'une des solutions de services informatiques gérés les plus utilisées et qui connaît une forte croissance actuellement. Votre fournisseur documentera les RTO et les RPO dans un contrat sur les niveaux de service (SLA) qui décrira vos limites de durée d'indisponibilité et vos attentes en matière de récupération des applications.

Les fournisseurs de service DRaaS fournissent généralement des environnements de reprise en ligne. Ce modèle offre une importante économie de coût par rapport au maintien de ressources matérielles dédiées redondantes dans votre propre centre de données. Il existe des contrats dans lesquels vous payez des frais pour le maintien des fonctionnalités de reprise en ligne et les coûts d'utilisation des ressources consommées en cas de reprise après incident. En règle générale, le fournisseur se charge de la configuration et du maintien de l'environnement de reprise en ligne.

Les offres de service de reprise après incident diffèrent d'un fournisseur à l'autre. Certains fournisseurs définissent leur offre comme une solution tout-en-un complète, tandis que d'autres proposent des services fragmentés allant de la restauration d'une seule application à la réplication complète du centre de données dans le cloud. Certaines offres peuvent inclure des services de planification ou de test de reprise après incident, tandis que d'autres facturent des frais de conseil supplémentaires pour ces offres.

Assurez-vous que tous les applications logicielles de l'entreprise sont prises en charge, tout comme les fournisseurs de cloud public avec lesquels vous travaillez. Vous devez également vérifier que les performances des applications sont satisfaisantes dans l'environnement de reprise en ligne et que les procédures associées et de reprise par restauration ont été testées correctement.

Si vous avez déjà créé une solution locale de reprise après incident (DR), il peut s'avérer difficile d'évaluer ses coûts et ses avantages par rapport au passage à un abonnement DRaaS mensuel.

La plupart des solutions DR sur site entraînent des coûts matériels, d'électricité, de main-d'œuvre liés à la maintenance, à l'administration, aux logiciels et à la connectivité réseau. Outre les dépenses initiales liées à la mise en place de votre environnement DR, vous devez budgétiser des mises à niveau logicielles régulières. Comme votre solution DR doit rester compatible avec votre environnement de production primaire, vous devez vous assurer qu'elle dispose des mêmes versions logicielles. En fonction des spécificités de votre contrat de licences, les coûts logiciels peuvent doubler.

Non seulement le passage à un abonnement DRaaS peut réduire vos dépenses en matériel et en logiciels, mais il peut également diminuer vos coûts de main-d'œuvre en transférant au fournisseur la charge de la maintenance du site de reprise en ligne.

Si vous envisagez d'utiliser des solutions DRaaS tierces, vous devez vérifier que le vendeur dispose de la capacité pour effectuer des sauvegardes multisites entre les régions. Si un événement météorologique comme un ouragan affecte le site de vos bureaux principaux, le site de reprise en ligne est-il suffisamment éloigné pour ne pas être affecté ? De plus, le fournisseur dispose-t-il de la capacité suffisante pour répondre aux besoins combinés de tous ses clients dans votre région si plusieurs d'entre eux étaient touchés en même temps ? Vous faites confiance à votre fournisseur de DRaaS pour respecter les RTO et les RPO en temps de crise. Alors recherchez un fournisseur de services dont la fiabilité est reconnue.

Lisez le document « Disaster Recovery as a Service (DRaaS) vs. Disaster Recovery (DR): Which Do You Need? » pour un aperçu comparatif des deux solutions.