Quand l'infrastructure dérive : comment décider entre corriger ou accepter

Vous ouvrez votre tableau de bord d'infrastructure un lundi matin. Tout semble normal au premier coup d'œil. Puis vous remarquez quelque chose : la taille de l'instance de base de données est différente de ce que définit votre code Terraform. Quelqu'un l'a modifiée via la console cloud pendant le week-end. Le pipeline n'a pas été exécuté. Le code dit une chose, mais l'infrastructure réelle en dit une autre.

C'est ce qu'on appelle la dérive. Cela arrive plus souvent que la plupart des équipes ne l'admettent. Quelqu'un effectue une modification manuelle lors d'un incident. Un fournisseur cloud met à jour automatiquement une propriété de ressource. Un collègue modifie directement une règle de groupe de sécurité parce qu'il avait besoin que ce soit fait rapidement. Quelle qu'en soit la cause, vous avez désormais un écart entre ce que votre code déclare et ce qui existe réellement dans votre infrastructure.

La question n'est pas de savoir si la dérive va se produire. Elle se produira. La vraie question est de savoir ce que vous faites après l'avoir détectée.

Les trois voies de réconciliation

La réconciliation est le processus qui consiste à remettre votre infrastructure en conformité avec les définitions de votre code. Mais il n'existe pas de méthode unique et correcte. La meilleure approche dépend de la situation, du risque encouru et du contexte derrière le changement.

Utilisez cet arbre de décision pour déterminer rapidement quelle voie correspond à votre situation :

