Définir le RTO et le RPO d’une application métier : guide pratique de planification

Le RTO et le RPO répondent à deux questions différentes sur la reprise

L’objectif de temps de reprise (RTO) correspond à la durée pendant laquelle un système ou un processus métier peut être indisponible avant que les conséquences deviennent inacceptables. L’objectif de point de reprise (RPO) indique la durée maximale de données récentes que l’entreprise peut accepter de perdre ; il correspond au point dans le temps auquel les données doivent pouvoir être restaurées. [1]

Imaginons qu’une application tombe en panne après la dernière sauvegarde récupérable, effectuée la veille au soir. Le RPO aide à déterminer quelle quantité de travail saisie depuis ce point de reprise pourrait être perdue. Le RTO concerne la durée pendant laquelle l’entreprise peut tolérer l’indisponibilité de l’application, le temps qu’elle soit restaurée et de nouveau utilisable. [2]

Ces objectifs sont liés, mais l’un ne détermine pas l’autre. Une entreprise peut avoir besoin de remettre rapidement une application en service tout en pouvant reconstituer une partie des données récentes. À l’inverse, elle peut tolérer une interruption plus longue, mais avoir très peu de marge concernant la perte de transactions.

Commencez par le flux de travail métier, pas par le serveur

Avant de parler des objectifs de reprise, dressez la liste des tâches prises en charge par l’application. Un CRM peut soutenir les ventes et le service client ; une boutique en ligne peut prendre en charge la consultation des produits, les commandes et le traitement des paiements. La question essentielle est de savoir ce que les utilisateurs ne peuvent plus faire lorsque l’application est indisponible ou que ses données ne sont pas à jour.

Pour chaque flux de travail, déterminez qui est concerné, si le travail s’arrête complètement et quelles solutions de remplacement existent. Le personnel pourrait, par exemple, consigner temporairement les demandes dans un autre système approuvé. Mais cette solution de contournement peut être lente, limitée ou inadaptée à certaines données.

Une bonne première étape consiste à réaliser une brève analyse d’impact métier : recensez les processus essentiels, les systèmes dont ils dépendent et les conséquences d’une interruption. Faites participer les personnes qui effectuent le travail, et pas uniquement la personne responsable de l’application. [1]

• Nommez le flux de travail et les fonctionnalités de l’application dont il dépend.
• Identifiez le personnel, les clients ou les partenaires concernés en cas d’interruption.
• Consignez les procédures manuelles ou de remplacement, leurs limites et les personnes autorisées à les approuver.
• Précisez quelles activités métier doivent reprendre en premier.

Évaluez l’impact d’une interruption sur différentes durées

Ne choisissez pas un RTO simplement parce qu’un chiffre particulier semble rassurant. Évaluez les conséquences d’une interruption sur plusieurs durées : par exemple, une courte panne, une partie de la journée de travail ou une perturbation plus longue. Les intervalles appropriés dépendent du fonctionnement de l’entreprise.

Tenez compte des ventes perdues, des engagements de service non respectés, du personnel empêché de travailler, des décisions retardées et des clients susceptibles de se tourner vers un autre fournisseur. Demandez-vous à partir de quand l’impact cumulé dépasse ce que l’entreprise peut absorber. Ce seuil aide à définir un objectif de RTO ; il ne prouve pas que la reprise sera achevée à temps. [2]

Distinguez le temps nécessaire pour rétablir l’accès technique du temps nécessaire pour reprendre le processus métier. Une application peut être opérationnelle alors que le personnel doit encore vérifier les dossiers, confirmer les accès ou résorber un retard.

• Décrivez les conséquences d’une interruption pour chaque intervalle choisi.
• Tenez compte des perturbations opérationnelles autant que des effets financiers directs.
• Déterminez à quel moment une solution de contournement cesse d’être acceptable.
• Définissez ce que signifie « reprise » pour le flux de travail, et pas seulement pour le serveur.

Définissez le RPO en examinant quelles données peuvent être reconstituées

Pour chaque flux de travail, identifiez les enregistrements créés ou modifiés dans le cadre du travail habituel et demandez-vous dans quelle mesure ces informations pourraient être reconstituées après un incident. Un catalogue de produits peut être récupérable à partir d’une autre source, tandis que des commandes récentes, des paiements ou des mises à jour de données clients peuvent être difficiles, voire impossibles, à reconstituer fidèlement. [2]

La quantité de données récentes que l’entreprise peut accepter de perdre peut varier d’une partie à l’autre d’une même application. Examinez les conséquences d’une ressaisie du travail récent et demandez-vous si elle serait complète, rapide et sûre. Tenez compte du risque de doublons ou d’incohérences si des personnes utilisent une solution de contournement pendant l’interruption.

Formulez le RPO comme une tolérance métier à la perte de données — autrement dit, la durée maximale de données récentes susceptibles d’être perdues — et non comme une supposition sur la fréquence des sauvegardes. Vérifiez ensuite si les dispositifs de reprise respectent cette tolérance.

• Répertoriez les données importantes pour chaque flux de travail, notamment les transactions, les fichiers téléversés et les modifications apportées aux enregistrements existants.
• Classez chaque élément selon qu’il est facile, difficile ou impossible à reconstituer.
• Demandez-vous quelle quantité de travail récent pourrait être refaite sans entraîner de coûts, de confusion ou de risques inacceptables.
• Consignez, pour chaque flux de travail, la durée maximale de données récentes dont la perte serait acceptable.

Cartographiez les dépendances nécessaires à la reprise

Une application n’est qu’une composante du service. La planification de la reprise doit inclure les technologies et services auxiliaires qui influent sur le processus métier, même s’ils ne sont généralement pas considérés comme critiques à eux seuls. [3]

