Changement en échec sans plan de retour arrière
```text ERROR: column "customer_ref" does not exist Migration 0042 partially applied ```
Détecter
Une mise à jour applicative nocturne provoque des erreurs ; l'équipe tente de corriger « en avant » pendant trois heures et l'indisponibilité déborde sur les heures ouvrées.
Symptômes
Une mise à jour applicative nocturne provoque des erreurs ; l'équipe tente de corriger « en avant » pendant trois heures et l'indisponibilité déborde sur les heures ouvrées.
Environnement
Changement « normal » approuvé en CAB, migration de schéma de base de données incluse, pas de procédure de retour arrière testée.
Cause racine
Le dossier de changement ne contenait pas de plan de retour arrière exécutable ; la migration de schéma n'était pas rétrocompatible, rendant l'ancienne version inutilisable ; aucun critère de décision (« go / no-go / rollback ») n'était défini.
Diagnostic
- Chronologie du changement (heure de début, étapes, premières erreurs).
- État exact de la base (migrations appliquées).
- Possibilité de restauration (dernière sauvegarde, PITR).
Solution
Déclarer un incident majeur, décider rapidement d'un retour arrière (restauration PITR ou migration inverse), rétablir la version précédente, puis replanifier le changement.
Commandes
./manage.py showmigrations | tail
pg_restore --list backup.dump | head
Prévention
Dossier de changement avec plan de retour arrière testé et fenêtre de décision (ex. rollback si non résolu en 30 min), migrations expand/contract rétrocompatibles, sauvegarde vérifiée juste avant, post-implementation review.