Quand les changements d'infrastructure échouent : un guide de récupération pas à pas

Le pipeline est passé au rouge. Un terraform apply qui aurait dû prendre deux minutes tourne depuis quinze minutes. Votre tableau de bord de monitoring affiche cinq ressources qui n'ont pas pu être créées, et les health checks du load balancer renvoient des 503. Le canal de discussion est silencieux pour l'instant, mais vous savez que ce silence ne durera pas.

C'est le moment que tout ingénieur infrastructure redoute. Pas l'échec en lui-même, mais l'incertitude qui s'ensuit : que faire en premier ? Faut-il rollback immédiatement ? Essayer de réparer sur place ? Comment savoir quand tout est réellement revenu à la normale ?

La différence entre une récupération maîtrisée et un chaos improvisé réside dans le fait d'avoir une séquence d'actions claire avant d'en avoir besoin. Voici un guide pratique pour exécuter une récupération lorsque les changements d'infrastructure tournent mal.

Étape 1 : Confirmer l'échec

Le premier signe de problème ne devrait pas venir d'une plainte utilisateur. Il devrait venir de votre pipeline et de vos systèmes de monitoring. Un pipeline CI/CD bien conçu pour les changements d'infrastructure inclut des points de contrôle qui vérifient chaque étape : la ressource a-t-elle été créée avec succès ? La configuration est-elle correcte ? Le service répond-il toujours correctement ?

Voici à quoi ressemble une confirmation d'échec typique en pratique :

# Vérifier la sortie du plan Terraform pour les erreurs
terraform plan -var-file=production.tfvars

# Exemple de sortie montrant un échec clair
# Error: Error creating security group: InvalidGroup.Duplicate: The security group 'web-sg' already exists
#   on main.tf line 42, in resource "aws_security_group" "web":
#   42: resource "aws_security_group" "web" {

# Vérifier les logs du pipeline pour le job en échec
curl -s https://pipeline.internal/api/v1/jobs/12345/logs | tail -50

# Extrait de log exemple
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate
# [INFO] Retry attempt 1/3...
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate

Lorsqu'un point de contrôle échoue, le pipeline s'arrête et signale qu'un problème est survenu. Mais avant de passer en mode récupération, prenez un moment pour confirmer que l'échec est réel. Les alertes de monitoring peuvent se déclencher pour de nombreuses raisons : un problème réseau temporaire, un timeout qui se résout après une nouvelle tentative, ou un faux positif provenant d'un health check mal configuré.

Ce qu'il faut vérifier :

  • Consultez les logs du pipeline. L'erreur est-elle cohérente ou intermittente ?
  • Vérifiez si la même opération réussit lorsqu'elle est relancée manuellement.
  • Assurez-vous que l'alerte de monitoring n'est pas un faux positif connu.

Si l'échec est confirmé, passez à l'étape suivante. S'il s'agissait d'un problème transitoire, documentez-le et passez à autre chose. Inutile de déclencher une récupération complète pour un simple hoquet.

Étape 2 : Décider de la stratégie de récupération

C'est là qu'avoir un plan de récupération pré-écrit porte ses fruits. Dans le feu de l'action, vous ne voulez pas débattre pour savoir s'il faut rollback, appliquer l'ancien état, ou basculer vers un environnement de secours. Ces décisions devraient déjà être documentées et approuvées par l'équipe.

Le facteur clé dans cette décision est le temps. La plupart des plans de récupération définissent une fenêtre de rollback : une période après le changement pendant laquelle un rollback complet est sûr. Si l'échec est détecté en quelques minutes, revenir à l'état précédent est généralement la meilleure option. L'infrastructure n'a pas eu le temps de dériver, et les ressources dépendantes ont peu de chances de s'être adaptées à la nouvelle configuration.

Le diagramme suivant résume le processus de décision :

