Quand les Changements d'Infrastructure Tournent Mal : Options de Récupération de la Réapplication au Basculement
Vous venez d'exécuter terraform apply sur votre infrastructure de production. La sortie est propre. Aucune erreur. Puis votre alerte de monitoring se déclenche : les utilisateurs ne peuvent pas se connecter à la base de données. La modification du groupe de sécurité que vous avez effectuée a accidentellement bloqué la couche applicative.
Et maintenant ?
Ce moment sépare les équipes qui ont un plan de récupération de celles qui commencent à chercher frénétiquement la dernière configuration valide connue. Les changements d'infrastructure peuvent échouer d'une manière que les rollbacks d'application ne couvrent pas. Une mauvaise poussée de configuration peut ne pas casser votre code, mais elle peut casser la connectivité, le stockage ou le contrôle d'accès. La récupération nécessite son propre playbook.
Parcourons quatre options de récupération, de la plus simple à la plus complexe. Chacune correspond à des situations différentes, et chacune a des compromis que vous devez comprendre avant d'en avoir besoin.
Réappliquer l'Ancien État
L'approche la plus directe : ramener votre infrastructure à la configuration qu'elle avait avant le changement.
Si vous utilisez Terraform, cela signifie exécuter terraform apply avec le fichier d'état ou la configuration précédente. La même idée s'applique à Pulumi, CloudFormation ou tout outil d'infrastructure-as-code. Vous demandez au système de restaurer la version connue et valide de votre définition d'infrastructure.
Cela fonctionne bien lorsque le changement est idempotent et que les ressources impliquées ne contiennent pas de données critiques. Pensez aux règles de groupe de sécurité, aux variables d'environnement sur les instances de calcul ou aux paramètres du répartiteur de charge. Ces ressources peuvent basculer d'avant en arrière sans effets secondaires.
Voici une séquence de commandes concrète pour réappliquer l'ancien état :
# 1. Vérifier que le fichier d'état précédent existe
ls -la terraform.tfstate.backup
# 2. Restaurer l'état précédent (écrase l'état actuel)
cp terraform.tfstate.backup terraform.tfstate
# 3. Prévisualiser les modifications que Terraform va effectuer pour revenir en arrière
terraform plan -state=terraform.tfstate
# 4. Appliquer l'ancien état pour restaurer l'infrastructure
terraform apply -state=terraform.tfstate -auto-approve
Remarque : Vérifiez toujours que le fichier d'état de sauvegarde est valide avant de l'appliquer. Exécutez
terraform state list -state=terraform.tfstate.backuppour confirmer qu'il contient les ressources attendues.
Le hic : vous avez besoin que l'ancien état existe encore. Si votre équipe supprime les anciens fichiers d'état ou si le fournisseur d'infrastructure a nettoyé certaines ressources par ramasse-miettes, vous n'aurez peut-être rien à réappliquer. De plus, cette approche a du mal avec les ressources avec état. Vous ne pouvez pas simplement réappliquer une ancienne configuration de base de données et vous attendre à ce que les données reviennent à leur état précédent.
La réapplication est rapide, nécessite une intervention manuelle minimale et fonctionne pour la plupart des changements d'infrastructure sans état. Mais ce n'est pas une solution universelle.
Restauration d'Instantané
Lorsque votre changement touche des ressources qui contiennent des données, la réapplication ne suffit pas. Vous devez restaurer les données elles-mêmes.
Avant d'apporter une modification à une base de données, un système de fichiers ou toute ressource avec état, prenez un instantané. Les fournisseurs de cloud proposent cela pour les volumes, les bases de données et les buckets de stockage. L'instantané capture l'état de la ressource à un moment précis.
Si le changement échoue, vous restaurez à partir de cet instantané. La base de données revient à son état d'avant le changement. Le système de fichiers retrouve son contenu précédent.
Cette approche est plus lourde que la réapplication. La restauration d'un instantané prend du temps. Pendant ce temps, la ressource peut être indisponible. Les utilisateurs voient des erreurs ou un service dégradé. Mais pour les ressources avec état, la restauration d'instantané est souvent la seule option fiable.
Cela fonctionne mieux lorsque le rayon d'explosion est limité à une ressource ou un composant. Si vous avez modifié un schéma de base de données et que cela a cassé l'application, la restauration de l'instantané de la base de données corrige la couche de données. L'application peut nécessiter un redémarrage, mais les données sont revenues à la normale.
Le principal inconvénient : vous perdez toutes les données écrites entre l'instantané et le changement ayant échoué. Si votre application écrit en continu, cet écart compte. Planifiez le moment de vos instantanés en conséquence.
Rollback DNS
Parfois, la récupération la plus rapide ne consiste pas du tout à restaurer l'infrastructure. Il s'agit de rediriger le trafic loin de la version cassée.
Le rollback DNS fonctionne au niveau du routage du trafic. Au lieu de revenir sur le changement d'infrastructure, vous redirigez le trafic vers l'ancienne infrastructure qui est toujours en cours d'exécution.
Imaginez que vous ayez déployé une nouvelle version de votre serveur d'application. Le serveur lui-même est correct, mais le changement de configuration a cassé quelque chose. Votre ancien serveur est toujours en cours d'exécution avec l'ancienne configuration. Vous mettez à jour l'enregistrement DNS ou la configuration du répartiteur de charge pour renvoyer le trafic vers l'ancien serveur.
C'est rapide. Vraiment rapide. Les changements DNS se propagent rapidement dans des environnements contrôlés, et les mises à jour du répartiteur de charge sont quasi instantanées. Vous n'avez pas besoin de reconstruire ou de restaurer quoi que ce soit.
Mais il y a une exigence critique : l'ancienne infrastructure doit encore exister. Si votre processus de déploiement détruit les anciennes ressources lors de la création des nouvelles, le rollback DNS n'est pas une option. Cette stratégie fonctionne naturellement avec les déploiements bleu-vert ou les versions canaries, où les anciennes et nouvelles versions s'exécutent côte à côte.
Le rollback DNS ne résout pas non plus le problème sous-jacent. L'infrastructure cassée existe toujours. Vous devrez enquêter et la réparer plus tard. Mais pour remettre les utilisateurs en ligne rapidement, c'est difficile à battre.
Basculement vers un Environnement de Secours
C'est l'option de récupération la plus complexe, et aussi la plus fiable pour les systèmes critiques.
Vous maintenez un deuxième environnement qui reflète votre configuration de production. Cela peut être dans une zone de disponibilité différente, une région différente, ou même un fournisseur de cloud différent. L'environnement de secours exécute la même infrastructure, la même version d'application et dispose de données synchronisées.
Lorsqu'un changement en production échoue et que l'impact est étendu, vous basculez. Tout le trafic est déplacé vers l'environnement de secours. Les utilisateurs continuent de travailler, et vous gagnez du temps pour réparer l'environnement de production.
Le basculement implique des changements DNS, la gestion de la réplication de base de données et la synchronisation des données. Ce n'est pas quelque chose que vous voulez comprendre pendant un incident. Vous devez tester le processus de basculement régulièrement, idéalement dans le cadre de vos opérations normales.
L'investissement est significatif. L'environnement de secours coûte de l'argent à faire fonctionner. La synchronisation des données ajoute de la complexité. Vous avez besoin de personnes qui comprennent le processus de basculement et peuvent l'exécuter sous pression.
Mais pour une infrastructure qui doit rester opérationnelle, le basculement est l'option la plus fiable. Les banques, les systèmes de santé et les plateformes de commerce électronique à grande échelle utilisent cette approche car le coût des temps d'arrêt dépasse de loin le coût de maintenance d'un environnement de secours.
Choisir la Bonne Option
Chaque option de récupération correspond à différents scénarios :
- Réappliquer l'ancien état : Changements sans état, correctifs rapides, faible risque de données
- Restauration d'instantané : Changements avec état, impact sur une seule ressource, intégrité des données requise
- Rollback DNS : Environnements parallèles, récupération rapide, ancienne infrastructure toujours existante
- Basculement : Systèmes critiques, large rayon d'explosion, exigences de haute disponibilité
Votre choix dépend de trois facteurs : le type de changement que vous effectuez, le rayon d'explosion potentiel et la rapidité avec laquelle vous devez récupérer.
L'organigramme suivant associe les scénarios de défaillance courants au chemin de récupération recommandé :
Liste de Vérification Pratique Avant Votre Prochain Changement d'Infrastructure
Avant d'exécuter ce prochain terraform apply ou de pousser un changement de configuration, parcourez cette liste de vérification :
- Est-ce que je connais l'option de récupération pour ce changement ?
- Le fichier d'état ancien est-il accessible et valide ?
- Ai-je pris un instantané si le changement touche des ressources avec état ?
- L'ancienne infrastructure est-elle toujours en cours d'exécution si j'ai besoin d'un rollback DNS ?
- Ai-je testé le processus de basculement au cours du dernier mois ?
- L'équipe sait-elle qui exécute la récupération et comment ?
L'Essentiel à Retenir
La récupération après des défaillances d'infrastructure ne consiste pas à avoir une stratégie parfaite. Il s'agit de faire correspondre l'option de récupération au changement que vous effectuez. Un changement de groupe de sécurité ne nécessite pas un basculement complet. Une migration de base de données nécessite probablement un instantané. Un déploiement canari bénéficie d'un rollback DNS.
Connaissez vos options avant d'en avoir besoin. Le moment de décider comment récupérer est avant d'effectuer le changement, pas après que les alertes commencent à se déclencher.