Étape 08 — Simuler les incidents
Apprendre à récupérer avant que la panne réelle arrive.
Pourquoi casser volontairement ?
Un plan de reprise qui n’a jamais été essayé est une hypothèse. On simule donc les pannes avant le go-live : conteneur détruit, secret divulgué, webhook dupliqué, migration ratée et restauration de sauvegarde.
Lire la section complète, copier une commande à la fois, vérifier le résultat attendu, puis seulement continuer.
- Rollback : retour vers une version précédente.
- Restore : restauration des données à partir d’une sauvegarde.
- Incident : événement qui affecte sécurité, disponibilité ou intégrité.
1. Pourquoi casser volontairement ?
Un plan de restauration ou de rollback qui n’a jamais été exécuté reste une hypothèse. Cette étape transforme les procédures en compétences réelles.
2. Scénarios obligatoires
Backend détruit
Supprimer le conteneur backend puis le recréer à partir de l’image et de Compose.
Release défectueuse
Promouvoir volontairement une build de test puis revenir au digest précédent.
Migration
Tester une migration expand/contract puis revenir à l’ancienne version applicative.
Secret compromis
Simuler une détection Gitleaks et dérouler la rotation sans exposer de vrai secret.
Base perdue
Restaurer la dernière sauvegarde dans une base temporaire et exécuter les tests smoke.
Webhook Mollie dupliqué
Envoyer deux fois le même événement de test et vérifier qu’aucun double crédit ne se produit.
Voir la référence Mollie →3. Mesurer et documenter
Pour chaque exercice : heure de début, symptômes, diagnostic, commandes exécutées, heure de rétablissement, pertes éventuelles, leçon apprise et modification du runbook.