Estos diez consejos resumen lo que repetimos en la mayoría de auditorías que hacemos. Ninguno es revelación: son aplicación rigurosa de prácticas conocidas que muchos proyectos atajan al lanzar y acaban pagando caro más adelante.
Tabla de contenidos
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, dejar la base preparada para horizontal cuando llegue.
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. Ver guía Windows vs Linux si dudas.
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 reproducir el servidor en limpio sea posible 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.
Sin observabilidad, todo problema es sorpresa. Con observabilidad, casi todo es predecible.
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, en seis meses tienes la factura el doble de lo que esperabas.
10. Documenta antes de necesitarlo
La documentación no es el manual del fabricante: es el conjunto de decisiones tomadas y el porqué. 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 la diferencia entre operar y rezar.
Resumen
Estos diez puntos no son receta mágica: son disciplina aplicada. 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.
Preguntas frecuentes
¿Cuántos servidores necesito separar para un proyecto que empieza?
Si el presupuesto es ajustado, separa al menos la base de datos del servidor web/aplicación: es el punto único de fallo que más duele. El servidor de monitorización y el destino de backup deberían estar fuera (otro proveedor o región) en cuanto el proyecto sea crítico, aunque sean instancias pequeñas.
¿Linux o Windows Server para producción?
Linux para stacks modernos (Node, Python, PHP, Go, Ruby) por coste de licencia, rendimiento y ecosistema de automatización. Windows Server solo si dependes de .NET clásico, SQL Server o Active Directory. La regla es elegir según el stack, no por preferencia, y evitar híbridos si no los justifica una dependencia real.
¿Merece la pena automatizar la configuración si solo tengo uno o dos servidores?
Sí. El valor no está en gestionar muchos servidores, sino en poder reproducir el actual en limpio tras un fallo o una migración. Con uno solo, un servidor «irreproducible» es una caja negra que nadie se atreve a tocar. Ansible o un script idempotente bien documentado ya cubren el caso mínimo.
¿Cada cuánto debo probar la restauración de los backups?
Al menos trimestralmente, y siempre tras un cambio importante de infraestructura. Un backup que nunca se ha restaurado no es un backup, es una suposición: lo habitual es descubrir que falta un volumen, que el dump está corrupto o que el RTO real triplica al esperado solo cuando ya es tarde.
¿Te ayudamos con la operación de tus servidores?
En Elimática auditamos infraestructura, dimensionamos, securizamos y operamos servidores 24/7 para empresas B2B. Con SLA y casos reales con métricas.