Que se passe-t-il après un rollback : vérifier que votre récupération a réellement fonctionné

Vous venez d'appuyer sur le bouton de rollback. Le déploiement qui causait des erreurs, des ralentissements ou une corruption de base de données a disparu. Votre application est revenue à la version précédente. Votre équipe souffle.

Mais le système fonctionne-t-il vraiment ?

Effectuer un rollback ou un roll-forward n'est pas la fin d'un incident. C'en est le milieu. La vraie question est de savoir si la récupération elle-même a introduit de nouveaux problèmes, laissé des données résiduelles, ou cassé des intégrations avec d'autres services. Sans une vérification appropriée après la récupération, vous risquez de déclarer l'incident résolu alors que le système est toujours en panne, d'une manière qui ne se manifestera que des heures plus tard.

Les risques cachés de la récupération

Lorsque vous revenez en arrière sur une application, vous ne remontez pas simplement le temps. L'ancienne version revient, mais l'environnement a peut-être changé. Les schémas de base de données peuvent ne pas correspondre. Les fichiers de configuration peuvent provenir de la version plus récente. Les données écrites par la version problématique restent dans la base de données. Les services qui dépendaient du nouveau format d'API reçoivent désormais d'anciennes réponses et tombent en panne.

Le roll-forward avec un correctif chaud comporte ses propres risques. Vous avez corrigé un bug, mais le correctif a peut-être modifié autre chose. Une valeur de configuration qui fonctionnait dans le correctif d'urgence pourrait ne pas être correcte pour un fonctionnement normal. Le correctif a peut-être été écrit rapidement sans les tests habituels et pourrait contenir ses propres défauts.

C'est pourquoi la vérification après la récupération n'est pas facultative. C'est le filet de sécurité qui rattrape les problèmes que la récupération elle-même crée.

Commencez par des tests de fumée

Le moyen le plus rapide de vérifier si le système est vivant est un test de fumée. Il s'agit d'un court ensemble de vérifications qui confirment le fonctionnement des fonctions essentielles de votre application. Pas toutes les fonctionnalités, pas tous les cas limites, juste les chemins critiques dont dépendent les utilisateurs.

Un bon test de fumée pour une application web pourrait inclure :

• Les utilisateurs peuvent-ils se connecter ?
• Peuvent-ils voir leur tableau de bord principal ?
• Peuvent-ils soumettre un formulaire ou effectuer une transaction ?
• Y a-t-il des erreurs dans les journaux d'application ?

Ces vérifications doivent être automatisées. Si votre test de fumée nécessite qu'une personne clique manuellement sur des écrans, il sera ignoré lorsque l'équipe sera fatiguée et sous pression après un incident. Automatisez-le pour que, quelques minutes après la fin de la récupération, le test de fumée s'exécute et donne un résultat clair : succès ou échec.

Par exemple, un test de fumée automatisé simple utilisant curl pourrait ressembler à ceci :

#!/bin/bash
# Test de fumée simple après un rollback

BASE_URL="https://my-app.example.com"

# Vérifier le point de terminaison de santé
if ! curl -f -s -o /dev/null "$BASE_URL/health"; then
  echo "ÉCHEC : Point de terminaison de santé inaccessible"
  exit 1
fi

# Vérifier que la page de connexion se charge
if ! curl -f -s -o /dev/null "$BASE_URL/login"; then
  echo "ÉCHEC : La page de connexion ne se charge pas"
  exit 1
fi

# Vérifier que l'API renvoie 200 pour un point de terminaison critique
if ! curl -f -s -o /dev/null "$BASE_URL/api/v1/status"; then
  echo "ÉCHEC : Le point de terminaison de statut de l'API a échoué"
  exit 1
fi

echo "SUCCÈS : Tous les tests de fumée ont réussi"

Comparez les métriques avant et après

Les tests de fumée vous disent que l'application fonctionne. Les métriques vous disent si elle fonctionne bien.

Comparez les métriques clés d'avant l'incident, pendant l'incident et après la récupération. Les métriques importantes dépendent de votre application, mais les plus courantes incluent :

• Requêtes par seconde
• Taux d'erreur (pourcentage de requêtes ayant échoué)
• Temps de réponse moyen
• Utilisation de la mémoire et du processeur
• Latence des requêtes de base de données

