Observabilidad 24/7 en cadenas de supermercados con 50+ tiendas

Hay una pregunta que todo CTO de grocery enterprise escucha al menos una vez por trimestre, y siempre llega tarde:

"¿Por qué nadie nos avisó que la caja 4 de la tienda Mixco estaba caída desde las once?"

La respuesta honesta — la que nadie da en la reunión, pero todos sabemos — es que el sistema sí lo sabía. Lo que faltaba era que ese conocimiento llegara a una persona despierta antes de que el gerente de tienda llamara furioso a las dos de la mañana porque tenía cola y no podía cobrar.

Eso es observabilidad. Y cuando una cadena de supermercados tiene cincuenta tiendas, e-commerce activo, app móvil, integración con marketplaces y cadena fría — operar sin observabilidad no es ahorro, es ceguera estructural.

Este post es sobre cómo se construye observabilidad en grocery enterprise sin caer en las dos trampas clásicas: gastar treinta mil dólares al mes en herramientas que nadie mira, o tener tantas alertas que el equipo aprende a ignorarlas todas.

Los tres pilares — y por qué importan más en grocery

La industria de SRE establece tres pilares de observabilidad: logs, métricas y trazas. Repetir eso en una cadena de cincuenta tiendas sin entender qué hace cada uno es el origen de la mayoría de implementaciones fallidas que vemos. Los tres no son intercambiables — responden preguntas distintas.

Una cadena de supermercados tiene cinco superficies que necesitan los tres pilares cubiertos en simultáneo: POS por sucursal, e-commerce y app móvil, integraciones con marketplaces, cadena fría y procesos batch nocturnos (conciliación bancaria, sincronización con ERP, ETL hacia el data warehouse). Si tu observabilidad cubre fuerte solo dos o tres, los incidentes van a aparecer exactamente en las que dejaste fuera.

El stack moderno — y por qué OpenTelemetry no es opcional

Hace cinco años, la respuesta razonable era "usá Datadog". Hoy esa respuesta cuesta cuatro veces más y te encadena al proveedor. La respuesta correcta en 2026 — y la que aplicamos por default — es OpenTelemetry como estándar abierto, con backends elegibles según presupuesto y compliance.

La inversión inicial honesta para una cadena de cincuenta tiendas con e-commerce y app activos: entre USD 1.500 y 6.000 mensuales en herramientas, dependiendo del volumen de logs y si usás SaaS o self-hosted. Esto no incluye el equipo SRE, que es el costo real — pero sin las herramientas, tener equipo SRE no sirve de nada.

OpenTelemetry no es opcional por una razón concreta: cuando dentro de dieciocho meses quieras cambiar de Grafana a New Relic, o llevar parte del stack on-prem por un cliente que pide compliance, no querés reinstrumentar quince servicios. Con OTel, cambiás solo el endpoint del collector. Sin OTel, vuelves a empezar.

Patrones específicos de supermercados

Lo que diferencia observabilidad genérica de observabilidad para grocery son cinco patrones que necesitás resueltos antes del primer incidente serio.

POS por sucursal con jerarquía de criticidad

No todas las cajas son iguales. La caja 1 de la tienda principal en Cayalá un viernes a las 6 de la tarde no tiene el mismo peso operativo que la caja 6 de una sucursal en pueblo a las 10 de la mañana de un martes. Tu sistema de alertas tiene que conocer esa diferencia.

// services/pos-health/src/alerts/severity.ts
export function calculatePosSeverity(input: {
  storeTier: 'flagship' | 'standard' | 'satellite';
  posIndex: number;          // posición física de la caja
  hourOfDay: number;
  dayOfWeek: number;
  errorRate: number;         // 0-1
  isPeakSeason: boolean;     // 14-sep, día de la madre, BF, fin de quincena
}): 'p0' | 'p1' | 'p2' | 'p3' {
  const baseScore =
    (input.storeTier === 'flagship' ? 30 : input.storeTier === 'standard' ? 20 : 10) +
    (input.posIndex <= 3 ? 20 : 5) + // primeras 3 cajas son las más cargadas
    (input.hourOfDay >= 17 && input.hourOfDay <= 21 ? 25 : 5) +
    (input.dayOfWeek === 5 || input.dayOfWeek === 6 ? 15 : 0) +
    (input.isPeakSeason ? 25 : 0) +
    Math.round(input.errorRate * 30);
 
  if (baseScore >= 90) return 'p0'; // despierta a alguien
  if (baseScore >= 65) return 'p1'; // alerta inmediata, no despierta
  if (baseScore >= 40) return 'p2'; // ticket, revisión en horas
  return 'p3';                       // se mira en la mañana
}

Este tipo de lógica vive en tu capa de routing de alertas, no en cada herramienta separada. Es la diferencia entre un equipo que responde inteligentemente y uno que se quema en seis meses.

Cadena fría con alertas escalonadas

Las cámaras de carnicería, lácteos y congelados tienen sensores que reportan temperatura cada 30-60 segundos. Pero alertar a alguien cada vez que la temperatura sube un grado es la receta para que el equipo desactive las notificaciones la primera semana.

El patrón correcto: tres niveles de alerta basados en duración + magnitud.

