Especificar qué incluye exactamente el mantenimiento
Enumere cada parte del servicio: aplicación, base de datos, servidor, dominio, certificados, copias, API externas y atención a clientes. Nombre dueño y límite de responsabilidad de cada una. Un proveedor que corrige código quizá no administre el VPS o los pagos a terceros. Separe reparación de defectos, actualizaciones de seguridad, cambios pequeños, desarrollo de funciones y guardias en la propuesta. Cada tarea consume capacidad y coste diferentes. Si nadie vigila el vencimiento de certificados o un disco lleno, el problema puede descubrirse durante una interrupción. Describa mantenimiento del servicio concreto y no una promesa vaga de soporte técnico.
Defina qué es defecto y qué es nueva función. Por ejemplo, un formulario que deja de guardar mensajes es un incidente; añadir otro campo de CRM cambia el alcance. Los casos discutidos necesitan proceso de decisión y no cobro automático sin explicación. Indique los accesos necesarios para reparar y quién los proporciona. Si el cliente posee una dependencia, el proveedor no puede garantizar su recuperación. El acuerdo debe distinguir responsabilidad de responder y responsabilidad por el resultado final. Pida revisión jurídica del texto contractual real; una descripción operativa no sustituye asesoramiento legal.
Derivar la prioridad del impacto en usuarios
Defina gravedad con ejemplos concretos. No poder procesar un pago o perder datos puede ser crítico; un defecto visual fuera del recorrido principal tendrá menor prioridad. No debe depender solo de quién informa con más insistencia. Considere número de usuarios, impacto financiero o de seguridad y existencia de una alternativa. En algunos servicios, un resultado erróneo es peor que la falta de disponibilidad porque puede pasar inadvertido. Prepare ejemplos para cada nivel y quién puede cambiar la prioridad cuando aparezcan nuevos datos. Incluya el fallo de un tercero mientras su propia aplicación parece saludable.
Utilice un canal de aviso y número de caso. Al recibirlo anote momento, servicio, síntomas, impacto y pruebas sin difundir datos sensibles innecesarios. Confirmar recepción no es reparar. Distinga primera respuesta, comienzo del trabajo, restauración del servicio y solución de la causa. Con una dependencia externa el equipo puede responder enseguida mientras otra organización controla la recuperación. Explique estas diferencias antes del incidente. Registre cambios de prioridad para conservar clara la historia de decisiones durante una interrupción larga. Permita a usuarios aportar información nueva sobre impacto después de la clasificación inicial.
Fijar tiempos de respuesta desde la capacidad real
Indique horario de soporte, festivos, zona horaria y cómo se calculan plazos. Responder en dos horas laborales difiere de una guardia nocturna. Un SLA más estricto requiere personal disponible, supervisión, accesos y sustitutos; sin ello es una promesa de papel. Considere frecuencia de incidentes, complejidad y coste de guardias. Aclare qué ocurre si llega un aviso fuera de horario. No confunda confirmación garantizada con reparación definitiva. Para un problema complejo puede importar más comunicación periódica y una alternativa segura que un objetivo de reparación superficialmente corto.
Google SRE distingue un indicador de calidad de su valor objetivo; estos conceptos ayudan a definir expectativas internas antes del SLA contractual. Mida, por ejemplo, proporción de acciones de usuario satisfactorias y tiempo en que el servicio es realmente utilizable. Acuerde periodo de medición y tratamiento del mantenimiento programado. No copie un porcentaje de disponibilidad sin calcularlo ni incluir servicios externos críticos. Si falta historia, empiece con una meta temporal y revísela tras observar el servicio. Penalizaciones o compensaciones pertenecen a un contrato jurídico específico, no a una promesa técnica sin presupuesto.
Mantener dependencias y vulnerabilidades de forma sistemática
Una aplicación cambia aunque no se añadan funciones. Nuevas versiones del sistema operativo, bibliotecas, base de datos y API externas pueden requerir trabajo. Asigne dueño al inventario de dependencias, seguimiento de soporte y plan de actualizaciones. Pruebe cada cambio en recorridos principales. Aplazar una actualización puede ser razonable si se documentan riesgo y controles; ignorarla silenciosamente no. Para componentes críticos prepare una vía de reparación rápida o menor exposición. Un cambio de API del proveedor puede romper el servicio tanto como un defecto propio. Revise el riesgo en el informe de mantenimiento.
Priorice hallazgos de seguridad por exposición real, impacto y pruebas de explotación. El catálogo CISA Known Exploited Vulnerabilities registra fallos conocidos por ser explotados; es una entrada para decidir, no la respuesta completa para todo sistema. Fije plazos de valoración y remedio según la importancia del servicio. Si un parche no puede publicarse de forma segura al instante, considere protección temporal y sígala. Después compruebe versión y comportamiento real. Aclare si el mantenimiento de seguridad ordinario está en la cuota y quién aprueba una intervención mayor. Un aviso del escáner no demuestra por sí solo que su instalación esté expuesta.
Dar a copias y restauración un compromiso propio
Un SLA de aplicación queda incompleto sin plan para datos. Indique quién hace copias, dónde se guardan, cuánto tiempo y quién puede restaurarlas. Defina pérdida aceptable y tiempo de retorno. Operaciones debe demostrar periódicamente que una copia produce una aplicación utilizable con archivos necesarios, no solo que se creó un archivo. Compruebe especialmente la recuperación tras migrar la base. Una copia en el mismo servidor quizá no proteja frente a perderlo. Mantenga acceso seguro a recuperación sin depender de una sola persona. Incluya el resultado del último ensayo en el informe del servicio.
Durante un incidente distinga reanudar pronto de reparar todos los datos. Una versión temporal puede permitir trabajar mientras se comprueban registros ausentes. Documente quién decide restaurar, cómo se conserva la historia de cambios y quién comunica posibles pérdidas a usuarios. Un ensayo proporciona un número real para expectativas contractuales. Si tarda más, mejore el procedimiento o cambie la promesa; fingir cumplir el objetivo es peligroso. Para un sistema pequeño un ensayo sencillo y recurrente puede valer más que infraestructura compleja sin práctica. Conserve evidencia de qué datos se recuperaron.
Usar escalada e informes para decidir
Para cada nivel de incidente dé contacto principal y suplente. Indique cuándo interviene el dueño de producto, especialista de seguridad o proveedor de infraestructura. AWS Well-Architected recomienda procedimientos por alerta y rutas de escalada según impacto. Durante una interrupción importante fije frecuencia de novedades y lugar donde el cliente vea estado. Tras recuperarse explique qué ocurrió, su efecto y qué cambiará. No ofrezca detalles técnicos sin explicar el impacto para usuarios. Comunicar es parte del soporte, no una cortesía opcional. Dé al cliente una ruta urgente incluso cuando intervienen varios proveedores.
Un informe periódico puede mostrar disponibilidad de recorridos principales, incidentes por prioridad, tiempos de respuesta y recuperación, problemas abiertos, copias, actualizaciones y uso de capacidad. Añada una decisión propuesta: qué reparar, aplazar o aceptar como riesgo. Una tabla verde sin comprobar resultados del usuario dice poco. Si vuelve el mismo fallo, mantenimiento no puede limitarse a reiniciar repetidamente. Relacione estado técnico con coste e impacto comercial. Un informe breve que alguien lee vale más que uno extenso sin dueño. Acuerde quién lo revisa y cuándo se comprobará la acción resultante.
Separar desarrollo planificado de guardias
Soporte necesita capacidad para imprevistos; desarrollo planificado necesita encargo, prioridad y aprobación. Si compiten por el mismo tiempo sin reglas, una reparación urgente desplaza mejoras y recuperar después con prisa crea otro defecto. Defina precio de cambios pequeños, quién los encarga y cómo se prueban. Dé alcance propio al trabajo mayor. Mantenimiento puede incluir reducir deuda técnica cuando disminuye riesgos demostrables; describa ese beneficio. El cliente debe comprender por qué se destinó capacidad a seguridad antes que a una función nueva. Mantenga una vía para urgencias que no suprima toda revisión.
En cada publicación compruebe compatibilidad de datos, pruebas, copia y retorno. El contrato de mantenimiento no garantiza por sí mismo cambios seguros. Nombre quién aprueba producción y cuándo se despliega. La ruta urgente debe ser rápida conservando registro de lo hecho y una revisión posterior. Siga cambios de servicios externos igual que los propios. Si aumentan incidentes tras publicaciones rutinarias, revise el proceso de despliegue antes que solo reducir el tiempo de soporte. Avise de mantenimiento planificado con antelación a usuarios afectados.
Probar una oferta con un escenario concreto
Pida al proveedor que describa respuesta a un formulario roto, base inaccesible, factura incorrecta y sospecha de filtración. ¿Quién recibe el aviso, cuándo accede, cómo determina impacto y cuándo informa al cliente? ¿Qué puede reparar solo y qué necesita aprobación? ¿Cómo demuestra restauración? Pregunte por guardia real y sustitutos. Un precio sin estas actividades no puede compararse justamente. Confirme que el cliente posee cuentas, dominio, código y documentación. Solicite un ejemplo de informe de incidente y resultado reciente de prueba de recuperación si los hay.
Compare coste y riesgo total: cuota, trabajo adicional, licencias, supervisión, copias, intervenciones nocturnas y cambio de proveedor. EXCOIN puede mantener un sistema concreto, pero no prometer de forma responsable plazos o alcance de reparación sin inventario. El primer paso es revisar servicio, responsabilidades e incidentes recientes. Solo entonces puede fijarse apoyo y precio razonables. Un buen acuerdo permite al cliente saber qué sucederá al fallar algo y decidir cambios de operación con datos medidos. Haga tan visibles las exclusiones como lo incluido.
Lista antes de firmar
Confirme servicios, dueños, horario, prioridades, tiempos de respuesta y comunicación, frontera de mantenimiento y desarrollo, copias, recuperación y escalada. Verifique accesos, mediciones y formato de informes. Para cada número prometido pida método de cálculo y pruebas de que es alcanzable. Indique el procedimiento ante caída de un tercero y fin del acuerdo. Efectos jurídicos, remedios y exclusiones corresponden al contrato concreto y deben revisarse con un abogado. Una lista técnica ayuda a preguntar, no reemplaza revisión jurídica. Pruebe un escenario realista con los contactos designados.
Tras el primer mes compare incidentes reales, tiempos, calidad de comunicación y ensayos de recuperación con las hipótesis. Ajuste prioridades o capacidad basándose en pruebas. Si soporte combate una y otra vez el mismo defecto, reserve trabajo para la causa. El mantenimiento previsible es compartido: producto define importancia del servicio y el proveedor muestra estado técnico y riesgos. Un SLA útil crea respuesta clara y forma de verificarla, no la ilusión de que el software nunca falla. Registre en el acuerdo la primera fecha de revisión.