Un sistema a medida necesita mantenimiento continuo: correcciones, parches de seguridad, mejoras y soporte técnico. Sin mantenimiento, tu aplicación se vuelve frágil, lenta y vulnerable. Un SLA (Service Level Agreement) define expectativas claras: qué esperar cuando algo falla y cómo responde el equipo de soporte.

¿Qué es Mantenimiento de Software?

Mantenimiento de software incluye todas las actividades después del lanzamiento:

• Correctivo: Arreglar bugs y errores reportados por usuarios.
• Preventivo: Parches de seguridad, actualizaciones de dependencias, optimización de performance.
• Adaptativo: Ajustar la aplicación a cambios en SUNAT, regulaciones, o requerimientos del negocio.
• Perfectivo: Mejoras solicitadas por usuarios: nuevas features, UI mejorada, etc.

Ejemplo: Tu e-commerce tiene un bug donde descuenta mal impuestos SUNAT. Eso es mantenimiento correctivo. Instalar un parche de seguridad en PHP es preventivo. Agregar método de pago Yape es perfectivo.

¿Qué es un SLA?

Un SLA es un contrato entre tu empresa (cliente) y el proveedor de soporte (developers/agency) que especifica:

• Qué se incluye en soporte (bugs críticos, performance, seguridad).
• Tiempos de respuesta según prioridad.
• Disponibilidad esperada (uptime %).
• Horarios de atención.
• Canales de contacto.
• Penalizaciones si no se cumple.

Ejemplo SLA básico:

• Prioridad CRÍTICA (app caída): Respuesta en 30 min, resolución en 2 horas.
• Prioridad ALTA (feature no funciona): Respuesta en 4 horas, resolución en 24 horas.
• Prioridad MEDIA (lentitud, bug menor): Respuesta en 24 horas, resolución en 5 días.
• Uptime garantizado: 99.5% (máximo 3.6 horas de downtime/mes).

¿Por Qué Es Crítico para PYMES Peruanas?

Sin SLA claro:

• Sistema cae durante horario de ventas: nadie responde.
• Bug de facturación SUNAT: no sabes cuándo se arreglará.
• Tu developer está de vacaciones y nadie sabe el código.
• Cambio de regulación tributaria: aplicación no se adapta a tiempo.

Un SLA evita estos problemas: hay responsabilidad clara, tiempos garantizados, y tranquilidad operacional.

Componentes Esenciales de un SLA

1. Niveles de Prioridad Claros

Prioridad	Descripción	Respuesta	Resolución	Ejemplo
CRÍTICA	Sistema completo caído, datos perdidos, seguridad comprometida	30 min	2-4 horas	BD corrupta, app no inicia, brechas de seguridad
ALTA	Feature principal no funciona, impacta ventas/operación	4 horas	24 horas	Carrito de compras lento, facturas no se generan
MEDIA	Feature secundaria no funciona, workaround disponible	24 horas	5 días	Búsqueda lenta, reporte con datos incompletos
BAJA	Mejoras, requests, cambios estéticos	5 días	2-4 semanas	Cambiar color de botón, agregar link, ajustes UI

2. Canales de Contacto y Horarios

Canales recomendados:

• Correo: Reportes formales, documentación, seguimiento.
• Ticket system (Jira, Zendesk): Traceabilidad, historial, priorización.
• WhatsApp/Telegram: Avisos urgentes para CRÍTICAS (solo horario laboral).
• Teléfono: Incidentes críticos fuera de horario (si aplica).

Horarios típicos:

• Soporte básico: Lunes-viernes 9 AM - 6 PM (horario Perú).
• Soporte 24/7: Para CRÍTICAS (requiere costo adicional S/ 5,000-15,000/mes extra).

3. Monitoreo Proactivo

En lugar de esperar a que el usuario reporte, el equipo monitorea:

• Uptime: ¿App está online? (Pingdom, Uptime Robot)
• Performance: ¿Responde rápido? (New Relic, DataDog)
• Errores: ¿Hay excepciones en código? (Sentry, RollBar)
• BD: ¿Hay espacio? ¿Está optimizada? (queries lentas)
• Seguridad: ¿Hay vulnerabilidades nuevas? (Snyk, npm audit)

