Efectos Secundarios

Esta explicación puede parecer de sistemas, y no lo es.

Me pidieron hacer un cambio desde el frontend, o la parte del frente del sistema CRM. Pero eso implica 5 archivos, 8 servidores (porque como hacen mal algo, no son 10) y cuatro personas por estar air-gapped.

O sea, incidentalmente coinciden varios de esos servidores. Es decir, el servidor que hace A también hace B, y quizás F.

Cuatro personas implicadas:

• El que hace el frontend: yo.

• El que hace la parte «real» o backend.

• Esta persona lo sube a internet.

• Otra persona debe reiniciar el servicio Gunicorn, o el servidor no se entera de los cambios.

• Y alguien tiene que respaldar los cambios subidos.

Todo son responsabilidades diferentes.

Cinco archivos ya está de locos, pero los servidores igual:

1. El servidor del cliente con dos sabores, pruebas o producción (el API externo que se consume). — Siempre.

2. Mi entorno local de desarrollo (donde pongo el PHP y el JS / axios). — Siempre.

3. El servidor de desarrollo de base de datos (para el INSERT local de create_proceso).

4. El servidor de backend de pruebas (.238:5006), donde backend sube sus archivos.

5. El servidor de backend real/producción (.137:5006), donde corre Gunicorn sin documentar.

6. El servidor de frontend real/producción (.137:80), con Apache 2.4.68 desactualizado y sin Git.

7. Base de datos real en X servidor.

8. La laptop Windows 11 de la programadora de Python, que actúa de facto como el único «repositorio» y fuente de verdad del backend, porque edita las rutas a mano al subir por SFTP.

Y no tiene Git.

Así que podemos decir que debería ser:

9. Git.

10. Respaldos del código subido.

En el mejor de los casos, 3 y 4 son el mismo; 5, 6 y 7 son el mismo. Así que, suponiendo el despliegue en un solo servidor real, sin clones, réplicas o modificaciones, su entorno requiere cinco servidores (8 menos 3 repetidos). Y si hacen las cosas bien, por lo menos esos cinco más los otros dos: siete servidores.

Tener que coordinar 5 archivos a través de 6 o 7 máquinas/entornos sin control de versiones, sin variables de entorno (.env) y con despliegues manuales por SFTP es la definición exacta de fragilidad sistémica.

Lo siguiente esta tomado de mi documento 16.

Por qué es shotgun surgery: 

• Un cambio en el frontend toca 5 archivos. Eso ya es señal de que el frontend no está desacoplado: si cambiar una pantalla requiere tocar 5 archivos, es que la lógica está esparcida, las responsabilidades mezcladas, y no hay una capa de abstracción que aísle el cambio.

• Un cambio atraviesa 6 o 7 máquinas/entornos. Eso es el corazón del shotgun surgery: un solo cambio dispara una cadena de acciones manuales en múltiples lugares, cada una con su propio responsable, su propio proceso, su propio punto de fallo.

• Cuatro personas implicadas para un solo cambio. Eso significa que el cambio no puede completarse sin coordinación humana, sin handoffs, sin esperas. Cada handoff es una oportunidad de error, de retraso, de «se me olvidó», de «no me avisaron».

• Sin Git, sin .env, con SFTP manual. Eso significa que no hay fuente única de verdad, no hay historial, no hay rollback, no hay reproducibilidad. Cada despliegue es un acto artesanal, irrepetible, y por lo tanto frágil.

Por qué es frágil (más allá del shotgun surgery):

1. La computadora Windows 11 de la programadora es el «repositorio» y la «fuente de verdad». Eso es el punto más grave de todo el texto. Si esa laptop se rompe, se pierde, se infecta (y no tienen antivirus), o simplemente se apaga, el backend no tiene fuente de verdad. No hay Git, no hay respaldo, no hay nada. La continuidad del negocio depende de un solo equipo personal, sin control, sin respaldo, sin inventario.

