Pilier Reliability sur OUTSCALE

Le pilier Reliability couvre la multi-AZ, les objectifs RTO/RPO, les sauvegardes, le plan de reprise, les patterns de résilience (circuit breaker, retry with backoff, bulkhead) et le chaos engineering. Sur OUTSCALE, les briques de base sont la mécanique multi-AZ Net + Subnets, les snapshots BSU, les exports OOS pour le long terme, et l’EIP transférable entre VMs. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Reliability évalue la capacité d’une architecture à rester disponible malgré les défaillances (panne d’instance, perte d’AZ, corruption de données, erreur humaine), et à retrouver son état nominal dans des délais maîtrisés. Sur OUTSCALE, il se matérialise par une architecture multi-AZ explicite, des sauvegardes testées selon la règle 3-2-1, un runbook PRA versionné, et une culture de chaos engineering qui prouve la résilience plutôt que de la postuler.

Les questions clés

Une architecture qui revendique une posture Reliability doit pouvoir répondre aux questions suivantes :

RTO / RPO — quels sont les objectifs de reprise définis avec le métier ? Sont-ils différenciés par criticité de service, ou un objectif global non discriminant ?
Multi-AZ — le service est-il déployé sur au moins deux sous-régions d’OUTSCALE (eu-west-2a, eu-west-2b, eu-west-2c) ?
Subnets multi-AZ — chaque tier (public, privé, data) a-t-il un subnet par sous-région, avec route table dédiée ?
Sauvegardes — la règle 3-2-1 (3 copies, 2 supports, 1 hors-site) est-elle appliquée ? Concrètement : volume BSU + snapshot BSU + export OOS dans un compte séparé ?
Test de restauration — un test de restauration complet est-il mené trimestriellement ? Le résultat est-il documenté ?
Runbook PRA — existe-t-il un runbook versionné en Git, à jour, testé annuellement par game day ?
Patterns de résilience applicative — les workloads implémentent-ils retry with backoff, circuit breaker, bulkhead sur les appels critiques ?
EIP flottante — pour les workloads stateful avec un point d’entrée unique, le pattern de bascule d’EIP entre instances est-il en place ?
Chaos engineering — l’équipe pratique-t-elle des expériences contrôlées de défaillance (couper une AZ en pré-production, mesurer le RTO réel) ?
Monitoring de la santé — les probes de santé (HTTP healthcheck, TCP probe) sont-elles en place sur tous les services ? Routent-elles correctement vers une astreinte ?

Une organisation qui répond « non » à plus de trois questions est en posture fragile sur Reliability — un incident significatif aura un impact disproportionné par rapport à sa probabilité.

Application sur OUTSCALE

RTO / RPO différenciés par service

RTO (Recovery Time Objective) est le temps maximum acceptable d’indisponibilité d’un service. RPO (Recovery Point Objective) est la quantité maximum de données perdues acceptable, exprimée en temps.

Sur une organisation moyenne, on rencontre typiquement trois niveaux :

Critique — RTO 1 h, RPO 15 min. Site e-commerce en pic, plateforme de paiement, système de billetterie le jour J.
Important — RTO 4 h, RPO 1 h. Application métier en heures ouvrées.
Standard — RTO 24 h, RPO 24 h. Outils internes, environnements de pré-production.

Définir un RTO/RPO unique sur tous les services revient à surinvestir sur les services peu critiques (gaspillage) et à sous-investir sur les services réellement critiques (risque). La discrimination par criticité est l’essence du pilier.

Multi-AZ explicite

Une AZ (Availability Zone — sous-région chez OUTSCALE) est un datacenter physiquement séparé. Une panne sur une AZ n’affecte pas les autres AZ de la région. Le pattern minimal Reliability sur OUTSCALE :

Net unique par environnement.
Subnets par tier ET par sous-région : subnet-public-2a, subnet-public-2b, subnet-private-2a, subnet-private-2b, subnet-data-2a, subnet-data-2b.
Workloads stateless déployés sur les subnets privés avec au moins une instance par AZ.
Bases de données avec réplication active-passive (primaire en AZ-A, replica en AZ-B).
Load balancer LBU réparti sur les subnets publics multi-AZ.

