El servidor que nadie se atrevía a reiniciar

Catorce personas conectadas en remoto, el ERP de la empresa y la red privada por la que entrábamos nosotros. Todo sobre un servidor que nadie se atrevía a reiniciar.

No por precaución. Porque nadie sabía qué se iba a caer.

Miramos cómo estaban arrancados los procesos que lo sostenían.

Todo —Firebird con la base de Microsip, el cliente de Tailscale, los puentes de sincronización— corría como aplicaciones de usuario. Ventanas abiertas en una sesión, minimizadas, con la instrucción tácita de no cerrarlas.

La deuda técnica del "no lo toques"#

Cuando la infraestructura se despliega rápido y sin rigor, es común que queden esos hilos invisibles: una sesión remota abierta con procesos corriendo en el fondo, sostenidos por el hecho de que nadie ha cerrado sesión todavía.

Un sistema así es una bomba de tiempo. Una actualización automática del sistema operativo, un pico de voltaje de dos segundos, o el simple error de un operador que cierra su sesión en lugar de desconectarla, paralizan la empresa entera en pleno horario comercial. Y lo peor: como la red privada de acceso también dependía de una sesión abierta, los administradores externos tampoco podrían entrar a encenderlo. El rescate moría con la misma sesión que había que rescatar.

Nadie diseñó ese estado. Se llegó a él por acumulación, y todos terminan protegiéndolo con pánico precisamente porque nadie sabe qué lo sostiene.

La prueba ácida#

Ver un proceso "en ejecución" no prueba que sobreviva a un reinicio. Prueba que corre mientras alguien lo dejó corriendo. La única forma de saber si un servidor está de verdad blindado es apagarlo a propósito y ver qué vuelve solo.

Antes de tocarlo, corrimos un script forense que listaba cada proceso activo y revisaba si tenía una instrucción formal de arranque en el sistema. Si esa lista no salía vacía —si había aunque fuera un proceso vivo sin forma de volver por sí mismo—, el reinicio se cancelaba. Salió limpia. Entonces, a las nueve y media de la noche, ejecutamos el apagado.

Qué hicimos#

Cada proceso pasó a ser servicio de Windows con NSSM: arranque automático, reinicio ante caída, sin depender de que nadie tenga una sesión abierta. Y después el apagado de verdad, para comprobarlo — no leer una configuración, sino ver qué vuelve solo.

Diseñar para que vuelva solo#

Convertir un servidor frágil en infraestructura que se recupera sola toma horas, no semanas, si se conoce el estándar.

Los procesos críticos se encapsularon en gestores de servicios del sistema operativo, para que arranquen en la etapa previa a que alguien toque un teclado y se reinicien automáticamente si se cuelgan. Hay un matiz que importa y que se pasa por alto seguido: no todo va en automático a la fuerza. El motor de la base de datos, por ejemplo, se deja arrancar por su propio supervisor —un proceso vigilante que ya está en automático y cuyo único trabajo es levantarlo y revivirlo—; ponerlo también en automático por su cuenta crearía dos cosas peleándose por arrancar la misma pieza. La resiliencia no es "todo en automático", es que cada pieza tenga exactamente una forma clara de volver.

La red privada se configuró en modo desatendido y con la caducidad de llaves apagada, para que el túnel de acceso esté vivo en el segundo cero del arranque, sin esperar a que nadie inicie sesión.

El verdadero despliegue no termina cuando el sistema funciona; termina cuando el sistema sobrevive a que alguien apague la máquina.

Lo que quedó como regla#

Quince minutos después del apagado, las sondas de monitoreo marcaron verde una por una. La base de datos, el túnel cifrado y los conectores habían revivido completamente solos, listos para los catorce usuarios de la mañana siguiente. Nadie tuvo que entrar a encender nada, porque no había nada que encender a mano.

Si hoy en tu empresa hay una máquina, un proceso o un servicio del que se dice "ni lo mires que se cae", no estás cuidando el sistema: estás administrando el miedo a que elija, por su cuenta, el día más caro para fallar. Un servidor que necesita una sesión abierta para funcionar no es un servidor. Es una computadora de escritorio a la que se le pide que nunca se apague.

Caso real de una auditoría de infraestructura para un distribuidor industrial de refacciones importadas en México. Los datos identificables fueron removidos.