Un plan de reprise qui survit à une vraie panne
Un plan de reprise ne vaut quelque chose qu’une fois restauré, répété et tenu à jour. Cette page dit ce qui doit y figurer, comment se fixe un objectif de temps de reprise, et comment la reprise informatique se rattache à la continuité d’activité.
Les quatre grandeurs sur lesquelles repose un plan
Qui peut les remplir système par système a un plan. Qui ne le peut pas a une sauvegarde.
Ce que contient un plan de reprise informatique
Il décrit comment l’informatique revient après une panne : quels systèmes d’abord, depuis quelle copie, par qui, et comment on sait que c’est terminé.
- Une liste de systèmes, dans l’ordreTout n’a pas à revenir en même temps. Le plan classe les systèmes selon l’ordre dont le travail a besoin, et cet ordre vient du métier et non de la baie de serveurs. Ce qui n’y figure pas revient plus tard, et chacun le sait à l’avance.
- Un RTO et un RPO par systèmeCombien de temps il peut rester à l’arrêt et combien de travail peut disparaître. Ces deux valeurs décident de ce que la technique doit savoir faire ; l’inverse ne fonctionne pas. Une heure de RPO exige autre chose qu’une nuit.
- Où se trouve la copie et comment on y accèdeUne sauvegarde accessible uniquement via le système en panne n’est pas une sauvegarde. Le plan nomme l’emplacement, le chemin d’accès et qui détient les clés, y compris quand le réseau est coupé et que personne ne peut se connecter.
- Qui fait quoi, avec un numéro de téléphoneDes rôles plutôt que des noms seuls, car les gens partent en vacances. Qui décide de basculer, qui appelle le fournisseur, qui informe l’organisation. Sur papier, car dans ce scénario l’intranet est également indisponible.
Comment nous construisons un tel plan
Cinq étapes, dans cet ordre. Les deux premières portent sur le métier et les trois dernières sur la technique ; dans l’autre sens on construit ce dont personne n’avait besoin.
Chercher ce qui s’arrête
Quels processus s’arrêtent quand un système tombe, et au bout de combien de temps cela fait mal. Cette conversation, nous l’avons avec ceux qui font le travail et pas seulement avec l’informatique : le service qui crie le plus fort n’est pas toujours celui qui doit revenir en premier.
Fixer un RTO et un RPO par système
Nous mettons les chiffres en regard de ce qu’ils coûtent en technique et en travail. Quelque chose bouge presque toujours : une heure de RTO sonne bien jusqu’à ce qu’on voie ce qu’elle demande, et quatre heures suffisent alors pour la moitié des systèmes.
Bâtir la technique sur ces chiffres
Sauvegardes immuables, réplication ou bascule : ce qui convient découle des chiffres ci-dessus. Nous le mettons en place et veillons à ce qu’un système infecté ne puisse pas emporter la copie ; c’est le scénario sur lequel la plupart des plans se cassent.
Restaurer, pour de vrai
Une restauration exécutée sur un environnement séparé, avec le temps mesuré. C’est seulement là qu’on sait si le RTO tient. Presque chaque première tentative réserve une surprise : un certificat, une licence, une interface que personne n’avait notée.
Répéter et tenir à jour
Une fois par an, actionner réellement l’interrupteur, et mettre le plan à jour dès qu’un système arrive ou disparaît. Un plan vieux de deux ans décrit un environnement qui n’existe plus, et on s’en aperçoit au pire moment.
Reprise informatique et continuité d’activité
Les deux termes s’emploient l’un pour l’autre et ne désignent pas la même chose. La continuité d’activité, c’est continuer à travailler ; la reprise informatique, c’est l’informatique qui doit revenir pour cela.
- La continuité d’activité est plus largeUn plan de continuité décrit comment l’organisation continue quand quelque chose lâche : personnes, bâtiments, fournisseurs, communication. La panne informatique en est un scénario. Sans lui, un plan de reprise est un document technique sans commanditaire.
- La reprise informatique en est le volet techniqueC’est le chapitre qui dit comment les systèmes reviennent et à quelle vitesse. Il tient son cadrage du plan de continuité : c’est là que figure la durée d’arrêt tolérable d’un processus, et le RTO en découle.
- Le repli sans informatiquePour les heures où plus rien ne tourne : où sont les commandes papier, comment les clients restent joignables, qui dit quoi. Cela appartient au plan de continuité et non à nous, mais nous posons la question : un RTO de huit heures n’est acceptable que s’il y a huit heures à couvrir.
- Notifier en fait partieSi l’organisation relève de NIS2, une horloge de notification tourne à côté de la reprise. Mélanger les deux coûte du temps au mauvais moment ; le plan les place donc côte à côte, en disant qui fait laquelle.
Ce que nous faisons et ce qui reste chez vous
La continuité n’est pas un produit qui s’achète. Voici le partage que nous tenons, et la part qui doit rester dans l’organisation.
- Ce que nous faisonsÉcrire et entretenir le plan, mettre en place la sauvegarde et la bascule, exécuter et mesurer la restauration, et participer à la répétition. Le service tourne sur nos propres techniciens et ne part pas chez un sous-traitant.
- Ce que nous consignonsQuelle copie se trouve où, quand elle a été restaurée pour la dernière fois et combien de temps cela a pris. C’est le matériau que demande un auditeur, un assureur ou une autorité, et précisément la partie qui n’existe plus s’il faut la reconstituer après coup.
- Ce qui reste chez vousLa décision de basculer, et l’arbitrage sur la durée d’arrêt tolérable de chaque processus. C’est un choix de métier et non de technique ; nous chiffrons ce qu’il coûte et ce qu’il rapporte.
- Ce que personne ne peut promettreQue rien n’arrive. Ce qui est possible, c’est que la panne se déroule de manière prévisible : ordre connu, durée connue, responsabilités connues. C’est la différence entre un incident et une crise.
Votre restauration fonctionne-t-elle vraiment ? La seule façon de le savoir est de l’exécuter. Appelez le +31 85 060 9347 ou écrivez à info@itproposal.com et nous passons en revue ce qui existe. Vous aurez quelqu’un qui parle votre langue.
Pour aller plus loin
Les pages de cet ensemble et ce à quoi elles se rattachent.
Les questions qu’on nous pose
Celles qui reviennent le plus, en bref.
Quelle est la différence entre un plan de reprise et une sauvegarde ?
Une sauvegarde est une copie de vos données. Un plan de reprise décrit comment des systèmes complets en reviennent, dans quel ordre, en combien de temps et par qui. Une sauvegarde sans plan laisse une copie dont personne ne connaît le délai de restauration.
À quelle fréquence faut-il répéter un plan de reprise ?
Au moins une fois par an en actionnant réellement l’interrupteur, et le mettre à jour à chaque changement qui ajoute ou retire un système. Un plan vieux de deux ans décrit un environnement qui n’existe plus, et on s’en aperçoit au pire moment.
Pouvez-vous écrire un plan pour un environnement géré par quelqu’un d’autre ?
Oui. Nous écrivons le plan, mesurons la restauration et participons à la répétition, y compris quand l’exploitation quotidienne est ailleurs. Ce que nous demandons, c’est l’accès aux faits : quelles copies existent, où elles se trouvent et quand la dernière a été restaurée.
Savoir si votre plan tient ?
Dites-nous ce qui tourne et ce qui est déjà en place. Nous parcourons les systèmes, plaçons des RTO et des RPO en regard et disons lesquels ne seront pas tenus, avant qu’une panne ne le dise à notre place.
Des connaissances informatiques concrètes dans votre boîte mail
De nouveaux guides sur la gestion, la sécurité et le poste de travail, écrits par ceux qui font le travail. Sans discours commercial, et la désinscription se fait en un clic.