Servidor propio o en la nube: cómo se ve

En el día a día de un gerente de operaciones, la caída inesperada de un sistema crítico puede paralizar la facturación electrónica y generar sanciones de SUNAT. En este artículo verás, paso a paso, cómo una empresa peruana resolvió ese problema y qué puedes aplicar a tu organización.

El punto de partida

Tipo de empresa: distribuidora de insumos médicos, 120 empleados, con sucursales en Lima, Arequipa y Trujillo. Sector: salud, altamente regulado por la Ley de Protección de Datos Personales y la normativa de SUNAT para facturación electrónica.

Problema concreto: el ERP on‑premise, alojado en un servidor propio en el data center del edificio corporativo, presentaba interrupciones frecuentes durante los picos de carga (cierre de mes y envío masivo de facturas). Los tiempos de respuesta superaban los 10 s y, en tres ocasiones durante el último año, el sistema quedó fuera de línea por más de una hora, obligando a generar facturas manualmente y retrasando pagos.

Qué se hizo y por qué

Decisiones iniciales

• Descartar la migración total a la nube: el equipo de TI temía perder control sobre los datos de pacientes y la integración con equipos de laboratorio que requerían acceso a puertos locales.
• Mantener el servidor propio pero modernizar su arquitectura: se optó por una solución híbrida que combinara hardware local con servicios de monitoreo en la nube.

Implementación

1. Rediseño de la infraestructura: se instaló un cluster de dos servidores Dell PowerEdge con balanceador de carga interno (HAProxy). Cada nodo corre una réplica de la base de datos PostgreSQL configurada en modo streaming replication.
2. Alta disponibilidad para sistemas críticos: se añadió un heartbeat que detecta fallas de nodo en menos de 5 s y redirige automáticamente el tráfico al nodo activo.
3. Monitoreo de servidores: se contrató un servicio SaaS de monitoreo (Datadog) que recopila métricas de CPU, memoria, latencia de consultas y disponibilidad de APIs. Los dashboards se integraron a Slack del equipo de operaciones para alertas en tiempo real.
4. Pruebas de failover: se realizaron simulacros semanales de caída de nodo durante horarios de bajo tráfico, verificando que la conmutación fuera transparente para los usuarios.
5. Política de backup: se configuró replicación de snapshots a un bucket de almacenamiento en la nube (AWS S3) con retención de 30 días, cumpliendo con la normativa de SUNAT para conservación de comprobantes electrónicos.

Por qué esas decisiones

• Control de datos: mantener los datos críticos en servidores locales satisface la exigencia de la autoridad peruana de que la información de salud quede bajo jurisdicción nacional.
• Costo y tiempo: la migración completa habría requerido 12 semanas de re‑arquitectura y entrenamiento de usuarios, mientras que la solución híbrida se implementó en 6 semanas.
• Escalabilidad: el monitoreo en la nube brinda visibilidad sin necesidad de infraestructura adicional en la oficina central.

• El síntoma, en una frase. El ERP se vuelve lento o se cae en los picos de facturación.
• El síntoma, en una frase. Los equipos de laboratorio no pueden enviar resultados al sistema central.

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

Antes

• Los usuarios esperaban 8‑10 s para cargar una orden de compra.
• Cada caída provocaba una interrupción de 30‑60 min, generando tickets de soporte que se acumulaban en la bandeja de incidencias.
• El equipo de TI dedicaba 15 % de su tiempo a resolver incidentes de disponibilidad, en lugar de proyectos de mejora.

Después

• Tiempo de respuesta: la media bajó a 2‑3 s, incluso en los cierres de mes.
• Disponibilidad: el SLA interno pasó de 96 % a 99,7 % (menos de 2 h de inactividad al año).
• Trabajo del personal: las alertas automáticas redujeron los tickets de disponibilidad en un 70 %; el equipo de operaciones ahora dedica 5 % de su tiempo a gestión de incidentes y 10 % a optimización de procesos.
• Cumplimiento: al almacenar los backups en la nube con encriptación, la empresa cumplió con la normativa de SUNAT sin necesidad de auditorías adicionales.

El monitoreo continuo y la arquitectura de alta disponibilidad transforman la experiencia del usuario y liberan recursos de TI.

Qué es replicable y qué no

Replicable a otras empresas del sector salud

• Arquitectura híbrida: combinar servidores propios con un servicio de monitoreo en la nube es una solución que equilibra control y visibilidad.
• Procedimientos de failover: los simulacros semanales y la configuración de heartbeat pueden adoptarse tal cual.
• Política de backup en la nube: usar buckets S3 o Azure Blob con retención de 30 días satisface la mayoría de los requisitos regulatorios en Perú.

No replicable sin ajustes

• Hardware específico: el cluster Dell PowerEdge se eligió por la compatibilidad con equipos de laboratorio que usan drivers propietarios; otra empresa podría necesitar hardware distinto.
• Integración con equipos de laboratorio: la necesidad de puertos RS‑232 y protocolos propietarios es particular de este caso; empresas de retail o logística no lo requerirán.
• Restricciones de datos: si la normativa de tu sector permite almacenar datos en la nube sin restricciones, la solución híbrida puede simplificarse a una arquitectura 100 % cloud.

Conclusión

Al pasar de un servidor propio aislado a una arquitectura híbrida con monitoreo en la nube, la empresa peruana logró reducción del tiempo de respuesta, casi triplicar la disponibilidad y liberar al equipo de TI para actividades estratégicas. La clave estuvo en identificar los requerimientos regulatorios, elegir una solución que mantuviera el control de los datos críticos y aprovechar la visibilidad que brinda el monitoreo externo. Si tu organización enfrenta interrupciones en los momentos críticos, replicar este enfoque —ajustando hardware y políticas de backup a tu contexto— puede producir resultados medibles en semanas.