Funciona en prod: qué es, por qué ocurre y por qué es peligroso

Qué significa “funciona en prod”

“Funciona en prod” es una expresión consolidada entre desarrolladores que describe una situación en la que el código funciona en el servidor de producción pero se niega a funcionar en el entorno de pruebas o en la máquina local de un compañero. Externamente suena como “no hay problema”, aunque en realidad el problema existe — simplemente no se reproduce en el entorno de producción. La raíz de la divergencia está en la diferencia de configuraciones, versiones y datos entre los entornos.

La frase nació como el antípoda de otra excusa conocida — “en mi máquina funciona”. Si el desarrollador dice “funciona localmente”, el error solo existe para los demás. Pero si “funciona en prod”, el error solo aparece en staging o en el entorno de pruebas, mientras que producción está limpia. La ironía del destino: en ambos casos el problema es real, simplemente no se manifiesta en quien está mirando. Según el estudio DevOps Research and Assessment (DORA) 2023, los equipos con un alto nivel de automatización de despliegue se enfrentan a estas divergencias 3 veces menos.

Desde el punto de vista del negocio, la situación “funciona en prod” es más peligrosa de lo que parece. Si hay un error en staging pero no en prod, el desarrollador podría ignorarlo — y entonces, con el próximo despliegue, el error pasará a producción. Un alivio temporal se convierte en un problema futuro que habrá que corregir bajo la presión de los usuarios.

Por qué los desarrolladores dicen “funciona en prod”

La razón psicológica de la persistencia de la frase es un reflejo de defensa. El desarrollador que ve un error en staging pero no en producción puede subestimar inconscientemente el problema: “si en producción todo está bien, entonces no es urgente”. Un clásico sesgo cognitivo — el sesgo de supervivencia, donde el éxito visible de producción pesa más que la amenaza potencial de un futuro fallo.

La segunda razón es la responsabilidad difusa. Si producción funciona pero staging no, el culpable es el entorno, no el código. El desarrollador se libera de la responsabilidad del error y la traslada al ingeniero DevOps o al administrador. Según el Atlassian State of DevOps 2022, en equipos sin un entorno de despliegue unificado (Docker, Kubernetes), estas transferencias de responsabilidad ocurren un 60% más a menudo.

La tercera razón es el miedo a un lanzamiento sin tiempo de inactividad. Si el desarrollador corrige el error en staging y despliega la solución, esto requerirá otra revisión de código, pruebas y despliegue. La frase “funciona en prod” permite posponer la corrección hasta el próximo lanzamiento, reduciendo la carga de trabajo actual. Las correcciones aplazadas son una de las principales causas de acumulación de deuda técnica en los equipos.

Diferencia entre entornos de desarrollo y producción

Producción y staging nunca son completamente idénticos — esto es técnicamente imposible debido a las diferencias de escala, carga y datos. Sin embargo, los parámetros clave deben coincidir: la versión del sistema operativo, compilador, intérprete, base de datos, servidor web y todas las dependencias del proyecto. Si al menos un parámetro difiere, el comportamiento del código puede cambiar.

Las principales diferencias entre entornos incluyen:

• Hardware — procesador, cantidad de RAM, tipo de disco (SSD vs HDD) pueden afectar los tiempos y el rendimiento de la multitarea
• Entorno de red — firewall, DNS, proxy, balanceadores de carga solo están presentes en producción
• Datos en la BD — en staging normalmente hay datos de prueba, mientras que los registros reales de usuarios tienen patrones inesperados
• Versiones de dependencias — incluso una actualización menor de una biblioteca puede cambiar el comportamiento del código
• Variables de entorno — claves de API, tokens, flags de funcionalidades pueden diferir entre entornos

La contenedorización resuelve la mayor parte de estos problemas. La misma imagen de Docker creada para producción debe usarse también en staging. La única diferencia son las variables de entorno y los montajes de volúmenes. Según el Docker State of Application Development 2023, los equipos que usan una imagen única en todos los entornos reducen las discrepancias en un 74%.

Causas típicas de la discrepancia de comportamiento en producción

