29-5 · Chapitre 29 · 6 min de lecture

Quand la récupération automatique de l'infrastructure aggrave les choses

Scénario réel : à 2h du matin, une modification manuelle de base de données est annulée par un pipeline de réconciliation automatique. Solutions pour contrôler ce risque sans abandonner l'automatisation.

Quand la récupération automatique de l'infrastructure aggrave les choses

Il est 2 heures du matin. Votre application de production commence à générer des erreurs de pool de connexions. L'ingénieur d'astreinte se connecte à la console cloud, ajuste un paramètre de base de données, et le système se stabilise. Tout le monde souffle.

Vingt minutes plus tard, les alertes reviennent. Mêmes erreurs. L'ingénieur vérifie la console et constate que le paramètre a été réinitialisé à sa valeur d'origine. Votre pipeline d'infrastructure-as-code a détecté la modification manuelle comme une « dérive » et l'a automatiquement annulée. Vous êtes de retour en incident, et le cycle va se répéter jusqu'à ce que quelqu'un désactive le mécanisme de réconciliation automatique.

Ce scénario n'est pas hypothétique. C'est ce qui se produit quand la réconciliation automatisée traite toute déviation du code comme un problème à corriger.

Le problème de supposer que toute dérive est mauvaise

La réconciliation automatisée semble parfaite sur le papier. Votre pipeline détecte quand l'infrastructure réelle a dérivé de ce qui est défini dans le code, puis applique automatiquement l'état correct. Aucune intervention humaine nécessaire. Aucune fenêtre pour que la dérive persiste.

Mais l'hypothèse de base est erronée : toute dérive n'est pas une erreur. Parfois, des modifications en dehors du pipeline se produisent pour des raisons légitimes, et ces modifications sont ce qui maintient le système en fonctionnement.

Lors d'un incident, les ingénieurs effectuent des changements d'urgence. Lors d'une migration de base de données, les équipes modifient temporairement des ressources dans le cadre d'une procédure minutieuse. Lors de tests de charge, les paramètres de mise à l'échelle sont ajustés à la volée. Ce sont toutes des raisons valables d'avoir une infrastructure qui ne correspond pas à votre référentiel de code.

Un système de réconciliation automatisée n'a aucun moyen de distinguer un changement destructeur d'un changement salvateur. Il sait seulement que l'état réel diffère de l'état souhaité, et son travail est de restaurer l'état souhaité. Il n'a aucun contexte sur la raison pour laquelle la modification a été faite, s'il y a un incident actif, ou si la modification a été validée par l'équipe.

Quand le timing aggrave les choses

Le timing de la réconciliation automatisée crée une autre catégorie de risque. Imaginez une équipe en pleine migration complexe de base de données. Ils modifient délibérément plusieurs ressources cloud manuellement dans le cadre d'une procédure en plusieurs étapes qui n'a pas encore été entièrement capturée dans l'IaC. Si le pipeline de réconciliation s'exécute en pleine migration, il pourrait supprimer des ressources en transition, provoquant une perte de données ou un échec complet de la migration.

Ce n'est pas un cas limite théorique. Les migrations, les mises à niveau d'infrastructure et les réponses aux incidents de sécurité impliquent tous des états temporaires où l'environnement live s'écarte intentionnellement du code. La réconciliation automatisée qui s'exécute pendant ces fenêtres ne cause pas seulement des désagréments. Elle peut corrompre des données, casser des services en cours d'exécution ou annuler des mesures de sécurité critiques qui ont été appliquées manuellement parce que la situation exigeait de la rapidité plutôt que du processus.

Contrôler le risque sans abandonner l'automatisation

La réponse n'est pas de désactiver complètement la réconciliation automatisée. La réponse est de construire des contrôles qui correspondent au fonctionnement réel des opérations.

Le diagramme suivant illustre la boucle de réconciliation problématique et où les contrôles proposés interviennent.

flowchart TD A[Dérive détectée] --> B{Porte d'approbation ?} B -- Non --> C[Annulation auto] C --> D[Incident se répète] D --> A B -- Oui --> E[Revue humaine] E --> F{Dérive légitime ?} F -- Oui --> G[Adopter dans le code] F -- Non --> H[Reconcilier en sécurité] I[Fenêtre de réconciliation] --> B J[Gel des changements] --> B K[Règles d'exclusion] --> A

Portes d'approbation pour la réconciliation

