20 choses à planifier pour une reprise après sinistre informatique

La mise en œuvre d'une solution de reprise après sinistre dépend de trois facteurs :1) le temps 2) les ressources 3) le montant en dollars.

La plupart des organisations ne pensent même pas à la DR lorsque l'infrastructure informatique et les applications fonctionnent sans aucun problème. La plupart d'entre eux ne pensent à la reprise après sinistre qu'en cas de panne ayant un impact négatif majeur sur l'entreprise.

Si vous êtes un administrateur système ou quelqu'un qui est responsable du bon fonctionnement de l'informatique, vous devez travailler en permanence sur la reprise après sinistre. Que votre entreprise ait alloué du temps et du budget ou non, vous pouvez toujours travailler sur certains aspects de DR.

Vous trouverez ci-dessous une liste de divers éléments que vous pourriez envisager lors de la planification d'un DR. Cette liste n'est en aucun cas exhaustive, mais elle devrait vous donner suffisamment d'idées pour vous lancer dans la DR.

1. Centre de données principal résilient. Avant de planifier un centre de données distant secondaire, vous devez vous assurer que tous les composants de votre centre de données principal sont hautement redondants. Votre objectif doit être de concevoir votre centre de données principal aussi résilient que possible afin que vous puissiez rebondir rapidement après la plupart des catastrophes (à l'exception des catastrophes naturelles) sans jamais avoir à utiliser le centre de données distant secondaire. Par exemple, pour votre base de données de production, disposez d'une base de données de secours physique exécutée sur le même centre de données, configurez des cartes NIC doubles et des cartes HBA sur tous les serveurs de production, configurez plusieurs serveurs Web avec un équilibreur de charge, connectez le serveur à deux circuits d'alimentation à l'aide de la redondance alimentation sur les serveurs, etc.
2. Centre de données secondaire distant. Si vous implémentez un centre de données principal résilient, votre objectif d'utiliser un centre de données distant redondant est principalement pour les catastrophes naturelles telles que les tremblements de terre, les incendies, les inondations, etc. Bien que cela puisse être très évident, cela vaut la peine de le dire, car j'ai vu peu d'entreprises faire cela, ils ont à la fois le centre de données primaire et secondaire dans la même ville, ce qui va à l'encontre de l'objectif de DR. Si votre centre de données principal se trouve en Californie, configurez un centre de données secondaire quelque part sur la côte est.
3. Répliquer les composants de production dans le centre de données DR. Vous n'avez pas besoin de répliquer tout le matériel et les applications du centre de données principal vers le centre de données secondaire. Un administrateur système ou toute personne technique peut identifier rapidement tous les matériels et logiciels critiques qui doivent être répliqués sur le site DR, mais vous pourriez avoir besoin de l'aide d'autres services pour identifier les applications critiques pour l'entreprise. Vous devez associer les fonctions commerciales critiques aux composants de l'infrastructure informatique et vous assurer que tous ces composants de l'infrastructure, ainsi que les applications et les données, sont répliqués sur le site de DR.
4. Plan de stockage. Si vous disposez d'un type de stockage SAN (ou stockage NAS) qui prend en charge l'application critique dans le DR principal, vous devez également disposer d'un stockage SAN (ou stockage NAS) similaire sur votre site DR. Pour des raisons de performances, les serveurs de production du site DR doivent avoir les mêmes spécifications que les serveurs de production du site principal. Cependant, pour le stockage, si vous disposez d'un stockage SAN haut de gamme d'un grand fournisseur sur le site principal, envisagez d'implémenter un stockage SAN haut de gamme similaire d'un petit fournisseur, ce qui pourrait vous coûter beaucoup moins cher pour la même configuration et des performances similaires. .
5. Répliquer les données sur le site DR sur une base continue. La synchronisation des données entre le centre de données principal et le centre de données en cas de sinistre est un aspect essentiel d'une mise en œuvre réussie de la reprise après sinistre. Une fois que vous avez répertorié toutes les applications qui doivent être répliquées sur le site DR, vous devez déterminer comment synchroniser les données entre ces deux sites pour toutes ces applications. Par exemple, vous pouvez répliquer la base de données Oracle au niveau bloc à l'aide des technologies de réplication fournies par les fournisseurs de stockage, ou vous pouvez utiliser datagurad pour répliquer les données au niveau oracle. Les deux ont leurs propres avantages et inconvénients. Vous devez les analyser attentivement et choisir celle qui correspond à votre budget et à la portée du DR.
6. Répliquer les données initiales à l'aide de la méthode manuelle. Lorsque vous configurez le site DR pour la première fois, vous devez décider comment effectuer la synchronisation initiale des données. Par exemple, si vous répliquez une base de données d'entrepôt de données de grande taille, vous ne pouvez pas copier la sauvegarde initiale de la base de données sur le réseau vers le site distant, car cela pourrait monopoliser la bande passante. Au lieu de cela, vous pouvez effectuer une sauvegarde sur bande dans le centre de données principal et l'utiliser dans le centre de données secondaire pour configurer la base de données initiale. Une fois la configuration initiale terminée, vous pouvez implémenter une forme de synchronisation incrémentielle automatique entre les sites.
7. RTO signifie Recovery Time Objective. En collaboration avec l'équipe de direction, vous identifiez le RTO acceptable pour l'entreprise. Par exemple, votre organisation peut décider que le RTO acceptable est de 8 heures. c'est-à-dire qu'après un sinistre, dans un délai maximum de 8 heures, toutes les applications critiques doivent être pleinement opérationnelles sur le site DR. Le RTO a un impact direct sur le montant en dollars dépensé pour la mise en œuvre de la solution DR. Par exemple, un RTO de 1 heure peut nécessiter une solution de reprise après sinistre très sophistiquée bien trop coûteuse par rapport à ce qu'exige un RTO de 24 heures.
8. RPO signifie Recovery Point Objective. Tout comme le RTO, vous devez travailler avec la direction pour décider d'un RPO acceptable pour l'entreprise. Par exemple, votre organisation peut décider que le RPO acceptable est de 2 heures. c'est-à-dire qu'après un sinistre, lorsque vous basculez le service vers la DR secondaire, 2 heures de perte de données sont acceptables pour l'entreprise. Par exemple, si le sinistre se produit à 15 h 00, après la restauration du système sur le site DR, il contiendra les données de production uniquement à partir de 13 h 00. Donc, vous avez perdu des données de 13 h à 15 h. En termes simples, si votre RPO est de 2 heures, votre entreprise devrait être prête à perdre 2 heures de données en cas de sinistre.
9. Basculement automatique ou manuel ? Vous devez décider si vous souhaitez basculer automatiquement ou manuellement après un sinistre. Dans la plupart des cas, une intervention manuelle est acceptable, car vous ne souhaitez pas basculer automatiquement vers un site DR sur la base d'un faux signal. Gardez à l'esprit qu'une fois que vous avez basculé, il y a beaucoup de travail à faire pour revenir au centre de données principal.
10. Basculement réseau. J'ai vu des plans de reprise après sinistre accorder beaucoup d'attention à la réplication des données, mais moins aux aspects réseau de la reprise après sinistre. En collaboration avec votre équipe réseau, vous devez identifier toutes les infrastructures réseau qui doivent être répliquées. Par exemple, le basculement DNA pour vous assurer que votre URL de production pointe vers le site DR après le basculement. Si vous avez établi des connexions VPN pour vos clients, identifiez comment basculer les connexions VPN. Lorsque vous créez/modifiez des règles de pare-feu (ou tout élément lié à la sécurité) dans le centre de données principal, vous devez identifier comment ces politiques de sécurité peuvent être répliquées sur le site DR de manière continue.
11. Configuration de la main à distance. Vous devez disposer d'un plan approprié pour accéder au centre de données distant afin de déboguer tout problème. Vous pouvez configurer KVM sur le site DR pour accéder à la console du matériel situé sur le site DR depuis votre bureau. Ou, vous devez planifier une forme de services manuels à distance, où quelqu'un peut se rendre physiquement sur le site de DR et exécuter vos instructions.
12. Test annuel de reprise après sinistre. Plusieurs organisations consacrent beaucoup de temps et d'argent à la mise en place d'un site DR, pour se rendre compte qu'il ne fonctionne pas vraiment comme prévu lorsqu'elles se trouvent dans une situation DR réelle. Une fois par an, vous devez valider vos configurations DR actuelles pour vous assurer que le site DR fonctionne correctement et répond à l'objectif initial. Si tout est correctement configuré, vous devriez être en mesure de basculer manuellement vos applications critiques du site principal vers le site DR et de les laisser fonctionner pendant quelques jours. Cela vous aide également à voir comment le site DR gère la charge en temps réel.
13. Site DR en tant que plate-forme d'assurance qualité. Au lieu d'utiliser le site DR uniquement en cas de sinistre, vous pouvez les utiliser comme plate-forme d'assurance qualité pour effectuer des tests de performances et de charge de vos applications. Cela peut être utile, car vous n'avez pas besoin d'investir dans une infrastructure de test supplémentaire dans le centre de données principal. Lorsque vous adoptez cette approche, vous synchroniserez toujours les données du site principal vers le site DR de manière continue. Cependant, chaque fois que vous effectuez un test de charge, vous devez implémenter une solution supplémentaire où vous prenez un point de contrôle de l'état actuel du site DR, effectuez vos tests d'assurance qualité, puis revenez immédiatement au point de contrôle précédent et continuez à synchroniser les données du site principal. à partir de là.
14. Plan de réponse DR. Une fois que vous avez mis en place le site DR, vous devez disposer d'un plan DR clair sur la façon dont vous et votre équipe réagirez en cas de catastrophe réelle. Collaborez avec divers services de votre organisation et identifiez les ressources clés qui feront partie de l'équipe d'intervention en cas de reprise après incident, et identifiez leur rôle spécifique dans le plan d'intervention en cas de reprise après incident. Le plan d'intervention DR est une simple instruction étape par étape sur ce qui doit être fait lorsqu'il y a un DR, qui effectuera ces tâches et dans quel ordre ces tâches seront exécutées.
15. Vous n'avez pas de site de reprise après sinistre ? Beaucoup d'organisations n'ont pas de site DR. Si vous travaillez pour l'un d'entre eux et que vous êtes responsable des applications critiques et de l'infrastructure informatique, il est de votre responsabilité de proposer un plan de reprise après sinistre et d'éduquer votre direction sur l'importance de consacrer du temps et de l'argent à la reprise après sinistre, et d'obtenir leur approbation. Proposez trois plans DR différents :un qui coûte $$$, un qui coûte $$, un qui coûte $. Comme nous l'avons expliqué précédemment, le plan de reprise après sinistre peut varier en fonction de divers facteurs, et le coût en fait partie. Après avoir présenté votre plan de reprise après sinistre détaillé à votre direction, s'ils ne l'approuvent toujours pas, au moins vous vous sentirez bien d'avoir fait de votre mieux pour élaborer un bon plan de reprise après sinistre.
16. Quand déclarer une catastrophe ? Vous devez l'identifier clairement à l'avance. Vous devez avoir des critères écrits très clairs sur le moment où vous passerez au site DR. c'est-à-dire quels critères déclenchent les critères de basculement DR ? Quand initiez-vous un DR ? À quel moment déclarez-vous qu'il s'agit d'un DR, ajoutez-vous commencer à travailler sur le basculement vers le site DR ? La réponse à ces questions doit être clairement définie et examinée par chaque département de votre organisation, et enfin ces critères doivent être approuvés par la direction. Pour certains, lorsque la production est arrêtée, parce que quelqu'un a supprimé quelque chose en production par erreur, cela peut ne pas déclencher de DR. Pour certaines organisations, il est probablement préférable de restaurer les données à partir de la sauvegarde sur le site principal lui-même. Pour les autres organisations, l'entreprise ne peut pas attendre la restauration à partir de la sauvegarde et doit passer au site DR.
17. Sauvegarde, sauvegarde et sauvegarde. Les sauvegardes sont un facteur très important dans un plan de reprise après sinistre. Comme nous l'avons mentionné précédemment, votre objectif devrait être de ne jamais utiliser le site DR, à moins qu'une véritable catastrophe naturelle ne se produise. Ainsi, une stratégie de sauvegarde solide sur votre site principal est très critique. Vous devez sauvegarder toutes vos applications critiques. Lorsque vous sauvegardez votre base de données, stockez la sauvegarde dans quatre emplacements. Les sauvegardes sont pratiquement inutiles si vous ne les restaurez pas sur un serveur de test pour valider qu'elles fonctionnent de manière continue.
18. Appliquer des correctifs. Lorsque vous appliquez un correctif de système d'exploitation, mettez à niveau le micrologiciel ou effectuez tout type de gestion de configuration sur le matériel du site principal, vous devez disposer d'une stratégie pour effectuer ces opérations sur le site DR de manière continue. Vous ne voulez pas vous retrouver dans une situation où la configuration du système d'exploitation sur votre site principal est différente de celle du site DR.
19. La réussite de la DR dépend de nombreux facteurs. Bénédiction de la haute direction, allocation budgétaire adéquate, implication de toutes les divisions commerciales, plan de reprise après sinistre solide, ressources techniques solides, mise en œuvre entièrement testée de la reprise après sinistre. Plus important encore, un périmètre de reprise après sinistre bien défini et aligné sur l'objectif commercial est très important pour une reprise après sinistre réussie.
20. Documentation DR. Une bonne planification DR nécessite la mise en place de nombreux processus. Tous ces processus doivent être correctement documentés. Par exemple, un document qui explique le processus d'escalade lorsqu'un DR frappe. Une documentation technique qui explique ce qu'il faut faire pour effectuer le basculement vers le site DR. Un document de communication qui répertorie tous les membres de l'équipe impliqués dans le DR, ce dont ils sont responsables et comment ils peuvent être contactés pendant le DR. Un document pour l'équipe de support client, qui sait ce qui doit être communiqué au client et comment joindre les clients en cas de sinistre. Un document de test DR qui répertorie tout ce qu'une équipe d'assurance qualité doit tester après la mise en ligne du site DR, etc.

Nous n'avons fait qu'effleurer la surface de la reprise après sinistre. Il y a beaucoup plus que les éléments ci-dessus. Si vous êtes un administrateur système ou quelqu'un qui est responsable de vos applications et de votre infrastructure informatiques et que vous n'avez pas de plan de reprise après sinistre, considérez ceci comme un rappel pour commencer quelque chose pour votre stratégie de reprise après sinistre.