L’architecture détaillée est traitée dans Réseau — design Net + Subnets.

Sauvegardes — règle 3-2-1 sur OUTSCALE

La règle 3-2-1 se décline sur OUTSCALE de la manière suivante :

3 copies des données importantes.
2 supports différents — volume BSU primaire (1) + snapshot BSU (2).
1 hors-site — export OOS dans un compte OUTSCALE séparé (compte de sauvegarde).

L’export OOS dans un compte séparé est crucial : si le compte applicatif est compromis (attaque, erreur opérateur supprimant tout), les sauvegardes restent intactes. La séparation des comptes est traitée dans EIM — patterns multi-comptes.

Pour les données critiques (registres légaux, archives), ajouter un object lock sur le bucket OOS de sauvegarde, avec une rétention alignée sur les contraintes réglementaires.

Test de restauration — non négociable

Une sauvegarde non testée n’est pas une sauvegarde, c’est un espoir. Le test de restauration trimestriel consiste à :

Choisir un dataset (un volume BSU) au hasard parmi les sauvegardes de la dernière semaine.
Restaurer le snapshot dans un subnet de test.
Attacher le volume restauré à une VM et vérifier l’intégrité applicative (la base démarre, les enregistrements sont cohérents).
Documenter le résultat (durée réelle, anomalies détectées, actions correctives).

Une équipe qui ne teste jamais ses sauvegardes découvre en situation de crise réelle que le format a changé, que le script de restauration référence un compte qui n’existe plus, ou que le snapshot référencé est corrompu.

Runbook PRA versionné

Le runbook PRA (Plan de Reprise d’Activité) documente la procédure de bascule en cas de sinistre majeur. Il doit être :

Versionné en Git, à côté du code IaC.
Concret — pas « contacter l’équipe sécurité » mais « envoyer un message à #incident-response avec le template INCIDENT.md ».
À jour — relu et mis à jour à chaque évolution architecturale significative.
Testé annuellement par un game day : l’équipe simule un sinistre, exécute le runbook, mesure le RTO réel, identifie les écarts.

Un runbook qui n’a jamais été testé est statistiquement faux : 30 à 50 % des étapes sont obsolètes ou imprécises.

Patterns de résilience applicative

Au-delà de l’infrastructure, le code applicatif doit gérer les défaillances transitoires :

Retry with backoff — sur les appels API externes (OAPI ou tiers), réessayer en doublant le délai (100 ms, 200 ms, 400 ms…) avec un plafond. Évite les tempêtes de retry qui aggravent l’incident.
Circuit breaker — quand un service externe répond en erreur sur N appels consécutifs, couper les appels pendant une fenêtre de temps. Permet au service externe de récupérer sans subir de charge.
Bulkhead — isoler les pools de connexions par dépendance externe. Une saturation sur un service ne bloque pas les autres.
Timeout explicite — toujours définir un timeout sur les appels externes. Sans timeout, un service en latence anormalement haute provoque l’épuisement du pool de threads applicatif.

Ces patterns sont indépendants d’OUTSCALE mais essentiels sur tout cloud — ils transforment une dépendance fragile en dépendance acceptable.

EIP flottante pour les patterns actif-passif

Pour les workloads stateful avec un point d’entrée unique (cluster Pacemaker, base de données primaire-secondaire), le pattern de bascule d’EIP entre VMs permet de maintenir l’IP publique stable même en cas de défaillance d’une VM. La mise en œuvre concrète est traitée dans la section Expérimentations — ce n’est pas un service managé OUTSCALE.

Chaos engineering — prouver la résilience

La majorité des architectures décrites comme résilientes n’ont jamais subi de bascule réelle. Le chaos engineering consiste à provoquer délibérément des défaillances en environnement contrôlé pour vérifier le comportement. Sur OUTSCALE :

Niveau débutant — éteindre une VM applicative en staging, mesurer le temps de récupération.
Niveau intermédiaire — couper temporairement la connectivité d’un subnet (en modifiant les routes), observer la bascule du load balancer.
Niveau avancé — simuler une perte d’AZ entière (toutes les VMs d’une sous-région), vérifier que le service reste disponible et mesurer le RTO réel.