La primera y más frecuente causa son las versiones diferentes de dependencias. El desarrollador instala un paquete localmente con la bandera --save pero olvida actualizar package.json o el archivo lock. Al desplegar en producción se instala una versión diferente que se comporta de manera distinta. Para el ecosistema npm, el archivo lock resuelve completamente el problema; para otros gestores de paquetes existen mecanismos análogos (Gemfile.lock, Podfile.lock, pubspec.lock).

La segunda causa son las variables de entorno ausentes o sobrantes. El desarrollador usa un archivo .env en su máquina local pero no agrega las variables correspondientes al pipeline de CI/CD o al servidor. El resultado: el código falla con un error de conexión a la API o base de datos. Según la GitLab DevSecOps Survey 2023, el 27% de los incidentes en producción están relacionados con variables de entorno incorrectas.

La tercera causa es el estado de la base de datos. En staging, la BD puede contener registros que no existen en producción, o viceversa — pueden faltar migraciones. Un escenario típico: el desarrollador escribe código que trabaja con un nuevo campo en la tabla, pero la migración aún no se ha aplicado en producción. Una estrategia de migración con compatibilidad hacia atrás es la única forma de evitar estas situaciones.

La cuarta causa son los ajustes regionales y de idioma. El formato de fechas, los separadores de decimales, la codificación del texto — todo esto puede diferir en la máquina local del desarrollador y en el servidor. Es especialmente relevante para proyectos con internacionalización. La solución es especificar explícitamente la configuración regional en la configuración de la aplicación y no depender de los ajustes del sistema.

Cómo diagnosticar el problema “funciona en prod”

El primer paso es comparar los registros de ambos entornos. La diferencia en el nivel de registro a menudo oculta la causa: en producción puede estar activado INFO, mientras que en staging está DEBUG. Configure el mismo nivel de registro y asegúrese de que ambos entornos escriban en un formato que permita la comparación automatizada. Use sistemas centralizados de recopilación de registros — Sentry, Datadog, ELK Stack.

El segundo paso es verificar las versiones de dependencias. Compare los archivos lock, liste los paquetes instalados en ambos entornos. Una diferencia en una versión menor o de parche es la causa más probable de la divergencia. Herramientas como npm ls, pip freeze, mvn dependency:tree ayudan a identificar rápidamente las discrepancias.

El tercer paso es reproducir el entorno de producción localmente. Use Docker Compose o herramientas similares para levantar una copia exacta de la infraestructura de producción. Si el error se reproduce en un contenedor local, el problema está en el código, no en el entorno. Si no se reproduce, busque una diferencia en la configuración.

El cuarto paso es verificar los feature flags y las pruebas A/B. Quizá el código funciona en un modo diferente en producción porque el flag incorrecto está activado. Según el LaunchDarkly State of Feature Management 2023, hasta el 40% del comportamiento inesperado en producción está relacionado con valores incorrectos de feature flags. Un manifiesto único de flags para todos los entornos resuelve este problema.

Prevención de divergencias de entornos en el proyecto

La principal herramienta de prevención es Infrastructure as Code (IaC). Todos los entornos deben describirse en código: Dockerfile, docker-compose.yml, scripts de Terraform o playbooks de Ansible. Los cambios manuales en el servidor están prohibidos — cualquier cambio de configuración pasa por el repositorio y revisión de código. Esto garantiza que todos los entornos tengan la misma configuración.

La segunda herramienta más importante es un pipeline CI/CD unificado. El mismo script de compilación, pruebas y despliegue debe usarse para todos los entornos. La única diferencia son las variables objetivo (URL, claves). Si el pipeline para staging y producción difiere en los pasos, las divergencias son inevitables.

La tercera herramienta es la sincronización automática de datos. Actualice periódicamente (a diario o según un horario) el entorno de staging con una copia anonimizada de la base de datos de producción. Esto permite probar el código con datos reales en lugar de fixtures sintéticos. Herramientas: pg_dump/pg_restore para PostgreSQL, mysqldump para MySQL, servicios especializados como DataGrip.

La cuarta herramienta es la supervisión de divergencias. Configure alertas cuando se detecten diferencias entre staging y producción. Un script simple que compare los hashes de los archivos de configuración o las versiones de los paquetes instalados ahorrará horas de depuración. La prevención siempre es más barata que el diagnóstico: prevenir las divergencias de entornos requiere menos esfuerzo que encontrar la causa del error “funciona en prod”.