Zéro-coupure et plan de retour

Prérequis : cours 5.3 et 6.1.

Pourquoi

La disponibilité ne s'improvise pas : checklist exécutée avant, plan de retour écrit avant. Le reste, c'est de l'espoir — et l'espoir n'est pas une stratégie.

Concepts

• Hotfix : correctif minimal et urgent appliqué directement (nouveau tag, pipeline complet quand même — jamais de bidouille SSH en prod).
• Migration DOWN : le script inverse d'une migration (annule son effet). Alternative : réparer en avant — corriger par une nouvelle migration plutôt que revenir en arrière. Les deux se décident avant, se testent avant.
• Fenêtre de déploiement : plage annoncée (heure creuse) + 30 minutes de surveillance derrière. Déployer avant de partir = faute professionnelle.

Exemple : le plan en 3 lignes (dans le ticket, avant)

Si cassé < 10 min : pull <tag précédent> + up -d + DOWN testée.
Si cassé plus tard : hotfix + tag (réparer en avant).
Décideur : moi. Surveillance : 30 min, 3 voyants.

Règles d'or : ancien tag jamais supprimé avant d'être sûr ; jamais de déploiement qu'on ne sait pas annuler ; reboot complet testé (reboot → tout remonte seul).

Cas réel

Deploy vendredi 18h sans plan, bug à 18h20, tag précédent déjà pruné « pour faire de la place » : rebuild de 25 minutes sous pression + migration DOWN jamais testée qui échoue. Bilan : 1h12 de down pour une release qui valait 10 minutes. Depuis : plan écrit, tag gardé, jamais le vendredi soir.

Pièges

• DOWN jamais testée : une DOWN théorique échoue une fois sur deux (ordre, contraintes, données).
• Rollback décidé pendant l'incident : sous stress on choisit mal — d'où l'écriture avant.
• Surveiller 5 minutes puis partir : les incidents aiment les 20 minutes suivantes.

À retenir

Checklist avant, DOWN testée ou réparation décidée, tag gardé, 30 min de surveillance.