flowchart TD A[Dérive détectée] --> B{Savez-vous pourquoi ?} B -- Non --> C[Enquêter d'abord] B -- Oui --> D{Était-ce intentionnel ?} D -- Non --> E[Réappliquer le pipeline] D -- Oui --> F{Changement bénéfique ?} F -- Oui --> G[Adopter la dérive] F -- Non --> H{Ressource en production ?} H -- Oui --> I[Correction manuelle] H -- Non --> E C --> D

Voie une : réappliquer le pipeline

L'option la plus simple consiste à exécuter à nouveau votre pipeline sans modifier le code. Vous reprenez votre Infrastructure as Code (IaC) existante, la conservez exactement telle quelle, et exécutez l'étape d'application. Des outils comme Terraform, Pulumi ou AWS CloudFormation comparent le fichier d'état aux ressources réelles et effectuent les ajustements nécessaires pour tout restaurer selon ce que le code définit.

Cette approche fonctionne bien lorsque la dérive est accidentelle. Quelqu'un a redimensionné une instance via la console sans se rendre compte qu'il contournait le pipeline. Un développeur a temporairement ouvert un port de groupe de sécurité pour déboguer et a oublié de le fermer. Un travail planifié d'une autre équipe a modifié une balise sur vos ressources. Dans ces cas, réappliquer le pipeline est propre et sûr. Le code représente l'état souhaité, et l'infrastructure a simplement besoin de rattraper son retard.

Le risque ici est faible car les modifications n'étaient pas intentionnelles. Vous corrigez une erreur, vous n'annulez pas une décision délibérée.

Voie deux : adopter la dérive

Parfois, la modification manuelle était en fait la bonne chose à faire. Lors d'un incident de production, votre équipe d'exploitation a augmenté la capacité de la base de données pour gérer un pic de trafic. L'application est restée opérationnelle grâce à ce changement. Après l'incident, vous réalisez que la nouvelle capacité est plus adaptée à votre charge de travail actuelle. L'ancienne valeur dans votre code est désormais obsolète.

Dans ce cas, revenir à l'ancien code serait une erreur. Vous annuleriez un correctif qui a maintenu votre système en fonctionnement. Au lieu de cela, vous mettez à jour votre IaC pour refléter le nouvel état. C'est ce qu'on appelle adopter la dérive. Vous modifiez le code pour qu'il corresponde à ce qui est réellement en cours d'exécution, puis vous exécutez le pipeline pour confirmer que tout est cohérent.

Adopter la dérive maintient votre pipeline comme source unique de vérité tout en préservant les changements qui se sont avérés utiles. Mais cela nécessite une évaluation minutieuse. Vous devez comprendre pourquoi la modification a été effectuée, si elle a été testée et si elle introduit des effets secondaires. Adopter la dérive sans examen peut transformer votre IaC en un ensemble désordonné de décisions non documentées.

Voie trois : correction manuelle

Il existe des situations où l'exécution d'un pipeline automatisé est trop risquée. La ressource qui a dérivé sert du trafic en direct. Une modification de groupe de sécurité protège un point d'accès critique. Une configuration d'équilibreur de charge répartit les requêtes entre les instances. Si votre pipeline applique les modifications automatiquement, cela pourrait provoquer une brève interruption, voire une panne complète.

Dans ces cas, la correction manuelle est le choix le plus sûr. Une personne ayant accès à la console cloud ou au serveur examine les modifications une par une, les annule soigneusement et surveille l'impact en temps réel. C'est plus lent et plus exigeant en main-d'œuvre, mais cela vous donne le contrôle sur l'ordre et le moment de chaque modification.

La correction manuelle n'est pas un échec de l'automatisation. C'est la reconnaissance que certaines ressources nécessitent un jugement humain lors de la récupération. L'essentiel est de documenter ce qui a été fait et pourquoi, afin que la prochaine fois que la même dérive apparaîtra, vous puissiez décider s'il faut automatiser la correction.

Qui doit décider ?

La réconciliation n'est pas une décision purement technique. Elle nécessite du contexte. La dérive a-t-elle été causée par une erreur, un incident ou une expérience qui n'a jamais été enregistrée ? La réponse détermine la voie à suivre.

La décision doit impliquer les personnes qui comprennent le changement et son impact. Cela peut être l'équipe d'exploitation qui a géré l'incident, le développeur qui a effectué la correction manuelle, ou l'ingénieur de plateforme qui surveille le comportement du système. Une seule personne prenant la décision en isolation peut facilement mal évaluer la situation.

Une règle empirique simple : si vous ne savez pas pourquoi la dérive s'est produite, ne réconciliez pas automatiquement. Enquêtez d'abord. Ne réappliquez que lorsque vous êtes sûr que la modification n'était pas intentionnelle. N'adoptez que lorsque vous êtes sûr que la modification était bénéfique. Corrigez manuellement lorsque vous n'êtes sûr ni de l'un ni de l'autre.

Une liste de contrôle pratique pour les décisions de réconciliation

Avant d'agir sur une alerte de détection de dérive, passez en revue ces questions :

  • Est-ce que je sais qui a effectué cette modification et pourquoi ?
  • Cette modification a-t-elle été effectuée lors d'un incident ou sous pression ?
  • La ressource qui a dérivé sert-elle actuellement du trafic de production ?
  • Le fait d'annuler cette modification causerait-il un problème connu ?
  • Existe-t-il un enregistrement de cette modification dans un ticket, un chat ou un runbook ?

Si la réponse à la première question est non, commencez par une enquête, pas par une action. Si la ressource sert du trafic, préférez la correction manuelle à l'application automatisée. Si la modification a été effectuée lors d'un incident, envisagez d'adopter la dérive après un examen approprié.

La réconciliation n'est pas la fin

Une fois la réconciliation effectuée, le travail n'est pas terminé. Vous devez confirmer que la réconciliation n'a pas introduit de nouveaux problèmes. Une application automatisée qui annule une correction de sécurité critique peut exposer votre système. Une modification manuelle adoptée sans test peut introduire de l'instabilité.

L'objectif n'est pas d'éliminer la dérive. L'objectif est de la gérer de manière à maintenir votre système fiable et votre code pertinent. Chaque événement de dérive est aussi une opportunité d'améliorer vos processus. Si la même dérive apparaît sans cesse, votre pipeline a peut-être besoin d'une barrière de sécurité. Si les modifications manuelles sont trop fréquentes, votre processus de réponse aux incidents a peut-être besoin d'un chemin plus clair pour les mises à jour de code post-incident.

L'essentiel à retenir

La dérive n'est pas un signe que votre infrastructure est cassée. C'est un signe que quelque chose s'est produit en dehors de votre pipeline. La bonne réponse dépend du contexte, pas du dogme. Réappliquez lorsque la modification était accidentelle. Adoptez lorsque la modification était utile. Corrigez manuellement lorsque le risque est élevé. Et toujours, toujours comprenez pourquoi la dérive s'est produite avant de décider de la suite.