L’infrastructure-as-code est un changement de paradigme que beaucoup dans les métiers de l’infrastructure ont du mal à intégrer.

Exemple : vendredi soir, la prod s’est cassée un peu plus tôt. On a investigué, trouvé le cause de l’incident et on l’a fixé… en direct sur la production. On se dit qu’il est tard et qu’on finira plus tard. Mon expérience m’a appris que tu as 90% de chance que la production soit de nouveau cassée lundi matin. Tu as bloqué les déploiements automatiques, mais ils ont été réactivité par l’astreinte en pleine nuit et ton paramètre a été écrasé. Fail.

De même, en semaine une fin de journée, tu veux commiter sur la préproduction ton nouveau paramètre. Ton collègue est déjà parti, tu zappes la revue et tu pousses sur la préproduction. Tu vérifies l’effet voulue et tu vois que ça a marché. Tu pousses en production.

Le lendemain matin à ton arrivée, ton collègue te saute dessus, la production est cassé depuis hier 20h. Tu as négligé un paramètre qui a provoqué un effet de bord qui n’est visible qu’en production où le nombre de serveurs frontaux est différent de celui de la préproduction. Fail.

Les exemples sont nombreux. L’infra-as-code entraîne habituellement un confort et une sécurité pour les déploiements, mais elles entraînent aussi des responsabilités individuelles différentes de l’époque où on y allait sans filet sur la production. Il en ressort aussi une organisation différente du travail qui peut être un défi à mettre en place quand tous ceux qui travaillent sur la production ne sont pas dans la même culture.

L’auteur

Je suis architecte infrastructure onpremise et cloud (AWS et Azure) senior freelance certifié AWS Solutions Architect Associate. Je conçois les infrastructures dont vous avez besoin pour faire tourner les services IT de vos entreprises et vous aide dans vos grands processus de migrations et de remédiations. Disponible pour une nouvelle mission. N’hésitez pas à me contacter si je peux vous aider dans vos projets.