10 consejos prácticos para configurar servidores en producción

21 de octubre de 2025

1. Empieza con arquitectura simple pero escalable

No diseñes para 10 millones de usuarios el día 1. Diseña para los 1.000 que tienes hoy con la posibilidad de pasar a 10.000 sin reescribir. Eso significa separar capas (frontend, app, base de datos), usar servicios gestionados donde sea razonable y dejar la base preparada para escalar en horizontal cuando haga falta.

2. Elige el sistema operativo según el stack

Linux para aplicaciones modernas (Node, Python, Ruby, PHP, Go), Windows Server si dependes de .NET o stack Microsoft. Hibridación si tu aplicación lo justifica. Si dudas, tienes la comparativa entre Windows Server y Linux.

3. Hardening desde el primer arranque

Antes de instalar la aplicación:

Firewall por defecto cerrado, abre solo lo necesario.
SSH solo con clave, deshabilita login por contraseña.
Usuario root con shell deshabilitada para login directo.
Fail2ban o equivalente para frenar fuerza bruta.
Actualizaciones de seguridad automáticas.
SELinux o AppArmor activos (no en permissive).

El servidor mal configurado de origen ya es un servidor comprometido en cuanto se expone a internet.

4. Automatiza la configuración inicial

Ansible, Terraform, Pulumi, scripts shell con idempotencia. Como mínimo, que el servidor se pueda reproducir en limpio siguiendo un procedimiento documentado. Sin esto, el «servidor de producción» se convierte en una caja negra única e irreproducible.

5. Separa servicios críticos

Una sola máquina con la web + la base de datos + el correo + el backup destinatario tiene puntos únicos de fallo en cascada. Separar:

Servidor web/aplicación.
Servidor base de datos.
Servidor de backup (otro proveedor o región).
Servidor de monitorización (no puede caer cuando todo lo demás cae).

Si el presupuesto no llega para todo, separar al menos la base de datos del resto.

6. Monitoriza desde el primer día

Antes que esperar al primer incidente, configura:

Métricas de sistema: CPU, memoria, disco, red.
Métricas de aplicación: latencia p50/p95/p99, tasa de error, throughput.
Métricas de base de datos: queries lentas, conexiones, replicación.
Logs centralizados: agregar en un punto, retención adecuada.
Alertas accionables: solo lo que requiere acción humana. Lo demás es métrica para revisar a posteriori.

7. Planifica backup y recuperación

Backup no es lo mismo que poder restaurar. Antes de necesitarlo:

Define RPO/RTO por tipo de dato.
Aplica regla 3-2-1 (tres copias, dos soportes, una off-site).
Cifra los backups que viajan.
Prueba la restauración periódicamente. Sin prueba, no sabes si funciona.

8. Infraestructura como código

Cualquier cambio en producción que no esté codificado se pierde. Terraform o CloudFormation para recursos cloud, Ansible/Puppet/Chef para configuración del sistema operativo, Helm/Kustomize si usas Kubernetes.

Beneficios reales: rollback rápido, entornos reproducibles, auditoría de quién cambió qué y cuándo, despliegues sin sorpresas.

9. FinOps: vigila el coste desde el día 1

En cloud, el coste se dispara fácilmente. Mínimos:

Tagging consistente (entorno, proyecto, propietario) para imputar coste.
Presupuestos con alerta automática.
Revisión mensual de top costes.
Apagado de entornos no productivos fuera de horario.
Instancias reservadas o Savings Plans para cargas estables.

Sin FinOps activo, la factura acaba muy por encima de lo previsto.

10. Documenta antes de necesitarlo

La documentación recoge las decisiones tomadas y su porqué. Como mínimo:

Diagrama de arquitectura actualizado.
Runbook por incidente típico (qué hacer si X cae, si Y se llena, si Z no responde).
Credenciales en gestor de secretos, no en chats ni archivos sueltos.
Postmortems de cada incidente importante.

Cuando el técnico que sabe cómo funciona todo se va de vacaciones (o de la empresa), la documentación es lo que permite seguir operando.

Resumen

La mayoría de incidentes serios que vemos en auditorías se reducen a no haber hecho dos o tres de estos pasos antes de necesitarlos.

¿Te ayudamos con la operación de tus servidores?

