Cómo una aplicación mal hecha puede poner en riesgo toda una empresa

Hace algunos años comencé a dar consultoría a una empresa cuyo proceso productivo dependía completamente de una aplicación interna (nada raro hasta aqui).

La empresa utilizaba una aplicación desarrollada en Java para gestionar las órdenes de servicio del su proceso productivo. Cada orden pasaba por varias estaciones de trabajo, donde los operadores realizaban diferentes tareas hasta completar el proceso. En teoría, el sistema solo necesitaba algunos ajustes y mejoras menores.

A simple vista, parecía algo sencillo.

Sin embargo, al revisarla por primera vez pensé que se trataba de un prototipo universitario… pero no. Era el sistema que movía toda la operación de la empresa.

El software no tenía arquitectura, no seguía buenas prácticas y estaba “desplegado” directamente desde el IDE en un computador con Windows. Los usuarios accedían a la aplicación usando la dirección IP que el DHCP asignaba a ese equipo.

Problemas de esta “arquitectura”

No estoy seguro de que se le pueda llamar arquitectura a esta forma de trabajo, pero a lo largo de los años aparecieron varios problemas importantes.

Antes de mencionarlos, vale la pena aclarar que se propuso en varias ocasiones modernizar la aplicación y su infraestructura. Sin embargo, por decisiones presupuestales y procesos internos de la empresa, estas mejoras nunca se aprobaron.

Estos fueron algunos de los problemas más recurrentes.

1. Dependencia de una IP asignada por DHCP

Aunque los routers modernos tienen mecanismos para intentar asignar siempre la misma IP a un dispositivo, esto no es completamente confiable.

Un día recibí una llamada porque nadie podía acceder al sistema. Después de hacer varias pruebas descubrimos que una impresora había tomado la dirección IP que normalmente usaba el computador que funcionaba como servidor. Como resultado, el equipo cambió de IP y la aplicación dejó de ser accesible.

Un problema completamente evitable.

2. La dirección IP estaba “quemada” en el código

A primera vista, alguien podría pensar que cuando cambió la dirección IP del equipo el problema tenía una solución rápida: simplemente acceder a la aplicación usando la nueva IP.

Pero la realidad era diferente.

La aplicación tenía escrita directamente en el código la dirección IP del propio servidor, y esa era la dirección que utilizaba para realizar todas las consultas AJAX.

Esto significaba que, aunque los usuarios intentaran acceder al sistema desde la nueva IP, las peticiones internas de la aplicación seguían intentando comunicarse con la dirección anterior.

El problema no terminaba ahí: la IP no estaba definida en una variable de configuración ni en un archivo centralizado.

Estaba literalmente escrita en cientos de líneas de código diferentes.

En consecuencia, algo tan simple como cambiar la dirección del servidor implicaba revisar y modificar manualmente múltiples partes del sistema, aumentando el tiempo de mantenimiento y el riesgo de introducir nuevos errores.

3. Modificar la aplicación era un riesgo

La aplicación no tenía una arquitectura clara, no seguía buenas prácticas y tampoco estaba diseñada para escalar.

Realizar un pequeño cambio podía romper varias funcionalidades. De hecho, esto ocurría con frecuencia.

Esto generaba dos consecuencias claras:

• Cada modificación requería muchas más horas de trabajo.
• Cada cambio implicaba un riesgo para el funcionamiento del sistema.

En otras palabras, algo que debería tomar pocas horas podía convertirse en días de trabajo.

4. La aplicación corría desde un IDE en Windows

La aplicación estaba ejecutándose directamente desde el IDE en un computador con Windows.

Esto, en un entorno productivo, es una mala práctica crítica.

Windows no está diseñado para funcionar como un servidor de aplicaciones 24/7, y mucho menos un IDE.

Cada vez que ocurría una falla eléctrica, el sistema quedaba completamente detenido. No existía un protocolo de inicio automático ni sistemas de respaldo eléctrico como los que normalmente tienen los servidores.

Después de cada corte de energía, alguien debía ir físicamente al equipo, encenderlo, abrir el IDE y ejecutar nuevamente la aplicación.

Debo admitir que el personal se volvió sorprendentemente experto en hacerlo.

Otro problema grave era que el código fuente estaba siempre visible en pantalla. Entre esas líneas de código estaban escritas directamente las credenciales de la base de datos.

El fallo inevitable

Un sábado, alrededor de las 11 de la mañana, recibí una llamada solicitando soporte.

El computador donde corría la aplicación estaba extremadamente lento y se quedaba congelado.

Esta fue una señal de advertencia importante.

Sin embargo, al ser sábado y trabajar solo hasta el mediodía, no fue posible coordinar una revisión completa en ese momento. No volví a tener noticias hasta el lunes.

Ese día me informaron que simplemente habían reiniciado el equipo y el problema parecía haberse solucionado.

Aunque el incidente estaba aparentemente resuelto, para mí era una señal clara de que algo debía revisarse con urgencia. Como suele ocurrir en muchas empresas, el día a día terminó desplazando la revisión.

Cuando finalmente falló el sistema

Aproximadamente 10 días después ocurrió lo inevitable.

Un jueves a las 9 de la mañana recibí una llamada: la aplicación no funcionaba.

Cuando revisaron el computador encontraron una pantalla negra. El equipo tardaba mucho en iniciar Windows y, cuando lo hacía, se congelaba en el escritorio.

El diagnóstico de Dell fue claro: el disco duro tenía fallas críticas.

El sistema no podía arrancar normalmente y la información parecía irrecuperable por medios convencionales.

La única opción fue recurrir a un laboratorio especializado en recuperación de datos.

Como es habitual en estos casos, el proceso fue costoso.

Afortunadamente se logró recuperar la información: años de datos y archivos que nunca habían sido archivados ni eliminados.

La solución de emergencia

Durante ese mismo fin de semana, junto con el equipo de soporte de General Software, tomamos varias decisiones urgentes:

• Dockerizamos la aplicación.
• Migramos las rutas del sistema de Windows a Linux.
• Implementamos librerías más modernas.
• Montamos la aplicación en un contenedor dentro de Proxmox.
• Utilizamos un servidor que la empresa ya tenía para su sistema contable.

Para el sábado ya teníamos la aplicación funcionando nuevamente en esta nueva infraestructura, utilizando la base de datos recuperada.

Sin embargo, aún faltaban pruebas funcionales con el personal del negocio, por lo que el proceso continuó la semana siguiente.

La lección

El objetivo de este artículo es mostrar un ejemplo real de un error muy común en el mundo empresarial.

Muchas empresas intentan ahorrar dinero contratando desarrollos baratos o evitando invertir en buenas prácticas de ingeniería de software.

Pero esas buenas prácticas —que muchas veces son invisibles para el negocio— son precisamente las que permiten que un sistema sea:

• Estable
• Escalable
• Mantenible
• Seguro
• Y fácil de modificar en el futuro

También son las que permiten implementar elementos fundamentales como copias de seguridad periódicas, políticas de almacenamiento, monitoreo e infraestructura adecuada.

En otras palabras, son las que realmente reducen costos a largo plazo.

Conclusión

El software no es solo código que funciona hoy.

Cuando una empresa depende de una aplicación para operar su negocio, esa aplicación se convierte en una pieza crítica de su infraestructura.

Intentar ahorrar en su desarrollo o mantenimiento puede terminar costando mucho más.

¿De qué sirve tener un software barato si a corto o mediano plazo terminará costando dos o tres veces más su valor original?

---