Si algo falla, el equipo se entera antes que tú.

4. Backups y Recuperación

Estrategia 3-2-1 recomendada:

• 3 copias de tus datos (BD, archivos).
• En 2 medios diferentes (cloud + local o cloud + external drive).
• 1 copia offsite (lejos geográficamente).

Implementación práctica:

• Backup diario a AWS S3 (offsite cloud).
• Backup semanal a servidor local.
• Prueba de restauración mensual (importante: no solo respaldar, sino probar que recuperas).

SLA de backups:

• RTO (Recovery Time Objective): ¿Cuánto tardas en recuperar? Máximo 2 horas.
• RPO (Recovery Point Objective): ¿Cuánto datos pierdes? Máximo 24 horas.

5. Parches de Seguridad y Actualizaciones

Las dependencias (librerías de código) tienen vulnerabilidades. Deben actualizarse regularmente.

Ejemplo: PHP 8.0 tiene un bug de seguridad. Necesitas actualizar a 8.1 antes de que sea explotado. SLA debe incluir esto.

Política recomendada:

• Parches críticos de seguridad: aplicar en 24-48 horas.
• Actualizaciones menores: aplicar en próxima ventana de mantenimiento (semanal).
• Pruebas: siempre testear en staging antes de producción.

Costos de Mantenimiento en Perú (Soles)

Opción 1: Soporte Básico (Recomendado para PYMES)

• 8 horas/mes de soporte dedicado.
• Respuesta en 24 horas para issues no críticas.
• 1 release/mes (despliegues pequeños).
• Monitoreo básico + alertas.
• 1 backup diario (almacenado 30 días).
• Costo: S/ 1,500-3,000/mes (depende de complejidad).

Opción 2: Soporte Estándar

• 20 horas/mes de soporte.
• Respuesta en 4 horas para issues ALTAS.
• 2 releases/mes.
• Monitoreo avanzado (performance, errores, seguridad).
• Backups diarios + 1 offsite semanal.
• Actualizaciones mensuales de dependencias.
• Costo: S/ 4,000-7,000/mes.

Opción 3: Soporte Premium (24/7)

• 40 horas/mes de soporte + oncall 24/7.
• Respuesta en 30 min para CRÍTICAS (cualquier hora).
• Releases ilimitadas.
• Monitoreo exhaustivo.
• Backups cada 6 horas + múltiples offsite.
• SLA de 99.9% uptime garantizado (compensación si no se cumple).
• Costo: S/ 12,000-25,000/mes.

Caso de Estudio: Empresa Exportadora Peruana (50 empleados)

Situación inicial: Sistema de gestión de pedidos + facturación SUNAT. Sin SLA, sin monitoreo. Developer único. Cambios de regulación SUNAT cada 6 meses causaban bugs.

Problema:

• Cambio SUNAT: App genera facturas mal durante 3 días.
• BD se llena sin aviso: sistema se ralentiza, se cuelga.
• Vulnerabilidad de seguridad: clientes ven datos de otros clientes.
• Developer se enfermó: nadie pudo hacer deploy 1 semana.

Solución: SLA Estándar implementado

• Contrataron agencia externa para soporte 20 horas/mes.
• Monitoreo automático de facturación + BD size.
• Code review mensual para vulnerabilidades (OWASP Top 10).
• Backups diarios + test mensual de restauración.
• Documentación de código para nueva empresa pueda tomar el proyecto.

Resultados (6 meses):

• Cambio SUNAT detectado y arreglado en 4 horas (vs 3 días).
• BD issue resuelta antes de causar downtime.
• 0 brechas de seguridad encontradas en auditoría anual.
• Puede haber cambios de developer sin impacto operacional.
• Costo SLA: S/ 5,500/mes x 6 = S/ 33,000.
• ROI: Evitó pérdida de S/ 100,000+ en ventas por downtime.

Buenas Prácticas: Checklist de Mantenimiento