Au lieu de faire appliquer automatiquement les modifications par le pipeline lors de la détection d'une dérive, faites-le s'arrêter à une étape de revue. Envoyez une notification à l'équipe concernée avec les détails de ce qui a changé. Exigez une approbation avant que la réconciliation ne s'exécute. Cela donne à l'équipe le temps de vérifier si la dérive doit être annulée ou adoptée dans la base de code.

Cela ne signifie pas des opérations lentes. Un processus d'approbation bien conçu peut être rapide. L'essentiel est qu'un humain prenne la décision, pas un système automatisé qui manque de contexte.

Fenêtres de réconciliation

Définissez des plages horaires spécifiques pendant lesquelles la réconciliation automatisée est autorisée à s'exécuter. Par exemple, uniquement entre 9h et 17h en semaine. En dehors de ces heures, la dérive est détectée et signalée, mais pas corrigée automatiquement.

Cette règle simple empêche le scénario d'incident à 2h du matin. Si un changement d'urgence survient la nuit, le pipeline le journalisera et alertera l'équipe, mais n'annulera pas la correction avant le matin, quand quelqu'un pourra la revoir correctement.

Gel des changements

Lorsque l'équipe est en période de gel, désactivez toute réconciliation automatisée. Les gels surviennent avant les versions majeures, pendant les audits ou lors de migrations critiques. Pendant un gel, la dérive est surveillée et journalisée, mais aucun changement automatique n'est autorisé. L'équipe peut réactiver la réconciliation après la fin du gel et après avoir confirmé que tous les changements légitimes ont été enregistrés dans le code.

Règles d'exclusion pour les ressources dynamiques

Certaines ressources changent fréquemment en dehors du pipeline par conception. Les groupes de mise à l'échelle automatique ajustent leur taille en fonction de la charge. Les outils de surveillance ajustent automatiquement les configurations. Ces ressources doivent être exclues de la réconciliation automatisée ou bénéficier de règles spéciales qui autorisent certains types de dérive.

Par exemple, dans Terraform, vous pouvez utiliser le bloc lifecycle avec ignore_changes pour empêcher le pipeline d'annuler les ajustements dynamiques légitimes :

resource "aws_autoscaling_group" "app" {
  name               = "production-app-asg"
  min_size           = 2
  max_size           = 10
  desired_capacity   = 4
  launch_configuration = aws_launch_configuration.app.id
  vpc_zone_identifier = ["subnet-abc123", "subnet-def456"]

  lifecycle {
    ignore_changes = [
      desired_capacity,
      min_size,
      max_size,
    ]
  }
}

Cela indique à Terraform d'ignorer les modifications des paramètres de mise à l'échelle, de sorte que les ajustements manuels lors des pics de charge ne soient pas annulés.

Il ne s'agit pas de faire des exceptions à la règle. Il s'agit de reconnaître que certaines infrastructures sont intrinsèquement dynamiques, et que traiter leurs changements opérationnels normaux comme une dérive crée plus de problèmes que cela n'en résout.

Une liste de contrôle pratique

Avant d'activer la réconciliation automatisée pour un groupe de ressources, vérifiez ces points :

L'équipe peut-elle outrepasser ou mettre en pause la réconciliation pendant les incidents ?
Existe-t-il une fenêtre de réconciliation définie qui exclut les heures creuses ?
Les ressources dynamiques comme les groupes de mise à l'échelle automatique sont-elles exclues ou bénéficient-elles de règles spéciales ?
Le pipeline nécessite-t-il une approbation humaine avant d'appliquer les modifications de réconciliation ?
Existe-t-il un processus documenté pour adopter la dérive légitime dans le code ?

Le véritable enseignement

La réconciliation automatisée est un outil, pas une politique. Elle fonctionne bien quand votre infrastructure est stable, que tous vos changements passent par le pipeline et que les incidents sont rares. Elle joue contre vous quand les opérations sont désordonnées, que les urgences surviennent et que les humains doivent prendre des décisions éclairées.

Les équipes qui gèrent bien cela n'automatisent pas tout. Elles automatisent la détection et la notification de la dérive, mais gardent la décision de réconcilier entre des mains humaines. Elles construisent des fenêtres et des gels qui correspondent à leur réalité opérationnelle. Elles excluent les ressources qui sont censées être dynamiques.

Votre infrastructure dérivera de votre code. Une partie de cette dérive sera un problème. Une autre partie sera la raison pour laquelle votre service est resté en ligne. L'objectif n'est pas d'éliminer la dérive. L'objectif est d'avoir suffisamment de contrôle pour savoir à quel type vous avez affaire avant d'agir.