Haute disponibilité et reprise après sinistre : calculs, RTO, RPO et stratégies de PRA

On parle souvent de deux disciplines comme s'il n'y en avait qu'une. La haute disponibilité consiste à survivre aux pannes auxquelles on s'attend — une machine qui meurt, un disque plein, un data center privé de courant — sans intervention humaine et sans que les utilisateurs s'en aperçoivent vraiment. La reprise après sinistre traite des événements que l'on ne peut pas absorber sur place : une panne à l'échelle d'une région, une base de données corrompue et répliquée partout, un compte compromis dont les ressources ont été supprimées. Les deux reposent sur des mécanismes différents, ne coûtent pas le même prix et échouent de façons différentes ; un système peut exceller dans l'une et être totalement démuni dans l'autre.

Ce guide commence par le calcul, parce qu'un objectif de disponibilité fixé sans lui n'est qu'un vœu pieux. Il aborde ensuite les domaines de défaillance, les patterns de redondance qui améliorent la disponibilité, les objectifs de reprise qui définissent la reprise après sinistre, les quatre stratégies de reprise classiques et leur économie, et enfin les tests sans lesquels on ne peut rien affirmer de tout cela.

Le calcul de la disponibilité

La disponibilité est le temps de fonctionnement divisé par le temps total, exprimée par convention en nombre de « 9 ». Ce qui compte, c'est la marge d'indisponibilité qu'elle autorise.

Quatre 9 autorisent moins de cinq minutes d'indisponibilité par mois — moins que le temps nécessaire pour réveiller quelqu'un et lui faire ouvrir son ordinateur portable. Tout ce qui vise ce niveau ou au-delà doit se rétablir sans intervention humaine, et c'est une affirmation d'architecture, pas d'exploitation.

Les composants en série — tous nécessaires pour qu'une requête aboutisse — se multiplient. Un load balancer, une couche applicative, un cache et une base de données, chacun à 99,99 % de façon indépendante, donnent 0,9999⁴ ≈ 99,96 %, soit environ trois heures et demie par an, avant même de compter vos propres bugs et déploiements. Chaque dépendance ajoutée abaisse le plafond.

Les composants redondants en parallèle multiplient au contraire leurs probabilités de défaillance. Deux instances disponibles chacune à 99 % ne tombent en même temps que 1 % × 1 % du temps, ce qui donne 99,99 % — à condition que les pannes soient indépendantes. Toute la démonstration repose sur cette réserve, et elle est généralement fausse.

Domaines de défaillance et pannes corrélées

Un domaine de défaillance est un ensemble de ressources susceptibles de tomber en panne ensemble. Savoir les nommer est la compétence essentielle, car la redondance n'aide que si les copies se trouvent dans des domaines différents.

La hiérarchie physique va du processus à l'hôte, puis à la baie, au data center, à la zone de disponibilité et à la région. Les fournisseurs exposent la zone comme l'unité de placement, et répartir les instances sur plusieurs zones est la défense standard contre un incident de data center.

Les domaines qui provoquent réellement des incidents sont pourtant rarement physiques :

• Les dépendances partagées. Trois instances dans trois zones derrière un seul load balancer, qui lisent toutes une seule base de données dans une seule zone. Le domaine, c'est la base.
• Le control plane. Les API de provisionnement, l'autoscaling et l'IAM sont des services régionaux. Lors d'un incident régional d'ampleur, les API mêmes dont vous avez besoin pour lancer de la capacité de remplacement sont celles qui sont dégradées. Les chemins de reprise qui exigent de créer de nouvelles ressources sont plus fragiles que ceux qui se contentent de déplacer le trafic vers des ressources existantes — c'est ce qu'on appelle être statiquement stable (statically stable).
• La configuration et le déploiement. La cause la plus fréquente de panne corrélée est un changement appliqué partout à la fois : un mauvais push de configuration, une migration de schéma, un certificat expiré déployé par la même automatisation sur chaque réplica. La redondance ne protège de rien ici ; un déploiement progressif, si.
• La capacité et les quotas. Un failover qui double la charge dans la zone survivante ne réussit que si celle-ci disposait de capacité de réserve. Déployer sur deux zones en dimensionnant chacune pour exactement la moitié du trafic garantit une dégradation dès que l'une tombe.
• Le sort partagé dans le logiciel. Toutes les instances qui exécutent le même code rencontrent la même fuite mémoire au même temps de fonctionnement, et le même message empoisonné fait planter chaque consommateur.

