Fixer et tester le RTO et le RPO

Définir deux objectifs distincts

Le Recovery Time Objective (RTO) fixe la durée maximale acceptable d’interruption avant le retour d’un service utile. Le Recovery Point Objective (RPO) fixe la perte maximale acceptable de données, mesurée en temps. Convenez de ces objectifs avec le responsable métier pour un service et un scénario de défaillance définis.

Un objectif de disponibilité décrit les performances du service sur une période. Le RTO et le RPO décrivent les attentes de reprise. Ils répondent à des questions différentes.

Pour un service de commandes fictif, le responsable fixe un RTO de 60 minutes et un RPO de 15 minutes. Ce sont des exemples, pas des recommandations générales. Un autre service peut nécessiter d’autres limites, car des commandes manquantes et des rapports retardés n’ont pas les mêmes conséquences.

Mesurer la reprise complète

Le service s’arrête à 10:00. L’équipe consigne cet exercice :

La durée totale de reprise est de 55 minutes. L’exercice respecte le RTO de 60 minutes. Compter uniquement les 25 minutes de restauration masquerait la majeure partie de l’interruption.

Le dernier point de restauration utilisable est 09:40. L’écart avec l’interruption de 10:00 est de 20 minutes. Il dépasse le RPO de 15 minutes de 5 minutes. Restaurer les mêmes données plus vite ne réduirait pas cet écart.

Examinez les enregistrements réellement manquants ou incohérents. Un écart temporel décrit l’exposition ; il ne compte pas les commandes touchées. Rapprochez les enregistrements externes de paiement et d’exécution des commandes avant de reprendre le traitement normal. Testez d’autres hypothèses dans l’exercice de reprise.

Choisir une stratégie de reprise

Une stratégie doit couvrir le service, les données et les dépendances nécessaires. Comparez ces modèles aux objectifs mesurés :

Ces modèles n’ont pas de temps de reprise universels. L’implémentation, le volume de données, les dépendances et les conditions de test déterminent le résultat. Incluez le coût d’exploitation et les capacités de l’équipe dans la décision.

Se protéger contre autre chose qu’une panne

Un réplica peut copier une suppression indésirable ou un enregistrement corrompu. Conservez des versions récupérables ou prévoyez une restauration à un instant donné lorsque cela est nécessaire. Vérifiez la conservation, les permissions de restauration et l’accès aux clés de chiffrement. Adaptez l’isolation des sauvegardes au scénario, y compris à la perte d’accès au compte principal.

Pour une reprise régionale, vérifiez l’emplacement autorisé des données et toute la chaîne de dépendances. Incluez l’identité, le DNS, les certificats, les secrets, les artefacts de déploiement, les quotas et l’accès réseau. Un environnement de reprise auquel il manque une seule clé nécessaire peut être inutilisable.

Définissez qui peut déclarer l’événement, qui exécute la reprise et qui accepte le service restauré. Préparez le retour vers l’environnement initial ou la poursuite de l’exploitation dans l’environnement de reprise. Empêchez les écritures concurrentes contradictoires et réconciliez les données avant un nouveau basculement.

Transformer le plan en preuves

Rédigez un runbook et testez-le dans des conditions contrôlées. Consignez le scénario, la taille du jeu de données, les heures de début et de fin, le point de restauration des données, les étapes échouées et les responsables. Vérifiez une opération métier réelle avec des enregistrements de test sans danger.

Répétez l’exercice après les changements pertinents et selon le calendrier convenu. Un changement de schéma, une nouvelle dépendance externe ou un autre volume de données peut invalider les résultats antérieurs. Reliez les preuves de l’exercice à la livraison et aux responsabilités d’exploitation.