Aquí va la conclusión por adelantado: el monitoreo de integraciones WMS tiene exactamente un estándar. Cuando una integración se rompe, el monitoreo debe enterarse antes que el negocio. Si el servicio al cliente se entera primero por un cliente, o el almacén lo nota porque no llegaron pedidos nuevos, la configuración de monitoreo ha fallado, por muy verde que parezca su panel. He visto demasiados lanzamientos con una documentación de interfaces preciosa y una sola luz verde que solo significa que el servidor está vivo. No dice nada sobre si los pedidos realmente fluyeron.
En noviembre de 2024, un cliente de ropa del este de China lanzó un nuevo WMS conectado a su marketplace y a sus transportistas de paquetería. En la tercera mañana, el gerente del almacén me llamó: ¿por qué no había llegado ningún pedido nuevo en toda la mañana? La interfaz de pedidos del marketplace había muerto a las 2 a.m. El middleware seguía reintentando, la cola de reintentos seguía creciendo, y a las 8 a.m. más de 600 pedidos estaban acumulados. No se disparó ni una alerta, porque la comprobación de salud sondeaba la puerta de enlace, que estaba viva, mientras que la interfaz de pedidos en sí estaba muerta. La frase del cliente se me quedó grabada: pagamos por un sistema que necesita que el almacén cuente pedidos para descubrir un fallo.
Cuatro tipos de alertas, porque las integraciones mueren de cuatro maneras
Las integraciones mueren de cuatro maneras, y cada manera necesita su propio tipo de alerta. Si falta un tipo, queda un punto ciego.
El primer tipo es la vitalidad, que vigila si una interfaz responde. Pero la vitalidad debe sondear la interfaz de negocio real, no la página principal de la puerta de enlace. Esa fue la lección de aquel cliente de ropa: sondear el endpoint equivocado. Sondea cada interfaz crítica por separado, cada uno a tres minutos, y alerta después de dos fallos consecutivos, no de tres. Mantén el sondeo ligero: solo devuelve el estado, nunca ejecutes una consulta pesada dentro de una comprobación de salud.
El segundo tipo es el atraso en cola, que vigila si los datos están atascados. La entrada de pedidos, la sincronización de inventario y la confirmación de envíos tienen cada una su propio umbral de cola. Fija el umbral a partir de datos de pruebas de carga, no por intuición. Con las cifras de aquel almacén de ropa, el volumen normal rondaba los 400 pedidos por hora, así que un atraso superior a 200 pedidos durante 15 minutos significaba que el consumidor ya se había quedado atrás. Los umbrales pertenecen a la lista de verificación de lanzamiento antes del arranque, no se ajustan por intuición después.
El tercer tipo es el de los reintentos fallidos, que vigila si se pierden datos. Cualquier mensaje que falle tres reintentos debe terminar en una cola de mensajes fallidos y alertar a una persona de inmediato. El diseño más peligroso es el reintento silencioso más la pérdida silenciosa: un mensaje da vueltas por los registros unas cuantas veces y nadie se hace cargo de él jamás. La cola de mensajes fallidos necesita un responsable con nombre y una hora diaria de vaciado, escritos en la lista de verificación, no dados por supuestos.
El cuarto tipo es la conciliación, que vigila si ambas partes coinciden. Ejecútala en un horario diario fijo: envíos del WMS contra envíos del marketplace, inventario del WMS contra inventario del marketplace. Alerta cuando la diferencia supere un valor acordado. La conciliación es la última red. Cuando los tres primeros tipos pasan por alto un fallo, la conciliación igual lo detecta el mismo día. Una integración sin conciliación funciona desprotegida.
| Tipo de alerta | Qué vigila | Ejemplo de activación |
|---|---|---|
| Vitalidad | Si la interfaz responde | Dos fallos consecutivos de sondeo en una interfaz crítica |
| Atraso en cola | Si los datos están atascados | Atraso superior a 200 pedidos durante 15 minutos |
| Reintentos fallidos | Si se pierden datos | Tres reintentos fallidos, mensaje en la cola de mensajes fallidos |
| Conciliación | Si ambas partes coinciden | Diferencia en la conciliación diaria superior al valor acordado |
Tres fallos que he visto, cada uno desde un punto ciego distinto
He visto este problema tres veces, y cada fallo murió de forma distinta. El primero fue el cliente de ropa de arriba: la vitalidad sondeaba el lugar equivocado, y una interfaz de pedidos permaneció muerta seis horas antes de que el almacén lo notara. La solución, además de mover el sondeo a la interfaz de pedidos, fue una alerta de volumen de negocio: si los pedidos nuevos por hora caen por debajo del 30% del promedio normal, la alerta se dispara de inmediato. Una máquina sana con un volumen de negocio en caída es en sí misma una señal de fallo.
El segundo fue un cliente 3PL del sur de China en marzo de 2025, conectado a tres transportistas de paquetería. La devolución de llamada de seguimiento de un transportista fallaba de forma intermitente, los números de seguimiento nunca volvían, y las quejas de los clientes se triplicaron en una semana. Las devoluciones fallidas quedaron en los registros sin responsable, porque no había cola de mensajes fallidos. La recuperación supuso crear la cola de mensajes fallidos y la conciliación diaria, y luego reproducir las devoluciones faltantes por número de seguimiento. Después de ese proyecto me impuse una regla estricta: ninguna interfaz sale en vivo sin una cola de mensajes fallidos.
El tercer fallo fue el más silencioso: retraso en la sincronización de inventario. El inventario del WMS cambió, el inventario del marketplace se actualizó dos horas después, y más de 40 pedidos se vendieron en exceso entre tanto. La interfaz estaba viva, las colas estaban despejadas, todos los reintentos tuvieron éxito, y los tres primeros tipos de alertas se mantuvieron en verde. Solo la conciliación podía detectarlo. El retraso de sincronización de los SKU principales necesita su propio umbral: alerta cuando el retraso supere los 30 minutos, no en la siguiente conciliación diaria. Los pedidos vendidos en exceso cancelados, las disculpas y las malas reseñas cuestan mucho más que la interrupción de una alerta.
Aquí va el punto contrario a la intuición: más alertas no es mejor. Un equipo ahogado en alertas termina tratando cada alerta como ruido, y entonces tampoco lee la alerta real. Divide las alertas por gravedad. El fallo de vitalidad, las llegadas a la cola de mensajes fallidos y las brechas de conciliación despiertan a alguien por la noche. El atraso en cola y el retraso de sincronización van al canal de trabajo para gestionarlos durante el día. Monitorear sin niveles de gravedad es lo mismo que no monitorear.
Quién recibe la alerta importa tanto como la alerta en sí
El último eslabón de la cadena es el que más se pasa por alto: sale una alerta, pero ¿puede el destinatario actuar sobre ella? He visto alertas llegar a un grupo de proyecto de veinte personas donde nadie se hacía cargo de ellas, hasta que llamó un cliente y alguien por fin se movió. Cada alerta necesita un responsable principal con nombre y un suplente con nombre. Si el principal no responde en 30 minutos, la alerta escala automáticamente al suplente, y luego al gerente del proyecto. La escalada debe estar configurada en el sistema, no gritarse en un grupo de chat.
El texto de la alerta debe leerse como instrucciones, no como un código de estado. Qué interfaz, a qué hora, cuántos pedidos afectados y qué revisar primero pertenecen al cuerpo de la alerta. Una alerta que solo dice «error de interfaz» manda al ingeniero de guardia a buscar en los registros a las 3 a.m. antes siquiera de saber qué interfaz se rompió. Una buena alerta se lee así: fallo de vitalidad de la interfaz de pedidos, dos sondeos sin respuesta en dos minutos, atraso de unos 180 pedidos, revisa primero los registros del middleware y luego la página de estado del marketplace. Cinco minutos con ese texto bastan para saber si el problema es nuestro o de ellos.
Una trampa más: el propio canal de alertas no debe depender del sistema que se monitorea. Mantén al menos dos canales independientes, como SMS y un bot de chat aparte, para que la caída de un canal no silencie las alertas. Prueba los canales mensualmente, probando el canal en sí, no esperando a un incidente real para descubrir un token de bot caducado.
La lista de verificación de la noche anterior al lanzamiento
La lista de verificación de la noche anterior al lanzamiento es un ritual que sigo en cada proyecto. Cada punto lleva una firma. Un «más o menos listo» verbal no cuenta.
- Sondeos de vitalidad configurados para cada interfaz crítica, apuntando a endpoints de negocio reales, no a páginas principales de puertas de enlace
- Umbrales de cola para las colas de pedidos, inventario y confirmación fijados a partir de datos de pruebas de carga y escritos en la lista de verificación
- Cola de mensajes fallidos creada, con tres reintentos fallidos que se derivan allí automáticamente y alertan al responsable al llegar
- Conciliación diaria programada, con umbrales de diferencia y destinatarios de alertas confirmados
- Línea base de volumen de negocio fijada: si los pedidos por hora caen por debajo del 30% del promedio normal, la alerta se dispara de inmediato
- Destinatarios de alertas confirmados con suplentes: si el principal está ausente o ilocalizable, el suplente recibe la alerta
- Un simulacro completado: romper deliberadamente una interfaz y confirmar que la alerta llega a una persona en cinco minutos
- Un plan de reversión escrito: cuando una interfaz sigue caída, quién ejecuta la importación manual de pedidos y cómo
El simulacro es el punto que más se omite, y el más importante. Una cadena de alertas nunca probada, en su primer timbre real, irá a la persona equivocada, al grupo equivocado o a ninguna parte. Media hora de simulacro ahorra seis horas de apagar incendios en la noche del lanzamiento. El estándar sigue siendo simple: la próxima vez que se rompa una integración, la primera persona en enterarse debe ser el ingeniero de guardia, no el gerente del almacén ni el cliente.
Por Lin Xiao, Consultor de Implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
