Auditoría de Despliegue e IA
Lo que encontré auditando nuestro propio despliegue (y por qué la IA no me lo iba a avisar) — Criterio técnico vs. IA.
Este artículo fue originalmente publicado por Gonzalo Oviedo en LinkedIn el 29 de julio de 2026. Es una reflexión profunda sobre la optimización de infraestructura (Docker, Cloud Run, GraalVM), el costo de la ineficiencia y el rol del criterio técnico en la era de la inteligencia artificial.
Me senté a revisar en serio la configuración de despliegue de nuestro servicio core en Cloud Run. No porque algo estuviera fallando. Precisamente porque nada estaba fallando.
Encontré tres cosas. Ninguna rompía nada. Las tres costaban dinero.
1. Un sh -c que estaba cortando requests en cada deploy
Section titled “1. Un sh -c que estaba cortando requests en cada deploy”ENTRYPOINT ["sh", "-c", "java -jar app.jar"]Lo miré varias veces antes de que me hiciera ruido. Se ve perfectamente normal.
El problema: sh queda como PID 1 y Java como su hijo. Cuando Cloud Run despliega o escala hacia abajo, manda SIGTERM al PID 1. sh no propaga esa señal. Diez segundos después llega SIGKILL y la JVM muere de golpe, con requests en vuelo.
La solución es una palabra: exec (o usar la sintaxis de array directo sin shell: ENTRYPOINT ["java", "-jar", "app.jar"]).
Una palabra que ninguna IA me iba a agregar, porque yo nunca le pregunté qué pasa con las señales del sistema operativo cuando el contenedor se apaga.
2. Un comentario que normalizaba 15 minutos perdidos por deploy
Section titled “2. Un comentario que normalizaba 15 minutos perdidos por deploy”# Deshabilitado porque falla con Spring Boot 3 + GraalVM# RUN ./mvnw dependency:go-offlineFalló, se comentó, se siguió. Todos hemos hecho eso.
El costo real: cada build baja el repositorio Maven completo desde cero y encima recompila la imagen nativa. Entre 10 y 20 minutos por deploy.
El diagnóstico correcto no era arreglar go-offline. Era usar cache mounts de BuildKit y borrar la línea. Build de 2 minutos.
La distancia entre “lo comenté porque fallaba” y “entendí por qué fallaba” son 60 horas al mes.
3. Rendimiento que estaba ahí, gratis, y no estábamos usando
Section titled “3. Rendimiento que estaba ahí, gratis, y no estábamos usando”Compilamos a binario nativo con GraalVM Community. Correcto sobre el papel.
Pero la distribución Community no soporta Profile-Guided Optimizations (PGO). Y PGO da típicamente 20-40% más de throughput, justo en el punto donde una imagen nativa pierde frente a una JVM con JIT.
Nadie decidió no usarlo. Simplemente no sabíamos que había una decisión ahí.
Lo que me llevo de esto
Section titled “Lo que me llevo de esto”Ninguno de los tres problemas rompió nada. Ese es exactamente el punto.
Llevo más de 15 años haciendo esto y uso IA todos los días. Escribe mejor código que yo en la mitad del tiempo. Lo que no hace es preguntarme qué pasa con las señales del kernel cuando escala mi contenedor, ni advertirme que ese comentario inocente me cuesta 60 horas al mes.
Esa pregunta la tengo que traer yo. Y viene de haber estado despierto a las 3 AM entendiendo por qué el deploy tiró 5xx.
La IA no reemplaza el criterio técnico. Lo multiplica — en la dirección en que ya venías apuntando.
Si venías apuntando mal, ahora te equivocas más rápido y a mayor escala.
¿Cuándo fue la última vez que alguien de tu equipo auditó el Dockerfile que llevas 8 meses desplegando sin tocar?