Suivez le parcours de l’utilisateur qui accomplit la tâche. Selon l’application, ce parcours peut faire intervenir une base de données, des fichiers téléversés, l’identité ou l’authentification, le DNS, le routage, des certificats TLS, la messagerie ou d’autres services externes. Vérifiez quelles dépendances sont essentielles, qui les gère et quelles étapes doivent être terminées avant que les utilisateurs puissent reprendre leur travail.

Pensez également aux intégrations et aux partenaires externes. Une application restaurée peut ne pas permettre de reprendre le flux de travail si un service connecté essentiel est indisponible ou si sa connexion nécessite une intervention. [3]

• Répertoriez l’application, la base de données et les fichiers nécessaires au flux de travail.
• Incluez, le cas échéant, les dépendances liées à l’accès, aux noms de domaine et aux connexions.
• Consignez les services externes et les partenaires dont dépend l’application.
• Désignez un responsable ou un contact pour chaque dépendance et indiquez l’ordre de reprise.

Définissez des objectifs distincts lorsque la criticité métier varie

Attribuer le même RTO et le même RPO à toutes les applications peut masquer des différences importantes. Définissez les objectifs pour chaque application ou flux de travail en fonction de son impact métier, de sa tolérance à la perte de données et des solutions de remplacement disponibles. [4]

Par exemple, le flux de travail qui reçoit les commandes des clients peut nécessiter une reprise différente de celle d’un processus interne de génération de rapports qui utilise la même application. Consignez la raison de chaque différence afin que les objectifs reflètent les priorités métier, plutôt qu’un classement informel des logiciels.

Lorsque plusieurs flux de travail dépendent d’une application, indiquez lequel détermine la priorité de reprise. Veillez à ce que les responsables de ces flux de travail approuvent les objectifs proposés.

• Regroupez les applications ou les flux de travail selon leur impact métier, et pas uniquement pour des raisons de commodité technique.
• Attribuez un RTO et un RPO à chaque groupe ou cas d’usage pertinent.
• Expliquez les raisons métier de chaque objectif.
• Examinez les conflits lorsqu’une application sert des flux de travail ayant des priorités différentes.

Vérifiez que les objectifs sont réalisables

Un objectif n’est utile que si le mode de déploiement choisi et les dispositifs de reprise peuvent raisonnablement le respecter. Comparez chaque objectif aux moyens concrets de restaurer l’application et ses données. Tenez compte des dépendances, du temps nécessaire à la prise de décision, de l’accès aux procédures de reprise et des vérifications nécessaires pour confirmer que le service restauré est opérationnel.

Ne supposez pas qu’une fréquence de sauvegarde équivaut à un RPO, ni que la disponibilité d’une sauvegarde prouve qu’un RTO peut être respecté. L’organisation doit comprendre ce que couvre la reprise, comment les données et services nécessaires sont restaurés et comment l’état opérationnel est confirmé.

Airbip gère le déploiement d’applications répertoriées sous forme de charges de travail Docker sur ses serveurs cloud, automatise le routage et les certificats TLS avec Traefik et Let’s Encrypt, et fournit des vérifications DNS, la gestion du cycle de vie des services ainsi que des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces fonctionnalités ne garantissent pas qu’un RTO ou un RPO particulier sera atteint. Consultez les détails du service en vigueur et les besoins de reprise propres à votre application avant de décider si cette solution vous convient.

Si les dispositifs de reprise ne permettent pas de respecter les objectifs proposés, revoyez les objectifs, la solution de contournement métier ou l’approche de déploiement. Ne présentez pas un objectif non testé comme une garantie. [5]

• Vérifiez quelles données et dépendances sont couvertes par le dispositif de reprise.
• Vérifiez comment la reprise est déclenchée et qui dispose des accès et de l’autorité nécessaires.
• Comparez le calendrier des sauvegardes et les procédures de restauration aux objectifs RPO et RTO.
• Repérez les lacunes, les hypothèses et les décisions à valider avant de vous fier aux objectifs.

Transformez les objectifs en un plan de reprise attribué et testé

Ne vous contentez pas de consigner le RTO et le RPO. Un plan pratique précise qui décide du déclenchement de la reprise, qui exécute chaque étape, qui vérifie que l’application est utilisable et qui communique avec le personnel, les clients ou les partenaires. [6]

Définissez clairement les étapes de décision : comment un incident est détecté, qui est autorisé à déclarer une interruption, à quel moment une solution de contournement doit être utilisée et quelles vérifications sont nécessaires avant la reprise normale du travail. Indiquez l’ordre de restauration des dépendances et la manière de traiter le travail effectué pendant l’interruption.

Testez le plan et consignez les résultats. Un objectif de reprise est une cible à valider, et non la preuve que la reprise l’atteindra. Les exercices peuvent révéler des responsabilités mal définies, des accès manquants, des dépendances oubliées ou un écart entre l’objectif annoncé et la procédure de reprise. [5]

Après un test ou une interruption réelle, mettez à jour les objectifs et les procédures si nécessaire. L’évolution des flux de travail, de l’importance des données, des intégrations ou des modalités d’exploitation peut rendre un ancien plan de reprise inexact.

• Désignez une personne décisionnaire, les responsables de la reprise et les responsables des communications.
• Rédigez les étapes de reprise et l’ordre des dépendances dans un langage que les intervenants peuvent suivre.
• Définissez les vérifications permettant de confirmer que le service et le flux de travail métier sont utilisables.
• Testez le plan, consignez les résultats et suivez les lacunes non résolues.
• Réexaminez les objectifs lorsque les processus métier ou les dépendances de l’application changent.