Des déploiements hors des heures d’affaires avec un retour arrière déjà testé

Le changement en soirée typique se passe comme suit. Quelqu’un de bonne volonté se connecte à 18 h 45, suit les étapes de mémoire, découvre à 19 h 20 qu’une étape ne s’est pas comportée comme prévu, puis improvise pendant deux heures pendant que la seule personne qui connaît le système est déjà au téléphone avec un conjoint qui voudrait savoir quand on soupe. Le lendemain matin, personne n’est certain de l’état de la production.

Ce n’est pas un problème de compétence. C’est un problème de plan manquant. Un déploiement hors heures avec retour arrière n’a rien d’héroïque : c’est un changement court, écrit et répété, avec un chemin de retour. Voici comment une équipe TI d’appoint comme la nôtre en mène un, et ce qu’une équipe interne peut emprunter même si elle ne nous engage jamais.

Pourquoi le soir, et pourquoi il faut plus de soin

Les soirées et les débuts de matinée sont populaires pour les changements parce que moins de gens sont dans le système et que les clients sont moins touchés. Cet avantage est réel. Le coût l’est tout autant : si quelque chose casse, ceux qui pourraient aider ne sont pas à leur poste.

La règle est donc simple. Moins il y a de personnel disponible, plus il faut avoir écrit avant le début du changement. Si le plan vit dans la tête d’une seule personne, la fenêtre n’est pas prête.

C’est la même logique que celle de notre texte sur l’équipe TI d’appoint pour les équipes internes : une personne interne qui connaît l’entreprise, et une équipe externe qui peut prendre en charge un travail défini avec un plan écrit, sans prétendre être un centre de service 24/7.

Le dossier de changement tient sur une page

Avant toute fenêtre, nous rédigeons un dossier de changement d’une page. Ce n’est pas de la paperasse pour la paperasse : c’est ce qui permet à quelqu’un d’autre de prendre le relais si vous êtes injoignable.

• Ce qui change, en une phrase
• Pourquoi maintenant, et pourquoi cela ne peut pas attendre les heures d’affaires
• Systèmes et utilisateurs touchés
• Heure de début, heure de fin et point de non-retour
• Étapes, numérotées, en copier-coller autant que possible
• Vérification, une liste de contrôles observables
• Retour arrière, étape par étape, avec qui décide
• Personnes-ressources, nommées des deux côtés, avec un numéro de téléphone auquel on répond

Si vous ne pouvez pas remplir « point de non-retour », c’est que vous ne comprenez pas encore le changement. Faites cette réflexion d’abord.

Prendre le point de retour avant de toucher à quoi que ce soit

Un retour arrière n’en est un que si vous avez quelque chose vers quoi revenir. Avant la fenêtre :

1. Sauvegarder ou prendre un instantané de l’élément modifié (base de données, serveur, configuration, fichiers du site)
2. Confirmer que la sauvegarde est lisible; quand l’enjeu le justifie, la restaurer sur une copie de test, comme dans notre exercice de restauration
3. Exporter la configuration actuelle (enregistrements DNS, règles de pare-feu, paramètres de politiques) vers un fichier conservé hors du système modifié
4. Noter les numéros de version de ce qui est installé maintenant
5. Garder la version précédente disponible, pas seulement la nouvelle

Pour un site ou une application, cela veut généralement dire garder la dernière version fonctionnelle connue et la sauvegarde de la base juste avant le changement. Pour l’infrastructure, un export de configuration. Pour l’identité ou Microsoft 365, une capture ou un export de la politique existante. « On peut annuler » doit être une phrase sur des fichiers qu’on peut montrer du doigt.

Geler, puis changer

L’heure qui précède un changement n’est pas le moment d’un ajustement de plus. Nous appliquons un petit gel :

• Aucun autre changement aux systèmes touchés à partir de l’approbation du plan
• Avis aux personnes touchées, avec la fenêtre et une personne-ressource
• Une surveillance qui nous dira si le changement a échoué, mise en place avant, pas après
• Une deuxième personne informée, même si elle ne fait que lire le plan et rester joignable

Beaucoup de mauvaises surprises en soirée sont deux changements qui se percutent : le vôtre et celui qu’un collègue a fait à 16 h et oublié de mentionner.

Exécuter le changement comme une liste de vérification

Pendant la fenêtre, la personne qui fait le travail suit les étapes numérotées et inscrit l’heure à côté de chacune. Pas des notes de la taille d’un roman. Une ligne par étape : fait à 19 h 05, résultat attendu observé. C’est ce dont le réviseur du lendemain vous remerciera.

