Consejos para usar un servidor sin romperlo

Publicado el 2026-09-12 por frfrand

Cinco costumbres que evitan la mayoría de los incidentes en un servidor: un cambio por vez, copias antes de editar, validar antes de recargar, dejar una sesión de rescate y documentar.

La mayoría de las caídas que vi en producción no fueron ataques ni fallas de hardware. Fueron cambios hechos con apuro, sin red de contención.

La buena noticia es que casi todas se evitan con costumbres, no con herramientas caras. Estas son las cinco que más veces me salvaron.

1. Un cambio por vez

Suena obvio hasta que estás con el sitio caído a las once de la noche y tocaste el nginx, el firewall y una variable de entorno en la misma tanda.

Cuando algo se rompe después de tres cambios simultáneos, no tenés un problema: tenés tres sospechosos y ninguna forma de saber cuál fue. Peor todavía, a veces la causa es la interacción entre dos de ellos.

La regla práctica: un cambio, verificar, y recién entonces el siguiente. Parece más lento y termina siendo mucho más rápido.

2. Nunca editar un archivo de configuración sin copiarlo antes

cp /etc/nginx/sites-available/mi-sitio /etc/nginx/sites-available/mi-sitio.bak

Un segundo. Eso es lo que cuesta tener a dónde volver.

Y una variante que vale oro cuando el cambio es grande: copiá el archivo con la fecha en el nombre (mi-sitio.2026-11-01.bak). Cuando dentro de dos meses aparezca un comportamiento raro, vas a poder comparar contra la versión que funcionaba.

Si el servidor te lo permite, mejor todavía: llevá los archivos de configuración en un repositorio git. Un "git diff" contesta en dos segundos la pregunta "¿qué cambió acá?".

3. Validar antes de recargar

Casi todos los servicios serios traen un modo de validación. Se usa poco y es lo que separa un susto de una caída:

nginx -t # revisa la sintaxis de nginx sshd -t # revisa la config de SSH systemd-analyze verify mi.service apachectl configtest

nginx -t te dice el archivo y el número de línea del error. Si en cambio hacés systemctl reload nginx con un error de sintaxis, nginx se niega a arrancar con la configuración nueva y, según el caso, te quedás sin sitio.

El orden correcto es siempre: editar → validar → recargar → comprobar que responde.

4. Dejar una segunda sesión abierta

Esta es la que más veces salva de un desastre real.

Cuando vayas a tocar el firewall, la configuración de SSH o los permisos de tu usuario, abrí una segunda sesión SSH antes y no la cierres. Hacé el cambio en una, y probá entrar desde cero en la otra.

Si te equivocaste y te dejaste afuera, la sesión vieja sigue viva y podés revertir. Si cerraste todo y te trabaste, la única salida es la consola del proveedor, y a veces ni eso.

Regla mental: antes de tocar cualquier cosa que controle tu propio acceso, preguntate "si esto sale mal, ¿cómo vuelvo a entrar?".

5. Anotar lo que hiciste

No hace falta un documento formal. Un archivo NOTAS.md en el servidor, o un canal de Slack, o un comentario en el ticket. Tres líneas:

2026-11-01 · subí worker_connections a 2048 en nginx.conf porque aparecían 'worker_connections are not enough' backup en nginx.conf.2026-11-01.bak

El valor real aparece meses después, cuando alguien (probablemente vos) pregunte por qué ese número está en 2048 y no en el valor por defecto. Sin la nota, la respuesta es "ni idea, no lo toques". Con la nota, se puede decidir.

Lo que tienen en común

Ninguna de las cinco es técnica. Todas son maneras de dejarte una salida.

Un servidor bien administrado no es el que tiene la configuración más ingeniosa: es el aburrido, el que hace lo mismo todos los días y del que nadie se acuerda. Aburrido es el mayor cumplido que le podés hacer a producción.

En ArduMaker parte de esto viene de fábrica: cada comando que se ejecuta sobre un VPS queda registrado con quién lo lanzó y cuándo, así que el "¿qué cambió acá?" tiene respuesta aunque nadie haya tomado notas. Pero las otras cuatro siguen siendo tuyas.