Meilleures pratiques ou ressources pour l'élaboration d'un plan de reprise après sinistre? [fermé]

J'ai été chargé de diriger un projet concernant la mise à jour d'un ancien plan de reprise après sinistre quelque peu déséquilibré. Pour l'instant, nous cherchons simplement à régler le côté informatique de DR. La dernière fois qu'ils l'ont fait, ils ont défini leur portée en inventant une seule catastrophe (le centre de données inondé) et en la planifiant à l'exclusion de tous les autres types de catastrophes. Je voudrais adopter une approche plus équilibrée. Je sais que c'est un problème résolu, d'autres organisations ont écrit des plans de reprise après sinistre.

Notre plan est de prendre notre plan de DR informatique et d'aller de l'avant avec lui et de dire "Hé, c'est ce que nous voulons dans un plan de DR pour l'informatique, cela correspond-il à ce que fait le reste de l'Université? voudrais changer? " Nous avons une assez bonne idée du reste du plan et nous nous attendons à ce que cela se passe bien.

Ce que je recherche, c'est des conseils sur la façon de définir un plan de reprise après sinistre et sur les questions auxquelles je devrais réfléchir. Avez-vous des ressources, des livres, une formation préférés liés à l'élaboration d'un plan de reprise après sinistre?

Une excellente source d'information est Disaster Recovery Journal (à propos ).

Les ressources communautaires disponibles comprennent l'ébauche actuelle de leur document sur les pratiques généralement acceptées (BPA) , qui fournit un excellent aperçu du processus et des livrables qui constituent un solide plan et processus de continuité des activités. Il existe également plusieurs livres blancs couvrant divers sujets DR / BC.

Le processus semble intimidant, mais s'il est abordé systématiquement avec un bon aperçu de l'endroit où vous souhaitez vous retrouver (comme le document DRJ GAP), vous pouvez vous assurer d'optimiser le temps investi et de maximiser la valeur du produit final.

Je trouve que leur publication trimestrielle est également intéressante et informative ( abonnez-vous ).

Assurez-vous d'avoir une liste de contacts d'urgence. alias une liste de rappel

Il devrait ressembler à un arbre et montrer qui contacte qui. À la fin d'une succursale, la dernière personne doit appeler la première et signaler toute personne qui n'a pas pu être contactée.

(Cela peut être coordonné par le biais des RH et utilisé pour tout type de catastrophe)

Si nous ajoutons nos idées, nous pourrions créer un wiki sympa à partir de ce message une fois que tout le monde aura ajouté ses propres idées. Je comprends qu'il y a des tas de choses à suivre, mais certains d'entre nous ont des priorités spécifiques en matière de rétablissement. Pour commencer, voici le mien:

Assurez-vous d'avoir une documentation hors ligne / à distance de votre réseau

Avec DR, les éléments de base sont vos RTO (objectifs de temps de récupération) et RPO (objectifs de point de récupération), qui se traduisent grosso modo par "combien de temps il est acceptable de passer pour le récupérer et combien de données pouvons-nous nous permettre de perdre". Dans un monde idéal, les réponses seraient «aucune et aucune», mais un scénario DR est une circonstance exceptionnelle. Ceux-ci devraient vraiment être dictés par vos clients, mais puisque vous partez de l'angle informatique, vous pouvez faire de meilleures suppositions, mais soyez prêt à vous ajuster à la hausse ou à la baisse selon les besoins. Viser le plus près possible de «aucun et aucun» est une bonne chose, mais vous devrez être capable de reconnaître quand le point de rendement décroissant entre en jeu.

Ces deux facteurs peuvent être différents à différents moments de l'année et différents selon les systèmes.

