Pourquoi le rollback d'infrastructure n'a rien à voir avec le rollback d'une application

Vous déployez une mise à jour d'application défectueuse. Les utilisateurs voient des erreurs. Votre équipe bascule le répartiteur de charge vers la version précédente, ou le pipeline redéploie l'ancien artefact. En quelques minutes, l'application exécute l'ancien code. Les données sont intactes. La base de données n'a pas changé. Les serveurs sont les mêmes machines qu'avant. Le problème a disparu.

Voilà ce qu'est un rollback d'application. Cela fonctionne parce que les applications sont généralement sans état. Vous échangez le code, et l'ancien comportement revient. Aucun effet secondaire durable.

Imaginez maintenant que vous ayez modifié une règle de pare-feu, redimensionné un disque de base de données ou mis à jour une configuration de sous-réseau. Quelque chose casse. Vous voulez revenir en arrière. Pouvez-vous simplement réappliquer l'ancienne configuration et vous attendre à ce que tout fonctionne ?

Probablement pas.

Le rollback d'infrastructure est un problème d'une autre catégorie. Les ressources impliquées contiennent des données, gèrent des chemins réseau et fournissent des services fondamentaux dont dépendent d'autres systèmes. Lorsque vous modifiez l'infrastructure, vous ne vous contentez pas d'échanger du code. Vous modifiez l'état de quelque chose qui peut avoir des années de données, des connexions à des dizaines de services, ou un rôle de fondation pour tout ce qui se trouve au-dessus.

L'état est le premier problème

Les applications sont conçues pour être jetables. Vous pouvez tuer un conteneur, en créer un nouveau avec l'ancien code, et l'application démarre à neuf. Aucune mémoire de la version précédente. Aucune donnée résiduelle du déploiement défaillant.

L'infrastructure est l'inverse. Une base de données conserve ses données même si vous modifiez sa configuration. Un volume de disque conserve ses fichiers même si vous le redimensionnez. Ces ressources sont avec état. Elles conservent un état qui persiste au-delà du cycle de vie de tout changement de configuration.

Lorsque vous effectuez un rollback d'application, vous restaurez simplement le code. Lorsque vous effectuez un rollback d'infrastructure, vous devez restaurer la configuration sans détruire les données qui se sont accumulées à l'intérieur de la ressource. Ce n'est pas toujours possible.

Voici un exemple concret. Vous passez d'un type d'instance de base de données petit à grand parce que le trafic a augmenté. Le nouveau type d'instance pose problème. Vous voulez revenir à la petite instance. Mais pendant que la grande instance fonctionnait, davantage de données ont été écrites dans la base de données. L'ancienne petite instance ne peut plus contenir ces données. Revenir en arrière n'est pas sûr. Vous ne pouvez pas réduire l'instance sans perdre de données, et vous ne pouvez pas conserver les données si vous revenez en arrière.

La différence devient claire lorsque l'on compare les deux chemins côte à côte.

