Utilisez cet exercice de rollback pour répéter la restauration d'une release cassée en 5 minutes : quoi snapshotter, quoi vérifier et qui clique quoi pendant l'exercice.
Une release peut sembler correcte en test, puis casser dans les cinq premières minutes de trafic réel. La partie effrayante n'est généralement pas le bug. C'est l'incertitude : qu'est-ce qui a changé, ce que vous pouvez annuler en toute sécurité, et si un rollback risque d'empirer la situation.
Juste après une release, les défaillances sont souvent simples et douloureusement visibles. Un nouveau bouton peut planter la page sur mobile. Un changement backend peut renvoyer une forme de données incorrecte, si bien que le paiement échoue. Un petit réglage de configuration peut casser la connexion, les emails ou les paiements. Même quand la correction est simple, la pression monte parce que les utilisateurs regardent et chaque minute semble coûteuse.
La panique commence quand la voie de rollback n'est pas claire. Les gens posent les mêmes questions en même temps : avons‑nous un snapshot ? Quelle version était la dernière bonne ? Si on revert l'app, qu'en est‑il de la base ? Qui a l'accès pour le faire ? Quand ces réponses ne sont pas déjà écrites, l'équipe perd du temps à débattre au lieu de restaurer le service.
Deviner en plein incident a un coût réel. Vous perdez du temps, les utilisateurs perdent confiance, et des changements précipités peuvent provoquer une seconde panne en plus de la première. Les ingénieurs sont aussi tirés dans trop de directions à la fois : debugging, communication et prise de décision.
Une répétition change l'atmosphère parce qu'elle remplace l'incertitude par de la mémoire musculaire. Un bon exercice de rollback n'est pas juste « peut‑on revert le code ». C'est une routine répétable : ce que vous snapshottez, ce que vous restaurez, ce que vous vérifiez et qui est autorisé à agir. Après quelques exercices, le rollback cesse d'être perçu comme un échec et devient un outil de sécurité.
Si votre installation de déploiement prend déjà en charge les snapshots et la restauration (certaines plateformes, y compris Koder.ai, intègrent cela dans le flux de release), les exercices deviennent plus simples parce que « revenir au connu bon » est une action normale, pas une procédure d'urgence sur mesure. Dans tous les cas, le but est le même : quand le moment arrive, personne ne doit improviser.
« Restaurer en 5 minutes » ne signifie pas que tout est parfait de nouveau. Cela veut dire que vous pouvez rapidement remettre les utilisateurs sur une version fonctionnelle, même si la nouvelle release est toujours défaillante.
Service d'abord, corrections ensuite. Si vous pouvez rétablir le service rapidement, vous gagnez du temps calme pour trouver le vrai bug.
Le chronomètre commence quand vous vous mettez d'accord : « Nous effectuons un rollback. » Il n'inclut pas une longue discussion pour savoir si les choses peuvent se rétablir d'elles‑mêmes.
Décidez de votre déclencheur de rollback à l'avance. Par exemple : « Si les erreurs de checkout restent au‑dessus de X% pendant 3 minutes après le déploiement, on rollbacke. » Quand le déclencheur est atteint, suivez le script.
« Restauré » doit être un petit ensemble de signaux qui indiquent que les utilisateurs sont en sécurité et que le système est stable. Gardez‑le serré et facile à vérifier :
Lorsque ces signaux sont bons, arrêtez le chronomètre des 5 minutes. Tout le reste peut attendre.
Pour que l'exercice reste honnête, marquez explicitement ce que vous ne faites pas pendant le chemin des 5 minutes : debug approfondi, changements de code ou hotfix, et tout ce qui se transforme en travail d'ingénierie.
Un rollback ne semble rapide que lorsque la décision est en grande partie déjà prise. Choisissez une approche qui fonctionne pour la plupart des incidents, puis entraînez‑vous jusqu'à ce que ce soit ennuyeux.
Votre exercice doit répondre à quatre questions :
Le rollback est préférable quand la nouvelle release nuit activement aux utilisateurs ou aux données, et que vous avez déjà une version connue comme bonne à restaurer. Le hotfix est préférable quand l'impact est petit, le changement isolé et que vous êtes confiants de pouvoir patcher en sécurité.
Une règle par défaut simple marche bien : si les utilisateurs ne peuvent pas compléter l'action principale (checkout, login, inscription) ou si le taux d'erreur explose, rollbackez d'abord et corrigez ensuite. Réservez les hotfixes aux problèmes qui sont gênants mais pas dangereux.
Votre « cible » doit être quelque chose que l'équipe peut sélectionner rapidement, sans débat. La plupart des équipes ont trois cibles communes :
Si vous disposez de snapshots de déploiement fiables, faites-en le défaut car c'est le plus répétable sous pression. Gardez le rollback uniquement de configuration comme chemin séparé pour les cas où le code est correct mais un paramètre est mauvais.
Définissez aussi ce qui compte comme « précédent bon ». Ce doit être la release la plus récente qui a terminé les contrôles de monitoring et n'avait pas d'incident actif, pas « celle dont les gens se souviennent ».
N'attendez pas une réunion pendant un incident. Écrivez les déclencheurs qui lancent un rollback et tenez‑vous‑y. Les déclencheurs typiques incluent un flux principal cassé pendant plus de quelques minutes, un taux d'erreur ou une latence franchissant des seuils convenus, un risque sur les données (écritures incorrectes, doubles prélèvements) et toute question de sécurité ou de confidentialité introduite par la release.
Puis décidez qui peut approuver le rollback. Choisissez un rôle (incident lead ou on‑call), plus un remplaçant. Tout le monde peut conseiller, mais personne ne doit pouvoir bloquer. Quand le déclencheur est atteint et que l'approbateur dit « rollback », l'équipe exécute les mêmes étapes à chaque fois.
Un exercice de rollback ne fonctionne que si vous pouvez revenir rapidement à un état connu comme bon. Les snapshots ne sont pas juste « agréables à avoir ». Ce sont des reçus qui prouvent ce qui tournait, ce qui a changé et comment revenir.
Avant chaque release, assurez‑vous de pouvoir récupérer ces éléments sans fouiller dans les historiques de chat :
La sécurité de la base de données est le piège habituel. Un rollback rapide de l'app n'aide pas si la base de données attend désormais le nouveau schéma. Pour les migrations risquées, planifiez une release en deux étapes (ajouter d'abord les nouveaux champs, commencer à les utiliser plus tard) afin que le rollback reste possible.
Utilisez une règle de nommage unique partout, et faites‑la triable :
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
Incluez l'environnement, l'horodatage, la version et le commit. Si vos outils proposent des snapshots dans une UI, utilisez la même règle de nommage là‑bas pour que n'importe qui puisse localiser le bon point de restauration pendant un incident.
Un exercice de rollback est plus rapide et plus calme quand chacun connaît son rôle. L'objectif n'est pas « tout le monde saute ». C'est une personne qui décide, une personne qui agit, une personne qui confirme et une personne qui informe les autres.
Pour les petites et moyennes équipes, ces rôles fonctionnent bien (une personne peut cumuler deux casquettes si nécessaire, mais évitez de combiner Déployeur et Vérificateur pendant l'exercice) :
Les permissions décident si ce plan est réel ou juste un joli document. Avant l'exercice, accordez‑vous sur qui est autorisé à rollbacker la production et comment fonctionnent les urgences.
Une configuration simple :
Si vous utilisez une plateforme qui gère snapshots et rollback (y compris Koder.ai), décidez qui peut créer des snapshots, qui peut les restaurer et où cette action est enregistrée.
Un exercice de rollback fonctionne mieux quand il ressemble à un exercice d'incendie : mêmes étapes, mêmes mots, mêmes endroits pour cliquer. Le but n'est pas la perfection. C'est que n'importe qui en on‑call puisse restaurer rapidement la dernière version connue comme bonne, sans débattre des options.
Choisissez un déclencheur clair et dites‑le à voix haute quand l'exercice commence. Exemples : « Checkout retourne 500 pendant plus d'1 minute » ou « Le taux d'erreur est 5x la normale juste après le déploiement. » Le dire empêche l'équipe de dériver vers la recherche de causes.
Gardez une courte liste de préparation à côté du runbook :
Démarrer le chrono. Une personne énonce le déclencheur et la décision : « Nous faisons un rollback maintenant. »
Geler les changements. Mettez en pause les nouveaux déploiements et arrêtez les modifications non essentielles qui pourraient changer le système en plein rollback.
Prendre un snapshot de dernière chance (si sûr et rapide). C'est une protection si vous devez recréer l'état cassé plus tard. Nommez‑le clairement et passez à la suite.
Exécuter l'action de rollback exactement comme documenté. N'improvisez pas. Lisez les messages de confirmation à voix haute pour que le chronométreur capture ce qui s'est passé.
Confirmer que le rollback est terminé dans un endroit de confiance. Utilisez toujours un écran et un signal unique (vue historique de déploiement, étiquette « version actuelle » ou un indicateur d'état clair).
Juste après l'action, capturez l'essentiel pendant que c'est frais :
Si le rollback prend plus de 5 minutes, n'expliquez pas cela par des circonstances. Trouvez l'étape lente, corrigez le runbook et refaites l'exercice.
Un rollback n'a « fonctionné » que lorsque les utilisateurs le ressentent. Vous n'essayez pas de prouver que l'ancienne version est déployée. Vous prouvez que le service est à nouveau utilisable et stable.
Gardez la vérification petite et répétable. Si la liste fait plus de cinq éléments, les gens la sauteront sous stress.
Utilisez des checks rapides avec un résultat clair pass/échoué :
Après les vérifications fonctionnelles, jetez un œil au signal de santé système le plus simple que vous faites confiance à voir. Vous voulez voir le taux d'erreur chuter et la latence cesser de grimper en quelques minutes.
Confirmez aussi que les parties moins visibles repartent. Les jobs en arrière‑plan doivent s'exécuter et les files doivent se vider, pas grossir. Les vérifs DB doivent être rapides et ennuyeuses : connexions stables, pas d'accumulation de verrous évidente, et l'app peut écrire.
Enfin, testez le monde extérieur quand c'est pertinent et sûr : effectuez un test de paiement si possible, confirmez la délivrabilité des emails et vérifiez que les webhooks sont acceptés (ou au moins qu'ils ne failent pas).
Pré‑écrivez une phrase pour éviter l'improvisation :
« Rollback terminé. Flux core vérifiés (login + checkout). Taux d'erreur et latence revenus à la normale. Monitoring pendant 30 minutes. Prochaine mise à jour à 14:30. »
Il est 10:02 un mardi. Une nouvelle release sort, et en une minute une partie des utilisateurs ne peut plus se connecter. Certains obtiennent « session invalide », d'autres voient un spinner qui ne finit jamais. Les inscriptions fonctionnent encore, donc le problème est facile à rater au début.
Le premier signal n'est généralement pas une panne dramatique. C'est un pic discret : tickets support, baisse des connexions réussies et quelques messages en colère d'utilisateurs réels. L'on‑call voit une alerte « taux de succès de login en baisse de 18% en 5 minutes », et le support poste : « 3 utilisateurs ne peuvent pas se connecter après la mise à jour. »
Parce que l'équipe s'est entraînée, elle ne débat pas longtemps. Elle confirme, décide et agit.
Ce qui est reverté : le code applicatif et la config pour les services web et API. Ce qui reste : la base de données et les données utilisateur.
Si la release incluait une migration de base de données, la règle du drill est simple : ne jamais rollbacker la base de données dans le chemin des 5 minutes. Gardez les migrations backward‑compatible, ou mettez en pause et demandez un second regard avant de deployer.
Pendant le rollback, l'incident lead poste des mises à jour courtes toutes les quelques minutes : ce que voient les utilisateurs, quelle action est en cours et quand la prochaine mise à jour aura lieu. Exemple : « Nous rollbackons la dernière release pour restaurer le login. Prochaine mise à jour dans 2 minutes. »
Après le rollback, ils bouclent la boucle : « Le login est revenu à la normale. L'analyse racine est en cours. Nous partagerons ce qui s'est passé et ce que nous avons changé pour éviter les répétitions. »
Un bon exercice de rollback doit être ennuyeux. S'il est stressant, l'exercice expose probablement des lacunes réelles : accès, snapshots manquants, ou étapes qui n'existent que dans la tête de quelqu'un.
Vous vous entraînez avec des accès supposés, pas des permissions réelles. Les gens découvrent en plein incident qu'ils ne peuvent pas déployer, changer la config ou accéder aux dashboards. Correctif : faites l'exercice avec les mêmes comptes et rôles que vous utiliseriez pendant un incident.
Les snapshots existent, mais ils sont incomplets ou difficiles à trouver. On snapshotte l'app mais on oublie les changements d'env, les feature flags ou le routage. Ou le nom du snapshot n'a aucun sens. Correctif : faites de la création de snapshot une étape de release avec une règle de nommage et vérifiez pendant les drills que le snapshot est visible et restaurable rapidement.
Les migrations DB rendent le rollback dangereux. Un changement de schéma incompatible transforme un rollback rapide en problème de données. Correctif : préférez des migrations additives. Si un changement cassant est inévitable, planifiez un correctif forward et marquez clairement la release : « rollback allowed: yes/no ».
Vous déclarez le succès avant d'avoir vérifié ce que ressentent les utilisateurs. L'app est déployée, mais le login est encore cassé ou les jobs sont bloqués. Correctif : gardez la vérification courte mais réelle, et timeboxez‑la.
L'exercice est trop complexe pour être répété. Trop d'outils, trop de checks, trop de voix. Correctif : réduisez l'exercice à une page et un propriétaire. Si ça ne peut pas se faire à partir d'un seul runbook et d'un seul canal de communication, ça n'arrivera pas sous pression.
Un bon exercice de rollback est une habitude, pas une performance héroïque. Si vous ne pouvez pas le terminer calmement, enlevez des étapes jusqu'à y parvenir, puis n'ajoutez que ce qui réduit réellement le risque.
Un exercice de rollback marche mieux quand tout le monde suit la même checklist d'une page. Gardez‑la épinglée là où votre équipe regarde vraiment.
Une version compacte que vous pouvez exécuter en moins de 10 minutes (préparation et vérification incluses) :
Faites les drills assez souvent pour que les étapes deviennent normales. Mensuel est un bon défaut. Si votre produit change quotidiennement, faites‑les toutes les deux semaines, mais gardez la vérification concentrée sur le parcours utilisateur principal.
Après chaque drill, mettez à jour le runbook le jour même pendant que c'est frais. Stockez‑le avec les notes de release et ajoutez une ligne « testé en dernier » datée pour que personne ne fasse confiance à une procédure obsolète.
Mesurez uniquement ce qui vous aide à vous améliorer :
Si votre équipe utilise Koder.ai, traitez snapshots et rollback comme une habitude : nommez les snapshots de manière cohérente, répétez les restaurations dans la même interface que vous utiliserez en on‑call, et incluez des vérifications rapides de domaine personnalisé et d'intégrations dans les étapes du vérificateur. Mentionner cela dans le runbook garde l'exercice aligné avec votre manière réelle de livrer.
Un exercice de rollback est une répétition où vous simulez une mauvaise release et suivez une procédure écrite pour restaurer la dernière version connue comme bonne.
L'objectif n'est pas de « déboguer vite » : il s'agit de rendre la restauration du service répétable et sereine sous pression.
Définissez un déclencheur à l'avance pour éviter le débat sur le moment. Exemples courants :
Si le déclencheur est atteint, retournez en arrière d'abord, puis investiguez une fois les utilisateurs en sécurité.
Cela signifie que vous pouvez remettre rapidement les utilisateurs sur une version fonctionnelle, même si la nouvelle release est toujours défaillante.
Concrètement, « restauré » correspond à un petit ensemble de signaux sains : l'action utilisateur essentielle fonctionne, le taux d'erreur et la latence redeviennent proches de la normale, et il n'y a pas de boucle de crash.
Choisissez une cible que l'équipe peut sélectionner en quelques secondes, sans discussion :
Définissez « précédent bon » comme la release la plus récente ayant un monitoring normal et sans incident actif — pas celle que quelqu'un se rappelle juste.
Au minimum, capturez avant chaque release :
Les changements de base de données sont le piège courant : un rollback d'app ne servira à rien si le schéma n'est pas compatible.
Nommez-les pour qu'ils se trient et se retrouvent vite, par exemple :
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123Incluez l'environnement + l'horodatage + la version + le commit. La cohérence compte plus que le format exact.
Une répartition simple et répétable pour petites équipes :
Évitez que le Deployer soit aussi le Verifier pendant les exercices ; on veut une vérification indépendante « ça marche vraiment ? ».
Gardez-le minuscule et binaire. Exemples de vérifications incontournables :
Ensuite, confirmez que le taux d'erreur et la latence reviennent près de la normale, et que les files/jobs ne s'accumulent pas.
Ne faites pas du rollback de base de données le chemin 5 minutes. Au lieu de cela :
Cela maintient le chemin de rollback rapide sûr et prévisible.
Si votre plateforme prend en charge snapshots et restauration dans le flux de release, les exercices deviennent plus simples parce que « revenir au connu bon » devient une action normale.
Sur Koder.ai en particulier, décidez à l'avance :
L'outil n'élimine pas le besoin de rôles, déclencheurs et d'une courte liste de vérifications.