Después del lanzamiento, alguien tiene que cuidar de la aplicación, sus datos y los servicios que usa. El trabajo depende de lo que la gente necesita: una web de contenidos y una aplicación que recibe pedidos de clientes requieren comprobaciones y planes de recuperación distintos.
Antes de acordar un mantenimiento, define qué necesita atención, quién se encarga de cada cosa y qué pruebas vas a recibir. Estas son las preguntas que repasaría contigo.
Separa hosting, mantenimiento y desarrollo nuevo
El hosting proporciona la infraestructura donde se ejecuta tu software. Según el servicio, también puede gestionar parte de la seguridad, los certificados o las copias de seguridad. Eso no significa que alguien esté comprobando que el pago, el inicio de sesión o las notificaciones sigan funcionando.
El mantenimiento cubre el trabajo acordado para que el producto actual siga funcionando. El desarrollo nuevo cambia lo que hace. Un plan de mantenimiento puede incluir tiempo para ambas cosas, pero un rediseño, un flujo de pago nuevo o una integración importante necesita su propio alcance. Deja ese límite por escrito antes de empezar.
Pregunta también qué soporte se incluye después de la entrega inicial, durante cuánto tiempo y qué cubre. Saber dónde termina ese soporte facilita planificar el trabajo continuo.
Mantén las dependencias al día y comprueba las actualizaciones
Las aplicaciones dependen de librerías, frameworks y servicios externos que cambian con el tiempo. Las correcciones de seguridad y los fines de soporte requieren atención. Las actualizaciones deben evaluarse para tu aplicación y comprobarse con los flujos importantes antes de llegar a producción.
El ritmo depende del riesgo y del producto. Un problema de seguridad urgente que te afecte no debería esperar al hueco mensual habitual de actualizaciones. Acordemos cómo se avisan y se gestionan esos casos, incluido el trabajo que quede fuera del plan.
Ten claro qué se copia y cómo restaurarlo
El código del repositorio es solo una parte de la recuperación. Tu producto también puede depender de registros de clientes, archivos subidos y configuración de servicios. Pregunta qué se copia, con qué frecuencia, cuánto tiempo se guardan las copias y quién puede restaurarlas.
Elige la frecuencia de las copias según cuántos datos podrías permitirte perder. Por ejemplo, si la última copia correcta fue a medianoche y la base de datos falla a las 17:00, restaurar solo esa copia dejaría fuera los cambios del día. Un producto que recibe pedidos puede necesitar un enfoque distinto al de una web cuyo contenido cambia cada semana.
Por otro lado, acordemos cuánto tiempo puede estar el producto sin servicio mientras se restaura. Cuántos datos puedes recuperar y cuánto tiempo hace falta para recuperarlos son preguntas distintas.
Un aviso de copia correcta no demuestra que la aplicación se pueda restaurar. Prueba la recuperación en un entorno separado adecuado y documenta los pasos. Lasrecomendaciones del NCSC sobre copias de seguridad también aconsejan comprobar que las copias contienen los datos importantes y que sabes cómo restaurarlas.
Vigila lo que necesitan tus clientes
Una comprobación de disponibilidad te dice que una página responde. Puede que no revele que los correos fallan, que una tarea en segundo plano se ha detenido o que un cliente no puede completar una compra. Decide qué comprobaciones importan para el producto y dónde deben notificarse los fallos.
Disponibilidad de la aplicación y de sus servicios importantes.
Errores en flujos críticos, como el inicio de sesión, el pago o la reserva.
Tareas en segundo plano, notificaciones e integraciones con terceros que fallan.
Renovación del dominio, estado del certificado, límites de almacenamiento y uso de los servicios.
Cada alerta necesita un destinatario y una respuesta acordada. Define en qué horario responde alguien, cómo se avisa de un problema urgente y a quién se contacta si esa persona no está disponible. Un plan mensual no implica cobertura de incidencias las 24 horas; eso hay que acordarlo de forma explícita.
Pregunta qué significa un compromiso de respuesta. Reconocer un problema, empezar a investigarlo y restablecer el servicio son pasos distintos. La redacción debe dejar claro qué paso está cubierto y qué pasa después.
Revisa el rendimiento y los accesos a medida que cambia el producto
Los datos crecen, llegan funcionalidades nuevas y los usuarios reales se comportan distinto que las cuentas de prueba. Revisa las páginas lentas y las operaciones costosas cuando haya indicios de un problema. Empieza por el impacto en el usuario y luego investiga la causa, en lugar de ampliar la infraestructura por costumbre.
Revisa los accesos a las cuentas cuando alguien entra o sale. Mantén al día la titularidad y los datos de renovación, y documenta dónde están los servicios importantes. Un producto no debería depender de una cuenta olvidada que nadie del equipo puede recuperar.
Pide un plan de mantenimiento que entiendas
Antes de acordar un trabajo continuo, haz estas preguntas:
¿Qué aplicación, servicios y entornos están cubiertos?
¿Qué comprobaciones y tareas rutinarias se harán realmente?
¿Quién se encarga de las copias, las pruebas de restauración, las renovaciones y las facturas de los servicios?
¿Qué horario de respuesta aplica y cómo aviso de un problema urgente?
¿Cómo se usa el tiempo para correcciones o mejoras, y qué requiere un presupuesto aparte?
¿Qué registro del trabajo hecho y de los riesgos pendientes voy a recibir?
¿Qué pasa con los accesos y la documentación si dejamos de trabajar juntos?
Pide un registro escrito del trabajo hecho y de los temas abiertos. Por ejemplo, una actualización de mantenimiento podría decir:
Hecho: actualicé las dependencias de la aplicación y comprobé en staging el inicio de sesión, el restablecimiento de contraseña y el flujo principal de reservas antes de publicar.
Prueba de recuperación: restauré la última copia de la base de datos en un entorno separado y revisé una muestra de registros. Los archivos subidos todavía no se han incluido en esta prueba.
Necesita una decisión: el uso de almacenamiento está aumentando. Las opciones y su impacto previsto están listados para revisarlos antes de hacer ningún cambio.
Es un ejemplo del nivel de detalle que conviene pedir, no la promesa de un calendario mensual concreto. Tu plan debería indicar qué comprobaciones se aplican a tu producto y con qué frecuencia.
Empieza por el producto que tienes
Para echar un primer vistazo a una web pública, puedes usar michequeo de salud web o laauditoría del sitio. Pueden mostrar problemas que vale la pena investigar. No pueden revisar el código privado de la aplicación ni demostrar que tus copias de seguridad y los flujos de tus clientes funcionan.
Si quieres ayuda continua,cuéntame sobre tu producto, los servicios que usa y qué necesitas cubrir. Podemos definir un plan de mantenimiento a partir de esas necesidades o acotar primero un conjunto concreto de mejoras.