> Tech > Les idées reçues de la reprise après sinistre

Les idées reçues de la reprise après sinistre

Tech - Par Larry Bolhuis - Publié le 13 juin 2011
email

La liste commence bien avant le moment du sinistre. Consultez ici les points que vous devez prendre en compte dans un plan de reprise d'activité.

Auparavent, pour ceux qui auraient raté cette étape, n'oubliez pas de répondre au questionnaire de la reprise après sinitre (RAS).

Les idées reçues de la reprise après sinistre

Site de sauvegarde. La première phase du planning consiste à s’assurer que le site de sauvegarde est paré pour la poursuite de l’activité : assez d’espace disque, assez de mémoire, assez de CPW, et deux autres choses cruciales. La première : un lecteur de bandes compatible avec vos bandes. La seconde est que le fournisseur ait un système qui reconnaisse votre système d’exploitation. Cela peut sembler élémentaire, mais si votre configuration change, vous devez travailler avec le fournisseur. C’est particulièrement vrai si vous êtes à la pointe ou à la traîne de la technologie.

Cryptage des bandes. Nous sommes bien d’accord : les bandes cryptées ne peuvent pas être lues sans le lecteur et les clés appropriées. Exact ?

Communications. Par le passé, vous pouviez facilement utiliser le fax, le téléphone et autres, pour communiquer avec le reste de votre société. Mais aujourd’hui, une solide infrastructure de communication avec vos sites est indispensable. C’est aussi un élément que vous ne pouvez pas créer au pied levé. Vous seul savez combien de communications sont nécessaires et où. Dans certains cas, vous aurez besoin de lignes dédiées toujours actives sur le site, et dans d’autres cas, il suffira de rediriger simplement les réseaux privés virtuels (VPN) vers le site. Dans tous les cas vous devez être en mesure de communiquer avec le système de sauvegarde dès qu’il est opérationnel. En effet, si vous ne pouvez pas communiquer avec lui, il ne sert à rien.

Logistique. Vous devez absolument savoir qui ira sur le site de reprise et par quels moyens. Et aussi avoir un plan de financement, comme une carte de société rangée sur le site, ou une enveloppe d’argent liquide. Vous ne devez pas supposer que les employés pourront financer eux-mêmes ce voyage. Pensez aux remplacements au cas où quelqu’un ne serait pas disponible. L’un de mes gros clients m’a confié que son plan de secours couvre non seulement la disparition des machines, mais aussi celle du personnel. N’oubliez pas qu’au moment où vous déclarez un sinistre, le site de reprise doit être parmi les premiers informés. La logistique doit prévoir qui peut appeler, qui il faut appeler, et pour quoi dire.

Documentation. Tous les processus doivent être décrits par une documentation à jour. Quelqu’un doit savoir où elle se trouve. Le meilleur moyen d’appliquer le plan est de l’avoir dans une base de données Lotus Notes et copié sur les portables de tous les membres de l’équipe. Par cette méthode, les changements parviennent à chacun tout naturellement. N’oubliez pas quand même que si votre documentation est quelque part en ligne, vous ne pouvez compter sur aucun équipement des sites — y compris les communications — pour accéder au plan.

Gestion du changement. Cet aspect de la RAS ne devrait pas vous surprendre. En effet, tout système de gestion du changement doit englober le plan de reprise. Dans le climat économique actuel, le changement peut survenir rapidement et concerner des éléments qui influenceront la reprise. Assurez-vous que votre processus de gestion du changement prévoit l’impact sur chacun de ces éléments.

La gestion du changement doit aussi inclure tous les types d’objets du système. Voyons un point, mineur en apparence, qui pourrait faire dérailler votre plan de reprise. Supposons que vous fassiez un SAVE 21 (Full System Save) chaque dimanche matin et que vous envoyiez les bandes hors site. Il y a répartition sur de nombreux sites. La plus grande partie de votre base de données est journalisée, et vous changez les journaux toutes les six heures, copiez les récepteurs sur bande et envoyez la bande hors du site. Durant la nuit, vous exécutez la commande SAVCHGOBJ (Save Changed Objects), très rapidement d’ailleurs, parce que la plupart des fichiers sont déjà journalisés. Ensuite, de son propre chef, l’un de vos développeurs commence à journaliser sur le fichier et à placer les journeaux dans une bibliothèque de travail afin de pouvoir suivre les transactions et déboguer une application. Voilà votre plan de secours en péril, car ces journaux ne seront pas sauvegardés et ne seront pas disponibles hors site. Qui plus est, cet objet ne sera plus sur la bande SAVCHGOBJ. Je parie que vous n’aviez pas prévu cela !

Sauvegardes. Je me souviens d’une session COMMON, il y a bien longtemps, où j’entendis pour la première fois Jim Sloan parler des récentes évolutions de QUSERTOOL. Il raconta l’histoire des premiers mots jamais prononcés par la base de données DB2 elle-même. Il faisait noir dans le laboratoire, et il trébucha presque dans le couloir. Mais il fit demi-tour et l’écouta lui murmurer trois mots seulement. Lentement, soigneusement, et clairement, elle dit : « sauvegarde, sauvegarde, sauvegarde. »

Test. Une fois ces sauvegardes faites, il faut tester. Tester, et tester encore. Il n’est pas nécessaire que les premiers tests se déroulent sur un système distant. Vous pouvez démarrer sur une autre partition votre système courant, sur un ancien système conservé, ou sur un système que votre partenaire réserve à ce genre d’occasion. Il est presque certain que tout n’ira pas bien lors des premiers tests, lesquels coûteront moins cher s’ils sont faits localement, sans déplacement ni temps perdu. Réglez ces premiers problèmes rapidement et abordez les tests finaux avec beaucoup plus de chances de réussite.

Logiciel FAI. Vous devez connaître chaque clé du fournisseur d’accès à Internet (FAI) requise, et savoir comment le fournisseur génère une clé. Vous devez savoir qui contacter et comment. Ce processus doit être rodé à l’avance et, croyez-moi, ce n’est pas facile avec tous les fournisseurs. Certains autorisent simplement un certain nombre de jours avant qu’une clé ne soit nécessaire. Vous devez démarrer et travailler sans clé, et vous pouvez contacter le fournisseur pendant les heures ouvrables normales. Certains fournisseurs vous donnent des clés à l’avance, mais soyez prudents car vous n’opérerez pas chaque fois sur le même système physique. Dans certains cas, même si vous êtes sur le même système que celui du test, vous vous retrouverez peut-être dans un numéro de partition différent (et certains fournisseurs utilisent ce numéro dans leur processus de génération de clé). Certains fournisseurs génèrent une clé pour vous chaque fois que vous appelez, et d’autres ont un service client déficient qui ne vous donnera des clés que pendant les heures ouvrables (de huit à cinq). Pas de clés, pas de logiciel. Pas de logiciel, pas d’activité. Vous devez mettre sur pied un plan avec ces fournisseurs, ou en changer.

Cette liste n’est pas un document de planification de RAS complet. La liste détaillée est beaucoup plus longue, et chaque fois que vous arrivez à la fin, d’autres choses surgissent. Sachez aussi que la préparation n’est pas une simple planification mais un processus continu. Le plan de reprise après sinistre doit s’intégrer dans votre programme quotidien. Il doit figurer dans toutes les réunions de planning et devenir partie intégrante de la gestion du changement.

Téléchargez gratuitement cette ressource

Comment sécuriser la Digital Workplace ?

Comment sécuriser la Digital Workplace ?

Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

Tech - Par Larry Bolhuis - Publié le 13 juin 2011