Les règles que nous respectons :

• Ne pas sauter d’étape parce que « ça va aller »
• Ne pas ajouter d’étape en cours de route sans l’écrire
• Si un contrôle de vérification échoue, s’arrêter et décider : corriger vers l’avant ou reculer, selon les critères du plan
• Reculer tôt dans le doute; un retour arrière raté à 21 h est un meilleur problème qu’une indécision à minuit

Les critères de décision sont la partie précieuse. « Si la connexion échoue pour le compte de test après l’étape 6, on recule » élimine une discussion au pire moment.

Vérifier comme un utilisateur

Un changement qui se déploie sans erreur n’a pas forcément fonctionné. Nous vérifions ce qu’un utilisateur ou un client remarquerait :

• Le site ou l’application charge, et une transaction clé se complète
• Un envoi de formulaire arrive où il le doit
• La connexion fonctionne pour un utilisateur ordinaire, pas seulement pour l’administrateur qui a fait le changement
• La circulation du courriel, si le courriel ou le DNS étaient en cause
• La surveillance est au vert, et les alertes joignent encore une personne
• La performance paraît raisonnable pour les premières requêtes

Puis nous écrivons le résultat au bas du dossier : réussi, partiellement réussi, annulé, et l’état de la production tel que nous le laissons.

La vérification du lendemain matin

Au début du jour ouvrable suivant, 9 h HE, quelqu’un regarde de nouveau. Non pas parce que nous attendons des problèmes, mais parce que les tâches de nuit, les caches et les tâches planifiées révèlent ce qu’un test de 19 h ne peut pas. Nous vérifions les journaux pour de nouvelles erreurs, confirmons que les sauvegardes ont roulé après le changement, demandons à une personne de votre équipe si quelque chose cloche, puis fermons le dossier.

Si un problème apparaît à ce moment, le dossier montre exactement ce qui a changé et quel était le retour arrière : la conversation prend quelques minutes.

Quand une équipe d’appoint a du sens

Les changements en soirée sont un travail classique pour une équipe externe parce qu’ils sont bornés, écrits et répétables. Ils fatiguent aussi les petites équipes internes, où la même personne fait le travail et répond au téléphone à 8 h le lendemain. Une équipe d’appoint prend le changement planifié, remet le dossier et laisse votre personne au travail qui a besoin d’elle.

Nous ne prétendons pas être votre garde 24/7. Nous pouvons offrir des fenêtres planifiées, un opérateur nommé et une escalade écrite, et nous disons ce qui est couvert avant l’ouverture de la fenêtre. C’est ainsi que fonctionne la TI clé en main à Montréal : des personnes nommées, des changements écrits et aucun mystère sur qui est joignable et quand.

La sécurité compte aussi. Un déploiement qui désactive discrètement l’AMF, assouplit une règle de pare-feu ou laisse un compte administrateur temporaire est une régression même si la fonction marche. Nos notes sur le renforcement sont une bonne source de questions à poser après un changement.

Commencer par un seul changement

Si un changement s’en vient (déménagement de serveur, mise en ligne d’un site, mise à jour DNS ou d’identité), envoyez-nous la description en une phrase et la date envisagée. Nous répondons les jours ouvrables, de 9 h à 17 h HE, à hello@aervio.io ou au +1 438-498-3913. Nous vous dirons ce que le dossier de changement devrait contenir, si une fenêtre en soirée est sage, et où doit se trouver le point de retour. Notre équipe TI d’appoint couvre la planification et la fenêtre.

Questions

Pourquoi déployer hors des heures d’affaires?

Parce que le coût d’une erreur est moindre quand moins de gens travaillent dans le système. Le revers, c’est que moins de gens sont disponibles pour aider : c’est pourquoi un plan écrit, une personne-ressource nommée et un retour arrière sont obligatoires, pas facultatifs.

Et si le retour arrière échoue?

C’est que le plan n’avait pas été testé. Nous répétons le retour arrière sur une copie ou un environnement de préproduction quand c’est possible, et nous définissons d’avance le point après lequel reculer n’est plus sûr, pour que la décision soit prise avant le changement, pas pendant.

Offrez-vous une garde 24/7 réelle?

Pas par défaut. Notre couverture standard est du lundi au vendredi, de 9 h à 17 h HE, à Montréal. Les fenêtres de changement en soirée ou en fin de semaine se planifient à l’avance et se confirment par écrit, avec les heures et le chemin d’escalade.