Monitoreo y disponibilidad: conectar lo que ya

En tu día a día, la caída inesperada de un módulo crítico afecta la operación y la confianza de tus clientes. En este artículo verás paso a paso cómo alinear el monitoreo y la disponibilidad del sistema con las herramientas que ya utilizas en tu empresa peruana.

Con qué se tiene que hablar

Antes de implementar cualquier capa de observabilidad, es esencial mapear los sistemas que ya forman parte del ecosistema empresarial. En la mayoría de las organizaciones peruanas, estos incluyen:

• ERP o contabilidad (por ejemplo, Odoo, SAP Business One, o sistemas a medida).
• Plataformas de facturación electrónica que ya están conectadas a SUNAT.
• Gateways de pago como Yape, Plin, Niubiz o Izipay.
• Herramientas de gestión de incidencias (Jira, Redmine) y de comunicación interna (Microsoft Teams, Slack).
• Servidores de bases de datos (PostgreSQL, MySQL, Oracle) y servicios de mensajería (RabbitMQ, Kafka).

Cada uno de estos componentes genera métricas propias (latencia, errores HTTP, uso de CPU, colas llenas) y, a su vez, necesita ser consumido por el sistema de monitoreo. La clave está en exponer los datos sin modificar el código existente. Las opciones más habituales son:

1. Exportadores de métricas (Prometheus exporter) que leen directamente del proceso o de la base de datos.
2. Webhooks que envían eventos a un endpoint de observabilidad.
3. Logs estructurados enviados a un agregador (Elastic, Loki) mediante agentes ligeros.

Al decidir cuál usar, considera el nivel de intrusión que puedes permitir. Un exportador que se ejecuta como contenedor separado suele ser la opción menos invasiva y se puede desplegar en menos de 2 semanas para la mayoría de los sistemas críticos.

SUNAT y facturación electrónica

La normativa peruana obliga a que toda factura electrónica sea enviada a SUNAT en tiempo real y que el código de respuesta sea registrado en el ERP. El proceso típico es:

1. El ERP genera el XML de la factura.
2. Se envía a SUNAT mediante el Web Service de la SUNAT.
3. SUNAT devuelve un CDR (Constancia de Recepción) con código 0 (aceptado) o 98‑99 (rechazo).

Requisitos técnicos

• Certificado digital vigente (p12) instalado en el servidor.
• Conexión TLS 1.2 obligatoria.
• Endpoint: https://e-factura.sunat.gob.pe/ol-ti-itcpfegem-beta/billService (producción) o su versión de pruebas.
• Formato de mensaje: SOAP 1.2 con esquema XSD oficial.

Errores típicos y cómo evitarlos

• Tiempo de respuesta > 5 seg. La integración bloquea la generación de la siguiente factura y el backlog crece.
• Certificado expirado. SUNAT rechaza todas las facturas y el negocio se detiene hasta la renovación.
• Desincronización de estados. El ERP muestra “enviado” pero SUNAT devuelve rechazo; la conciliación manual genera doble trabajo.

Para que el monitoreo detecte estos fallos, agrega checks de salud que consulten:

• Validez del certificado (renovación cada 30 días).
• Latencia del SOAP (alerta si supera 3 s).
• Código de respuesta (alerta inmediata ante cualquier código distinto a 0).

Un alerta por correo o ticket automático debe generarse en menos de 5 minutos desde la detección, garantizando que el responsable de facturación actúe antes de que se acumulen facturas pendientes.

Cobros y bancos

Los pagos digitales en Perú se han diversificado: Yape y Plin son wallets móviles, mientras que Niubiz e Izipay operan como pasarelas de tarjetas y transferencias bancarias. Cada uno tiene su propio flujo de integración, pero comparten patrones que facilitan una estrategia unificada.

Yape y Plin

• API REST con autenticación OAuth 2.0.
• Webhook de notificación de pagos recibido en tiempo real.
• Plazo de conciliación: 0‑2 minutos para pagos instantáneos.