flowchart TD A[Échec confirmé] --> B{Dans la fenêtre de rollback ?} B -- Oui --> C{Changement propagé à d'autres ressources ?} C -- Non --> D[Rollback complet] C -- Oui --> E[Réapplication de l'état] B -- Non --> F{Environnement de secours disponible ?} F -- Oui --> G[Bascule vers le secours] F -- Non --> H[Réapplication de l'état] D --> I[Exécuter la récupération] E --> I G --> I H --> I

Mais si une heure s'est écoulée et que le changement s'est déjà propagé à d'autres ressources, un simple rollback pourrait causer plus de problèmes qu'il n'en résout. D'autres systèmes ont peut-être commencé à dépendre de la nouvelle configuration. Dans ce cas, la meilleure stratégie pourrait être d'appliquer l'ancien état vers l'avant, ou de basculer vers un environnement de secours qui n'a jamais été touché par le changement défaillant.

Trois stratégies de récupération courantes :

  • Rollback complet : Revenir à l'état précédent exact à l'aide de votre outil Infrastructure as Code.
  • Réapplication de l'état : Appliquer la dernière configuration connue comme bonne sans annuler les autres changements.
  • Bascule : Router le trafic vers un environnement séparé qui n'a pas été affecté par le changement.

La décision doit être guidée par votre plan de récupération, pas par ce qui semble juste sur le moment.

Étape 3 : Exécuter la récupération

Une fois la stratégie choisie, exécutez-la exactement comme documenté. Ce n'est pas le moment d'improviser. Si votre plan dit d'exécuter terraform apply avec un fichier d'état spécifique, exécutez cette commande. N'essayez pas un autre flag ou une version plus récente de l'outil parce que vous pensez que cela pourrait être plus rapide.

Pendant l'exécution, enregistrez chaque action que vous effectuez. Notez l'heure, la commande, la sortie et tout comportement inattendu. Ces logs ne servent pas uniquement aux post-mortems. Ils vous aident à suivre ce qui a été fait au cas où la récupération elle-même causerait de nouveaux problèmes.

Si la stratégie implique une bascule, activez le mécanisme que vous avez préparé plus tôt. Cela peut signifier mettre à jour les enregistrements DNS, changer les cibles du load balancer, ou modifier la configuration de routage. Les étapes exactes dépendent de votre infrastructure, mais le principe est le même : suivez le plan, pas votre intuition.

Étape 4 : Vérifier la récupération

La récupération n'est pas terminée tant que vous n'avez pas vérifié que tout est revenu à la normale. Ne supposez pas que parce que le terraform apply a réussi, l'infrastructure est saine. Ne supposez pas que parce que le serveur est en ligne, l'application fonctionne.

La vérification implique de contrôler plusieurs couches :

  • État des ressources : Les ressources d'infrastructure sont-elles dans la configuration attendue ?
  • Santé des services : Les services sont-ils en cours d'exécution et répondent-ils aux requêtes ?
  • Comportement de l'application : L'application peut-elle remplir ses fonctions principales ?
  • Systèmes dépendants : Les services en aval qui dépendent de cette infrastructure sont-ils également sains ?

Exécutez les mêmes vérifications que votre pipeline effectuerait lors d'un déploiement normal. Si vous avez des tests de smoke automatisés, exécutez-les. Si vous avez des étapes de vérification manuelles, suivez-les. L'objectif est d'être certain, pas simplement optimiste.

Étape 5 : Communiquer le résultat

Une fois la vérification terminée, informez le reste de l'équipe. D'autres ingénieurs attendent peut-être que votre infrastructure se stabilise avant de déployer leurs propres changements. Les équipes d'exploitation surveillent peut-être les mêmes alertes et se demandent si elles doivent escalader.

Une communication claire doit inclure :

  • Ce qui s'est mal passé
  • Ce qui a été fait pour récupérer
  • Si la récupération a réussi
  • Les risques ou observations en cours

Cela évite les changements qui se chevauchent et réduit la confusion. Cela aide également les autres équipes à ajuster leurs plans si nécessaire.

Une checklist pratique de récupération

Quand la pression monte, une simple checklist vous aide à rester concentré. En voici une que vous pouvez adapter pour votre équipe :

  • Confirmer que l'échec est réel (pas un problème transitoire ou une fausse alerte)
  • Vérifier la fenêtre de rollback : combien de temps s'est écoulé depuis le changement ?
  • Sélectionner la stratégie de récupération dans le plan pré-écrit
  • Exécuter les étapes de récupération exactement comme documenté
  • Enregistrer chaque action et son résultat
  • Vérifier l'état de l'infrastructure, la santé des services et le comportement de l'application
  • Communiquer le résultat à l'équipe

Le vrai travail commence après la récupération

L'infrastructure est revenue à la normale. Les alertes se sont calmées. L'équipe peut respirer à nouveau. Mais le processus de récupération n'est pas vraiment terminé tant que vous n'avez pas répondu à une question : pourquoi cela s'est-il produit, et que pouvons-nous faire pour éviter que cela ne se reproduise ?

L'évaluation après la récupération est l'endroit où vous améliorez vos processus. Peut-être que le pipeline a besoin de meilleures vérifications pré-déploiement. Peut-être que le plan de récupération a oublié une étape. Peut-être que l'équipe a besoin d'une politique de fenêtre de rollback plus claire. Quelle que soit la leçon, capturez-la et mettez à jour vos plans en conséquence.

Un changement d'infrastructure qui échoue n'est pas un échec de l'équipe. C'est un signal que le système a besoin d'être amélioré. Les équipes qui récupèrent bien ne sont pas celles qui n'échouent jamais. Ce sont celles qui ont un processus clair, pratiqué et reproductible pour quand les choses tournent mal.