Mantenimiento y operación del software tras el lanzamiento: qué debe estar regulado después

El patrón es conocido. Un software implantado hace dos años muestra de repente un mensaje de error. La empleada de la oficina llama a la persona de contacto de entonces, que ahora está metida en otro proyecto. El acceso al servidor está en manos de un proveedor que ya nadie recuerda, y la contraseña probablemente está en un correo de aquella época. Cuando alguien entiende la situación, la tarde ya ha pasado.

En este escenario, el proyecto no hizo nada mal. El software cumple su función, la aceptación fue limpia, los usuarios están satisfechos. Lo que falta es un modelo de operación, porque en el proyecto no había sitio para él. El desarrollo tiene un final y un presupuesto; la operación no tiene ni lo uno ni lo otro. Dura mientras dura la empresa.

Este artículo describe qué debería regularse tras el lanzamiento. Va dirigido a la dirección y a los responsables internos que usan o planean un software a medida y quieren saber qué preguntas deben plantear antes de la puesta en producción. No se trata de una herramienta, sino de responsabilidades, ciclos y evidencias.

Una idea útil de entrada: el software se comporta como un edificio, no como un mueble. Envejece incluso sin uso, porque su entorno cambia. Navegadores, sistemas operativos, bibliotecas y situaciones de seguridad siguen evolucionando, tanto si su empresa cambia algo como si no.

La estrategia de operación más común es: no tocar nada mientras funcione. Parece razonable, porque todo cambio conlleva un riesgo. Pero solo traslada el riesgo. Una aplicación que lleva dos años sin una actualización no se vuelve más estable; su distancia con el entorno crece. Cuando más tarde el salto resulta necesario, es grande, difícil de probar y rara vez planificable.

Detrás hay varios cuadros de fallos que rara vez aparecen por separado. Las dependencias, es decir, las bibliotecas de terceros de las que se compone en buena parte el software moderno, reciben correcciones de seguridad que nunca se instalan. Las copias de seguridad se ejecutan cada noche, pero nadie ha probado nunca una restauración. El acceso del antiguo desarrollador sigue activo. El certificado caduca y nadie tiene la fecha en el calendario.

A ello se suma una debilidad organizativa: el conocimiento está en las cabezas. Quien construyó la aplicación conoce peculiaridades que no están escritas en ningún sitio, por ejemplo por qué un proceso nocturno tiene que ejecutarse a las tres o qué configuración hay que trasladar al cambiar de servidor. Cuando esa persona deja el proyecto, el conocimiento se va con ella y la operación se convierte en un juego de adivinanzas.

La consecuencia no es el pánico, sino la sobriedad. Un concepto de operación no tiene que ser grande, pero tiene que existir y pertenecer a alguien. Las preguntas que responde son abarcables y la mayoría puede aclararse en media jornada si se plantean antes de la caída y no después.

Para hacer tangible la operación, ayuda descomponerla en capas que se apoyan unas en otras. Abajo está la infraestructura: servidor, red, sistema operativo. Sobre ella se ejecuta el entorno de ejecución con sus bibliotecas y, encima, la aplicación propiamente dicha con sus datos. Cada capa tiene su propia velocidad de envejecimiento, sus propios responsables y sus propios cuadros de fallos, y pueden examinarse por separado.

De forma transversal discurren temas que afectan a todas las capas: accesos, protección de datos, supervisión y documentación. Suelen olvidarse porque no pertenecen a ninguna capa concreta. Un concepto de roles, por ejemplo, no es ni un asunto de servidor ni pura lógica de aplicación, y un concepto de eliminación afecta por igual a la base de datos, las copias de seguridad y los registros.

La descomposición es útil sobre todo para aclarar responsabilidades. Ante una caída, en minutos se decide si la causa está abajo o arriba. Pero si no se ha establecido quién es responsable de cada capa, la búsqueda empieza con el proveedor, que señala al alojamiento, que remite a la aplicación. Una tabla sencilla con capa, responsable y suplente resuelve este problema con una fiabilidad sorprendente.

