Software frágil: 15 señales de que una auditoría técnica es urgente

Una aplicación puede funcionar y, al mismo tiempo, volverse frágil. Los incidentes se resuelven uno a uno, las entregas tardan más, los costes aumentan, pero nadie sabe decir por qué. En este punto, añadir un desarrollador o lanzar una reforma suele equivaler a decidir sin diagnóstico.

Una auditoría técnica establece constataciones sobre el código, la arquitectura, las dependencias, la seguridad y la explotación, y después las clasifica por prioridad. Las quince señales siguientes, agrupadas en cinco áreas, indican cuándo este examen se vuelve urgente. Varias señales en una misma área merecen que se detenga en ellas.

• ¿Su aplicación ya no funciona? La lista de comprobación para recuperarla↗

Estas señales muestran que la aplicación no es observable. Sin registros aprovechables, sin seguimiento de errores y sin reversión, cada incidente se trata a ciegas. La auditoría verifica qué se mide, qué tiene copia de seguridad y qué puede restaurarse.

• ✓Los mismos incidentes vuelven tras cada corrección.
• ✓Nadie recibe una alerta antes de que los usuarios señalen un problema.
• ✓La vuelta a la versión anterior es imposible o nunca se ha probado.

Cuando un equipo duda en entregar, el problema rara vez está en su motivación. Los despliegues manuales, la falta de pruebas y unos entornos distintos de producción hacen incierto cada cambio. La auditoría identifica qué hace arriesgadas las entregas y qué convendría hacer más fiable en primer lugar.

• ✓Los plazos se vuelven imprevisibles, incluso para pequeñas modificaciones.
• ✓Las puestas en producción se hacen a mano, a menudo fuera del horario laboral.
• ✓La lista de correcciones pendientes crece más rápido de lo que disminuye.

Un código puede ser antiguo sin ser frágil. La señal útil es el efecto de los cambios: si una corrección local rompe funciones alejadas, las fronteras entre las partes del sistema son difusas. Las dependencias obsoletas añaden un riesgo de seguridad y complican cada actualización.

• ✓Una modificación local provoca regresiones en otras partes de la aplicación.
• ✓Algunas dependencias ya no se mantienen o hace mucho tiempo que no se actualizan.
• ✓Nadie puede afirmar que el código en producción corresponde al repositorio.

El riesgo más subestimado es humano. Cuando solo una persona sabe desplegar o conoce las reglas de negocio, su salida puede detener la evolución del producto. En Macq, en el proyecto TRADEMEX, CUB3 movilizó un perfil que ya conocía el producto para asegurar la continuidad tras una salida clave y transmitir ese conocimiento a los equipos.

• ✓Solo una persona sabe desplegar o entiende una parte crítica.
• ✓Los interlocutores técnicos cambian a menudo y el contexto se pierde.
• ✓No existe documentación actualizada ni gestión centralizada de los accesos.

• El caso Macq: continuidad técnica en TRADEMEX↗

Las señales técnicas acaban afectando a los ingresos o al cumplimiento normativo. Una factura cloud que aumenta sin que aumente el uso, una petición de cliente imposible de cumplir o una pregunta de seguridad sin respuesta merecen un examen antes del próximo compromiso.

• ✓La factura de alojamiento aumenta sin un aumento comparable del uso.
• ✓Hay compromisos comerciales bloqueados por limitaciones técnicas.
• ✓Una pregunta de seguridad o de cumplimiento normativo sigue sin una respuesta clara.

JustWC conecta a profesionales itinerantes, como repartidores o técnicos de campo, con aseos y puntos de agua mediante una WebApp basada en tickets. El producto estaba en producción, pero los interlocutores técnicos cambiaban a menudo y las solicitudes avanzaban despacio. La auditoría de CUB3 abarcó el código, las dependencias, la seguridad y el dimensionamiento en AWS.

Reveló máquinas sobredimensionadas y problemas de seguridad que corregir. Después, los trabajos se ordenaron según su impacto y el presupuesto: corrección de los problemas de seguridad, refactorización de las partes prioritarias y, por último, una infraestructura redimensionada y descrita con Terraform. El coste de infraestructura pasó de 75 € a 18 € al mes, es decir, un 76 % menos. Este resultado corresponde a este producto y a su uso; no es un ahorro garantizado.

• Leer el caso JustWC↗

Una auditoría útil termina con decisiones posibles, no con una simple lista de defectos. En CUB3, la auditoría abarca una aplicación y un repositorio: revisión del código y de la arquitectura, examen de las dependencias, controles específicos de seguridad y rendimiento y, por último, un informe priorizado y una presentación. El presupuesto orientativo es de 2 000 a 4 000 € sin IVA, confirmado tras definir el alcance.

Lo que la auditoría no hace importa igual: no corrige los problemas, no es una prueba de intrusión y no equivale a una certificación. Las correcciones se presupuestan después según las prioridades elegidas, en forma de recuperación, configuración DevOps o mantenimiento.

• ✓Las constataciones remiten a elementos verificables del código o de la infraestructura.
• ✓Cada recomendación tiene una prioridad y una justificación.
• ✓Los riesgos inmediatos se separan de las mejoras deseables.
• ✓La presentación permite elegir el siguiente paso: corregir, recuperar o reconstruir.

• El alcance y el precio de la auditoría técnica↗