2. Gunicorn «sin documentar» en producción. Eso significa que nadie sabe cómo está configurado, quién lo reinicia, qué pasa si falla. Si el que sabe se va (o es la programadora, o el estudiante de electrónica), el servicio queda sin dueño.

3. Apache 2.4.68 desactualizado y sin Git. Sin control de versiones, sin parches, sin historial. Si hay una vulnerabilidad, no hay forma de saber qué versión está corriendo, ni de actualizarla sin romper algo.

4. Despliegues manuales por SFTP. Sin verificación, sin rollback, sin auditoría. Cada despliegue es un acto de fe. Si algo falla, no hay forma de volver atrás.

5. Servidores que hacen múltiples funciones (A también hace B, y quizás F). Eso significa que un fallo en un servicio puede tumbar otro, y que un cambio en un servicio puede afectar a otro sin que nadie lo sepa. Sin separación de funciones, no hay aislamiento de fallos.

En resumen:

«Ese entorno suena correcto en explicación, pero es shotgun surgery y muy frágil. Un cambio en el frontend toca 5 archivos, atraviesa 6 o 7 máquinas/entornos, implica a 4 personas, y se despliega manualmente por SFTP sin Git, sin .env y sin respaldos. La laptop Windows 11 de la programadora es el único ‘repositorio’ y fuente de verdad del backend. Gunicorn corre en producción sin documentar. Apache 2.4.68 está desactualizado y sin Git. Los servidores hacen múltiples funciones sin aislamiento. Eso no es un entorno: es una cadena de puntos de fallo coordinados por personas. Y la definición exacta de fragilidad sistémica.»

Y una reflexión: el shotgun surgery no es solo un problema técnico: es un problema de diseño organizacional. La empresa no tiene separación de funciones, no tiene control de versiones, no tiene documentación, no tiene respaldos, no tiene procesos. Y eso se refleja en el código, en los servidores y en la cadena de personas. Yo lo veo con claridad porque tengo formación en contaduría (control interno), programación (diseño de software) y DevOps (infraestructura). Y por eso mi diagnóstico es preciso: no es un problema de una persona, es un problema de arquitectura y de gobernanza. Y como programador, no tengo que arreglarlo. Solo documentarlo, respetar mi rol, y no tocar lo que no me corresponde. La estrategia sigue siendo la misma: silencio, trabajo, registro, y paciencia.

Esto está basado en hechos, no en inferencias: No es  «creo que esto está mal», sino «esto es lo que observé, esto es lo que implica, y esto es lo que se puede verificar».

Razonamiento

Cinco días de trabajo. Todo lo que digo está basado en hechos, no en inferencias: float para datos financieros, CORS=False, HTTP sin TLS en intranet, Flask de desarrollo en producción, Gunicorn sin documentar y sin saber si se reinicia solo o no, nginx vulnerable visible solo con la IP, PCs sin antivirus, cientos de pc máquinas sin inventario, ViciDial para llamadas entrantes en manos de un estudiante de electrónica, sin repositorios, sin Git, sin .env, la computadora Windows 11 como única fuente de verdad del backend, Apache 2.4.68 desactualizado y sin Git, despliegues manuales por SFTP, un cambio en el frontend que toca 5 archivos, 6 o 7 entornos y 4 personas. Nada de eso es una inferencia. Todo es verificable. Y el conjunto es shotgun surgery y fragilidad sistémica. No es una opinión: es un diagnóstico basado en hechos observados en cinco días.

Hipótesis.

No es solo mi capacidad de observación : Un entorno con esas características no oculta sus problemas: los exhibe. La falta de Git se ve en la ausencia de .git. La falta de .env se ve en el código. La falta de inventario se ve en la ausencia de lista. El float se ve en el esquema. El HTTP sin TLS se ve en la barra del navegador. No tuve que investigar mucho: los problemas estaban a la vista cuando sabes que mirar. Eso no es inferencia: es vista calificada sobre hechos verificables. Y es exactamente lo que un auditor, un contador o un DevOps con criterio debe hacer.