El orden de análisis sigue al daño, no a la técnica. Empezamos por lo más caro de perder: los datos y el acceso a ellos. Solo después merece la pena hablar de comodidad, rendimiento y evolución.

Para la operación hay tres modelos entre los que elegir, y ninguno es siempre el correcto. En la operación propia, la empresa asume por sí misma el alojamiento y el mantenimiento, o lo hace con un proveedor de TI local. Esto da control, pero exige conocimientos técnicos y disposición a estar localizable también de noche. Para las pequeñas empresas rara vez es realista, salvo que la aplicación no sea crítica.

En el segundo modelo, el desarrollador opera el software con un contrato de mantenimiento. La ventaja es que el código y la operación están en una sola mano y los errores se acotan rápidamente. La desventaja es la dependencia: si el contrato se complica o el proveedor cambia de orientación, la empresa se enfrenta a un cambio que, sin buena documentación, resulta caro. Precisamente por eso la capacidad de salida debe formar parte del concepto desde el principio.

El tercer modelo separa la responsabilidad. Un proveedor de alojamiento opera la infraestructura, el desarrollador mantiene la aplicación y una tercera parte, a menudo la dirección o un responsable interno, mantiene unidos los hilos. Es el modelo más robusto, pero también el que tiene más interfaces. Solo funciona con interlocutores claramente designados y un documento común en el que conste quién hace qué.

Por regla general recomendamos separar la infraestructura de la aplicación, siempre que la empresa no tenga TI propia. Limita la dependencia y permite sustituir una parte sin reconstruirlo todo. La condición es que la aplicación pueda volver a montarse en otro servidor sin conocimientos especiales, y eso se puede comprobar en lugar de darlo por supuesto.

Un marco operativo consta de pocos elementos que repasamos como lista de comprobación antes de la puesta en producción. El primero es un ciclo de mantenimiento: las dependencias y el sistema operativo se revisan a intervalos fijos, y las correcciones de seguridad de alta urgencia se tratan fuera de calendario. El ciclo es menos una cuestión de técnica que de acuerdo, porque garantiza que alguien lo haga.

El segundo elemento es el concepto de roles. Regula quién puede ver y modificar qué en la aplicación y sigue el principio del mínimo privilegio: cada persona recibe exactamente los accesos que necesita para su tarea. A ello se suma un procedimiento para altas y bajas, para que las cuentas de empleados que se han ido no sigan activas durante años. Lo mismo vale para los accesos técnicos, como cuentas de servidor, usuarios de base de datos y claves de interfaz.

En tercer lugar, la documentación. No se trata de una biblioteca de prosa, sino de un manual de operación esbelto: esquema de arquitectura, lista de entornos, custodia de las credenciales en un gestor de contraseñas, descripción de los procesos programados, pasos de reinicio y personas de contacto. Debe estar redactado de modo que una persona cualificada pero ajena al proyecto pueda entender la aplicación en un día.

En cuarto lugar, las cuestiones de propiedad, que a menudo solo se notan en caso de litigio. ¿A quién pertenece el código fuente, quién puede modificarlo o cederlo y dónde está? Consideramos razonable que el código esté en un repositorio al que el cliente tenga acceso propio y que los derechos de uso estén regulados con claridad en el contrato. Los detalles jurídicos corresponden al contrato y a la revisión por un jurista; aquí se trata del aspecto técnico: el acceso no puede depender únicamente de la buena voluntad del proveedor.

En las actualizaciones de seguridad cuenta menos la frecuencia que la capacidad de instalarlas sin riesgo. Para ello hacen falta un entorno de pruebas parecido al de producción, pruebas automatizadas para los procesos más importantes y un procedimiento para revertir los cambios. Entonces, una actualización es una operación rutinaria. Sin estos requisitos, cada actualización se convierte en una prueba de valor y, por precaución, se omite. Las herramientas que revisan las dependencias en busca de vulnerabilidades conocidas aportan la base de datos para ello, pero no sustituyen la valoración de si un aviso afecta realmente a la propia aplicación.

