Pourquoi planifier les changements d'infrastructure avant de les appliquer

Vous examinez une pull request qui modifie une ligne dans un fichier de configuration de pare-feu. Le changement ouvre le port 443 pour le trafic public. Assez simple, non ?

Mais cette seule ligne pourrait avoir des conséquences que vous n'avez pas anticipées. Peut-être qu'une autre règle entre en conflit avec elle. Peut-être que ce port a été intentionnellement fermé pour des raisons de sécurité il y a six mois, et que personne ne se souvient pourquoi. Peut-être que l'ouvrir va casser une connexion de base de données qui passait par un port différent. Vous ne saurez rien de tout cela tant que le changement ne sera pas appliqué et que quelque chose ne cessera de fonctionner.

C'est exactement la situation que le workflow planifier-examiner-appliquer est conçu pour éviter.

Le problème de l'application directe

Lorsque vous appliquez des changements d'infrastructure directement, vous travaillez à l'aveugle. Vous avez peut-être le code sous les yeux, mais le code seul ne vous montre pas ce qui se passera réellement lorsqu'il s'exécutera sur votre environnement de production. L'état réel de votre infrastructure peut être différent de ce que votre code suppose. Quelqu'un a peut-être fait un changement manuel la semaine dernière. Un déploiement précédent a peut-être laissé les choses dans un état inattendu. Votre code dit "ajouter cette règle", mais le système pourrait interpréter cela comme "remplacer toutes les règles existantes par celle-ci".

L'application directe transforme chaque changement en un pari. Vous ne savez que vous avez perdu que lorsque les choses se cassent.

Comment fonctionne le workflow planifier-examiner-appliquer

Le workflow comporte trois étapes, chacune ayant un objectif spécifique.

Le diagramme ci-dessous illustre le flux :

Planifier génère une comparaison détaillée entre l'état actuel de votre infrastructure et l'état que votre code souhaite créer. Il montre exactement ce qui sera ajouté, modifié ou supprimé. Ce n'est pas un résumé ou une supposition. C'est un diff précis, généré par machine, de votre infrastructure.

Examiner est l'étape où les humains analysent ce plan. Vous vérifiez qu'il n'y a pas de surprises. Vous vous assurez que le plan correspond à l'intention du changement. Vous repérez des choses comme "cette suppression de groupe de sécurité va affecter les serveurs de production" avant que quiconque n'appuie sur le bouton d'application.

Appliquer exécute les changements planifiés. Comme le plan a déjà été vérifié, l'étape d'application présente un risque beaucoup plus faible de résultats inattendus. Vous ne devinez plus. Vous exécutez un ensemble connu de changements.

À quoi ressemble réellement un plan

Un plan n'est pas une description vague. C'est une liste concrète d'opérations. Par exemple, un plan pourrait montrer :

• Ajouter une nouvelle règle de groupe de sécurité pour le port 443
• Modifier un écouteur de load balancer existant pour utiliser un nouveau certificat
• Supprimer un groupe de sous-réseaux de base de données qui n'est plus référencé

Chaque opération inclut l'identifiant de la ressource, la valeur actuelle et la nouvelle valeur. Ce niveau de détail vous permet de repérer les problèmes avant qu'ils ne se produisent. Vous pourriez voir que le plan veut supprimer une ressource que vous pensiez inutilisée, ou modifier un paramètre dont une autre équipe dépend.

Faire du plan une exigence stricte

Les équipes les plus efficaces traitent le plan comme une étape non négociable. Leur pipeline est configuré pour s'arrêter si aucun plan n'a été généré, ou si le plan n'a pas été examiné et approuvé. C'est l'équivalent infrastructure de l'exigence d'une revue de code avant de fusionner une pull request. Vous ne fusionneriez pas du code non revu en production. Pourquoi appliqueriez-vous des changements d'infrastructure non revus ?