Problema frecuente: la URL del webhook no está disponible en producción por restricciones de firewall interno. Solución: abrir un puerto específico (ej. 8443) y registrar la URL en la consola de Yape/Plin. El tiempo de implementación suele ser 1‑2 semanas.

Niubiz e Izipay

• API SOAP (Niubiz) y REST (Izipay) con firma digital HMAC‑SHA256.
• Proceso de autorización en dos pasos: token → transacción.
• Plazo de conciliación: 15‑30 minutos para tarjetas, 1‑2 días para transferencias bancarias.

Errores típicos:

• Desfase de zona horaria: los logs de la pasarela se registran en GMT‑5 mientras el ERP usa GMT‑4, provocando falsas alarmas de retraso.
• Cambio de versión del API sin notificación previa; la firma deja de coincidir y todas las transacciones son rechazadas.

Monitoreo específico para cobros

1. Health check del token: renovar cada 24 h y validar que el endpoint devuelve 200.
2. Latencia de autorización: alertar si supera 2 s (Yape/Plin) o 5 s (Niubiz).
3. Tasa de rechazo: umbral del 1 % sobre el total de transacciones en una ventana de 15 minutos; supera el umbral → ticket automático.

Implementar estos checks en Grafana o Kibana permite visualizar en tiempo real el desempeño de cada canal de cobro y actuar antes de que el flujo de ingresos se vea comprometido.

Qué pedirle al proveedor

Cuando contratas una solución de monitoreo o un proveedor de integración, la claridad contractual evita sorpresas costosas. Los puntos críticos son:

• APIs documentadas: deben incluir especificación OpenAPI/Swagger, ejemplos de request/response y definición de códigos de error.
• Versionado: cada cambio mayor debe publicar una nueva versión (v1, v2…) y mantener al menos 12 meses de soporte para la versión anterior.
• Política de cambios: notificación mínima 30 días antes de modificar contratos, endpoints o formatos de mensaje.
• SLAs de disponibilidad: al menos 99.5 % mensual para la capa de observabilidad; cualquier caída superior a 5 min debe ser compensada con reportes de causa raíz.
• Acceso a logs: el proveedor debe ofrecer exportación de logs en formato JSON o syslog, sin limitaciones de retención inferior a 90 días.
• Soporte de incidentes: canal de tickets con tiempo de respuesta < 15 min para incidentes críticos (p.ej., pérdida de métricas de facturación).

Qué ocurre cuando la otra parte cambia

Supongamos que SUNAT actualiza su esquema XSD y el proveedor de tu ERP no lo refleja en 48 h. El resultado inmediato es rechazo masivo de facturas. Para mitigar este riesgo:

1. Entorno de pruebas: mantén una réplica del proceso de facturación con datos simulados y ejecuta pruebas de regresión cada vez que recibas un aviso de cambio.
2. Feature flags: habilita la nueva versión del esquema bajo una bandera que puedas activar/desactivar sin redeploy.
3. Alertas de versión: suscríbete al RSS de cambios de la SUNAT y a los boletines de tu proveedor de pasarela de pagos.

Con este enfoque, el tiempo entre la publicación del cambio y su adopción en producción se reduce de semanas a días, manteniendo la disponibilidad del sistema dentro del objetivo del 99.9 %.

Una integración bien monitorizada reduce el tiempo medio de detección de incidentes de 45 min a menos de 5 min.

Conclusión

Quien ha llegado hasta aquí entiende que la disponibilidad no se logra solo con hardware robusto, sino con una conexión consciente entre el monitoreo y los sistemas ya operativos. Mapear los componentes existentes, adaptar los checks a los requisitos de SUNAT y a los flujos de pago, y exigir claridad contractual al proveedor son pasos concretos que, en menos de 6 semanas, pueden elevar la confiabilidad del ecosistema a niveles que evitan pérdidas operativas y mantienen la confianza de clientes y socios.