Deux questions par lesquelles commencer
Lorsqu’il est question de protéger une entreprise contre une panne, la discussion commence presque toujours par les outils. Certains s’interrogent sur le logiciel de sauvegarde, d’autres sur une baie de stockage ou le cloud. Ce n’est pas le bon ordre. Sans deux décisions métier, impossible d’évaluer si un outil convient ni combien il devrait coûter.
Il faut distinguer dès le départ trois notions qui ont tendance à se confondre dans les échanges. Une sauvegarde est une copie des données qui permet de les récupérer après la suppression d’un fichier ou la panne d’un disque. La reprise après sinistre consiste à rétablir l’activité après la perte de l’ensemble de l’environnement, par exemple à la suite d’un incendie, d’une inondation ou d’une attaque ayant chiffré les serveurs. Le plan de continuité d’activité va encore plus loin, car il définit aussi comment l’entreprise travaille tant que les systèmes ne sont pas rétablis.
Ces décisions répondent à deux questions. Combien d’heures l’entreprise peut-elle tenir sans un système donné, et quelle part du travail le plus récent peut-elle perdre ? Le premier chiffre s’appelle RTO, le second RPO. Ces sigles semblent techniques, mais ce n’est pas l’administrateur qui connaît les réponses. Elles viennent de la personne qui sait ce qui se passe dans l’entreprise lorsque les commandes cessent d’arriver.
Tout le reste découle de ces deux chiffres : la fréquence des sauvegardes, leur lieu de stockage, la nécessité éventuelle d’un environnement de secours et le budget pertinent. En inversant l’ordre, on aboutit soit à une solution coûteuse qui ne répond toujours pas aux attentes, soit à une solution bon marché que tout le monde suppose suffisante.
RTO ou le nombre d’heures que l’entreprise peut tenir sans système
RTO signifie Recovery Time Objective. Dans son guide de planification d’urgence, l’organisme américain NIST le définit comme la durée pendant laquelle un système peut rester en phase de reprise avant que le fonctionnement de l’organisation n’en pâtisse. Plus simplement, il s’agit du nombre d’heures pendant lesquelles un système donné peut être indisponible tout en restant supportable pour l’entreprise.
L’erreur la plus fréquente consiste à chercher un chiffre unique pour toute l’entreprise. Le RTO se définit séparément pour chaque système. Un magasin privé de son système de vente ne fonctionne plus du tout. Les archives des documents des années précédentes peuvent rester indisponibles pendant deux jours sans que personne ne le remarque. Ces deux cas ne peuvent pas bénéficier du même niveau de protection, car ce serait gaspiller de l’argent dans l’un des deux.
Le deuxième piège consiste à ne compter que la restauration elle-même. Le RTO ne commence pas au moment où quelqu’un lance la restauration. Il commence au moment de la panne et couvre toutes les étapes : détection du problème, décision d’activer le plan, accès au matériel, restauration, vérification de l’intégrité des données et retour des équipes au travail. Si personne n’est d’astreinte le week-end, le temps écoulé jusqu’au lundi doit aussi être inclus dans le RTO.
Il faut aussi garder à l’esprit qu’un système ne fonctionne jamais seul. Une application a besoin d’une base de données, de l’authentification, du réseau et souvent aussi d’échanges de données avec la comptabilité ou l’entrepôt. Le RTO couvre toute cette chaîne. Le chiffre réel correspond donc au temps de reprise du maillon le plus faible, et non au seul temps de restauration de l’application.
RPO ou la quantité de travail qui peut être perdue
RPO signifie Recovery Point Objective. NIST le définit comme le point dans le temps auquel les données doivent être restaurées après une panne. En pratique, il répond à une question. Jusqu’où l’entreprise remonte-t-elle dans le temps après une panne ?
Une horloge permet de le comprendre. Si une sauvegarde est effectuée une fois par jour à deux heures du matin et que le serveur tombe en panne à seize heures, quatorze heures de travail disparaissent. Il ne s’agit pas de données abstraites. Ce sont les commandes reçues ce jour-là, les factures émises, les notes prises lors des échanges téléphoniques avec les clients et les modifications apportées aux fichiers sur lesquels toute l’équipe a travaillé.
Une partie de ce travail peut être reconstituée de mémoire et à partir des documents papier. Une autre ne reviendra jamais, car personne ne se souvient exactement de ce qu’un client a dit au téléphone. Il est donc utile de définir le RPO avec les personnes qui saisissent les données, et pas seulement avec la direction. Ce sont elles qui savent combien de temps prend la ressaisie d’une journée de travail.
Comme le RTO, le RPO varie selon les systèmes. La base de données des commandes et le dossier contenant les photos du pique-nique de l’entreprise n’ont pas besoin de sauvegardes à la même fréquence.
Un exemple simple qui rend le coût concret
Prenons une entreprise qui reçoit ses commandes via son propre système. Vingt personnes l’utilisent et chaque commande entraîne une expédition et une facture. La direction fixe le RPO à une heure et le RTO à quatre heures. Voyons ce que cela implique.
Le RPO détermine la fréquence des sauvegardes et la manière de les effectuer. Une sauvegarde quotidienne ne respecte pas cet objectif, puisqu’elle autorise la perte d’une journée entière. Une sauvegarde toutes les heures suppose une autre façon de travailler avec la base de données, davantage d’espace disque et une sollicitation plus forte de la liaison si les données quittent l’entreprise. Descendre à quelques minutes nécessite généralement une réplication. Une seconde copie du système est alors maintenue à jour en permanence. Chacune de ces trois options a un coût différent et exige un travail de maintenance distinct.
Le RTO détermine sur quelle infrastructure le système sera relancé à partir de ces données. Quatre heures ne suffisent pas pour attendre la livraison d’un serveur et réinstaller le système à partir de zéro. Il faut donc disposer d’un environnement sur lequel redémarrer. Il peut s’agir de ressources libres sur l’hyperviseur existant, d’une machine de secours ou d’un environnement cloud préparé à l’avance. C’est la partie du coût à laquelle personne ne pense généralement, car elle est associée à la sauvegarde alors qu’elle correspond simplement à du matériel et à de l’espace.
Modifier l’un de ces chiffres change la solution et son prix. Un RTO d’une journée permet de restaurer le système sur un nouvel équipement sans urgence. Un RTO d’une heure implique presque toujours un second environnement prêt à prendre le relais. La vraie question n’est donc pas de savoir quelle solution est la meilleure, mais quel chiffre est réellement nécessaire à l’entreprise.
L’erreur la plus fréquente consiste à fixer le RTO sans faire le calcul
Lorsqu’on demande sous quel délai un système doit être rétabli, presque tout le monde répond qu’il doit l’être immédiatement. C’est compréhensible, mais totalement inexploitable, car « immédiatement » est la réponse la plus coûteuse qui soit. Il vaut mieux commencer par calculer une chose. Combien coûte une heure d’indisponibilité à l’entreprise ?
Plusieurs postes entrent dans ce calcul :
- le nombre de personnes qui ne peuvent pas travailler pendant cette période et leur coût horaire
- ce qui ne peut être ni vendu, ni expédié depuis l’entrepôt, ni facturé pendant cette période
- le travail à rattraper par la suite, y compris les heures supplémentaires
- les échéances manquées pendant cette période et les pénalités contractuelles qui en découlent
- le coût des échanges avec les clients informés de l’indisponibilité du système
Le résultat n’a pas besoin d’être exact. Une estimation fiable suffit pour la mettre en regard du coût de la solution. C’est le principe de l’analyse d’impact sur l’activité. Le NIST la décrit comme l’étude des fonctions opérationnelles et des conséquences qu’une interruption pourrait avoir sur elles.
Le résultat de ce calcul réserve souvent la surprise inverse. Pour certains systèmes, il apparaît que l’entreprise peut supporter deux jours d’interruption sans dommage majeur. C’est une très bonne nouvelle, car cela libère du budget pour le système qui, lui, doit être rétabli en une heure.
Une sauvegarde n’est pas encore un plan de continuité d’activité
Une sauvegarde est une copie des données. Un plan de continuité d’activité correspond à la capacité de poursuivre le travail après une panne. Plusieurs éléments font la différence et un logiciel de sauvegarde ne peut pas les fournir à lui seul.
Il faut au minimum ajouter les éléments suivants aux sauvegardes :
- un environnement sur lequel les données peuvent effectivement être remises en service, c’est-à-dire des ressources disponibles, du matériel de secours ou un espace préparé dans le cloud
- l’ordre de restauration des services, car une application restaurée avant sa base de données et avant le système d’authentification ne démarrera tout simplement pas
- les personnes et la procédure, c’est-à-dire qui constate la panne, qui prend la décision et qui appelle qui
- la connectivité et l’accès à distance, si les personnes doivent travailler depuis un autre lieu que d’habitude
- un test, c’est-à-dire une restauration d’essai avec mesure du temps nécessaire, et pas seulement un rapport indiquant qu’une sauvegarde a été effectuée
Cette liste n’a pas été inventée. Le guide du NIST sur la planification d’urgence structure un plan précisément autour de ces éléments : de l’analyse d’impact sur l’activité, en passant par le choix d’un site de secours et la répartition des responsabilités, jusqu’aux tests et à la formation des personnes chargées de mettre ce plan en œuvre.
Le dernier point est le plus important et le plus souvent négligé. Une sauvegarde qui n’a jamais été restaurée n’est qu’une hypothèse. Seule une restauration d’essai montre combien de temps elle prend réellement. C’est aussi lors de cet essai que les lacunes invisibles dans tout rapport de sauvegarde apparaissent le plus facilement, par exemple une dépendance à un autre système ou un mot de passe dont plus personne ne se souvient.
Comment vérifier que le plan existe réellement
Quelques questions permettent de cerner rapidement la situation. Vous pouvez les poser à votre service informatique ou à l’entreprise qui gère l’infrastructure :
- quand des données ont été restaurées pour la dernière fois à partir d’une sauvegarde et combien de temps cela a pris
- sur quel système elles ont été restaurées, car restaurer un fichier sur le même serveur ne prouve rien
- quels RTO et RPO sont définis pour chaque système indispensable au fonctionnement de l’entreprise
- s’il existe une sauvegarde inaccessible depuis le réseau de l’entreprise
- qui décide d’activer le plan un dimanche à cinq heures du matin
Si les réponses indiquent que les sauvegardes sont effectuées et qu’elles font l’objet d’une supervision, l’entreprise dispose d’une sauvegarde. Elle n’a pas encore de plan. Il ne s’agit pas d’un reproche adressé à qui que ce soit, mais simplement d’une indication sur le travail qui reste à accomplir.
Chez C4PL, nous réalisons de véritables tests de restauration. Nous ne nous limitons pas au déploiement et à la maintenance des sauvegardes. Le périmètre de l’assistance, y compris l’astreinte 24 h/24 et 7 j/7, est défini dans le contrat, car il détermine le RTO réellement envisageable la nuit et le week-end.
Par où commencer
Le point de départ, ce ne sont pas les outils. Il faut d’abord dresser la liste des systèmes sans lesquels l’entreprise ne peut pas fonctionner. Elle est généralement plus courte qu’on ne le pense. Pour chacun, on note deux chiffres et une phrase décrivant ce qui se passe lorsque le système est indisponible.
Remplir un tel tableau ne nécessite pas d’audit. Une seule réunion avec les personnes responsables des ventes, de la production, de l’entrepôt et de la comptabilité suffit. La partie technique ne commence qu’ensuite et devient alors bien plus simple, car les exigences à respecter sont claires.
Une fois les deux chiffres définis, il est utile de les consigner par écrit. Tant que RTO et RPO ne sont évoqués qu’oralement, ils restent un souhait. Inscrits dans le contrat avec l’entreprise qui exploite l’infrastructure, ils deviennent un engagement. Ce n’est qu’alors que le délai de prise en charge et le périmètre de l’astreinte peuvent y être adaptés.
Si vous souhaitez examiner ce point avec quelqu’un qui réalise concrètement des tests de restauration, appelez le +48 662 036 615 ou écrivez à [email protected]. Un échange autour de ces deux chiffres prend un quart d’heure et révèle généralement d’emblée où se situe la principale lacune.