Préparer une mise en production : environnements, plan de déploiement et retour arrière

Préparer une mise en production, c'est décider où le service sera testé, vérifier que tout ce dont il a besoin existe, écrire pas à pas comment il sera installé et comment revenir en arrière si l'installation échoue, puis faire autoriser le tout. Une mise en production réussie se joue presque entièrement avant le jour J : le jour J, on déroule un plan déjà écrit. Ce chapitre présente les environnements, la liste des prérequis, la demande de changement, le plan de déploiement, le plan de retour arrière et la décision go/no-go.

Les environnements

Un environnement est une installation complète du service (serveurs, application, base de données, configuration) réservée à un usage. On n'essaie jamais une nouvelle version là où les utilisateurs travaillent : on la fait passer d'un environnement à l'autre, du moins risqué au plus exposé.

Une petite organisation a souvent trois environnements : développement, recette et production. Pour un service d'infrastructure (un GLPI, un serveur de fichiers, une nouvelle règle de pare-feu), la « recette » est une maquette : une machine virtuelle de test dans le labo, un clone de la VM de production, ou un instantané pris juste avant la modification (modèles et clones Proxmox).

Ce qui change d'un environnement à l'autre

La règle d'or : la version testée en recette est exactement celle qui part en production. Pas une version recompilée, pas une configuration retouchée à la main sur le serveur. Ce qui diffère d'un environnement à l'autre, c'est seulement :