Le chaos engineering n’est pas une mode — c’est la seule preuve que les claims de résilience sont vrais.

Checklist Definition of Done

ADR types

ADR-REL-01 — Définition différenciée des RTO/RPO

Contexte : un RTO/RPO unique de 24 h est appliqué sur tous les services. Conséquences : surinvestissement sur les services peu critiques, sous-investissement sur les services critiques.

Décision : définir trois niveaux de criticité (Critique, Important, Standard) avec RTO/RPO différenciés. Documenter chaque service dans un catalogue Git versionné. Aligner les politiques de sauvegarde et de réplication sur la criticité.

Conséquences : effort initial de cartographie (1 sprint pour un parc moyen). Bénéfices durables : allocation des ressources alignée sur la valeur, audits internes plus rapides, justification métier des coûts cloud.

ADR-REL-02 — Test de restauration trimestriel obligatoire

Contexte : les sauvegardes sont configurées mais jamais testées en restauration réelle. Le risque de découvrir une sauvegarde inutilisable en situation de crise est élevé.

Décision : instaurer un test de restauration trimestriel sur un dataset choisi aléatoirement. Le test inclut la restauration physique, la vérification d’intégrité applicative, et la documentation du résultat. Bloquer la mise en production de tout nouveau service tant que sa procédure de restauration n’est pas validée.

Conséquences : 0,5 à 1 jour-homme par trimestre dédié. Bénéfices : sauvegardes prouvées fonctionnelles, RTO réel mesuré, équipe entraînée.

Points d’audit correspondants

Sur un compte OUTSCALE réel, ces contrôles peuvent être menés via oapi-cli. Quelques exemples :

oapi-cli ReadSnapshots

Vérifier la fréquence des snapshots BSU (un par jour minimum sur les volumes data) et leur âge (tout snapshot critique doit avoir été testé dans les 90 derniers jours).

oapi-cli ReadVolumes

Pour chaque volume, vérifier qu’au moins un snapshot existe, et que l’environnement applicatif (tag env) correspond bien à l’environnement attendu.

oapi-cli ReadSubnets

Vérifier que chaque tier (public, privé, data) a un subnet par sous-région (SubregionName à eu-west-2a, eu-west-2b, etc.).

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

RTO postulé sans test. Définir un RTO sur le papier sans jamais le mesurer en condition réelle. La première bascule en crise révèle un RTO 5 à 10 fois supérieur à la promesse.

Sauvegardes dans le même compte que la production. Si le compte applicatif est compromis, l’attaquant supprime aussi les sauvegardes. La séparation est non négociable.

Mono-AZ par confort. Déployer en mono-AZ pour économiser sur les volumes BSU répliqués ou pour simplifier l’architecture. Le jour de la panne d’AZ (cela arrive en moyenne plusieurs fois par an chez tous les fournisseurs cloud), l’indisponibilité dépasse plusieurs heures.

Runbook obsolète. Maintenir un runbook PRA qui référence des outils, des comptes ou des contacts qui n’existent plus. La règle : un runbook non testé annuellement est présumé obsolète.

Chaos engineering reporté à plus tard. Considérer le chaos engineering comme un luxe à pratiquer « quand on aura le temps ». Le résultat est qu’on ne le pratique jamais. Démarrer petit (éteindre une VM en staging) suffit pour débloquer la culture.

À retenir

RTO/RPO différenciés par criticité de service, validés par le métier.
Architecture multi-AZ non négociable sur les services critiques.
Règle 3-2-1 appliquée — BSU + snapshot + export OOS compte séparé, object lock pour les données critiques.
Test de restauration trimestriel documenté — sans test, la sauvegarde n’est pas validée.
Runbook PRA versionné Git, testé annuellement par game day.
Patterns applicatifs — retry with backoff, circuit breaker, timeout explicite.
Chaos engineering comme preuve de résilience — démarrer petit, monter en maturité.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

Sauvegardes — RPO/RTO/PRA Le guide opérationnel des sauvegardes sur OUTSCALE.

Réseau — design Net + Subnets L'architecture multi-AZ qui sert ce pilier.

EIM — patterns multi-comptes La séparation compte applicatif / compte sauvegarde.