Tareas Diarias
Monitoreo de uptime (¿app está online?)	[ ] Sí [ ] NO
Revisar logs de errores (¿hay excepciones?)	[ ] Sí [ ] NO
Verificar BD size y performance (¿espacio suficiente?)	[ ] Sí [ ] NO
Backup automático ejecutado sin errores	[ ] Sí [ ] NO
Tareas Semanales
Revisar tickets de soporte abiertos	[ ] Sí [ ] NO
Verificar performance (tiempos de carga)	[ ] Sí [ ] NO
Actualizar dependencias críticas si hay parches	[ ] Sí [ ] NO
Tareas Mensuales
Test de restauración de backup (¿funciona?)	[ ] Sí [ ] NO
Revisión de seguridad (OWASP Top 10, dependencias vulnerables)	[ ] Sí [ ] NO
Análisis de performance (queries lentas, memory leaks)	[ ] Sí [ ] NO
Reporte de uptime y SLA compliance	[ ] Sí [ ] NO
Tareas Trimestrales
Auditoría de código (code quality, deuda técnica)	[ ] Sí [ ] NO
Revisión de capacidad (¿necesitas upgrade de servidor?)	[ ] Sí [ ] NO
Disaster recovery drill (¿puedes recuperar en N horas?)	[ ] Sí [ ] NO
Tareas Anuales
Auditoría de seguridad externa (penetration testing)	[ ] Sí [ ] NO
Planificación de upgrades tecnológicos (PHP 8.2, Node 20, etc.)	[ ] Sí [ ] NO
Revisión y actualización del SLA	[ ] Sí [ ] NO

Herramientas Recomendadas para Monitoreo (Costos en S/)

Uptime Monitoring: Uptime Robot (gratis - 50 monitores) o Pingdom (S/ 500-2,000/mes)

Error Tracking: Sentry (S/ 0-3,000/mes) - Alertas si la app lanza excepciones

Performance Monitoring: New Relic (S/ 2,000-8,000/mes) o DataDog (S/ 2,500-10,000/mes)

Security Scanning: Snyk (S/ 0-2,000/mes) - Busca vulnerabilidades en dependencias

Backup Management: AWS S3 (S/ 50-200/mes para backups pequeños) o Veeam (S/ 3,000-8,000/mes para enterprise)

Log Aggregation: ELK Stack on-premise (gratis + servidor S/ 1,500/mes) o Datadog Logs (S/ 1,000-5,000/mes)

Total recomendado:** S/ 4,000-15,000/mes (incluido soporte + herramientas)

Errores Comunes a Evitar

1. No tener SLA documentado:

Si no está escrito, no existe. Ambigüedad = pleitos cuando algo falla.

2. SLA sin penalizaciones:

Si no hay consecuencias por no cumplir, ¿por qué cumplir? El SLA debe tener: reembolso parcial, crédito en próximo mes, o descuento.

3. Monitoreo insuficiente:

Si nadie monitorea, descubres problemas cuando usuarios gritan. Configura alertas automáticas.

4. Backups sin restauración probada:

Un backup que no puedes restaurar es inútil. Prueba cada mes.

5. Ignorar deuda técnica:

Patches parches sin refactorizar código viejo = aplicación cada vez más lenta y frágil.

Conclusión

Un sistema a medida es un activo de tu empresa. Como cualquier activo (vehículo, máquina), necesita mantenimiento regular. Un SLA claro es el seguro que te protege:

• Responsabilidad clara: qué esperar cuando algo falla.
• Tiempos garantizados: no quedar abandonado 1 mes.
• Tranquilidad operacional: dormir sin miedo a que se caiga.
• Crecimiento sostenible: la app evoluciona, no se estanca.

Recomendación para PYMES peruanas:

• Presupuesta S/ 2,000-5,000/mes para soporte + herramientas.
• Contrata agencia o freelancer con SLA formal (no "de confianza").
• Exige monitoreo, backups probados, y reporte mensual de uptime.
• Revisa SLA cada año conforme crece tu app.

En TSDFACT ofrecemos soporte SLA a medida para PYMES: desde S/ 1,500/mes con respuesta en 24 horas, hasta 99.9% uptime garantizado. Consultemos tu caso sin costo.

Solicitar SLA personalizado Volver al blog