El proceso que te cuesta dinero no falla.
Se hace a mano.

Antes de descomprimir un archivo subido por alguien de fuera, escribí una comprobación contra el ataque clásico: una entrada llamada ../../algo que escribe fuera de la carpeta de destino.

if unzip -l paquete.zip | grep -E '\.\./'; then
  echo "PELIGRO"; exit 1
fi
echo "rutas limpias"

Salió «rutas limpias». Y era mentira: unzip no estaba instalado en ese servidor. El comando falló, no escribió nada, grep no encontró nada, y la guardia concluyó que todo estaba bien.

Lo peor es la cara que pone: una comprobación que aprueba porque está rota parece diligencia. Nadie sospecha de algo que acaba de decirte que está todo en orden.

La idea era simple: no lanzar una tarea pesada si ya hay otra corriendo.

pgrep -f 'procesar.js'   # encuentra "algo" aunque no corra nada

El problema es que pgrep -f busca en la línea de órdenes completa, y el propio shell que lanza la búsqueda lleva el texto buscado en la suya. Se encuentra a sí mismo. Si va dentro de una conexión remota o de una llamada desde código, el envoltorio también la lleva.

Costó tres tropiezos la misma noche: un vigilante bloqueado eternamente, comprobaciones manuales que juraban que un proceso muerto seguía vivo, y una guardia que abortó por un proceso inexistente.

pgrep -f '[p]rocesar\.js'   # casa con el nombre, no consigo mismo

Una página de captación, publicada y con campaña activa. El formulario hacía exactamente esto:

alert('¡Gracias! Te contactaremos pronto');

Y nada más. Ni una petición, ni un guardado, ni un correo. La persona rellenaba sus datos, leía que la iban a llamar, y ese contacto no existía en ningún sitio.

No hubo ningún error en consola. No hubo alerta. La campaña gastaba con normalidad y las métricas de la plataforma de anuncios mostraban clics felices. Desde fuera, todo funcionaba.

«Ese dominio ya no lo uso», dijo el dueño. Se le añadió un registro apuntando al servidor nuevo y el panel se quejó: duplicate record.

No era un capricho del panel. El dominio seguía sirviendo un sitio real, y ahora tenía dos direcciones. Cuando un nombre resuelve a dos IP, el navegador elige una al azar: la mitad de las visitas veían la web y la otra mitad un 404.

$ nslookup ejemplo.tld
Addresses:  216.198.79.1      <- el sitio de verdad
            157.180.116.214   <- el servidor nuevo, sin nada

Y una segunda capa: al comprobarlo, el resolutor público seguía devolviendo el registro viejo por caché. La verdad estaba en los servidores autoritativos, no en la respuesta rápida.

Un asistente conectado a datos de negocio consultaba las cifras mediante llamadas a funciones. Al cambiar de proveedor de modelo, el nuevo no soportaba esa capacidad.

No dio error. No avisó. Simplemente dejó de consultar y empezó a responder de memoria: cifras plausibles, bien redactadas, con el tono de siempre. Delante de un cliente.

Es el fallo más difícil de detectar de toda esta lista, porque el resultado parece mejor que un error: sale rápido y suena seguro.

Una base de contactos de empresas, construida durante semanas. La cobertura parecía excelente: la mayoría tenía teléfono.

Un verificador que solo cruzaba los datos consigo mismos, sin salir a internet, encontró esto en segundos:

9.262 empresas "con teléfono"
  4.055  tienen alguno propio          <- 44%
  2.530  solo números compartidos por 20+ empresas
  1.305  compartidos por 50+ empresas
el más repetido aparece en 142 empresas distintas

Eran centralitas de directorios, números de la agencia que les hizo la web, plantillas copiadas. Un contacto repetido entre cien empresas no es de ninguna.

Un botón de una página pública redirigía usando el origen de la petición. En desarrollo funcionaba perfecto. En producción llevaba a una página muerta.

req.nextUrl.origin
// en local:       https://midominio.com   ✓
// tras un proxy:  http://localhost:3000   ✗

El servidor web recibe la petición en el puerto interno, así que eso es lo que el framework ve. La dirección pública viaja en una cabecera aparte que nadie miró.

Se descubrió después de que el enlace ya estuviera en correos enviados. El arreglo fue trivial; encontrarlo, no.

Dos archivos a medio escribir, olvidados en el directorio del servidor, daban errores de tipos al compilar. Como el despliegue compila el directorio de trabajo y no solo lo que viene del repositorio, cada despliegue fallaba y revertía.

Nadie se enteró. El repositorio estaba correcto, los comandos terminaban, y la comprobación de después miraba el identificador del último cambio — que durante el despliegue ya apunta al nuevo, y solo vuelve atrás al revertir.

Dos veces en un mismo día di por buena una comprobación que no probaba nada:

Una: busqué un fragmento de código en el buscador de la plataforma. Cero resultados. Conclusión: «no está subido a ningún sitio». La realidad: ese buscador no indexa repositorios privados. Lo correcto era listar el árbol por la interfaz de programación.

Dos: vi un contenedor marcado como Exited y anuncié que un servicio llevaba cinco días caído. Exited (0) es una salida limpia: estaba apagado a propósito, esperando una decisión.

Las dos veces se cayó al validar la herramienta, no al repetir la consulta.

Había respaldo diario, verificado, con rotación. Todo el mundo dormía tranquilo. Respaldaba la base de datos — y nada más.

Pero buena parte del trabajo no vivía en la base: eran archivos acumulados durante semanas en una carpeta del servidor. Si ese disco fallaba, se perdían enteros, y buena parte no se podía volver a generar.

El mismo agujero apareció tres veces con tres cosas distintas. Siempre igual: alguien monta un respaldo excelente para lo que tenía en mente ese día, y lo que llega después cae fuera sin que nadie lo revise.