Définir les RTO, RPO et niveaux de reprise

La planification de la continuité d’activité (BCP) est le processus qui vise à garantir que les fonctions essentielles d’une entreprise puissent se poursuivre pendant et après un sinistre. Dans le cloud, cela consiste à concevoir des systèmes capables de récupérer après des défaillances dans des limites acceptables de durée et de perte de données. Deux indicateurs clés — RTO et RPO — définissent ce qui est « acceptable » pour chaque charge de travail.

L’objectif de délai de Recovery (RTO) correspond à la durée maximale acceptable pendant laquelle un système peut rester hors ligne après un sinistre. Il répond à la question suivante : « Combien de temps l’entreprise peut-elle tolérer que cette application soit indisponible ? ». Le RTO s’exprime en heures, en minutes ou en secondes. Un système de traitement des Payment peut avoir un RTO de 15 minutes, tandis qu’un portail HR interne peut avoir un RTO de 24 heures.

L’objectif de point de Recovery (RPO) correspond à la quantité maximale acceptable de données perdues, mesurée en durée. Il répond à la question suivante : « Quelle quantité de données l’entreprise peut-elle se permettre de perdre ? ». Si le RPO est d’une heure, l’entreprise accepte de perdre jusqu’à une heure de transactions. Le RPO détermine la fréquence à laquelle vous devez sauvegarder ou répliquer les données. Un RPO de 0 nécessite une réplication synchrone, qui est coûteuse et peut réduire les performances d’écriture.

Il est important de ne pas confondre RTO et RPO :

• RTO concerne le temps — la durée pendant laquelle le système est indisponible
• RPO concerne les données — la quantité de données perdue

Un système peut avoir un RTO court (Recovery rapide), mais un RPO long (acceptation d’une perte de données importante), ou l’inverse. L’idéal est que les deux soient courts, mais cela nécessite des investissements importants dans la réplication et la capacité de secours à chaud.

Toutes les charges de travail n’ont pas le même niveau de criticité. Une approche courante consiste à les classer en niveaux de Recovery selon leur impact sur l’activité :

• Niveau 1 (critique pour la mission) — RTO/RPO stricts, coût maximal (par exemple, Payment, plateformes de négociation)
• Niveau 2 (critique pour l’activité) — RTO/RPO modérés (par exemple, CRM, ERP)
• Niveau 3 (non critique) — RTO/RPO souples, coût minimal (par exemple, environnements de développement, archives)

Différents niveaux de Recovery correspondent à différentes fonctionnalités Azure :

• Niveau 1 — écritures multi-régions Cosmos DB, groupes de basculement automatique SQL, architecture active-active, Traffic Manager
• Niveau 2 — Azure Site Recovery vers une région secondaire, géoréplication SQL (réplica en lecture), sauvegardes quotidiennes conservées pendant 30 jours
• Niveau 3 — Azure Backup avec des planifications hebdomadaires, aucune réplication, restauration à partir d’un instantané

Pour justifier l’investissement dans une architecture à RTO faible, calculez le coût d’indisponibilité de la charge de travail. Cela inclut la perte de Revenue, les pénalités SLA versées aux clients, la perte de productivité du Staff et l’atteinte à la réputation. Si une heure d’indisponibilité coûte 500 000 $, dépenser 50 000 $ par mois pour une configuration active-active est facilement justifiable. Utilisez ces chiffres pour élaborer un dossier métier en faveur du niveau de Recovery approprié.

Azure Site Recovery (ASR) est le service Primary permettant d’atteindre les objectifs de RTO/RPO du niveau 2 sur Azure. ASR réplique en continu les VMs vers une région secondaire et peut lancer un basculement en quelques minutes. La fréquence de réplication des VMs Azure est de 30 secondes (cohérente après incident) ou de 1 à 4 heures (cohérente avec l’application), ce qui fournit généralement un RPO situé dans cette plage, selon la Configuration.

Pour les charges de travail dont le RPO se mesure en heures, Azure Backup avec une planification appropriée est suffisant. Par exemple, un RPO de 4 heures nécessite un intervalle de sauvegarde d’au moins 4 heures. Azure Backup prend en charge des stratégies améliorées qui permettent des planifications de sauvegarde toutes les heures pour les VMs Azure. Pour les bases de données, une restauration à un instant donné (PITR) avec des sauvegardes des journaux de transactions peut atteindre un RPO inférieur à une heure, à moindre coût qu’ASR.

Les objectifs RTO et RPO doivent être documentés officiellement dans une analyse d’impact sur l’activité (BIA) et examinés par les parties prenantes techniques et métier. La BIA associe chaque application à son niveau de Recovery, documente les objectifs RTO/RPO, identifie les services Azure qui permettront de les atteindre et précise la planification des tests (la fréquence à laquelle le plan de DR est validé au moyen d’exercices).

Les objectifs RTO et RPO restent théoriques tant qu’ils n’ont pas été validés par des tests de DR. Lors d’un test de DR, mesurez le temps réel nécessaire à la Recovery (respecte-t-il le RTO défini ?) ainsi que la perte réelle de données au point de Recovery (respecte-t-elle le RPO défini ?). Si le test révèle des écarts, mettez à jour l’architecture ou les procédures jusqu’à ce que les objectifs soient atteints de manière constante. Documentez les résultats des tests pour les audits de conformité.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le RTO correspond à la durée maximale d’indisponibilité acceptable, tandis que le RPO correspond à la perte maximale de données acceptable mesurée en durée ; que les charges de travail sont classées en niveaux de Recovery associés à des services Azure spécifiques ; et que les tests sont essentiels pour vérifier que les objectifs RTO/RPO peuvent être atteints. Nous allons maintenant étudier les plans de Recovery et le basculement automatisé avec Azure Site Recovery.