Monitoreo en producción: qué ocurre tras entrega

La entrega de un software a medida es solo el inicio; la verdadera prueba llega cuando el sistema pasa a operar en tu entorno real. En este artículo verás qué debes vigilar, quién debe responder y cómo estructurar el mantenimiento para que tu inversión no se convierta en una fuente de interrupciones.

Lo que empieza el día de la entrega

Nadie menciona que, al firmar el acta de entrega, también se está aceptando una serie de supuestos que impactan directamente en la disponibilidad del sistema. Entre ellos:

• Entorno de producción definido: Si el proyecto no especificó dónde alojar el sistema de tu empresa (nube pública, data center propio o hosting especializado), el equipo de desarrollo puede dejar configuraciones que no se alinean con tus políticas de seguridad ni con los requerimientos de la SUNAT para facturación electrónica.
• Acuerdos de nivel de servicio (SLA): Es fundamental que el contrato incluya tiempos de respuesta y porcentajes de disponibilidad (por ejemplo, 99.5 % mensual). Sin estos números claros, cualquier caída será negociada a posteriori.
• Procedimientos de monitoreo: El proyecto debe entregar los dashboards y alertas configuradas para el monitoreo de aplicaciones en producción. Si no hay indicadores de salud, la detección de incidentes será reactiva y costosa.
• Transferencia de conocimientos: El personal de operaciones debe recibir una capacitación mínima y un manual de operación antes del go‑live. Sin esto, la resolución de incidentes dependerá exclusivamente del proveedor.

Quién responde cuando algo falla

Una vez que el sistema está en marcha, la responsabilidad de atender incidentes debe quedar claramente definida. Lo ideal es un esquema escrito que incluya:

1. Primer nivel de respuesta – Tu equipo interno (Jefe de Operaciones o Responsable de TI) recibe la alerta y verifica si el problema está dentro del alcance del contrato (por ejemplo, una configuración del servidor). Si la causa está fuera, se escala al proveedor.
2. Segundo nivel – El equipo de Kovensa (o el proveedor contratado) interviene bajo los tiempos pactados. Un SLA típico para sistemas críticos exige respuesta inicial en 15 min y resolución parcial en 2 horas.
3. Escalamiento – Si la incidencia supera el umbral de disponibilidad (por ejemplo, caída mayor al 5 % del tiempo mensual), se activa un comité de crisis que incluye a la gerencia y al área legal para evaluar impactos en la facturación electrónica y en la normativa de la SUNAT.

Qué exigir por escrito:

• Listado de contactos con horarios de disponibilidad.
• Procedimientos de escalamiento y criterios de prioridad.
• Reportes post‑incidente que incluyan causa raíz y plan de acción.
• Garantías de que el monitoreo de servidores seguirá activo durante el proceso de resolución.

Mantenimiento: qué es y qué no

El mantenimiento no es sinónimo de “arreglar bugs”. Se divide en tres categorías que deben quedar claras en el contrato:

• Correctivo: Solución de fallas detectadas en producción. Incluye parches de seguridad y corrección de errores que impiden la operación normal.
• Evolutivo: Mejoras que añaden funcionalidades o optimizan procesos. No forman parte del mantenimiento básico y suelen requerir un nuevo acuerdo de alcance.
• Preventivo: Actividades programadas, como actualización de versiones de dependencias, revisión de logs y pruebas de recuperación de desastres. Aquí entra la alta disponibilidad para sistemas críticos: pruebas de failover cada trimestre y revisión de configuraciones de balanceo de carga.

Lo que no es mantenimiento:

• Rediseñar la arquitectura completa.
• Migrar la solución a otro proveedor de hosting sin previo acuerdo.
• Implementar nuevas integraciones que cambien el flujo de negocio.

Mantener una línea clara entre estos tipos evita sorpresas en los plazos y en la facturación del proyecto.

Cómo evitar quedar atrapado

1. Accesos – Asegúrate de que tu empresa posea credenciales de administrador a todos los componentes (servidores, bases de datos, herramientas de monitoreo). La cláusula de “propiedad del código” debe incluir también los accesos.
2. Copias de seguridad – Define una política de backups fuera de sitio y verifica que los procesos de restauración se prueben al menos una vez al mes. En Perú, la normativa de la SUNAT exige conservar los comprobantes electrónicos por 5 años; tus backups deben cumplir ese requisito.
3. Documentación – Exige entregas de manuales de arquitectura, diagramas de flujo y scripts de despliegue. Un documento de “run‑book” bien estructurado reduce el tiempo de respuesta en un 30 %.
4. Propiedad del código – El contrato debe especificar que el código fuente y los artefactos son de tu empresa, con licencia perpetua. De lo contrario, dependerás del proveedor para cualquier ajuste futuro.
5. Revisiones periódicas – Programa auditorías trimestrales de disponibilidad y revisa los indicadores de monitoreo de aplicaciones en producción. Ajusta los umbrales de alerta según la carga real del sistema.

• El sistema se detiene sin aviso. Significa que no hay alertas configuradas o que los accesos al monitoreo están rotos.
• No tienes acceso a los logs. Indica falta de transferencia de credenciales y documentación.
• Los tiempos de respuesta del proveedor son mayores a los acordados. Señala que el SLA no está bien definido o que no se está cumpliendo.

Conclusión

Quien haya leído hasta aquí comprende que la entrega de un software no termina con la firma del contrato. El éxito depende de que se establezcan claramente los procesos de monitoreo, se definan responsabilidades y se mantenga la propiedad total del sistema. Con acuerdos de SLA precisos, un plan de mantenimiento bien delimitado y una documentación completa, tu empresa podrá garantizar la disponibilidad que exige la normativa peruana y la operatividad de sus procesos críticos.