Plan de reprise : quand tout casse

Prérequis : cours 4.2 (restauration), 6.2 (rollback), 7.3 (runbook).

Pourquoi

Le stress divise le QI par deux : sans plan écrit et testé, on improvise — et l'improvisation en prod casse plus qu'elle ne répare. Le plan, c'est l'intelligence d'avant l'incident au service de la panique pendant.

Concepts

• Les 5 phases : constater (quoi, depuis quand, ampleur — pas d'action avant diagnostic), contenir (stopper l'hémorragie : couper l'accès, rebasculer, figer les écritures si corruption), restaurer (backups testés, en chronométrant), vérifier métier (connexion, parcours critique, écriture test — pas juste « 200 OK »), post-mortem (timeline, cause, 1 action datée).
• RTO / RPO : durée max d'interruption acceptable / perte de données max acceptable. Ils se mesurent lors des tests : un « RTO 10 min » avec restauration de 40 min est un mensonge confortable.
• Hors bande : un accès indépendant de ce qui est cassé (console provider si SSH mort, contacts registrar — l'organisme chez qui le domaine est enregistré — et fournisseur SSO).
• Game day : panne volontaire planifiée (reboot, kill base, réseau simulé) pour prouver que tout remonte seul et révéler les trous.

Exemple : sous la main, avant

• Console provider testée (s'y connecter une fois pour de faux).
• Procédure de restauration testée, donc connue par cœur.
• Runbook imprimé dans la tête par les game days : reboot du dimanche matin, tout remonte seul ?

Cas réel

Premier game day : reboot volontaire → le worker ne remonte pas (enable oublié !), la file s'accumule 20 minutes avant l'alerte. Sans game day : même panne un mardi à 3h, découverte par hasard. Le game day a payé sa matinée.

Pièges

• Plan jamais testé : du papier, pas un plan.
• Restaurer sans figer des écritures corrompues : on restaure sur une corruption en cours.
• Post-mortem sans action : rituel qui console au lieu de protéger.

À retenir

5 phases, accès hors bande testé, restauration connue par cœur, game days réguliers, RTO/RPO mesurés.