• la configuration, fournie au démarrage (variables d'environnement, fichiers de configuration) : l'adresse de la base, le serveur de courriel, le niveau des journaux, l'adresse publique du service ;
• les secrets : chaque environnement a ses propres mots de passe et clés, et ceux de la production ne sont connus que de l'équipe d'exploitation ;
• les données.

Le cours Intégration continue montre comment un pipeline fait passer la même image d'un environnement à l'autre avec ses secrets propres.

Les prérequis : la liste qui évite les surprises

Un prérequis est une condition qui doit être remplie avant de commencer le déploiement. La liste se construit à partir de l'architecture (chapitre 2) : chaque composant, chaque dépendance et chaque flux donne au moins une ligne. Pour chacune, écris comment on vérifie qu'elle est remplie : un prérequis qu'on « pense » fait n'est pas fait.

La demande de changement

Mettre un nouveau service en production est un changement au sens d'ITIL : une modification de l'infrastructure qui peut avoir un effet sur les services. Il passe donc par la pratique de gestion des changements (gestion des changements et retour arrière).

• Un changement standard est courant, à faible risque, décrit par une procédure éprouvée et pré-autorisé : ajouter un salarié à un groupe, déployer une version corrective d'une application qui a déjà un pipeline rodé.
• Un changement normal est évalué et autorisé au cas par cas : la première mise en production de Prêt'Matos en est un.
• Un changement urgent suit un circuit accéléré : corriger une faille exploitée.

La demande de changement (request for change, RFC) résume tout ce que ce chapitre prépare : la description et la justification, les éléments touchés, l'analyse d'impact et de risque, le plan de mise en œuvre, le plan de tests, le plan de retour arrière et la date. Chez Sorbier, elle est saisie dans GLPI (Assistance > Changements), liée au projet, et c'est Antoine, l'autorité de changement, qui l'autorise. Dans une grande organisation, un comité consultatif des changements (CAB) donnerait son avis.

L'analyse de risque tient en un petit tableau : ce qui peut mal tourner, sa probabilité, sa gravité, et ce qu'on prévoit.

Le plan de déploiement

Le plan de déploiement décrit comment la version sera installée et ouverte aux utilisateurs : qui fait quoi, dans quel ordre, à quelle heure, et comment on vérifie chaque étape. Il doit pouvoir être suivi par quelqu'un d'autre que son auteur : si Moussa est malade le jour J, Chloé doit pouvoir le dérouler.

Le déroulé est le cœur du plan. Celui de Prêt'Matos, pour la matinée du samedi :

Le chapitre 5 détaille l'exécution de ces étapes, et le chapitre 8 les commandes exactes.

Choisir la date et la fenêtre

La date d'une mise en production ne se choisit pas selon le calendrier de l'équipe technique, mais selon celui des utilisateurs.

• Éviter les pics d'activité : une fin de mois pour la comptabilité, un départ en tournée pour les commerciaux, la veille d'un inventaire pour la logistique.
• Garder du temps après : une mise en production le vendredi à 18 h laisse un week-end sans personne pour réagir. Si on déploie un samedi, quelqu'un doit être joignable et l'ouverture aux utilisateurs a lieu un jour où toute l'équipe est présente.
• Prévoir une fenêtre de maintenance quand un service existant s'arrête : une plage annoncée, assez large pour le retour arrière.
• Tenir compte des contraintes extérieures : le départ de l'intérimaire qui tient le tableur fixe une date au plus tard ; les congés de l'équipe fixent des dates impossibles.

Prêt'Matos remplace un tableur : aucun service ne s'arrête, il n'y a donc pas de coupure à annoncer, seulement un gel du tableur entre vendredi 17 h et lundi 8 h.

Le plan de retour arrière

Le plan de retour arrière (rollback ou backout plan) décrit comment revenir à la situation d'avant si le déploiement échoue. Il se prépare avant, avec quatre éléments :

1. Le critère de déclenchement, mesurable : « si un test de fumée est rouge ou si les comptages de l'import diffèrent, et que la cause n'est pas corrigée à 11 h 30, on revient en arrière ».
2. L'heure limite de décision, pour ne pas s'acharner jusqu'au soir.
3. La procédure, aussi concrète que celle du déploiement : des commandes, des fichiers, des écrans.
4. Ses conséquences sur les données : que deviennent les données saisies entre la bascule et le retour arrière ?

Pour Prêt'Matos, revenir en arrière avant l'ouverture ne coûte presque rien : on arrête les conteneurs, on rouvre le tableur en écriture, on prévient les salariés que le nouvel outil est reporté. Après l'ouverture du lundi, chaque réservation saisie dans l'application devrait être recopiée à la main dans le tableur : c'est le point de non-retour. Au-delà, on préfère corriger en avant (livrer un correctif) sauf anomalie bloquante, et c'est Antoine qui tranche.

Pour un service d'infrastructure, le retour arrière s'appuie souvent sur un instantané de la machine virtuelle pris juste avant (instantanés et sauvegardes dans Proxmox) : on revient à l'état exact d'avant en quelques secondes. Mais un instantané ramène aussi en arrière les données saisies depuis : il ne convient que tant que le service n'a pas été rouvert aux utilisateurs.

La décision go/no-go

La réunion go/no-go a lieu quelques jours avant le déploiement. Elle répond à une seule question : tout est-il prêt pour lancer ? Chacun présente l'état de ses prérequis, puis le décideur tranche, et la décision est écrite.

La décision peut être go, no-go (on reporte, avec une nouvelle date), ou go sous conditions (« go si le certificat est installé et vérifié avant jeudi 18 h »). Elle est consignée dans la demande de changement.

Exercices

Exercice 1 sur 4 Quel environnement ? Réussi À revoir

Pour chaque situation, dis dans quel environnement on se trouve, ou dans lequel on devrait se trouver.

1. Yanis teste une requête de recherche en modifiant le code toutes les deux minutes.
2. Nadia et deux salariés vérifient que les réservations qui se chevauchent sont refusées.
3. Moussa veut savoir si la mise à jour de GLPI de 12.0.1 vers 12.0.2 casse les règles métier, sans toucher aux tickets des salariés.
4. Un test automatique crée 200 réservations puis les supprime à chaque modification du code.
5. Chloé ouvre un ticket dans GLPI pour un salarié dont le poste ne démarre plus.

Voir la réponseMasquer la réponse de l'exercice 1

1. Développement : son poste.
2. Recette : la MOA et des utilisateurs valident un comportement métier.
3. Une recette pour un service d'infrastructure : un clone de srv-glpi (ou une VM de test restaurée depuis la dernière sauvegarde) dans le VLAN 21, où il passe la mise à jour et vérifie les règles. Un instantané de la production juste avant la mise à jour servira, lui, de retour arrière.
4. Intégration : le pipeline de CI, avec une base créée et détruite par les tests.
5. Production : de vraies données, un vrai utilisateur.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Des prérequis vérifiables Réussi À revoir

Ces prérequis, notés dans un plan de déploiement, ne se vérifient pas. Réécris chacun pour qu'il dise comment on le vérifie.

1. « Le DNS est fait. »
2. « Le pare-feu est ouvert. »
3. « La sauvegarde est en place. »
4. « Les utilisateurs sont prévenus. »

Voir la réponseMasquer la réponse de l'exercice 2

1. « L'alias pretmatos.ad.sorbier.example répond 192.168.21.130 à Resolve-DnsName depuis un poste du VLAN 10, et à getent hosts pretmatos.ad.sorbier.example depuis srv-pretmatos. »
2. « Chaque flux F1 à F9 de la matrice a été testé depuis sa source, avec le résultat consigné ; par exemple Test-NetConnection pretmatos.ad.sorbier.example -Port 443 depuis un poste renvoie TcpTestSucceeded : True. »
3. « La sauvegarde nocturne s'est exécutée deux nuits de suite, et la plus récente a été restaurée sur srv-recette : l'application y démarre avec les données attendues. »
4. « L'annonce a été envoyée à la liste de diffusion de tous les salariés à J−14 et rappelée à J−3 ; la fiche réflexe est publiée sur l'intranet. »

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Un plan de retour arrière à refaire Réussi À revoir

Pour la mise à jour de GLPI de 12.0.1 vers 12.0.2, un technicien a écrit : « Retour arrière : en cas de problème, on restaure. » La mise à jour est prévue un mardi de 12 h 15 à 13 h 30, pendant la pause du midi, et GLPI reste ouvert aux salariés jusqu'à 12 h 15.

Réécris le plan de retour arrière avec ses quatre éléments.

Voir la réponseMasquer la réponse de l'exercice 3

Une réponse possible :

• Critère de déclenchement : la commande de mise à jour de la base échoue, ou l'un des tests suivants échoue : connexion d'un salarié par l'annuaire, création d'un ticket par le portail, notification reçue, relève de la boîte du support, page des actions automatiques à jour.
• Heure limite : décision à 13 h 15 au plus tard, pour que le service soit rétabli avant 13 h 30.
• Procédure : GLPI passe en mode maintenance à 12 h 15 et l'action automatique mailgate (le collecteur) est désactivée pendant la fenêtre ; sauvegarde de la base et de la configuration ; instantané de la VM srv-glpi. En cas de retour arrière : retour à l'instantané (moins d'une minute), vérification de la connexion et de la création d'un ticket, sortie du mode maintenance.
• Conséquences sur les données : aucune, si le mode maintenance et l'arrêt du collecteur ont bien empêché toute saisie entre 12 h 15 et la décision ; les courriels reçus pendant ce temps restent dans la boîte du support et seront relevés à la réactivation du collecteur. Un collecteur resté actif aurait retiré ces courriels de la boîte en créant leurs tickets, et le retour à l'instantané aurait effacé les tickets : les demandes seraient perdues. Les salariés sont prévenus que GLPI est indisponible de 12 h 15 à 13 h 30.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Go ou no-go ? Réussi À revoir

À J−4 de la mise en service de GLPI, la situation est la suivante. Décide go, no-go ou go sous conditions, et justifie.

• Recette terminée, PV signé avec deux réserves mineures.
• Connexion par l'annuaire, notifications, collecteur : tous testés et verts.
• L'agent d'inventaire n'est déployé que sur 4 postes sur 16 : la stratégie de groupe a une erreur de chemin.
• La sauvegarde de la base n'a jamais été restaurée.
• Annonce envoyée, fiche « Déclarer une demande » prête.

Voir la réponseMasquer la réponse de l'exercice 4

Go sous conditions, ou no-go si les conditions ne peuvent pas être tenues.

• L'agent d'inventaire ne bloque pas l'ouverture : les salariés peuvent déclarer leurs demandes sans lui. On corrige la stratégie de groupe et on la déploie par vagues après l'ouverture. C'est une réserve, pas un motif de report.
• La sauvegarde jamais restaurée est, elle, une vraie condition : un service mis en production sans restauration testée ne respecte pas son engagement de continuité. Condition : « une restauration complète sur une VM de test, réussie avant J−1 ». Si elle échoue, no-go.

Tu avais trouvé ?

Oui, j'avais bonPas encore