Séance 2 : Architectures résilientes, Runbook, tests PRA et post-mortem

Introduction (10 min)

Lors d'un test PRA, une équipe a appliqué par erreur une procédure de restauration destinée à un environnement de test sur la production : la mauvaise manipulation a allongé l'incident de 6 h au lieu de permettre une récupération rapide. Cet exemple illustre l'importance d'un runbook précis, de tests planifiés et d'un protocole de bascule contrôlé.

À l'issue de cette séance, vous serez capable de :

• Concevoir des architectures résilientes adaptées aux RTO/RPO décidés en séance 1.
• Rédiger un runbook de reprise complet et exécutable.
• Concevoir et conduire un test PRA contrôlé, analyser les écarts et proposer actions correctives via un post-mortem structuré.

1. Architectures résilientes (70 min)

Les architectures résilientes reposent sur la réplication, la redondance et la capacité à basculer rapidement.

DRBD — Réplication bloc-à-bloc sous Linux

DRBD réplique un device block (ex : /dev/vg-data/lv-www) vers un device /dev/drbd0 sur un nœud secondaire. Le device DRBD apparaît comme un disque local et peut être utilisé comme PV LVM ou directement formaté.

# Initialiser DRBD (configuration dans /etc/drbd.d/*.res)
drbdadm create-md r0
drbdadm up r0

# Forcer primary sur le nœud choisi (après vérification)
drbdadm primary --force r0

# Vérifier l'état de la réplication
cat /proc/drbd

Attention : prévoir la gestion du split-brain (fencing, stonith) et les procédures de resynchronisation.

Proxmox HA (cluster 3 nœuds, quorum)

Un cluster Proxmox constitué de 3 nœuds permet d'atteindre le quorum et d'activer HA manager pour redémarrer automatiquement des VMs sur les nœuds survivants.

# Créer un cluster sur le premier nœud
pvecm create proxmox-cluster

# Ajouter un nœud secondaire
pvecm add proxmox02

# Vérifier le quorum
pvecm status

Snapshots ZFS et LVM

# ZFS snapshot (restauration conservatrice)
zfs snapshot pool/data@2024-01-15
zfs rollback pool/data@2024-01-15

# LVM snapshot
lvcreate -s -n snap-www -L 1G /dev/vg-data/lv-www

# Monter le snapshot en lecture seule pour examen
mount -o ro /dev/vg-data/snap-www /mnt/snap-www

Schéma — Réplication DRBD + Proxmox HA

        [Internet]
            |
        [Firewall]
            |
      [Proxmox Cluster]
       /    |    \
  node1  node2  node3    (Quorum — 3 nœuds)
     |       |       \
  /dev/drbd0 <----> /dev/drbd0   (réplication bloc-à-bloc)
     |                   |
 VMs (win-srv01, debian-srv02, ...)

Si node1 tombe → HA manager démarre VMs sur node2/node3 (RTO ≈ min)

2. Runbook de reprise — structure et exemple (40 min)

Un runbook doit être clair, concis et actionnable. Structure recommandée :