flowchart TD A[Changement défectueux déployé] --> B{Est-ce une app ?} B -->|Oui| C[Échange de code via LB ou pipeline] C --> D[Ancien code exécuté, aucun effet secondaire] D --> E[Rollback réussi] B -->|Non, c'est de l'infra| F[Identifier les ressources avec état] F --> G{L'état peut-il être préservé ?} G -->|Non| H[Le rollback peut détruire des données] G -->|Oui| I[Vérifier les dépendances] I --> J[Séquence de rollback ordonnée] J --> K[État partiel ou cassé] K --> L[Récupération nécessaire, pas seulement un rollback]

Ce n'est pas un problème d'outil. C'est une contrainte fondamentale des ressources avec état. Le fait d'exécuter la nouvelle configuration modifie la ressource d'une manière que l'ancienne configuration ne peut pas accommoder.

Les dépendances multiplient le risque

Les ressources d'infrastructure existent rarement seules. Un seul changement peut toucher dix ressources interconnectées : un VPC, un sous-réseau, un groupe de sécurité, un répartiteur de charge, plusieurs instances et une base de données. Chaque ressource dépend des autres de manière spécifique.

Lorsque vous effectuez le rollback d'une ressource, les ressources qui en dépendent sont affectées. Restaurer un ancien groupe de sécurité peut casser la communication entre le répartiteur de charge et les instances. Restaurer un sous-réseau peut couper la connexion à la base de données. Le rollback n'est pas une opération unique. C'est une séquence qui doit être ordonnée avec soin, et l'ordre dépend de la façon dont les ressources ont été créées à l'origine et de la façon dont elles ont changé depuis.

En pratique, cela signifie que vous ne pouvez pas simplement exécuter terraform apply sur l'ancien fichier d'état et vous en aller. L'ancien état peut entrer en conflit avec l'état actuel d'autres ressources qui n'ont pas été restaurées. Le résultat est souvent une récupération partielle qui laisse votre infrastructure dans un état cassé.

L'application idempotente ne signifie pas un rollback sûr

Les pipelines d'infrastructure sont conçus pour être idempotents. Vous pouvez exécuter la même configuration plusieurs fois et obtenir le même résultat. Cela fonctionne bien pour appliquer des changements. Mais une application idempotente ne signifie pas un rollback sûr.

Prenons la taille d'un disque. Vous déclarez un disque de 100 Go, vous l'appliquez, et le disque est créé. Vous exécutez la même configuration à nouveau, et rien ne change. C'est idempotent. Maintenant, vous modifiez la configuration à 200 Go et vous l'appliquez. Le disque grandit. Ensuite, vous remettez la configuration à 100 Go et vous l'appliquez à nouveau. Que se passe-t-il ?

La plupart des outils d'infrastructure vont soit rejeter l'opération, soit détruire le disque et en créer un nouveau. Ils ne peuvent pas réduire un disque sans risquer une perte de données. La configuration est idempotente en théorie, mais la ressource réelle a changé d'une manière qui ne peut pas être inversée.

C'est ce qu'on appelle la dérive d'état. La configuration dans votre code dit une chose, mais la ressource réelle dans le cloud ou sur le serveur est différente. Lorsque vous essayez de faire un rollback, vous ne vous contentez pas de revenir sur le code. Vous essayez de réconcilier une configuration qui ne correspond plus à la réalité. Et la réalité gagne souvent.

Ce que cela signifie pour votre équipe

Le rollback d'infrastructure nécessite une préparation différente de celle du rollback d'application. Vous ne pouvez pas compter sur le même pipeline ou le même modèle mental. Vous devez savoir quelles ressources peuvent être restaurées en toute sécurité, lesquelles ne le peuvent pas, et dans quel ordre procéder.

Certains changements sont réversibles. Modifier la configuration d'une vérification d'état d'un répartiteur de charge est généralement sûr à annuler. Modifier un groupe de paramètres de base de données peut être sûr si les nouveaux paramètres n'ont pas altéré les données stockées. Mais changer la taille d'une instance, la taille d'un disque, la topologie du réseau ou le moteur de stockage est souvent irréversible sans perte de données ou temps d'arrêt.

L'approche la plus sûre est de planifier la récupération, pas seulement le rollback. La récupération signifie accepter que l'ancienne configuration ne soit plus valide et construire une voie à suivre plutôt qu'à reculer. Cela peut impliquer la création d'une nouvelle ressource avec l'ancienne configuration et la migration des données, ou l'acceptation d'un état dégradé pendant qu'un correctif est développé.

Liste de contrôle pratique pour les changements d'infrastructure

Avant d'appliquer un changement d'infrastructure, posez-vous ces questions :

  • Cette ressource contient-elle un état ? Si oui, l'état peut-il être préservé si nous revenons sur la configuration ?
  • Quelles autres ressources dépendent de celle-ci ? Le rollback va-t-il casser leur connectivité ?
  • Le changement est-il réversible ? L'outil peut-il réduire un disque, rétrograder une instance ou restaurer un chemin réseau sans détruire de données ?
  • Quel est le plan de récupération réel en cas d'échec du changement ? Est-ce un rollback, une migration ou une reconstruction ?
  • Avons-nous testé le chemin de récupération dans un environnement hors production ?

À retenir

Le rollback d'application est un échange de code. Le rollback d'infrastructure est un problème de réconciliation d'état. Les traiter de la même manière conduit à des systèmes cassés, des pertes de données et des temps de récupération longs. Planifiez la récupération, pas seulement le rollback. Sachez quels changements sont réversibles et testez votre chemin de récupération avant d'en avoir besoin.