En Elimática auditamos, dimensionamos, protegemos y operamos servidores de empresas B2B, con opción de guardia 24/7 para incidencias críticas. Con SLA y casos reales con métricas.

Servidores gestionados | Diagnóstico gratuito.

Preguntas frecuentes

¿Qué es un servidor de producción?

Es el servidor que da servicio real a los usuarios, frente a los de desarrollo, pruebas o preproducción, donde sí se experimenta. Esa diferencia condiciona todo lo demás, porque en producción no se prueban cambios a mano, se despliega lo que ya se ha validado antes en otro entorno. Un servidor de producción bien planteado se puede reproducir en limpio siguiendo un procedimiento documentado; si nadie sabe cómo se llegó a su configuración actual, es una caja negra y no un servidor de producción.

¿Qué es montar un servidor?

Es bastante más que instalar el sistema operativo y subir la aplicación. Montar un servidor para producción implica decidir la arquitectura separando capas, endurecer el sistema antes de exponerlo, automatizar la configuración para poder reproducirla, dejar la monitorización y las alertas en marcha desde el primer día y tener backup con su restauración probada. Cada uno de esos pasos que se salta al lanzar se acaba pagando después, y casi siempre en el peor momento.

¿Para qué sirve montar un servidor?

Sirve para tener control real sobre dónde viven tus datos y tu aplicación, ajustar los recursos a lo que de verdad consume y no chocar con los límites de una plataforma compartida. Compensa cuando la aplicación necesita configuración a medida, cuando el volumen hace que un servicio compartido se quede corto o salga caro, o cuando hay requisitos de cumplimiento sobre la ubicación de los datos. A cambio asumes la operación, es decir, actualizaciones, seguridad, monitorización y backups, que es justo la parte que se suele subestimar.

¿Cuánto cuesta montar un servidor?

La máquina es la parte pequeña y previsible del coste, ya sea una instancia cloud facturada por uso o hardware propio amortizado a varios años. Lo que decide el presupuesto es la puesta en marcha y la operación posterior, porque un servidor sin monitorización, sin backups probados y sin actualizaciones no es más barato, solo tiene la factura aplazada al primer incidente. Antes de pedir cifras, define qué carga tiene que aguantar, qué RTO y RPO necesitas y quién lo va a operar, y con eso el número sale solo.

¿Cuánto cuesta configurar un servidor?

Depende sobre todo de si la configuración se hace a mano una sola vez o se deja escrita en código. A mano parece más barato el primer día y termina siendo el coste recurrente más caro, porque cada cambio hay que repetirlo, nadie recuerda por qué está algo puesto así y reconstruir la máquina tras un fallo lleva días. Con Ansible, Terraform o un script idempotente bien documentado el trabajo inicial es mayor, pero rehacer el servidor pasa a ser cuestión de minutos y cada cambio queda auditado.

¿Para qué sirve un servidor web?

Es el componente que atiende las peticiones HTTP y entrega la web o la API a quien la solicita, normalmente Nginx o Apache por delante de la aplicación. En producción no debería compartir máquina con la base de datos, porque un pico en una tumba a la otra y conviertes un problema local en un fallo en cascada. Si el presupuesto no llega para separarlo todo, separa al menos la base de datos del servidor web y de la aplicación.

¿Qué hay que configurar en un servidor antes de exponerlo a internet?

Lo mínimo es cortafuegos cerrado por defecto abriendo solo lo necesario, acceso remoto únicamente con clave y sin contraseña, sin inicio de sesión directo de root, bloqueo automático de intentos de fuerza bruta, actualizaciones de seguridad automáticas y SELinux o AppArmor en modo activo, no en permissive. Todo eso va antes de instalar la aplicación, nunca después. Un servidor mal configurado de origen está comprometido en cuanto se expone.

¿Cada cuánto hay que probar la restauración de los backups?

Al menos una vez por trimestre y siempre después de un cambio importante de infraestructura. Un backup que nunca se ha restaurado es una suposición, no una copia de seguridad, y lo habitual es descubrir que falta un volumen, que el volcado está corrupto o que el tiempo real de recuperación triplica al previsto justo cuando ya no hay margen. Aplica la regla 3-2-1, tres copias, dos soportes y una fuera de la ubicación principal, y cifra las que salen de casa.