J'aime l'approche plus équilibrée; il est tentant d'énumérer les événements qui peuvent conduire à un scénario de reprise après sinistre, mais ceux-ci appartiennent davantage à un exercice d'analyse / d'atténuation des risques. Avec la RD, l'incident s'est déjà produit et les détails de ce qu'il était sont moins pertinents (sauf peut-être en termes d'affectation de la disponibilité des installations de DR). Si vous perdez un serveur, vous devez le récupérer, qu'il ait été touché par la foudre, formaté accidentellement ou autre. Une approche axée sur l'ampleur et la propagation de la catastrophe est plus susceptible de donner des résultats.

Une approche à utiliser sur les clients, si vous constatez qu'ils hésitent à s'impliquer, est de leur poser des questions DR sous un angle non informatique. Demander quels sont leurs plans si tous leurs dossiers papier s'enflamment est un exemple ici. Cela peut les aider à s'impliquer davantage dans le domaine plus large de la reprise après sinistre et peut alimenter vos propres plans en informations utiles.

Enfin, tester régulièrement votre plan est essentiel au succès. Ce n'est pas bon d'avoir un beau plan DR qui a fière allure sur le papier mais qui ne répond pas à ses objectifs.

En fait, le modèle de développement "à incident unique" est une bonne idée, comme première étape. L'une des raisons est que cela rend l'exercice de planification plus réaliste et plus ciblé. Planifiez l'inondation, tout le long. Supposez ensuite un incident différent (disons, panne de courant à long terme), appliquez-lui ce plan et corrigez ce qui se casse. Après quelques itérations, le plan devrait être relativement robuste.

Quelques réflexions ... - assurez-vous de tenir compte des personnes indisponibles. En cas d'inondation, vous ne pouvez pas supposer que tout le personnel concerné est disponible. Quelqu'un pourrait être en vacances, blessé ou avoir affaire à sa famille.
- prévoir les problèmes et les faiblesses de communication. Avoir plusieurs numéros et plusieurs modes.
- le plan DR a besoin d'une chaîne de commandement. Il est essentiel de savoir qui prend les décisions.
- le plan doit être largement diffusé, y compris hors site et hors réseau. Il doit être accessible pendant la catastrophe!

Là où je travaille, j'ai participé à l'exécution d'un test DR à grande échelle au cours de chacune des deux dernières années. Nous avons découvert que tester nos services, nos collaborateurs et nos processus dans des situations "réalistes" a été utile. Quelques leçons apprises (peut-être évidentes), dans l'espoir que vous les trouverez utiles:

• Les services non testés, malgré ce qu'ils ont écrit dans leur documentation DR, ont généralement des dépendances implicites, induisant une catastrophe. Les secouer avec un ou deux tests réalistes est un résultat utile et mesurable d'un processus de préparation DR.
• Les personnes non testées ont tendance à penser que leurs systèmes fonctionnent bien et «savent quoi faire» en cas de catastrophe. Les secouer jusqu'à avec un test réaliste ou deux est grande.
• Les processus non testés s'effondrent rapidement dans les situations d'urgence réelles. En particulier, les processus d'escalade complexes se sont concentrés principalement sur l'information de la rupture de la haute direction de manière spectaculaire. Les processus légers axés sur les besoins du personnel d'exploitation et des autres intervenants, les sources centrales d'information sur le déroulement de l'urgence, le transfert explicite de responsabilité et les procédures de réponse d'urgence «quotidiennes» fonctionnent mieux.

Je suppose que ce que je veux dire, c'est que vous devriez essayer de ne pas tout rendre théorique sur votre processus de planification de la reprise après sinistre. Poussez pour obtenir la permission de casser les choses et d'obtenir ainsi des données fiables sur la préparation de votre organisation. Cela nécessitera bien sûr un soutien sérieux de la part de la direction, mais il peut être merveilleux de se concentrer pour que l'entreprise passe quelques jours à répéter pour le pire.

Cian

Il existe plusieurs normes du British Standards Institute (BSi) qui se concentrent sur la gestion de la continuité et la reprise après sinistre.

• BS 25999-1: 2006 Gestion de la continuité des opérations, Partie 1: Code de pratique
• BS 25999-2: 2007 Gestion de la continuité des activités. spécification
• BS 25777: 2008 Gestion de la continuité des technologies de l'information et des communications. Code de pratique

Cela peut sembler évident, mais pour suivre la documentation hors site ci-dessus, assurez-vous d'avoir des sauvegardes hors site (de préférence hors de la région). Cela pourrait être un service de stockage en ligne ou un endroit où emmener des cassettes.

Je dis de préférence hors de la région car je viens d'une zone où nous n'avons pas beaucoup de catastrophes naturelles chaque année, mais, si / quand nous en avons une, c'est à l'échelle régionale avec des destructions massives (tremblements de terre, volcans). Son tout bon d'avoir votre sauvegarde dans un coffre-fort à la banque, jusqu'à ce que votre banque est sous magma chaud liquide (/ Dr Evil Voice).

Quelque chose que j'ai lu, c'est que les agences partagent le coût de la maintenance d'un site chaud lorsque le grand site frappe. Ils adoptent des plans pour restaurer la mission critique des deux entreprises sur le site chaud en utilisant la virtualisation et autres, puis partagent le personnel au niveau de assurez-vous que toutes les lumières clignotent. Juste une pensée.

Pour les livres, il y a Disaster Recovery Planning de Jon William Toigo, maintenant dans sa 3ème édition, avec un 4ème blook (blog + livre) à l'horizon.

Laura,

Voici un lien de SQLServerPedia qui donne les bases de DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Lisez aussi sur "Business Continuity"