Eran poco más de las 2 a.m. cuando sonó mi teléfono. Al otro lado estaba el jefe de mantenimiento de un cliente 3PL, con la voz ronca: acababan de terminar una actualización del WCS, y ahora los transportadores estaban muertos, dos grúas apiladoras congeladas en medio del pasillo, y las tareas de salida se acumulaban en la pantalla. Una veintena de personas estaba alrededor de las cintas sin nada que hacer, y dos oleadas de camiones debían llegar antes del amanecer. Fallar una y perdían los puntos SLA de los muelles del cliente.
Habían optado por una actualización con parada total: apagar todo, cambiarlo todo de una vez, salir del trámite rápido. Resultó que la nueva versión del WCS tenía un desajuste de handshake con los drivers PLC antiguos, una pequeña diferencia de versión que nunca apareció en el entorno de pruebas porque el volumen de datos era demasiado pequeño. En producción, las comunicaciones colapsaron de inmediato. Revirtieron y apagaron fuegos hasta la mañana. Los camiones hicieron cola, las penalizaciones cayeron.
Después de aquella noche lo convertí en regla para cada cliente: las actualizaciones de WCS en producción siempre son graduales. Nada más de cortes de gran explosión. Lo que sigue es el playbook completo.
Los números explican por qué nadie se atreve a detener la línea. Los cálculos de la industria sitúan el costo del tiempo de inactividad no planificado en aproximadamente $10,000 por hora para un almacén de 750,000 pies cuadrados. Y los almacenes estadounidenses son viejos: datos de CBRE muestran que los edificios de más de diez años representan el 89% del inventario de almacenes de EE. UU., con una edad promedio de 34 años. Los edificios viejos usan sistemas viejos, y las actualizaciones del WCS son inevitables. La única pregunta es si las hacen sin detener el negocio.
La noche anterior: las instantáneas y las copias de seguridad son la verdadera actualización
El primer paso de una actualización gradual no es la actualización. Es construirse una salida.
La noche anterior pasan tres cosas. Primero, tomar una instantánea completa del WCS: configuración del sistema, reglas de programación de tareas, mapeos de interfaces, versiones de programas PLC, todo. Un WCS está en el medio de todo, hablando hacia arriba con el WMS y el ERP y hacia abajo con los PLC, transportadores y grúas. Un desajuste de versión en cualquier punto de esa cadena y la actualización produce fantasmas. La instantánea es la foto familiar de tu sistema antes de la cirugía; cuando algo se rompe, comparas contra ella.
Segundo, una copia de seguridad completa de la base de datos con un punto de restauración definido. Una copia sola no basta. Restáurala una vez en el entorno de pruebas y demuestra que funciona. He visto demasiadas tragedias donde la copia existía y la restauración no. Medio día de simulacros de restauración puede salvar tu operación.
Tercero, prepara dos paquetes: la actualización y la reversión. El paquete de reversión no es el instalador viejo. Es un plan completo de reversión que incluye la lógica inversa de migración de datos. Si la nueva versión cambia el esquema de la base de datos, la reversión tiene que devolver tanto el esquema como los datos a su estado previo a la actualización. La mayoría de los equipos olvida esto la primera vez.
Una cosa más: envía el plan de actualización al gerente de operaciones del almacén con antelación y explícale lo que el negocio sentirá en cada etapa. El plan técnico más elegante del mundo no te salvará si operaciones no sabe lo que estás haciendo. Tu teléfono sonará sin parar toda la noche.
Noche de actualización: primero el equipo en espera, luego desvía el tráfico poco a poco
Mis noches de actualización siguen la misma cronología cada vez.
Alrededor de las 10 p.m., cuando el volumen baja, actualiza el equipo en espera. La mayoría de las configuraciones de WCS funcionan en activo-pasivo. Lleva el nodo en espera a la nueva versión y haz una prueba de humo: una tarea real de entrada, una de salida, un conteo cíclico. Observa toda la cadena, despacho de tareas, respuesta de equipos, confirmaciones de devolución. Esto toca cero tráfico de producción, así que los errores son baratos.
Alrededor de las 11, con la prueba de humo en verde, desvía un hilo de tráfico. Elige una línea de transportadores no crítica o un solo pasillo y dirige sus tareas al nuevo WCS. Mantén la ventana de observación en al menos una oleada completa de salida. Una oleada ejercita el ciclo completo de liberación de pedidos, asignación de tareas, ejecución de equipos y manejo de excepciones. Una oleada limpia significa que los fundamentos de la nueva versión son sólidos. La versión vieja sigue cargando con el grueso del negocio; la nueva es solo un piloto.
Después de la medianoche, expande nodo por nodo. Termina un nodo, mantén un período de observación, confirma que las tasas de éxito de tareas y los tiempos de respuesta de equipos no se han degradado, luego pasa al siguiente. Nunca actualices varios nodos en paralelo para ahorrar tiempo. Si la nueva versión tiene una mina terrestre, las actualizaciones en paralelo la entierran bajo cada nodo a la vez, y no hay vuelta atrás.
En la madrugada, cuando el volumen toca fondo, toca el núcleo al final: el núcleo de programación, el nodo primario de la base de datos. Antes del cambio, verifica una vez más que el paquete de reversión esté preparado y que la persona que decide esté en la sala.
Toda la noche, alguien vigila la pared de monitoreo. Tres números: tareas en espera, estado de comunicación de equipos, ratio de tareas de excepción. En el momento en que alguno falle, detente. Diagnostica primero, luego decide si continuar o revertir.
Traza la línea de reversión antes de empezar
Demasiados equipos tratan la reversión como improvisación después de una actualización fallida. No lo es. La reversión es parte del plan de actualización, escrita antes de empezar.
Cuantifica los disparadores y haz que todos los firmen. Por ejemplo: el ratio de tareas de excepción sube a varias veces la línea base normal, la cola supera la capacidad de procesamiento de una oleada, o un dispositivo crítico pierde comunicación más allá de los minutos acordados. Alcanza cualquiera de estos y reviertes, sin reunión, sin debate. La frase más peligrosa en una actualización es "vigilémoslo diez minutos más". Diez minutos después el problema es más grande.
Nombra exactamente a una persona que decida la reversión. Normalmente el jefe de mantenimiento o el gerente del turno de noche de guardia. Cuando él dice revertir, reviertes. Discútelo en el post-mortem, no a las 3 a.m.
Ensaya la reversión de principio a fin en el entorno de pruebas al menos una vez, y cronométrala. Ese número define tu ventana de mantenimiento: tiempo de actualización más observación más tiempo de reversión más margen. La mayoría de los equipos dimensiona la ventana solo para la actualización y no deja nada para la reversión. Cuando las cosas salen mal, están atrapados.
Una cosa que la gente olvida: la conciliación de datos después de la reversión. Las tareas y los movimientos de inventario creados mientras la nueva versión corría tienen que fluir de vuelta a la versión vieja limpiamente, o la versión vieja tiene que recogerlos. Un WCS es un sistema en tiempo real. Una brecha de datos duele más que el tiempo de inactividad.
Así que cada vez que un cliente pregunta cómo actualizar un WCS, mi respuesta es la misma: primero instantáneas y copias de seguridad, primero el equipo en espera, desvía el tráfico poco a poco, y traza la línea de reversión con antelación.
El plan de reversión se reduce a cinco verificaciones, marcadas antes de la noche de actualización: una persona que decide, en sitio; disparadores cuantificados escritos en el plan; paquetes de reversión y actualización preparados y probados juntos; un ensayo cronometrado en pruebas; pasos de conciliación de datos documentados. Marca las cinco y realmente puedes dormir esa noche.
Nadie recuerda una actualización exitosa. Pero una reversión limpia, todo el almacén recuerda eso.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
