Quand un rollback aggrave les choses (et que faire à la place)
Vous venez de déployer une nouvelle version. Le pipeline est vert. Les health checks passent. Le CPU et la mémoire semblent normaux. Mais votre téléphone se met à vibrer avec des messages d'utilisateurs. Une fonctionnalité qui fonctionnait hier est maintenant cassée. Les données écrites en base de données semblent erronées. Et les logs d'erreur ? Rien d'inhabituel.
C'est le moment où la plupart des équipes pensent : « Faisons un rollback. » Cela semble simple. Remplacer la nouvelle version par l'ancienne. Problème résolu. Mais en pratique, un rollback peut transformer un problème gérable en désastre. L'ancienne version pourrait ne pas comprendre les données que la nouvelle version a déjà écrites. Le schéma de base de données a peut-être changé. Ou le rollback lui-même prend tellement de temps que davantage d'utilisateurs sont affectés pendant la transition.
Le rollback n'est pas un bouton que l'on presse. C'est une décision que l'on prend sous pression, avec des informations incomplètes, et avec des conséquences qui se répercutent dans tout votre système. Comprendre quand et comment rollbacker — et quand ne pas le faire — est ce qui distingue les équipes qui récupèrent rapidement de celles qui empirent les choses.
Le vrai signal pour rollbacker
La plupart des équipes se fient aux health checks pour décider si un déploiement est sain. Mais les health checks indiquent seulement si l'application tourne techniquement. Ils ne disent pas si l'application fait ce qu'il faut.
Considérez ce scénario : votre nouvelle version écrit avec succès les commandes clients dans la base de données. Pas d'erreurs. Pas de crash. Mais les données de commande sont stockées avec le mauvais format de devise. L'application est techniquement saine, mais fonctionnellement cassée. Les health checks ne détecteront pas cela. Votre monitoring non plus, à moins d'avoir des métriques métier spécifiques en place.
La décision de rollbacker vient généralement d'une combinaison de signaux :
- Des health checks qui commencent à échouer
- Des taux d'erreur qui grimpent
- Des rapports utilisateurs décrivant un comportement qui ne correspond pas aux attentes
- Des métriques métier qui s'écartent des schémas normaux
Mais il y a un autre facteur que les équipes négligent souvent : le temps. Combien de temps attendez-vous avant de décider de rollbacker ? Cinq minutes ? Trente minutes ? Jusqu'à ce que quelqu'un se plaigne ? Plus vous attendez, plus la nouvelle version écrit de données. Et plus il y a de données écrites, plus le rollback devient difficile.
Définissez une fenêtre d'observation claire avant chaque déploiement. Décidez à l'avance : si nous ne voyons pas de problèmes dans les 15 premières minutes, nous considérons le déploiement comme stable. Si nous voyons des problèmes dans cette fenêtre, nous rollbackons immédiatement. Cela supprime l'hésitation qui empire les mauvaises situations.
Pourquoi les applications stateless et stateful ne sont pas identiques
La facilité du rollback dépend presque entièrement du fait que votre application gère ou non un état.
Pour les applications stateless, le rollback est simple. Vous redirigez le trafic vers l'ancienne version. Pas de données à restaurer. Pas de schéma à réconcilier. L'ancienne version reprend là où elle s'était arrêtée car elle ne dépendait pas de l'état de la nouvelle version. C'est pourquoi les services stateless sont souvent les premiers candidats pour des stratégies de rollback agressives.
Pour les applications stateful, le rollback est un jeu différent. Imaginez que votre nouvelle version a écrit 10 000 enregistrements en base de données avec un nouveau champ que l'ancienne version ne connaît pas. Lorsque vous rollbackez l'application, l'ancienne version essaie de lire ces enregistrements. Elle plante car le format des données ne correspond pas à ce qu'elle attend. Ou pire, la nouvelle version a modifié la structure d'une table. Maintenant, l'ancienne application ne peut même pas démarrer car le schéma est incompatible.
C'est le piège : rollbacker l'application sans rollbacker les données. Si votre déploiement a modifié le schéma de base de données ou écrit des données dans un nouveau format, rollbacker le code seul ne suffit pas. Vous devez soit :
- Restaurer la base de données à un point antérieur au déploiement
- Écrire des scripts de migration qui inversent les changements de schéma
- Accepter que certaines données seront perdues ou corrompues
Chacune de ces options a son propre coût et risque. La restauration de base de données prend du temps et peut perdre des données légitimes écrites par d'autres parties du système pendant la fenêtre. Les migrations inverses doivent être testées et prêtes avant le déploiement, pas écrites sous pression.
Trois stratégies qui fonctionnent réellement
Différentes situations nécessitent différentes approches de rollback. Voici trois stratégies utilisées par les équipes en pratique.
L'arbre de décision suivant peut guider votre choix :
Correction directe (Forward Fix)
Au lieu de revenir à l'ancienne version, vous construisez et déployez une nouvelle version qui corrige le problème. C'est souvent l'option la plus sûre pour les applications stateful car vous n'avez pas besoin d'annuler les modifications de données. Vous devez simplement les corriger.
La correction directe fonctionne bien quand :
- Le bug est isolé et peut être corrigé rapidement
- Votre pipeline peut livrer une nouvelle version en quelques minutes
- Les données écrites par la version cassée sont récupérables ou peuvent être migrées
Le risque est le temps. Si le bug est grave et que la correction prend des heures, les utilisateurs continuent de subir le problème pendant que vous travaillez. La correction directe nécessite d'avoir confiance en la capacité de votre équipe à diagnostiquer et corriger les problèmes rapidement.
Bascule de trafic (Traffic Shift)
Si vous utilisez un déploiement canary ou blue-green, le rollback est aussi simple que de rediriger le trafic vers l'ancienne version. L'ancienne version est toujours en cours d'exécution et prête à accepter du trafic. Il n'y a pas de processus de déploiement à attendre. Pas de période de transition où certains utilisateurs frappent l'ancienne version et d'autres la nouvelle.
C'est la méthode de rollback la plus rapide. Mais elle ne fonctionne que si vous avez conçu votre stratégie de déploiement en conséquence. Si vous utilisez des rolling updates, vous n'avez pas d'ancienne version en attente. Le rollback signifie relancer tout le processus de déploiement avec l'ancien artefact. Cela prend du temps et expose les utilisateurs à des erreurs pendant la transition.
Voici un exemple concret utilisant Kubernetes pour basculer le trafic vers l'ancienne version lors d'un déploiement canary :
# Vérifier la répartition actuelle du trafic (en supposant un service avec deux sélecteurs)
kubectl get virtualservice my-app -o jsonpath='{.spec.http[0].route[*].weight}'
# Basculer 100% du trafic vers l'ancienne version (v1)
kubectl patch virtualservice my-app --type='json' -p='[
{"op": "replace", "path": "/spec/http/0/route/0/weight", "value": 100},
{"op": "replace", "path": "/spec/http/0/route/1/weight", "value": 0}
]'
# Vérifier le changement
kubectl get virtualservice my-app -o yaml | grep -A5 "route:"
Cette approche suppose que vous avez un service mesh ou un contrôleur d'entrée (comme Istio ou Traefik) qui supporte le routage pondéré. Pour des configurations plus simples, vous pouvez obtenir le même résultat en mettant à jour le sélecteur du service pour pointer exclusivement vers les pods de l'ancienne version.
Accepter et corriger (Accept and Patch)
Parfois, la meilleure décision est de laisser la nouvelle version tourner et de corriger le problème sur place. Cela semble contre-intuitif, mais considérez ceci : si la nouvelle version a déjà écrit des données que l'ancienne version ne peut pas lire, le rollback garantit une indisponibilité. Garder la nouvelle version en cours d'exécution signifie que les utilisateurs peuvent toujours utiliser le système pendant que vous travaillez sur un correctif.
Cette approche fonctionne quand :
- Le problème n'est pas critique (problème d'affichage mineur, bug non bloquant)
- Les données écrites par la nouvelle version sont précieuses et seraient perdues lors d'un rollback
- L'équipe peut livrer un correctif dans un délai raisonnable
La clé est de savoir quand accepter et quand agir. Si le problème affecte les fonctionnalités de base ou corrompt les données, « accepter et corriger » n'est pas le bon choix.
Une checklist pratique avant votre prochain déploiement
Avant de déployer, parcourez ces questions avec votre équipe :
- Quels signaux déclencheront une décision de rollback ? (health, erreurs, rapports utilisateurs, métriques métier)
- Combien de temps allons-nous observer avant de décider ? (5 minutes, 15 minutes, 30 minutes)
- Ce déploiement modifie-t-il le schéma de base de données ou le format des données ?
- Si oui, avons-nous une migration inverse ou un plan de restauration testé ?
- L'ancienne version est-elle toujours en cours d'exécution et prête à accepter du trafic ?
- Pouvons-nous corriger directement plus rapidement que rollbacker ?
Notez les réponses. Partagez-les avec l'équipe. Le moment de planifier le rollback est avant le déploiement, pas pendant l'incident.
L'essentiel à retenir
Le rollback n'est pas un filet de sécurité universel. Pour les applications stateless, c'est une trappe de secours fiable. Pour les applications stateful, cela peut être un piège qui empire les choses. La décision de rollbacker dépend de la quantité de données affectées, de la rapidité avec laquelle vous pouvez corriger directement, et de la capacité de l'ancienne version à fonctionner avec l'état actuel de votre système.
Planifiez votre chemin de rollback avant chaque déploiement. Connaissez vos signaux. Définissez votre fenêtre d'observation. Et souvenez-vous : parfois, la meilleure récupération n'est pas de revenir en arrière, mais de corriger en avant.