Deux patterns limitent les dégâts corrélés. L'architecture cellulaire (cell-based architecture) répartit les utilisateurs entre des cellules indépendantes, chacune dotée d'une pile complète, si bien qu'une cellule défaillante n'affecte qu'une fraction connue des clients. Le shuffle sharding attribue à chaque client un sous-ensemble aléatoire de workers, de sorte qu'un tenant abusif fait rarement tomber un autre client.

RTO et RPO

La reprise après sinistre se définit par deux chiffres, et tous deux sont des décisions métier que l'ingénierie met en œuvre.

Le RTO (recovery time objective, durée maximale d'interruption admissible) est le délai maximal acceptable entre le sinistre et le rétablissement du service. Le RPO (recovery point objective, perte de données maximale admissible) est la quantité maximale de données que l'on accepte de perdre, exprimée en temps : un RPO de quinze minutes signifie que perdre les quinze dernières minutes d'écritures est tolérable.

Déduisez-les de l'impact, pas des ambitions. Demandez ce que l'organisation perd par heure d'interruption — chiffre d'affaires, pénalités réglementaires, avoirs contractuels, atteinte à la réputation — et ce que coûte la ressaisie des transactions perdues. Mettez en regard le coût de l'indisponibilité et le coût de la protection : la cible raisonnable se situe près de leur point de rencontre, pas à zéro. Demander à un responsable métier « quelle indisponibilité est acceptable ? » vous vaudra toujours « aucune » ; demandez plutôt « que feriez-vous pendant quatre heures sans ce système ? ».

Hiérarchisez le parc applicatif par niveaux. Un chemin d'autorisation de paiement peut exiger un RTO de quelques minutes et un RPO proche de zéro ; un outil de reporting interne peut s'accommoder d'une journée pour chacun. Appliquer partout le niveau le plus strict est le moyen le plus sûr de rendre la reprise après sinistre inabordable, et donc de ne jamais la construire.

Patterns de redondance pour la haute disponibilité

Au sein d'une région, les briques de base sont bien connues.

Des couches stateless réparties sur plusieurs zones. Placez des instances dans au moins trois zones derrière un load balancer, dans un groupe d'autoscaling dont le minimum survit à la perte d'une zone. Dimensionnez chaque zone pour que les survivantes absorbent la part de la zone défaillante : avec trois zones, cela représente environ 50 % de marge, contre les 100 % qu'exigent deux zones.

Des health checks qui ont un sens. Un check qui renvoie 200 tant que le processus est vivant continue d'envoyer du trafic vers une instance incapable de joindre sa base de données ; un check qui échoue dès qu'une dépendance est injoignable peut retirer toute la flotte lors d'un simple incident passager. Utilisez un check superficiel pour le load balancer et un check plus approfondi pour les alertes et les points de contrôle de déploiement.

Timeouts, retries avec jitter et circuit breakers. Des retries sans backoff exponentiel ni jitter aléatoire transforment un bref ralentissement d'une dépendance en déni de service auto-infligé. Un circuit breaker qui s'ouvre au-delà d'un seuil d'échecs et laisse passer quelques requêtes de sonde donne à la dépendance le temps de se rétablir. Les bulkheads — des pools de connexions distincts par dépendance — empêchent un service aval lent d'épuiser les ressources dont toutes les autres requêtes ont besoin.

La dégradation élégante. Décidez à l'avance de ce que fait le système sans chacune de ses dépendances. Servir des prix en cache périmés, mettre des écritures en file d'attente pour les traiter plus tard, ou désactiver les recommandations tout en gardant le tunnel de commande opérationnel : tout cela vaut mieux qu'une page d'erreur, et doit être conçu, pas improvisé.

Des services de données managés multi-zones. Le stockage objet et les files d'attente managées sont déjà redondants entre zones. Les bases de données relationnelles proposent en général un standby synchrone dans une deuxième zone avec failover automatique, plus des read replicas asynchrones. Sachez lesquels de vos stockages répliquent de façon synchrone : c'est ce qui sépare une perte de données nulle d'une perte non nulle.

Les quatre stratégies de reprise après sinistre

Entre régions, quatre patterns couvrent la quasi-totalité des besoins. Le coût augmente à chaque étape, et le temps de reprise diminue.

Backup and restore. Les sauvegardes et les snapshots sont copiés dans une deuxième région ; rien n'y tourne tant qu'on n'en a pas besoin. L'infrastructure est recréée à partir de templates et les données restaurées depuis la dernière copie. Le RPO équivaut à l'intervalle entre deux sauvegardes, le RTO va de quelques heures à une journée, et le coût permanent se limite au stockage. C'est le bon choix pour la plupart des systèmes internes, et la seule stratégie qui protège aussi contre la corruption logique — c'est pourquoi toutes les autres l'intègrent également.

Pilot light. La couche de données est répliquée en continu vers la deuxième région et maintenue active, tandis que la couche de calcul existe sous forme de templates et d'images mais tourne à capacité nulle ou quasi nulle. Reprendre, c'est faire monter en charge la couche de calcul et promouvoir le réplica. Le RPO se compte en secondes ou en minutes, le RTO en dizaines de minutes, et le coût permanent correspond aux données répliquées plus une petite empreinte toujours active.

Warm standby. Une copie complète mais réduite de l'environnement tourne en permanence dans la deuxième région, sans trafic ou avec une part symbolique. Le failover consiste à déplacer le trafic puis à monter en charge. Le RPO se compte en secondes, le RTO en minutes, et le coût est nettement plus élevé — couramment entre un quart et la moitié de la production, selon le degré de réduction. L'avantage décisif est que le standby tourne : ses déploiements, ses certificats et ses permissions sont exercés en continu au lieu d'être découverts à 3 h du matin.

Multi-site active-active. Les deux régions servent le trafic de production derrière une couche de routage globale. Le RTO tend vers zéro, le RPO dépend du modèle de réplication, et le coût est au moins doublé. C'est la seule option qui apporte aussi un gain de latence régional, et elle vous oblige à traiter la résolution des conflits, l'identité globale et la compatibilité simultanée des schémas. Le vrai prix, c'est la complexité ; la facture d'infrastructure en est la plus petite part.

Le failover de la base de données commande le délai de reprise

Dans presque toutes les reprises, la couche stateless est triviale et c'est la base de données qui fixe le chrono.

La réplication synchrone ne valide une écriture sur le primaire qu'une fois qu'un standby l'a acquittée : aucune perte de données, au prix d'une latence proportionnelle à la distance. Elle est praticable entre zones et généralement impraticable entre régions éloignées. La réplication asynchrone acquitte localement et transmet les changements ensuite, si bien que le RPO inter-régions équivaut au retard de réplication — qui doit faire l'objet d'une alarme, car il grossit en silence lors des pics d'écriture et des transactions longues.

La promotion est le moment dangereux. Une promotion automatique entre régions expose au split brain : une partition réseau convainc le secondaire que le primaire est mort alors que celui-ci continue d'accepter des écritures, ce qui laisse deux historiques divergents. Au sein d'une région, le failover automatique fondé sur un quorum est sûr et standard ; entre régions, la plupart des organisations exigent une décision humaine, car le signal de panne est ambigu.

Ce sont des détails pratiques qui déterminent si la promotion fonctionne : les applications doivent se reconnecter plutôt que garder indéfiniment en cache une adresse résolue ; les chaînes de connexion doivent pointer vers un alias DNS ou un endpoint de proxy que vous pouvez rediriger ; le failback doit être planifié, car inverser la réplication est souvent plus difficile que le failover ; et le secondaire doit disposer des mêmes clés de chiffrement, des mêmes identifiants et de la même version de schéma. Les conséquences sur la cohérence d'écritures acceptées à deux endroits sont traitées dans transactions distribuées et cohérence.

Les sauvegardes : ce que tout le monde revendique et que peu vérifient

Appliquez une règle 3-2-1 adaptée au cloud : au moins trois copies, sur deux types de stockage, dont une isolée — un autre compte ou abonnement, d'autres identifiants, l'object lock ou l'immuabilité activés, et de préférence une autre région. L'isolement ne vise pas la panne matérielle ; il vise un attaquant ou une automatisation fautive détenant des droits de suppression.

Testez ensuite les restaurations à intervalles réguliers et mesurez leur durée, car restaurer plusieurs téraoctets depuis un stockage à froid peut dépasser le RTO d'un ordre de grandeur, et seul l'essai le révèle. Automatisez une restauration périodique dans un environnement jetable, exécutez-y un checksum et une requête métier, et enregistrez la durée écoulée comme métrique, avec une alarme en cas de régression.

Le prouver avec des game days

Un plan de reprise non testé est un document, pas une capacité. Un game day est un exercice planifié au cours duquel l'équipe exécute un scénario de panne contre un environnement réel.

Commencez dans un environnement de préproduction qui reflète fidèlement la production, annoncez l'exercice et formulez d'abord une hypothèse : « si nous arrêtons l'instance primaire de la base de données, le trafic se rétablit en moins de quatre-vingt-dix secondes sans aucune écriture en échec ». Injectez ensuite la panne et consignez ce qui s'est réellement passé. Le résultat précieux, c'est la liste des surprises : un rôle IAM manquant, une alerte envoyée à une équipe dissoute, une étape de runbook qui cite un outil décommissionné.

Les scénarios qui méritent d'être répétés, à peu près par ordre de maturité : arrêter une instance ; basculer la base de données ; perdre une zone de disponibilité ; restaurer la plus grosse base de données en chronométrant l'opération ; laisser expirer un certificat ; perdre le fournisseur d'identité ; exécuter un failover régional ; et se remettre d'une corruption logique découverte six heures trop tard. Ce dernier est rarement répété, et c'est pourtant l'un des plus susceptibles de se produire.

L'injection de fautes automatisée rend l'exercice continu plutôt qu'annuel. Les deux grands clouds proposent des services managés d'injection de fautes qui arrêtent des instances, ajoutent de la latence ou limitent le débit des API dans un rayon d'impact maîtrisé, avec une condition d'arrêt liée à une alarme. Mener en continu de petites expériences — d'abord en préproduction, puis en production sous surveillance humaine — transforme une résilience revendiquée en résilience mesurée, et c'est exactement la preuve qu'attend une revue Well-Architected.

Points clés à retenir

• Les objectifs de disponibilité relèvent du calcul : les dépendances en série se multiplient, quatre 9 exigent une reprise automatique, et le SLA d'un fournisseur est un barème d'avoirs plutôt qu'une promesse sur votre système.
• La redondance n'aide qu'entre domaines de défaillance indépendants ; les pannes corrélées dues aux dépendances partagées, aux control planes, aux pushs de configuration et aux manques de capacité mettent en échec la simple duplication.
• Le RTO et le RPO découlent de l'impact métier et doivent être définis par niveaux, workload par workload ; appliquer partout le niveau le plus strict rend la reprise après sinistre inabordable.
• Les quatre stratégies de reprise arbitrent entre coût et temps de reprise — backup and restore, pilot light, warm standby, active-active — et toutes ont encore besoin de sauvegardes immuables et isolées.
• La réplication et la promotion de la base de données fixent le délai de reprise : synchrone au sein d'une région, asynchrone entre régions, avec un failback planifié à l'avance.
• Une capacité de reprise n'existe qu'une fois exercée : planifiez des game days, mesurez les durées de restauration et injectez des fautes en continu plutôt que de vous fier au runbook.