Una semana antes del pico de la temporada del año pasado, estaba recorriendo un 3PL en Rialto cuando su director de TI me mostró con orgullo la nueva API de etiquetas de la paquetería que acababan de integrar. «Maneja 2,000 solicitudes por segundo», dijo. Le hice una sola pregunta y se quedó paralizado: «Si esta API se cae a las 2 AM, ¿quién es la primera persona en enterarse?»
Pensó un largo momento. «Probablemente... el operador de la impresora de etiquetas a las 6 AM».
Eso lo dice todo. Qué tan robusta es una integración es una pregunta técnica. Quién se entera primero cuando falla es una pregunta de gestión. La mayoría de los almacenes en la práctica no tienen monitoreo de integraciones. No porque nunca lo hayan configurado, sino porque lo que configuraron bien podría no existir: umbrales absurdos, alertas enviadas a un buzón que nadie lee, o mensajes de texto a las 3 AM que despiertan a todo el equipo hasta que todos silencian el canal.
En veinte años he visto morir integraciones de al menos veinte formas distintas. Aquí está mi lista de verificación de monitoreo y alertas, explicada en lenguaje claro. Sígala, y la primera persona en enterarse de una caída será alguien de su equipo, no su cliente.
Las cinco señales. Todo lo demás es un extra.
No empiece con un panel de observabilidad elegante. En un almacén, cinco señales lo cubren todo. Si le falta una, la temporada alta todavía puede morderlo.
Primero, el latido (heartbeat). ¿Está vivo el endpoint? Lo más simple y lo más omitido: haga ping al endpoint de health-check cada cinco minutos, o envíe un mensaje de prueba. Las API de etiquetas de la paquetería, la validación de direcciones, las calculadoras de impuestos aduaneros — todo lo de terceros necesita su propio heartbeat. En 2023, un 3PL en Ontario perdió cuatro horas de impresión de etiquetas porque el certificado TLS de una paquetería expiró. Sin prueba de heartbeat, sin aviso. Nueve mil pedidos se acumularon antes de que alguien lo notara. Las pruebas de heartbeat no cuestan prácticamente nada. Omitirlas es pura pereza.
Segundo, la tasa de errores. Solicitudes fallidas como proporción del total en una ventana de cinco minutos. Proporción, no conteo absoluto — durante el pico, el volumen se multiplica por diez, así que los fallos absolutos subirán con normalidad. Un aumento en la proporción es lo que indica un problema real.
Tercero, la latencia. Latencia P99, no el promedio. Un promedio de 200ms suena precioso hasta que el P99 llega a ocho segundos — eso significa que el uno por ciento de las solicitudes se atasca, normalmente concentradas en los minutos más ocupados, y eso es exactamente lo que atasca la línea de empaque.
Cuarto, la profundidad del backlog. Longitud de la cola, conteo de archivos sin procesar, profundidad del pool de reintentos. «Lento pero no muerto» es el modo de falla más cruel: todo se ve bien en la superficie mientras la cola crece más y más, y cuando se da cuenta, 30,000 mensajes están enterrados y no hay forma de salir.
Quinto, brechas de conciliación. Conciliación programada: pedidos que enviamos contra pedidos que ellos recibieron. Etiquetas de la paquetería, documentos EDI 850/856, sincronizaciones de inventario — concilie al menos a diario. La conciliación es la última línea de defensa. Cuando las primeras cuatro señales fallan, esta la detecta.
Cómo fijar umbrales: tres niveles, sin talla única
El error clásico es un umbral para todo: o el niño que gritaba lobo todos los días, o una caída real que nadie nota. Yo clasifico por impacto al negocio:
P1 — llamada telefónica, responder en cinco minutos. Disparadores: el heartbeat falla dos veces seguidas en una interfaz central (impresión de etiquetas, confirmación de envío, sincronización de inventario); tasa de errores por encima del 5% en una ventana de cinco minutos; latencia P99 por encima de diez segundos durante diez minutos seguidos. P1 significa una llamada telefónica real al ingeniero de guardia. No un texto, no un correo. Sin respuesta en cinco minutos, escala automáticamente al segundo contacto.
P2 — texto más mensaje de grupo, responder en treinta minutos. Disparadores: tasa de errores por encima del 3% en una interfaz no central (validación de direcciones, callbacks de rastreo); backlog de cola por encima de 5,000 mensajes y sigue creciendo después de quince minutos; más de cincuenta reintentos fallidos en el mismo lote. P2 va al canal de guardia, y un «recibido» cuenta como acuse de recibo.
P3 — correo más resumen diario, atender en horario laboral. Disparadores: brecha de conciliación menor al 0.5%; un arrastre lento del P99 que aún no cruza la línea; un certificado que expira en treinta días. Estos van en el reporte matutino del standup de TI.
Un detalle crítico: ajuste los umbrales por interfaz, y congele los cambios de umbrales dos semanas antes del pico. La peor configuración que he visto tenía cada interfaz compartiendo un umbral de 1% de tasa de errores. Durante el pico, la API de validación de direcciones estaba en 2–3% de errores todo el día porque los compradores escriben direcciones basura — las alertas sonaban constantemente, todos las ignoraban, y esa noche una caída genuina P1 fue ignorada como una falsa alarma más. Calibre cada umbral contra el P95 histórico de esa interfaz antes del pico. Toma una tarde. Omitirlo le cuesta la única alerta que importa.
Quién recibe la alerta: el rol de guardia importa más que la tecnología
La tecnología puede ser perfecta y aun así inútil si las alertas llegan a personas que han silenciado todo. Tres reglas que exijo:
Una, debe haber un rol de guardia — una persona nombrada, no «el equipo». Una alerta en un chat grupal significa que todos asumen que otro la atenderá. Las alertas P1 van punto a punto: primero al ingeniero de guardia, sin respuesta en cinco minutos escala automáticamente al gerente de TI, luego al director de operaciones, quien tiene autoridad para tomar decisiones de negocio como cambiar a una paquetería de respaldo. El rol rota semanalmente, se publica una semana antes, y los turnos de feriado ganan tiempo compensatorio. Un rol sin tiempo compensatorio no sobrevive un mes.
Dos, separe los canales por severidad. P1 por teléfono, P2 por texto y chat grupal, P3 por correo. Nunca tire el resumen P3 en el mismo canal que P1 — una vez que el ruido es suficiente, la gente aprende a ignorar todo. Una vez vi un canal de 200 personas enviando 300 alertas al día. Un P1 enterrado ahí tenía cero chances.
Tres, revise las falsas alarmas mensualmente. Revise las alertas del mes pasado: cuáles fueron incidentes reales, cuáles falsos positivos, cuáles sonaron y fueron ignoradas. Cualquier umbral con una tasa de falsos positivos por encima del 30% se reajusta. Las alertas ignoradas se investigan. Un sistema de alertas, como una persona, se pudre sin revisión.
Y una lección pagada con sangre: haga un simulacro de «cortar la red» antes del pico. Una mañana tranquila de fin de semana, corte la API de la paquetería en staging y mida todo — qué tan rápido suena la alerta, qué tan rápido responde el de guardia, qué tan rápido entra el plan de respaldo. Un plan que solo se ha discutido en papel fallará su primera prueba real, garantizado. Los almacenes con los que he trabajado que hacen el simulacro contra los que no, se desempeñan como dos especies distintas la noche del pico.
¿Cuánto cuesta esto? Hagamos las cuentas.
Configurar esto no es caro. Las pruebas de heartbeat y el rastreo de tasa de errores con un APM listo para usar (Datadog, New Relic, o Prometheus de código abierto más Alertmanager) toma alrededor de una semana en montarse. El costo real es el estipendio de guardia: por aquí, un turno entre semana cuesta $50–80, los fines de semana $100–150. En la rotación, eso es un par de miles de dólares al mes.
Ahora el costo de no hacerlo. El escenario más común: la API de etiquetas muere de noche, nadie lo sabe hasta las 6 AM, 8,000 pedidos atrasados. Cada pedido se retrasa un día — cutoffs de la paquetería perdidos, tickets de soporte, penalizaciones de los marketplaces (el OTDR de Amazon baja medio punto y su peso en Buy Box recibe el golpe), más horas extra para ponerse al día. Un incidente así cuesta $20,000–50,000, siendo conservadores. Un solo incidente en un año paga el monitoreo diez veces.
Así que mi veredicto es directo: el monitoreo de integraciones no es un curso optativo de TI. Es un curso obligatorio de operaciones de almacén. Puede saltarse los paneles elegantes y las palabras de moda de observabilidad, pero cinco señales, tres niveles de umbrales y un rol de guardia — esos tres deberían existir para esta noche.
A primera hora mañana por la mañana: pregúntele a su líder de TI quién se entera primero cuando una interfaz muere a las 2 AM. Si no puede responder, ya sabe qué hacer.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