En las copias de seguridad, la regla general es clara: una copia que nunca se ha restaurado es una esperanza. Por eso planificamos pruebas de restauración periódicas en un entorno separado y comprobamos dos cosas. Primero, si los datos están completos y son legibles. Segundo, cuánto tarda la aplicación en volver a funcionar. Ese tiempo es el tiempo real de recuperación y a menudo se aparta mucho de lo supuesto. Además, al menos una copia debe guardarse en otro lugar, separada del servidor y de sus credenciales, para que un ataque o un error no destruyan a la vez la copia de seguridad.

La monitorización responde a una pregunta sencilla: ¿nos damos cuenta antes que los usuarios? Para ello suelen bastar pocas comprobaciones. ¿Es accesible la aplicación desde fuera, funciona la base de datos, queda suficiente espacio libre, se ejecuta el proceso nocturno, cuándo caduca el certificado? Los avisos deben llegar a alguien que pueda actuar y ser lo bastante escasos como para que se tomen en serio. Una alarma que salta diez veces al día sin motivo pronto se ignora.

Los registros completan el panorama. Los registros de errores de la aplicación muestran problemas que ningún usuario comunica, como llamadas fallidas a interfaces. Sin embargo, no deben recoger datos personales innecesarios y deben eliminarse tras un plazo determinado. Con ello rozan el concepto de eliminación, que retomamos en el capítulo sobre casos especiales.

El primer caso especial afecta a la protección de datos. Los datos personales no pueden conservarse indefinidamente, y esto vale también para las copias de seguridad y los registros. Un concepto de eliminación establece qué datos se conservan durante cuánto tiempo y cuándo se eliminan, y tiene en cuenta las obligaciones legales de conservación. Esto se entiende como orientación técnica, no como asesoramiento jurídico. Los plazos concretos debería aclararlos con su delegado de protección de datos o con un asesor jurídico. Técnicamente conviene prever la eliminación como función, porque añadirla después suele ser costoso.

El segundo caso es el cambio de personal en ambos lados. Cuando una empleada deja la empresa, deben ajustarse las cuentas en la aplicación, en el gestor de contraseñas y en el proveedor de alojamiento. Cuando cambia el desarrollador en el proveedor de servicios, una segunda persona debería conocer la aplicación. Esto se puede comprobar: pregunte quién interviene en caso de vacaciones y pida que le muestren la respuesta en lugar de que se la cuenten.

En tercer lugar, la carga heredada. Algunas aplicaciones funcionan con versiones para las que ya no existen correcciones de seguridad. Entonces el mantenimiento es, en el fondo, una cuestión de modernización. Valoramos según el riesgo: ¿es accesible la aplicación desde internet, contiene datos sensibles, es crítica para el negocio? Según la respuesta, basta un aislamiento en la red durante un periodo transitorio, o se vuelve urgente una reforma por etapas. Una reconstrucción completa rara vez es el primer paso.

El cuarto caso es el incidente de seguridad. Quien establece de antemano a quién informa, qué se desconecta primero y quién habla con los clientes actúa con más calma en caso de emergencia. Basta un plan de emergencia de una página: contactos, primeros pasos, ubicación de las copias de seguridad. Existen obligaciones de notificación en caso de brechas de datos; sus detalles corresponden a una revisión por especialistas y aquí no se desarrollan deliberadamente.

Por último, la salida. Un software tiene capacidad de salida si los datos pueden exportarse en un formato abierto, el código está en manos del cliente y el entorno está documentado. El objetivo no es cambiar, sino conservar la posición negociadora.

Un concepto de operación no hace invulnerable al software. Cambia la probabilidad y las consecuencias de las perturbaciones. Las caídas son menos frecuentes porque se cierran las vulnerabilidades conocidas, y duran menos porque la recuperación está ensayada. Nadie puede prometer con seriedad que no pasará nada, y quien lo hace vende una seguridad que no existe.