Cette barrière de sécurité empêche le schéma d'échec le plus courant : quelqu'un fait un petit changement, suppose qu'il est sûr, et l'applique sans vérification. Le pipeline les oblige à générer d'abord un plan, ce qui révèle souvent quelque chose qu'ils n'attendaient pas.

Les plans comme pistes d'audit

Les plans ont un deuxième objectif qui devient critique quand les choses tournent mal. Chaque plan peut être sauvegardé comme un artefact dans votre pipeline. Cela crée un enregistrement historique de chaque changement d'infrastructure : ce qui a changé, quand cela a changé, et qui l'a approuvé.

Lorsqu'un incident de production se produit, cet enregistrement est inestimable. Au lieu de demander autour de vous qui a changé quoi, vous consultez les artefacts du plan. Vous pouvez voir le diff exact qui a été appliqué juste avant le début du problème. Cela transforme l'investigation d'incident de la conjecture en une analyse basée sur des preuves.

Sans plans sauvegardés, il ne vous reste que les journaux manuels, les messages de chat et la mémoire. Rien de tout cela n'est fiable lorsque vous essayez de déboguer une panne de production à 2 heures du matin.

Gérer les changements concurrents

Les équipes travaillant sur la même infrastructure sont confrontées à un autre défi : les changements conflictuels. Deux personnes modifient des fichiers de configuration réseau en même temps. Les deux changements semblent corrects isolément. Mais combinés, ils créent un conflit qui pourrait casser la connectivité.

L'étape de planification détecte cela. Lorsque la deuxième personne génère un plan, il montrera le conflit avant que des changements ne soient appliqués. L'équipe peut résoudre le conflit dans le code, pas en production. C'est bien plus sûr que d'appliquer les deux changements en espérant qu'ils n'interagissent pas mal.

Ce que le plan ne résout pas

Le workflow planifier-examiner-appliquer est puissant, mais il a des limites. Il ne peut comparer que ce que votre code dit par rapport à ce que votre infrastructure rapporte actuellement. Si quelqu'un fait un changement manuel en dehors de votre pipeline, le plan pourrait ne pas détecter toutes les incohérences. Si votre fournisseur d'infrastructure a un bug ou un comportement inattendu, le plan pourrait montrer quelque chose de différent de ce qui s'exécute réellement.

Ces cas limites n'invalident pas le workflow. Ils signifient simplement que vous avez besoin de pratiques supplémentaires en parallèle, comme la détection de dérive et la réconciliation régulière entre votre code et votre infrastructure en direct.

Liste de contrôle pratique

Avant d'implémenter le workflow planifier-examiner-appliquer dans votre pipeline, considérez ces points :

• Générez les plans automatiquement après chaque pull request fusionnée, pas seulement à la demande
• Sauvegardez chaque plan comme un artefact de pipeline avec des horodatages et des métadonnées d'approbation
• Bloquez l'application si aucun plan n'existe ou si le plan n'a pas été examiné
• Examinez les plans pour détecter les surprises avant d'approuver, pas seulement pour vérifier l'exactitude
• Utilisez les plans lors de l'investigation d'incidents comme votre première source de vérité pour les changements récents

L'idée centrale

Le workflow planifier-examiner-appliquer transforme les changements d'infrastructure de paris aveugles en opérations calculées et vérifiées. Le plan vous montre ce qui se passera avant que cela n'arrive. L'examen détecte les problèmes avant qu'ils n'atteignent la production. L'application n'exécute que ce qui a été vérifié. Ce workflow n'élimine pas tous les risques, mais il élimine le risque d'appliquer des changements sans connaître leur impact complet.

Si votre équipe applique encore les changements d'infrastructure directement, commencez par une règle simple : générez d'abord un plan, lisez-le, et ensuite seulement décidez si vous devez l'appliquer. Cette seule habitude préviendra plus de problèmes de production que la plupart des outils de surveillance ne le feront jamais.