Si le taux d'erreur après la récupération est toujours plus élevé qu'avant l'incident, quelque chose ne va pas. Peut-être qu'un service n'a pas redémarré correctement. Peut-être qu'une configuration n'a pas été annulée. Peut-être que le processus de récupération lui-même a introduit un nouveau goulot d'étranglement.

Ne vous fiez pas à une seule métrique. Un faible taux d'erreur combiné à une latence élevée peut toujours signifier que le système est en mauvaise santé. Regardez l'ensemble du tableau.

La vérification de la base de données nécessite une attention particulière

La récupération de la base de données est la partie la plus délicate. Si vous êtes revenu à une sauvegarde prise avant le déploiement, toutes les données écrites entre cette sauvegarde et le rollback sont perdues. Ces données peuvent inclure des transactions utilisateur, des commandes ou des modifications de configuration.

Vous devez vérifier :

• La perte de données est-elle acceptable d'un point de vue commercial ?
• Pouvez-vous récupérer les données critiques à partir des journaux ou d'autres systèmes ?
• Y a-t-il des enregistrements orphelins laissés par la version plus récente que l'ancienne version ne peut pas gérer ?

Parfois, la réponse est qu'une certaine perte de données est acceptable. D'autres fois, vous devez restaurer manuellement des enregistrements spécifiques. Dans les deux cas, vous devez savoir ce qui a été perdu et décider si une action est nécessaire.

Vérifiez les intégrations avec d'autres systèmes

Votre application ne vit pas en isolation. Après la récupération, l'ancienne version pourrait ne pas être compatible avec les API que d'autres équipes ont modifiées pendant que votre déploiement était en cours. Ou le correctif chaud a peut-être modifié le format des données envoyées aux systèmes de surveillance, de journalisation ou d'analyse.

Testez les connexions :

• Votre application peut-elle toujours appeler des API externes ?
• Ces API renvoient-elles des réponses que votre version peut analyser ?
• Les services en aval reçoivent-ils les données qu'ils attendent ?

Les problèmes d'intégration après la récupération sont courants car les équipes se concentrent souvent sur leur propre application et oublient les services qui en dépendent ou dont elle dépend.

Vérifiez du point de vue de l'utilisateur

Les tableaux de bord et les journaux montrent ce que fait le système. Ils ne montrent pas toujours ce que vit l'utilisateur. Un utilisateur peut voir une page blanche qui ne génère pas de journal d'erreur. Une transaction peut échouer silencieusement car le frontend n'affiche pas le message d'erreur.

Si possible, demandez à des utilisateurs internes de tester les fonctionnalités principales après la récupération. Ou utilisez des outils de surveillance utilisateur réels pour vérifier des métriques comme le taux de réussite des transactions et la durée des sessions. Ces métriques révèlent souvent des problèmes que la surveillance de l'infrastructure ne détecte pas.

Documentez ce que vous avez trouvé

Une fois la vérification terminée, notez ce qui s'est passé. Cette documentation sert à deux fins :

1. Elle fournit la preuve que la récupération a réussi et que le système est revenu à la normale.
2. Elle aide votre équipe à améliorer le processus de déploiement et de récupération pour la prochaine fois.

Incluez ce qui n'a pas fonctionné, ce que la récupération a impliqué, ce que vous avez vérifié lors de la vérification et les problèmes que vous avez découverts. Cet enregistrement aidera les autres membres de l'équipe confrontés à des problèmes similaires à l'avenir.

Une liste de vérification pratique

Voici une courte liste de vérification à utiliser après toute récupération :

Le diagramme suivant illustre la séquence de vérification avec des points de décision à chaque étape :

• Test de fumée réussi pour toutes les fonctions critiques
• Taux d'erreur revenu aux niveaux d'avant l'incident
• Temps de réponse normal
• Utilisation des ressources (CPU, mémoire, disque) stable
• Intégrité de la base de données vérifiée, perte de données documentée
• Toutes les intégrations externes fonctionnent
• Les métriques côté utilisateur montrent un comportement normal
• Résultats documentés pour référence future

La véritable fin d'un incident

La vérification après la récupération n'est pas une formalité. C'est la dernière ligne de défense avant de déclarer l'incident résolu. Sans elle, vous risquez de déclarer le système sain alors qu'il est toujours en panne d'une manière qui créera un incident plus grave plus tard.

Le moment où vous confirmez que le système fonctionne réellement, c'est à ce moment-là que l'incident se termine vraiment. Tout ce qui précède n'est que récupération.