Monitoreo y disponibilidad: caso real peruano

En los últimos meses, el equipo de operaciones de una empresa peruana de distribución sintió el impacto directo de caídas inesperadas: pedidos retrasados, reclamos de clientes y presión sobre la gerencia. En este artículo verás paso a paso qué decisiones se tomaron, cómo cambió la rutina del personal y qué partes del proceso pueden replicarse en tu organización.

El punto de partida

Tipo de empresa: distribuidora de insumos industriales, 120 empleados, 3 sucursales en Lima, Arequipa y Trujillo. Sector: logística y suministro B2B. Problema concreto: en los últimos 6 meses se registraron 8 incidentes críticos que dejaron el ERP y la plataforma de seguimiento de pedidos fuera de línea entre 30 y 120 minutos cada uno. Cada caída generó pérdidas estimadas en un 0,8 % del volumen mensual de ventas y un aumento del 15 % en tickets de soporte.

Qué se hizo y por qué

1. Evaluación de la arquitectura actual – El ERP estaba alojado en un único servidor virtual en un data‑center local, sin redundancia ni balanceo de carga. La monitorización se limitaba a alertas por correo de un script casero que verificaba la disponibilidad del puerto 443.
2. Descartada la solución “solo backups” – Se consideró ampliar la frecuencia de backups, pero sin redundancia de ejecución la disponibilidad no mejoraba.
3. Decisión: migración a infraestructura híbrida – Se optó por mantener la base de datos crítica en un servidor dedicado en el data‑center de la empresa, y replicarla en tiempo real a una instancia en la nube pública peruana (AWS South‑America (São Paulo) con latencia <30 ms). Se añadió un balanceador de carga (AWS ELB) que dirige el tráfico a la instancia más saludable.
4. Implementación de monitoreo integral – Se adoptó una plataforma de observabilidad (Grafana + Prometheus) con dashboards personalizados para:
   • Latencia de API internas.
   • Uso de CPU, memoria y I/O de cada nodo.
   • Estado de replicación de la base de datos.
   • Métricas de SUNAT: tiempo de envío de facturas electrónicas. Alertas se configuraron por canales de Slack y SMS para los responsables de infraestructura y de operaciones.
5. Procedimientos de failover automatizado – Se definió un playbook de Ansible que, al detectar pérdida de conectividad del nodo primario, promueve la réplica en la nube a producción en menos de 2 minutos.

Qué cambió en el día a día

• Antes: El personal de operaciones revisaba manualmente los logs cada 2 h y, ante una caída, debía llamar al proveedor de hosting y esperar horas para que el servidor se reiniciara.
• Después: Los dashboards muestran en tiempo real el estado de cada componente. Cuando una métrica supera el umbral, el equipo recibe una alerta instantánea y ejecuta el playbook de failover con un solo comando. El tiempo medio de resolución pasó de 45 min a 3 min.
• Impacto en atención al cliente: Los tickets de soporte vinculados a indisponibilidad bajaron de 120 al mes a 15. La satisfacción del cliente, medida en NPS, subió 8 puntos en los tres meses posteriores.
• Trabajo del equipo de TI: Se redujo el 40 % del tiempo dedicado a incidentes y se liberó para proyectos de mejora continua, como la automatización de la generación de reportes de SUNAT.

• “Los sistemas se caen en los momentos críticos.” La falta de alertas tempranas y de un plan de recuperación automático obliga a reaccionar a fuego.
• “No sé si la base de datos está sincronizada.” Sin métricas de replicación, cualquier error pasa desapercibido hasta que afecta a los usuarios.

Qué es replicable y qué no

Replicable

• Arquitectura híbrida: cualquier empresa que dependa de un ERP o CRM puede replicar la estrategia de mantener la base de datos crítica on‑premise y una réplica en la nube peruana.
• Plataforma de observabilidad: Grafana + Prometheus es de código abierto y se adapta a diferentes entornos sin coste de licencia.
• Procedimientos de failover con Ansible: los playbooks son modulares; solo cambian los nombres de host y credenciales.

No replicable

• Latencia específica: la elección de la región de AWS (São Paulo) funcionó porque la empresa tenía enlaces de fibra directa con Lima. En otras regiones la latencia podría superar los 50 ms y requerir una zona de disponibilidad distinta.
• Acuerdos con proveedores locales: el data‑center on‑premise fue elegido por un contrato de 5 años con un proveedor que brinda soporte in‑site. Empresas sin esa relación tendrían que buscar alternativas.
• Cultura de respuesta: el éxito depende de que el equipo acepte la automatización de failover. Organizaciones con alta resistencia al cambio necesitarán un plan de capacitación más amplio.

Implementar monitoreo y alta disponibilidad redujo el tiempo de inactividad de 45 min a 3 min, mejorando la operación diaria.

Conclusión

Si tu empresa peruana depende de sistemas críticos para atender a clientes y cumplir con obligaciones como la facturación electrónica de SUNAT, el caso muestra que una arquitectura híbrida, combinada con monitoreo continuo y procedimientos automáticos de failover, transforma la gestión de incidentes. El beneficio es tangible: menos tiempo de inactividad, menos tickets de soporte y más tiempo del equipo de TI para innovar. Evalúa tu infraestructura actual, define métricas claras y establece un proceso de recuperación que pueda ejecutarse en minutos; esa es la diferencia entre perder ventas y mantener la confianza del cliente.