• Nivel 1 (informativo): la temperatura subió 2°C por menos de 10 minutos. Probablemente alguien abrió la puerta. Ticket pasivo.
• Nivel 2 (advertencia): subida sostenida más de 20 minutos o pico mayor a 4°C. SMS al gerente de tienda. No despierta a nadie, pero deja registro.
• Nivel 3 (crítico): temperatura fuera de rango más de 45 minutos, o subida de más de 6°C. Llamada automática al on-call de operaciones, al gerente de tienda, y al supervisor regional, en orden, hasta que alguien acuse recibo.

Las pérdidas en perecederos por una cámara fría que falló en horario nocturno y nadie se enteró pueden ir de USD 8.000 a 35.000 por incidente. Una cadena seria recupera la inversión en monitoreo IoT con cadena fría con un solo incidente evitado al año.

Sincronización de inventario y deriva acumulativa

Si tu cadena trabaja con middleware event-driven — y si no, hablamos de eso en Integración omnichannel sin reescribir el ERP — vas a tener una métrica nueva, crítica, que no aparece en ningún dashboard genérico de Grafana: deriva de inventario por SKU.

La deriva es la diferencia entre el inventario que ve el e-commerce y el que ve el ERP. En un sistema bien construido, esa deriva debería tender a cero en cuestión de segundos. Si crece y no decrece, hay un consumer roto.

// services/inventory-watch/src/metrics.ts
import { metrics } from '@opentelemetry/api';
 
const meter = metrics.getMeter('inventory-watch', '1.0.0');
 
const driftHistogram = meter.createHistogram('inventory.drift_units', {
  description: 'Diferencia absoluta entre inventario ERP y catálogo e-commerce',
  unit: 'units',
});
 
const driftAge = meter.createHistogram('inventory.drift_age_seconds', {
  description: 'Edad del último evento de inventario sin procesar',
  unit: 's',
});
 
export function reportDrift(sku: string, store: string, drift: number, ageSeconds: number) {
  driftHistogram.record(Math.abs(drift), { sku, store });
  driftAge.record(ageSeconds, { store });
}

Con esa métrica configurás una alerta: si la deriva mediana de inventario por tienda supera 3 unidades por más de 5 minutos, hay un problema en el consumer. Esa alerta va a salvarte de un Black Friday GT con cinco mil pedidos vendidos sobre stock que no existía.

Picos críticos del calendario guatemalteco

Cualquier cadena seria tiene su calendario operativo, pero hay cinco fechas en Guatemala donde la carga es atípica y donde el sistema necesita estar reforzado antes, no durante.

• Día de la Madre (10 de mayo): pico tarde-noche en lácteos, panadería, flores. Ojo con las cámaras frías de florería que rara vez se monitorean igual que las de cárnicos.
• 14 de Septiembre: pico bebidas, snacks, asados. Pico dramático en marketplaces — PedidosYa y Hugo procesan tres veces el volumen normal.
• Black Friday y CyberMonday GT: pico web y app, generalmente leve en tiendas físicas comparado con e-commerce.
• Fin de quincena: pico estable mensual, particularmente en zonas urbanas. La mayoría de los problemas de conciliación bancaria salen el primer día hábil del mes nuevo.
• Vendaval (octubre): tormentas tropicales pueden cortar internet en sucursales remotas. El sistema necesita degradación elegante: POS sigue cobrando offline, sincroniza después.

La regla operativa: dos semanas antes de cada uno de estos picos, hacés un game day. Simulás carga, simulás corte de internet en una sucursal, simulás caída del gateway bancario. No esperás al día.

El error más caro: alertas que nadie atiende

He visto seis veces el mismo patrón. Una cadena empieza con observabilidad. Configura cien alertas el primer mes. Tres meses después el equipo ignora todas. Seis meses después contratan una consultora para "arreglar el monitoreo", que les vende cien alertas más.

La fatiga de alertas es la enfermedad ocupacional del SRE moderno, y tiene una sola cura: disciplina brutal con la jerarquía de severidad.

El proceso operativo que hace que esto funcione: postmortem de alerta una vez por semana. Cada P0 disparada se revisa en grupo de 30 minutos. ¿Tenía las tres condiciones? Si no, baja a P1 o se ajusta el umbral. Si sí, ¿el runbook fue claro? ¿Faltó información? Cada alerta que no cumple las condiciones se ajusta o se elimina antes del lunes siguiente.

Sin esa disciplina, el sistema técnico más sofisticado falla por causas humanas en menos de un trimestre.

Si tu cadena ya pasó por una caja caída sin que nadie lo supiera

Si ya viviste el incidente del título — caja caída, gerente furioso a las 2 de la mañana, equipo enterándose por WhatsApp del gerente, no por la herramienta — ya sabés cuánto cuesta operar sin observabilidad en grocery enterprise.

Lo que diseñamos en nuestro retainer de ingeniería cubre exactamente eso: stack OpenTelemetry calibrado al contexto de tu cadena, alerting con jerarquía clara, runbooks por superficie, game days antes de cada pico estacional. No vendemos plataforma — diseñamos el sistema de observabilidad y nos quedamos cerca durante los primeros 90 días para que tu equipo lo opere con confianza.

Si esto suena a tu situación, hablemos. 30 minutos. Sin pitch.