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 un prestataire externe, et n'avait jamais été rejoué depuis. Pendant 4 ans, l'environnement avait évolué : nouvelles VM, 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 vérifiable dans le cadre des contrats de service.