Refonte PRA sur infrastructure vieillissante

Le problème avec les PRA non testés

Ce n'est pas que le PRA était mauvais. C'est qu'il n'existait que sur papier.

L'infrastructure VMware avait 4 ans. Le PRA avait été documenté lors du déploiement initial, validé formellement par une prestataire externe, et n'avait jamais été rejoué depuis. Pendant 4 ans, l'environnement avait évolué : nouvelles VMs, nouveaux flux applicatifs, modifications réseau. Le PRA documentait un état qui n'existait plus.

:::Point critique Un PRA documenté n'est pas un PRA fonctionnel. C'est un PRA déclaratif. La différence apparaît au premier incident de production. :::

Ce que l'audit a révélé

L'audit a duré 5 jours. Cinq jours pour produire une liste courte mais précise de problèmes :

Deux points de défaillance uniques non documentés sur le chemin réseau de production
Le processus de bascule supposait la disponibilité d'un administrateur avec accès physique au site secondaire — non garanti en dehors des horaires ouvrés
Le délai de décision pour activer le PRA n'était pas défini : qui décide, sur quel critère, dans quel délai ?
Trois VMs critiques ne disposaient pas d'un snapshot applicativement cohérent (flush avant snapshot non configuré)

:::Observation terrain Le RTO déclaré dans les SLA était de 20 minutes. Le RTO mesuré lors du test simulé était de 64 minutes. L'écart venait principalement du point 2 et du point 3. :::

Architecture HA retenue

Refonte vers Proxmox VE multi-nœuds avec les principes suivants :

Bascule automatique sans intervention humaine pour les VMs critiques (Proxmox HA)
Réplication synchrone vers un nœud secondaire sur site secondaire (réseau dédié)
Proxmox Backup Server sur site secondaire avec vérification d'intégrité automatique
Procédure de bascule exécutable depuis n'importe quel poste avec accès VPN (suppression du prérequis accès physique)
Runbooks testés : chaque procédure est validée par l'équipe interne avant d'être intégrée

:::Arbitrage retenu Réplication synchrone uniquement pour les 8 VMs critiques sous SLA. Les autres en réplication asynchrone. Ce n'était pas une question de budget — c'était une décision de conception : tous les workloads n'ont pas le même profil de risque. :::

Les tests réels

Trois séries de tests en conditions de production :

Simulation de panne nœud — coupure d'alimentation forcée du nœud primaire, mesure du temps de reprise automatique
Simulation de perte site primaire — bascule complète vers le site secondaire, mesure RTO complet incluant temps de décision
Restauration depuis backup — restauration d'une VM critique depuis PBS, mesure du RPO réel

Les tests ont été exécutés par l'équipe interne après formation, pas par VSHIFT. C'était délibéré : si l'équipe ne peut pas exécuter les procédures seule, le PRA n'est pas opérationnel.

:::Réalité production Le premier test de la série 2 a détecté un problème de configuration réseau sur le site secondaire qui n'était pas visible en fonctionnement normal. Mieux valait le trouver en test. :::

Résultat

RTO effectif inférieur à 6 minutes sur les charges critiques, mesuré en conditions réelles. RPO inférieur à 2 minutes via réplication synchrone. Bascule automatique testée et validée chaque trimestre par l'équipe interne. Points de défaillance uniques éliminés. Documentation PRA à jour et opposable aux clients dans les contrats de service.