El beneficio puede medirse con pocas magnitudes. Entre ellas, la disponibilidad a lo largo de un mes, medida desde fuera, el tiempo medido hasta la restauración desde la copia de seguridad, la antigüedad de las correcciones de seguridad instaladas y el número de vulnerabilidades conocidas y abiertas en las dependencias. A ello se suman indicadores más blandos: ¿cuánto tarda un nuevo desarrollador en arrancar la aplicación en local y cuántas incidencias comunicaron primero los usuarios?

El esfuerzo es continuo y debería tratarse como el mantenimiento de otros activos. Como orientación sirve una proporción respecto al desarrollo, que depende del tamaño y de la criticidad de la aplicación. Un porcentaje general no sería serio, porque las aplicaciones pequeñas y bien construidas necesitan poco, mientras que las interconectadas con muchas interfaces necesitan bastante más. Damos una estimación solo después de un inventario.

A los seis meses se ve si el concepto se sostiene. ¿Se respetaron los ciclos, se repitió la prueba de restauración, están los accesos al día? Donde no, rara vez es por la técnica. Normalmente falta un hueco en el calendario o una responsabilidad clara. Son problemas resolubles, pero no se resuelven solos.

Una de las fuentes de disputa más frecuentes es el límite poco claro entre mantenimiento y evolución. El mantenimiento conserva el estado existente: correcciones de seguridad, adaptación a nuevos entornos, supervisión. La corrección de errores elimina desviaciones del comportamiento acordado. La evolución amplía el conjunto de funciones y es un nuevo proyecto con su propio esfuerzo. Quien lo establece de antemano evita discusiones cuando el deseo de un nuevo campo se califica de repente como error.

Aun así existen casos límite. Si cambia un formato en una interfaz conectada, ¿la adaptación es mantenimiento o evolución? La asignamos al mantenimiento si se quiere conservar el comportamiento existente, y a la evolución si cambia el conjunto de funciones. Lo importante es que cliente y proveedor conozcan la regla antes de que se dé el primer caso.

En la práctica, da buen resultado una lista compartida de deseos pendientes, ordenada por urgencia y utilidad. De ella surge a intervalos fijos un pequeño paquete para su realización, en lugar de que cada idea provoque de inmediato una intervención. Esto cuida el presupuesto y la estabilidad, porque cada cambio es también un riesgo, y los cambios agrupados se pueden probar mejor.

Un punto que muchos subestiman: la deuda técnica también crece con soluciones rápidas bienintencionadas. Un apaño que nunca se sustituye es, a los dos años, parte del sistema. Por eso debería reservarse una parte del tiempo de mantenimiento para ordenar, de modo que la evolución no resulte cada vez más cara que la anterior.

Un software a medida es una herramienta con ciclo de vida. Su valor depende de si, pasados los años, sigue funcionando de forma segura, de si se pueden recuperar los datos y de si la empresa podría continuar con otro socio. Las respuestas no son cuestión de grandes presupuestos, sino de decisiones pequeñas y vinculantes que conviene tomar antes del lanzamiento.

El siguiente paso es sencillo. Compruebe cuatro cosas en su software: quién tiene acceso, cuándo se probó por última vez una restauración, qué antigüedad tienen las últimas correcciones de seguridad y si el código está en su poder. Si alguna de las cuatro preguntas no puede responderse en pocos minutos, ese es su punto de partida.

Reserve para ello una cita fija y breve cada trimestre. Una hora basta para repasar accesos, prueba de copia de seguridad, estado de las correcciones y deseos pendientes, y anotar los resultados en el manual de operación. Esa cita es discreta, pero marca la diferencia entre una operación que se cuida y una que simplemente sigue funcionando, con suerte.

Con mucho gusto lo revisamos juntos, con un inventario y una valoración honesta de qué marco operativo encaja con su aplicación. Que al final lleve usted mismo la operación, la externalice o la comparta es decisión suya. Nuestra tarea es que esa decisión se base en hechos conocidos.