• Titre du runbook / Service
• RTO / RPO cibles
• Prérequis (accès, comptes, clés, sauvegardes identifiées)
• Procédure pas-à-pas numérotée (actions à exécuter dans l'ordre)
• Contacts d'urgence (nom, rôle, téléphone, e-mail)
• Points de vérification (checks post-restauration)
• Rollback si échec (procédure et critères de déclenchement)
• Journal de la reprise (zone pour horodatage et signature)

Extrait d'en-tête de runbook — Restauration AD win-srv01

Runbook : Restauration AD - win-srv01
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RTO cible : 4 h — RPO cible : 1 h
Prérequis :
  - Accès Proxmox (root) sur proxmox01
  - Accès stockage backups : nas01:/backups/win-srv01
  - DSRM credentials (coffre-fort)
  - Ticket d'incident ouvert
Contacts :
  - Responsable SI : Alice Martin — +33 6 12 34 56 01
  - Technicien N2 : Bob Durand — +33 6 12 34 56 02

La partie procédure comporte des étapes claires, numérotées et conditionnelles (si A échoue → faire B).

3. Runbook exemple — Restauration AD win-srv01 (34 étapes)

Ce runbook suppose une restauration depuis une sauvegarde Windows Server Backup sur \\nas01\backups\win-srv01 et/ou depuis un backup Proxmox (/var/lib/vz/dump/vzdump-qemu-<vmid>-YYYYMMDD.vma.lzo).

1. Ouvrir le ticket d'incident et obtenir autorisation de restauration (horodatage, opérateur).
2. Confirmer RTO = 4 h et RPO = 1 h ; valider priorité avec le métier.
3. Notifier parties prenantes (mail + canal d'astreinte) et enregistrer l'heure de début.
4. Vérifier intégrité du stockage backup : ls -lh /mnt/backups/win-srv01 ou via SMB.
5. Monter le partage SMB si besoin : mount -t cifs \\nas01\backups /mnt/backups -o username=backupuser.
6. Lister les versions disponibles dans WinRE : wbadmin get versions -backupTarget:\\nas01\backups\win-srv01.
7. Si un backup image Proxmox valide est disponible, privilégier la restauration rapide via qmrestore : qmrestore /var/lib/vz/dump/vzdump-qemu-<vmid>-<date>.vma.lzo <vmid>.
8. Vérifier VMID cible et espace disque (pvesm status / df -h).
9. Lancer la restauration Proxmox et surveiller la progression.
10. Si restauration depuis WSB (méthode inside-VM) : créer une VM de restauration si nécessaire.
11. Attacher la ressource backup (partage NAS monté comme disque ou ISO de récupération).
12. Démarrer la VM et ouvrir la console Proxmox.
13. Démarrer en DSRM (Directory Services Repair Mode) si restauration d'état système requise.
14. Dans WinRE/DSRM, monter le partage backup : net use Z: \\nas01\backups /user:backupuser.
15. Identifier la version de sauvegarde à restaurer et noter l'ID/horodatage.
16. Lancer la restauration de l'état système :
    wbadmin start systemstaterecovery -version:<version> -backupTarget:Z: -quiet
17. Surveiller la progression et noter les erreurs dans le journal de restauration.
18. Si restauration autoritaire nécessaire, exécuter ntdsutil → activate instance ntds → authoritative restore.
19. Redémarrer la VM en mode normal : shutdown -r -t 0.
20. Vérifier les partages SYSVOL et NETLOGON : net share doit lister SYSVOL et NETLOGON.
21. Lancer les vérifications AD : dcdiag /v et corriger erreurs bloquantes.
22. Vérifier la réplication multi-DCs : repadmin /replsummary et repadmin /showrepl.
23. Vérifier les zones DNS intégrées AD : dnscmd /enumzones.
24. Sur DC secondaire, forcer une réplication : repadmin /syncall /AeD.
25. Contrôler les services dépendants (Kerberos, Netlogon, DNS) et les journaux d'événements.
26. Valider l'authentification depuis un poste client : connexion test + gpupdate /force.
27. Vérifier l'application des GPOs : gpresult /r sur un poste test.
28. Vérifier les services réseau dépendants (messagerie, site web) avec l'AD restauré.
29. Si des postes ne retrouvent pas le domaine, préparer la ré-adhésion PowerShell : Add-Computer -DomainName "INNOVATTECH" -Credential (Get-Credential) -Restart.
30. Si la restauration échoue ou AD est corrompu, activer le rollback plan (snapshot disponible ou escalade fournisseur).
31. Clôturer le ticket d'incident : heure de fin, actions réalisées, personnes impliquées.
32. Archiver les logs de restauration : /var/log/pra/win-srv01-restore-YYYYMMDD.log.
33. Planifier une fenêtre de tests complémentaires pour vérifier la réplication sur 24 h.
34. Mettre à jour le PRA/runbook avec les leçons apprises et numéros de version des sauvegardes utilisées.

4. Tests de PRA (30 min)

Types de tests

Bonnes pratiques

• Documenter le scénario et les objectifs du test avant exécution.
• Définir des critères de succès mesurables : RTO atteint, intégrité des données (checksum, contrôles applicatifs).
• Impliquer des utilisateurs-clés pour la validation fonctionnelle.
• Prévoir explicitement un critère de déclenchement du rollback.

5. Post-mortem et amélioration continue (20 min)

Après chaque test ou incident :

1. Rassembler une timeline (horodatage précis des actions).
2. Pratiquer la méthode des 5 Whys pour remonter à la cause racine.
3. Rédiger un RCA (Root Cause Analysis) et lister des actions correctives SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporel).
4. Mettre à jour runbooks, scripts et BIA selon les enseignements.
5. Planifier une vérification (test) des actions correctives dans un délai défini.

Méthode des 5 Whys — exemple

Problème : La restauration AD a pris 6h au lieu de 4h (RTO non respecté).

1. Pourquoi ?  — L'opérateur a utilisé la mauvaise procédure.
2. Pourquoi ?  — Il existait deux runbooks distincts : TEST et PROD.
3. Pourquoi ?  — La documentation n'est pas nommée distinctement.
4. Pourquoi ?  — Pas de convention de nommage imposée.
5. Pourquoi ?  — Aucune revue documentaire n'est planifiée.

Root Cause : Absence de gouvernance documentaire.
Action SMART : Implémenter convention de nommage runbook-{env}-{service}.md
               — Owner : Alice Martin — Deadline : J+30

6. Communication de crise (20 min)

Template d'email d'alerte initiale

Objet : [INCIDENT P1] - Service AD - 2025-01-15 08:12

Bonjour,

Nous observons une indisponibilité du service AD (win-srv01) depuis 08:12.
Impact estimé : tous les utilisateurs ne peuvent pas s'authentifier.
Équipe technique en intervention — RTO cible : 4 h.
Prochaine mise à jour à 09:30.

Contact urgence : Alice Martin — 06 12 34 56 01
Ticket incident : #INC-2025-0042

Chaîne d'escalade

Technicien N1
    │ si non résolu en 15 min
    ▼
Technicien N2 (Bob Durand)
    │ si impact > seuil financier (ex : > 10k€)
    ▼
Responsable SI (Alice Martin)
    │ si durée > RTO ou interruption service critique
    ▼
Directeur Général

Travaux Pratiques — TP S2 : Rédiger le PRA complet d'InnovatTech pour AD (80–90 min)

Contexte : win-srv01 (Windows Server 2022) — DC/AD/DNS — sauvegardes Windows Server Backup vers nas01 et snapshots Proxmox.

Objectif : rédiger un PRA complet pour AD incluant un runbook de restauration, exécuter une simulation sur VM de test et produire un compte-rendu des écarts avec mesures correctives.

Prérequis techniques

• Accès Proxmox (pve root), accès partage de sauvegarde (nas01).
• Image ISO Windows Server 2022 pour WinRE.
• VM de test isolée (win-srv01-test), credentials DSRM en coffre-fort.

Étapes générales

1. Rédiger le PRA détaillé (objectif, périmètre, RTO/RPO, dépendances, propriétaires, plan de communication).
2. Joindre le runbook d'exécution pas-à-pas (≥ 30 étapes opérationnelles, s'inspirer du runbook fourni).
3. Effectuer une simulation sur VM de test et documenter chaque commande et résultat.
4. Produire un rapport d'écarts listant ce qui n'a pas fonctionné et proposer actions correctives SMART.

Livrable attendu

• PRA complet en Markdown (ou PDF) + runbook numéroté.
• Journal de test (logs, captures console, sorties commandes).
• Rapport d'écarts avec plan d'actions (≥ 3 améliorations SMART).

Critères de réussite

• Runbook exécutable et reproductible (≥ 30 étapes claires).
• Simulation réalisée et validée par preuves (captures, logs).
• Rapport d'écarts identifie au moins 3 améliorations avec actions SMART.

Synthèse (10 min)

Un PRA opérationnel ne se limite pas à des sauvegardes : il combine architecture (réplication/snapshots), procédures (runbooks), tests réguliers et une communication maîtrisée. La répétition et l'amélioration continue (post-mortem) permettent de réduire l'incertitude et d'atteindre les RTO/RPO métier.

Question de vérification : Citez trois éléments essentiels qu'un runbook doit contenir pour garantir une restauration reproductible.