Defina qué significa gestionar una aplicación
Gestionar puede significar vigilar disponibilidad, resolver incidentes, mantener dependencias, cambiar funciones, administrar un dominio o atender usuarios. Cada actividad requiere personas y permisos diferentes. Antes de acordar el servicio, enumere sistemas, entornos y trabajos incluidos. Señale por separado lo que queda a cargo del cliente o de otro proveedor. Sin ese límite, incluso una interrupción pequeña puede acabar en una discusión sobre quién debía actuar. La definición es parte del servicio.
Un primer resultado útil es el mapa operativo: aplicación, base de datos, alojamiento, API externas, DNS, certificado, copias y personas con acceso. Asigne dueño y contacto de escalado a cada pieza. No es documentación hecha por formalidad. Si dejan de funcionar los pagos, el equipo debe saber quién revisa la integración, quién habla con el proveedor y quién informa a los usuarios. Un mapa claro reduce el tiempo para identificar la causa y encontrar a quien puede intervenir.
Disponibilidad y SLA dependen del recorrido
Una promesa de disponibilidad debe explicar qué se mide: respuesta de la portada, finalización de un pedido o capacidad del administrador para tramitar una solicitud. Cada medida describe un estado distinto. Defina periodo, mantenimiento previsto, umbral de incidente y tiempo de reacción. El objetivo debe reflejar el valor real y el coste de una caída. Un porcentaje de disponibilidad alto sirve de poco cuando el proceso crítico falla con frecuencia aunque el servidor responda.
Google SRE utiliza objetivos de nivel de servicio y presupuestos de error para equilibrar rapidez de cambios y estabilidad. Una organización pequeña no necesita copiar todo el método, pero el principio ayuda: si el servicio incumple sus objetivos, una función nueva quizá no sea la prioridad. Distinga objetivo de calidad, compromiso contractual y alerta interna. Un SLA es un acuerdo comercial con excepciones y consecuencias; no puede prometerse honestamente sin conocer infraestructura, dependencias y personal.
Los incidentes necesitan una secuencia
Durante una caída, primero determine el impacto en usuarios y detenga la expansión del problema. Después asigne una persona responsable, decida entre reparar o volver a una versión anterior y comunique el estado conocido. El diagnóstico mejora con una cronología: cuándo empezó, qué cambió y qué servicios están afectados. Discutir en ese momento quién puede reiniciar un proceso o contactar al proveedor sale caro. Acuerde permisos y contactos antes del incidente.
Las revisiones de preparación operativa de AWS aconsejan comprobar personas, procedimientos, monitorización y respuesta antes de publicar. Un sitio pequeño puede usar una lista proporcionada e instrucciones breves. Una describe un despliegue fallido, otra una caída de la base y otra una integración externa. Un ejercicio de fallo controlado descubre contactos caducados o permisos ausentes antes del incidente real. Después registre la causa y un cambio concreto que reduzca la repetición o el impacto.
Observe el trabajo completado
Comprobar el estado HTTP no basta. Una aplicación puede mostrar páginas y, al mismo tiempo, no aceptar mensajes, emitir facturas o enseñar datos recientes. Las medidas deben seguir sus tareas principales: operaciones terminadas, errores, antigüedad de la cola, latencia y salud de conexiones externas. Cada señal necesita umbral, responsable y procedimiento. Una alerta sin alguien capaz de actuar no aporta seguridad. Un flujo crítico sin medida puede fallar silenciosamente durante horas.
Demasiadas alarmas generan cansancio y ocultan cambios importantes. Revise avisos que suelen activarse sin impacto y añada controles para fallos silenciosos. Los registros deberían permitir seguir una operación concreta sin guardar contraseñas, tokens ni datos personales innecesarios. Observe también la calidad de las reparaciones: ¿cuántos casos exigen intervención manual y por qué? La estabilidad operativa es una propiedad de todo el servicio, no solo del servidor físico.
El mantenimiento incluye cambios y seguridad
La gestión periódica abarca actualizaciones del sistema, bibliotecas e imágenes de contenedores, certificados y revisión de permisos. Cada cambio exige pruebas apropiadas, una ventana de publicación y camino de regreso. Una dependencia sin parches puede requerir sustitución. No significa instalar cada versión nueva el día que aparece; significa registrar riesgo, prioridad y responsable. Planifique funciones y mantenimiento para que una actividad no desplace indefinidamente a la otra.
Al asumir una aplicación antigua, compruebe versiones, errores actuales, copias y acceso al repositorio. Un proveedor no puede prometer responsablemente estabilidad de un producto que aún no ha examinado. Para cambios importantes, explique al cliente efectos esperados y método de comprobación. Si el riesgo operativo supera el beneficio probable, quizá convenga añadir diagnóstico o un entorno de pruebas antes de modificar la aplicación.
Una copia requiere pruebas de restauración
El acuerdo de gestión debería precisar qué se copia, con qué frecuencia, dónde se guarda y quién puede iniciar la restauración. La existencia de un archivo no demuestra que sirva. Una base restaurada debe corresponder a la versión de la aplicación e incluir archivos o configuración necesarios. PostgreSQL ofrece distintos métodos según tamaño y necesidad de recuperar un momento concreto; su documentación explica las diferencias. Elija a partir de pérdida de datos aceptable y tiempo de recuperación.
Restaure regularmente una copia en un entorno aislado y pruebe una función esencial. Registre duración, alcance recuperado y obstáculos. Una copia en el mismo disco que la aplicación no protege frente a perder ese disco. Revise quién puede borrar copias y cómo se protege su acceso. Tampoco conviene conservar copias antiguas de información sensible para siempre sin motivo. Una regla de retención debe hacer previsibles tanto la recuperación como el tratamiento de datos.
Dominios, alojamiento y proveedores tienen límites
Un servicio web depende de DNS, certificados, alojamiento, correo, pagos y otros proveedores. La lista de dependencias debe identificar dueño de cuenta, recuperación del acceso, fecha de renovación y vía de escalado. Si caduca un dominio de otra persona, el equipo de aplicación no lo arregla cambiando código. Tampoco puede garantizar la reparación de una API ajena sin su operador. Sí debe detectar el fallo a tiempo y transmitir pruebas concretas.
Los accesos deberían pertenecer a la organización y no a la cuenta privada de una sola persona sin alternativa. Durante la colaboración, revise quién puede cambiarlos y dónde permanecen los registros de auditoría. Un cambio de proveedor no debe provocar pérdida de datos, repositorio o dominio. La entrega incluye exportaciones, procedimientos y retirada de permisos innecesarios. Este trabajo ordinario es menos visible que una función nueva, pero determina si el servicio seguirá siendo mantenible.
Delimite la colaboración sin promesas vagas
Para la primera solicitud prepare aplicaciones, horario de operación, número de usuarios, incidentes recientes, tiempos de respuesta deseados y proveedores actuales. Decida si necesita solo gestión técnica, también atención a usuarios o desarrollo continuo. Son actividades con capacidad y precio diferentes. La primera etapa puede consistir en revisar preparación operativa y proponer reparaciones próximas. A partir del estado observado podrá acordarse un soporte recurrente realista.
Un buen acuerdo describe límites, contactos, medidas, proceso de cambios, copias, incidentes y fin de la colaboración. Las exclusiones deben ser tan visibles como las tareas incluidas. Esta página no atribuye a EXCOIN un SLA no verificado, guardia permanente ni centro de datos propio. Un compromiso concreto solo puede definirse para una aplicación y personal determinados. La gestión debe permitir al cliente saber qué ocurre, cómo se resolverá un problema y quién responde por el siguiente paso.