L’objectif de temps de reprise est une décision, pas un réglage
L’objectif de temps de reprise dit combien de temps un système peut rester à l’arrêt avant que cela devienne inacceptable. Ce n’est pas un chiffre qui sort de la technique : il vient du métier, et la technique se construit ensuite autour.
Deux chiffres, deux questions
On les cite ensemble et ils mesurent autre chose. Les confondre, c’est acheter la mauvaise solution.
Objectif de temps de reprise et objectif de point de reprise
Le RTO parle de temps sans système. Le RPO parle de travail perdu. Les deux coûtent de l’argent, à des endroits différents.
- RTO : combien de temps avant que cela remarcheMesuré du moment où cela lâche au moment où l’utilisateur peut continuer. Y compris le temps nécessaire pour décider qu’on restaure : cette part est oubliée dans presque toutes les estimations et se révèle souvent la plus longue.
- RPO : combien de travail peut disparaîtreLa distance entre la dernière copie exploitable et l’instant de la panne. Un RPO d’une nuit signifie qu’une journée entière peut être à refaire. Pour certains systèmes c’est acceptable ; pour la gestion des commandes, rarement.
- Ils actionnent des leviers différentsUn RTO plus court demande d’être prêt : un environnement en attente, des personnes capables de basculer. Un RPO plus court demande de copier plus souvent ou en continu. On peut les choisir séparément, et c’est en général plus sage.
- Ils se fixent par systèmeUn RTO unique pour toute l’organisation conduit à surinvestir là où ce n’est pas nécessaire et à manquer là où ça l’est. La liste peut être courte, mais elle est par système.
Comment arriver à un RTO qui tient
Quatre étapes. La première est la seule qui ne parle pas d’informatique, et elle décide des autres.
Posez la question au processus, pas à l’informatique
Que devient le travail sans ce système : il ralentit, il passe en manuel, ou il s’arrête. Seule cette troisième réponse justifie un RTO court, et elle le justifie alors facilement.
Chiffrez ce que fait une heure d’arrêt
Non pas en montant générique mais dans vos propres unités : commandes qui n’entrent pas, personnes qui attendent, livraisons décalées, engagements non tenus. Ce chiffre rend soudain très courte la discussion sur le coût de la reprise.
Mesurez ce que vous obtenez aujourd’hui
Restaurez une fois un système sur un environnement séparé et chronométrez. Presque toute première mesure déçoit, et c’est le chiffre le plus utile de l’exercice : le seul qui ne soit pas une estimation.
Choisissez, et notez ce que le choix coûte
Entre le RTO souhaité et le RTO mesuré il y a un écart, et cet écart se paie ou s’accepte. Les deux réponses se défendent ; ne pas l’écrire ne se défend pas, car le choix n’apparaît alors que pendant la panne.
Pourquoi un RTO n’est pas tenu en pratique
Quatre causes que nous retrouvons sans cesse, et aucune ne se trouve dans le logiciel de sauvegarde.
- L’horloge avait démarré plus tôtLa détection et la décision comptent. S’il faut une heure avant que quelqu’un comprenne que c’est sérieux et une autre avant que quelqu’un puisse décider, la moitié d’un RTO de quatre heures est partie avant que rien ne commence.
- La restauration n’a jamais été exécutéeUne sauvegarde qui réussit n’est pas une restauration qui réussit. Certificats manquants, licences liées au matériel et liaisons externes n’apparaissent qu’au moment de remettre en place.
- Vouloir tout ramener en même tempsSans ordre, le RTO de chaque système devient celui du plus lent. Un ordre convenu à l’avance supprime la discussion au moment où il n’y a pas de temps pour elle.
- Personne n’était d’astreinteLa technique était prête, les personnes non. Qui promet un RTO court devrait dire qui le tient un dimanche matin, et c’est précisément là qu’un prestataire fait la différence.
Pour aller plus loin
Ce à quoi cela se rattache.
Les questions qu’on nous pose
Celles qui reviennent le plus, en bref.
Que signifie exactement objectif de temps de reprise ?
Le temps qui peut s’écouler entre la panne d’un système et le moment où l’utilisateur peut continuer. Y compris le temps nécessaire pour s’apercevoir du problème et décider de restaurer, la part que presque toutes les estimations oublient.
Quelle est la différence entre RTO et RPO ?
Le RTO regarde vers l’avant : combien de temps avant que cela remarche. Le RPO regarde vers l’arrière : combien de travail est perdu depuis la dernière copie exploitable. Un RTO plus court demande d’être prêt, un RPO plus court de copier plus souvent.
Comment savoir quel RTO nous atteignons aujourd’hui ?
En restaurant un système sur un environnement séparé et en le chronométrant. C’est le seul chiffre de tout l’exercice qui ne soit pas une estimation, et presque toute première mesure déçoit.
Mesurer ce que vous obtenez aujourd’hui ?
Restaurer un système sur un environnement séparé et laisser tourner le chronomètre. C’est le chemin le plus court vers un RTO qui ne soit pas une estimation, et en général vers la première surprise.
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.