Tomemos un pedido hipotético, el 4512. El ecommerce lo muestra como enviado, pero el depósito no lo encuentra. Para responder una consulta de atención al cliente, alguien revisa registros de varios sistemas y consulta a otro equipo. La pregunta parece simple; la información para contestarla está dispersa.
La trazabilidad permite seguir ese pedido de un sistema a otro. El monitoreo permite detectar que hay más pedidos detenidos de lo habitual, incluso antes de que alguien pregunte por uno.
Trazabilidad y monitoreo: dos preguntas distintas
Aunque suelen mencionarse juntos, responden preguntas diferentes:
- Trazabilidad: ¿qué pasó con esta operación? Permite seguir un pedido, un pago o una actualización de stock a través de todos los sistemas que atravesó, con su historial completo.
- Monitoreo: ¿cómo está funcionando la integración en general? Mira el comportamiento agregado (volumen, errores, tiempos, pendientes) para detectar cuándo algo se sale de lo normal.
Se necesitan ambos. El monitoreo avisa que algo anda mal; la trazabilidad permite entender qué operaciones se vieron afectadas y por qué.
Qué registrar en cada operación
La trazabilidad empieza por definir qué información deja cada operación a su paso. Un registro útil suele incluir:
- Identificador de correlación: un ID único que se genera al inicio del flujo y acompaña la operación a través de todos los sistemas, colas y servicios que atraviesa.
- Identificadores de negocio: número de pedido, SKU, número de factura o de remito. Es lo que el equipo operativo conoce y va a usar para buscar.
- Origen y destino: qué sistema envió la información y a cuál se dirigía.
- Estado y momento de cada paso: cuándo se recibió, cuándo se procesó, cuándo se confirmó.
- Respuesta del sistema destino: códigos y mensajes de error tal como los devolvió, sin resumirlos.
- Cantidad de intentos: para distinguir una operación que falló una vez de una que viene fallando hace horas.
Logs estructurados
Conviene que cada registro tenga siempre los mismos campos y un formato que una máquina pueda leer (JSON es el más habitual), en lugar de líneas de texto armadas a mano. Esto se conoce como logs estructurados, y es lo que permite reunir todos los pasos del pedido 4512 o agrupar los errores de un mismo sistema con una consulta, en vez de revisar archivos línea por línea. Estándares abiertos como OpenTelemetry ayudan a que ese contexto viaje de un servicio a otro.
Cuidado con los datos sensibles
Registrar el contenido de cada mensaje ayuda al diagnóstico, pero puede exponer datos personales, de pago o de salud. Conviene definir desde el diseño qué campos se enmascaran u omiten, quién tiene acceso a los registros y durante cuánto tiempo se conservan.
Un modelo de estados claro
Una de las prácticas que más simplifica el diagnóstico es definir explícitamente los estados por los que pasa cada operación. Por ejemplo:
- Recibida: la integración tomó la operación del sistema origen.
- En proceso: se está transformando o enviando al destino.
- Entregada: el sistema destino la aceptó.
- Confirmada: el destino informó que la procesó correctamente, cuando ese paso existe.
- Con error: agotó los reintentos o fue rechazada por un error permanente.
- Reprocesada: se volvió a ejecutar después de corregir la causa.
Con estados explícitos, preguntas como "¿cuántos pedidos de hoy siguen sin confirmar?" pasan a ser una consulta simple en lugar de una investigación.
Qué métricas monitorear
No hace falta medir todo desde el primer día. Para detectar pedidos detenidos, conviene empezar por estas señales:
- Volumen: cantidad de operaciones procesadas por período, comparada con lo esperable para ese día y horario.
- Tasa de error: porcentaje de operaciones fallidas, separado por sistema destino y por tipo de error.
- Latencia: cuánto tarda una operación de punta a punta y cuánto responde cada sistema externo.
- Pendientes y antigüedad: cuántas operaciones esperan en cola y cuánto hace que espera la más antigua. Una cola que crece o un mensaje que no avanza suelen ser la primera señal de un problema.
- Frescura de los datos: cuándo fue la última sincronización exitosa de stock, precios o catálogo.
- Ausencia de actividad: si en horario comercial no entra ningún pedido durante un período inusual, probablemente algo dejó de funcionar aunque no haya errores registrados.
Alertas que alguien pueda resolver
Un problema frecuente es el exceso de alertas. Si el canal recibe decenas de avisos por día y la mayoría no requiere acción, el equipo se acostumbra a pasarlos por alto, y el día que llega el aviso de pedidos detenidos nadie lo ve a tiempo. Algunas pautas para evitarlo:
- Alertar sobre síntomas, no sobre cada error: un pedido fallido aislado va a la cola de revisión; un aumento sostenido de la tasa de error dispara una alerta.
- Definir severidades: no es lo mismo una demora en la sincronización de catálogo que la caída del flujo de pagos.
- Asignar un responsable: cada alerta debería llegar a quien puede actuar sobre ella, sea el equipo técnico, el área operativa o un proveedor externo.
- Acompañar con un procedimiento: una guía breve con qué revisar primero y cómo reprocesar reduce el tiempo de resolución y la dependencia de personas puntuales.
Paneles para dos audiencias
La información de trazabilidad y monitoreo tiene al menos dos públicos, con necesidades distintas:
- Equipos operativos y de atención: necesitan buscar una operación por número de pedido y ver su estado e historial en lenguaje de negocio, sin acceder a logs técnicos. Un backoffice de consulta y reprocesamiento les da autonomía.
- Equipos técnicos: necesitan métricas agregadas, tiempos por sistema, errores agrupados y acceso al detalle técnico para diagnosticar la causa.
Resolver bien la vista operativa suele tener un impacto enorme: muchas de las consultas que hoy llegan al área técnica pasan a resolverse en el momento.
Checklist para revisar tus integraciones
- ¿Podés encontrar una operación por su número de negocio y ver todo su recorrido?
- ¿Cada operación tiene un estado explícito y consultable?
- ¿Sabés cuántas operaciones están pendientes ahora y hace cuánto espera la más antigua?
- ¿Te enterás de que una integración dejó de funcionar antes de que lo reporte un cliente?
- ¿Las alertas llegan a quien puede resolverlas, con información suficiente para actuar?
- ¿El equipo operativo puede consultar el estado de una operación sin depender del área técnica?
Si alguna respuesta es «no», elegí una operación concreta y seguí su recorrido: dónde se recibió, en qué estado quedó y quién puede intervenir. Esa información también ayuda a diseñar la recuperación ante errores.