Il était un peu plus de 2 a.m. quand mon téléphone a sonné. À l'autre bout, le responsable maintenance d'un client 3PL, la voix enrouée : ils venaient de terminer une mise à niveau du WCS, et maintenant les convoyeurs étaient morts, deux gerbeurs restaient figés au milieu de l'allée, et les tâches de sortie s'empilaient sur l'écran. Une vingtaine de personnes se tenaient autour des bandes sans rien faire, et deux vagues de camions devaient arriver avant l'aube. En rater une et c'en était fini des points SLA des quais clients.
Ils avaient opté pour une mise à niveau à arrêt complet : tout éteindre, tout changer d'un coup, en finir vite. Il s'est avéré que la nouvelle version du WCS avait un décalage de handshake avec les anciens drivers PLC, un petit écart de version qui n'était jamais apparu dans l'environnement de test parce que le volume de données était trop faible. En production, les communications ont explosé immédiatement. Ils sont revenus en arrière et ont éteint des incendies jusqu'au matin. Les camions ont fait la queue, les pénalités sont tombées.
Après cette nuit-là, j'en ai fait une règle pour chaque client : les mises à niveau du WCS en production se font toujours de façon progressive. Fini les bascules en big bang. Ce qui suit est le playbook complet.
Les chiffres expliquent pourquoi personne n'ose arrêter la ligne. Les calculs de l'industrie chiffrent le coût du temps d'arrêt non planifié à environ $10,000 par heure pour un entrepôt de 750,000 pieds carrés. Et les entrepôts américains sont vieux : les données de CBRE montrent que les bâtiments de plus de dix ans représentent 89% du parc d'entrepôts aux États-Unis, avec un âge moyen de 34 ans. Les vieux bâtiments tournent avec de vieux systèmes, et les mises à niveau du WCS sont inévitables. La seule question est de savoir si vous les faites sans arrêter l'activité.
La veille : les instantanés et les sauvegardes sont la vraie mise à niveau
La première étape d'une mise à niveau progressive n'est pas la mise à niveau. C'est de vous construire une sortie.
Trois choses se passent la veille. D'abord, prenez un instantané complet du WCS : configuration du système, règles d'ordonnancement des tâches, mappings d'interfaces, versions des programmes PLC, tout. Un WCS se trouve au milieu de tout, parlant vers le haut au WMS et à l'ERP et vers le bas aux PLC, convoyeurs et gerbeurs. Un décalage de version n'importe où dans cette chaîne et la mise à niveau produit des fantômes. L'instantané est la photo de famille de votre système avant l'opération ; quand quelque chose casse, vous comparez par rapport à elle.
Ensuite, une sauvegarde complète de la base de données avec un point de restauration défini. Une sauvegarde seule ne suffit pas. Restaurez-la une fois dans l'environnement de test et prouvez qu'elle fonctionne. J'ai vu trop de tragédies où la sauvegarde existait et la restauration non. Une demi-journée d'exercices de restauration peut sauver votre exploitation.
Troisièmement, préparez deux paquets : la mise à niveau et le retour en arrière. Le paquet de retour en arrière n'est pas l'ancien installeur. C'est un plan de retour complet incluant la logique inverse de migration des données. Si la nouvelle version change le schéma de la base de données, le retour en arrière doit ramener à la fois le schéma et les données à leur état d'avant la mise à niveau. La plupart des équipes oublient cela la première fois.
Une chose encore : envoyez le plan de mise à niveau au responsable des opérations de l'entrepôt à l'avance et expliquez-lui ce que l'activité ressentira à chaque étape. Le plan technique le plus élégant du monde ne vous sauvera pas si les opérations ne savent pas ce que vous faites. Votre téléphone sonnera sans arrêt toute la nuit.
La nuit de la mise à niveau : d'abord le secours, puis basculez le trafic progressivement
Mes nuits de mise à niveau suivent la même chronologie à chaque fois.
Vers 10 p.m., quand le volume baisse, mettez à niveau le secours. La plupart des configurations WCS fonctionnent en actif-secours. Montez le nœud de secours à la nouvelle version et faites un test de fumée : une vraie tâche d'entrée, une de sortie, un inventaire tournant. Surveillez toute la chaîne, dispatch des tâches, réponse des équipements, callbacks de confirmation. Cela ne touche aucun trafic de production, donc les erreurs coûtent peu cher.
Vers 11, avec le test de fumée au vert, basculez un filet de trafic. Choisissez une ligne de convoyeurs non critique ou une seule allée et dirigez ses tâches vers le nouveau WCS. Gardez la fenêtre d'observation à au moins une vague complète de sortie. Une vague fait travailler la boucle complète de lancement des commandes, allocation des tâches, exécution des équipements et gestion des exceptions. Une vague propre signifie que les fondamentaux de la nouvelle version sont sains. L'ancienne version porte toujours l'essentiel de l'activité ; la nouvelle n'est qu'un pilote.
Après minuit, étendez nœud par nœud. Terminez un nœud, gardez une période d'observation, confirmez que les taux de réussite des tâches et les temps de réponse des équipements ne se sont pas dégradés, puis passez au suivant. Ne mettez jamais à niveau plusieurs nœuds en parallèle pour gagner du temps. Si la nouvelle version cache une mine, les mises à niveau parallèles l'enterrent sous chaque nœud à la fois, et il n'y a pas de retour possible.
Au petit matin, quand le volume touche le fond, touchez le cœur en dernier : le cœur d'ordonnancement, le nœud primaire de la base de données. Avant la bascule, vérifiez une fois de plus que le paquet de retour en arrière est prêt et que le décideur est dans la salle.
Toute la nuit, quelqu'un surveille le mur de supervision. Trois chiffres : le retard de tâches, l'état des communications des équipements, le ratio de tâches en exception. Au moment où l'un d'eux dérape, arrêtez. Diagnostiquez d'abord, puis décidez s'il faut continuer ou revenir en arrière.
Tracez la ligne de retour en arrière avant de commencer
Trop d'équipes traitent le retour en arrière comme une improvisation après une mise à niveau ratée. Ce n'en est pas une. Le retour en arrière fait partie du plan de mise à niveau, écrit avant de commencer.
Quantifiez les déclencheurs et faites-les signer par tout le monde. Par exemple : le ratio de tâches en exception monte à plusieurs fois la ligne de base normale, le retard dépasse la capacité de traitement d'une vague, ou un équipement critique perd la communication au-delà des minutes convenues. Atteignez l'un de ces seuils et vous revenez en arrière, sans réunion, sans débat. La phrase la plus dangereuse dans une mise à niveau est "surveillons-le encore dix minutes". Dix minutes plus tard, le problème est plus gros.
Nommez exactement un décideur du retour en arrière. En général le responsable maintenance ou le chef d'équipe de nuit de permanence. Quand il dit de revenir en arrière, vous revenez en arrière. Discutez-en lors du post-mortem, pas à 3 a.m.
Répétez le retour en arrière de bout en bout dans l'environnement de test au moins une fois, et chronométrez-le. Ce chiffre fixe votre fenêtre de maintenance : temps de mise à niveau plus observation plus temps de retour en arrière plus marge. La plupart des équipes dimensionnent la fenêtre pour la seule mise à niveau et ne laissent rien pour le retour en arrière. Quand les choses tournent mal, elles sont coincées.
Une chose que les gens oublient : la réconciliation des données après le retour en arrière. Les tâches et les mouvements de stock créés pendant que la nouvelle version tournait doivent revenir proprement dans l'ancienne version, ou l'ancienne version doit les reprendre. Un WCS est un système temps réel. Un trou de données fait plus mal qu'un temps d'arrêt.
Donc chaque fois qu'un client me demande comment mettre à niveau un WCS, ma réponse est la même : d'abord les instantanés et les sauvegardes, d'abord le secours, basculez le trafic lentement, et tracez la ligne de retour en arrière à l'avance.
Le plan de retour en arrière se résume à cinq contrôles, cochés avant la nuit de la mise à niveau : un décideur, sur place ; des déclencheurs quantifiés écrits dans le plan ; les paquets de retour et de mise à niveau préparés et testés ensemble ; une répétition chronométrée en test ; les étapes de réconciliation des données documentées. Cochez les cinq et vous pouvez vraiment dormir cette nuit-là.
Personne ne se souvient d'une mise à niveau réussie. Mais un retour en arrière propre, tout l'entrepôt s'en souvient.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
