PlanContinuiteActivite
Ce sont les notions de base de la continuité d'activité informatique.
PCA et PRA
Le PCA (Plan de Continuité d'Activité) vise à ce que le service continue de fonctionner malgré un incident, avec peu ou pas d'interruption. On y parvient par la redondance : deux sites actifs en parallèle, des clusters, de la bascule automatique. L'utilisateur ne s'aperçoit presque de rien.
Le PRA (Plan de Reprise d'Activité) s'applique quand le service est interrompu : il décrit comment le redémarrer, sur un site de secours ou après reconstruction, et en combien de temps. Il y a une coupure, mais elle est maîtrisée et limitée.
On peut résumer ainsi : le PCA évite la coupure, le PRA organise le retour après la coupure. Un même SI combine souvent les deux, selon la criticité de chaque application.
RTO et RPO
Ce sont les deux chiffres qui définissent le niveau de protection attendu.
Le RTO (Recovery Time Objective) est la durée maximale d'interruption acceptable. Un RTO de 4 heures signifie que l'application doit être de nouveau disponible au plus tard 4 heures après le sinistre.
Le RPO (Recovery Point Objective) est la quantité maximale de données que l'on accepte de perdre, exprimée en temps. Un RPO de 15 minutes signifie qu'à la reprise, on doit retrouver les données telles qu'elles étaient au plus 15 minutes avant l'incident. Il dépend de la fréquence des sauvegardes ou de la réplication : une sauvegarde nocturne donne un RPO de 24 heures, une réplication synchrone donne un RPO proche de zéro.
Plus ces valeurs sont basses, plus la solution coûte cher (réplication, second site, bascule automatisée). Elles se fixent donc application par application, avec les métiers : la paie peut tolérer une journée d'arrêt, la caisse en magasin non.
Pourquoi « réalistes » et « sur des bases concrètes »
Dans beaucoup d'entreprises, les RTO/RPO sont écrits dans un document mais jamais vérifiés. On affiche « RTO 2 heures » alors que la restauration réelle de la base prend 6 heures, que l'annuaire dont dépend l'application n'est pas dans le plan, ou que personne n'a retesté la sauvegarde depuis un an.
Voir le SI depuis le data center permet de les rendre réalistes :
- On identifie les dépendances réelles (stockage, réseau, DNS, annuaire, hyperviseurs). Une application « critique » qui dépend d'un composant non protégé ne tiendra pas son RTO.
- On mesure les durées effectives de restauration et de redémarrage, au lieu de les estimer.
- Quand l'infrastructure est décrite en code, reconstruire un environnement devient une procédure répétable et testable, ce qui rend le RTO crédible.
- On teste régulièrement (exercices de bascule, restauration à blanc), car un plan jamais testé est une hypothèse, pas un plan.
Autrement dit, des RTO/RPO réalistes sont ceux que l'on a démontrés par des tests, en tenant compte de toute la chaîne technique, et pas seulement de l'application elle-même.
Backlinks: