10 configuraciones de servidor que debes revisar al final del año
(para evitar sorpresas inesperadas)
“¿Es realmente necesario revisar algo especial por fin de año?” La respuesta directa es sí.
El año no cambia la naturaleza del servidor, pero las personas sí.
- Menos personal operativo por vacaciones y días festivos
- Patrones de tráfico alterados
- Menor vigilancia
Por eso el fin de año suele ser la época con mayor riesgo de incidentes. Este artículo no es una lista de tareas compulsiva, sino un conjunto realista de verificaciones para que nada suceda durante las vacaciones.
1. Uso del disco y velocidad de crecimiento de los logs
Los logs no disminuyen en fin de año.
En particular, revisa:
- Uso de
/var/log - Configuración de rotación de logs de la aplicación
- Tamaño de logs de contenedores Docker (¿crecimiento infinito de logs JSON?)
Un disco lleno puede detenerse sin previo aviso. Lo que antes parecía tolerable puede convertirse en un fallo durante las vacaciones.
2. No basta con tener backups, hay que poder restaurarlos
Lo más importante no es que exista un backup, sino que se pueda recuperar.
“¿Realmente puedo restaurar con este backup?”
Antes de fin de año, haz al menos una prueba:
- Verifica que exista el backup más reciente
- Comprueba que el archivo comprimido no esté dañado
- Restaura en un entorno de prueba
Evita que el primer día del año sea “¡el backup estaba corrupto!”.
3. Fecha de expiración de certificados SSL/TLS
Los certificados suelen caducar justo antes o después de Año Nuevo.
- Confirma que la renovación automática de Let’s Encrypt esté funcionando
- Asegúrate de que
cronosystemd timerno estén desactivados - Revisa los logs de renovación recientes por errores
Pensar que la renovación automática es suficiente es el principal disparador de fallos en fin de año.
4. Reglas de firewall y configuraciones “temporales”
Con un año de operación, se acumulan:
- Puertos abiertos para pruebas
- IPs abiertas por breves necesidades
- Puertos de servicios que ya no se usan
Estas configuraciones temporales pueden convertirse en brechas de seguridad que nadie recuerda. Fin de año es el momento ideal para limpiarlas.
5. Métodos de acceso SSH y gestión de claves
Los intentos de intrusión durante las vacaciones suelen detectarse tarde.
Por eso, es prudente mantener SSH lo más seguro posible:
- Desactiva el login por contraseña
- Elimina claves SSH no usadas
- Quita claves de ex empleados o contratistas
- Asegúrate de que las cuentas de administrador tengan el mínimo de privilegios
El optimismo de “nadie se interesará en nuestro servidor” suele ser una falacia.
6. Fallos silenciosos de cron/schedulers
cron, systemd timer y otros schedulers pueden fallar sin avisar.
- Revisa logs recientes por errores
- Busca tareas que hayan fallado por mucho tiempo
- Elimina tareas que ya no son necesarias
Un scheduler roto en fin de año seguirá roto en el nuevo año.
7. Métricas de uso basadas en picos, no en promedios
El tráfico de fin de año es más volátil que el habitual.
- Aumentos de tráfico en periodos específicos
- Accesos anómalos de bots/crawlers
- Patrones de vacaciones por país
Por eso la monitorización debe enfocarse en los picos:
- Picos de CPU y memoria
- Conexiones a la BD, longitud de colas
- Usuarios concurrentes, sesiones
Decir “normal” durante fin de año no es suficiente.
8. Estado de los servicios dependientes
Un servidor puede estar sano, pero si un servicio dependiente falla, todo se detiene.
Ejemplos:
- Redis / Memcached
- Brokers de mensajes (Kafka, RabbitMQ, SQS, etc.)
- APIs externas (pago, autenticación, notificaciones)
- Almacenamiento de archivos/imagenes
Durante fin de año, estos servicios también suelen recibir despliegues y tareas periódicas. Verifica sus páginas de estado y canales de alerta.
9. Prueba de que las alertas de error llegan realmente
Tener un sistema de alertas no garantiza que las alertas lleguen.
- Genera un error artificialmente
- Confirma que el correo/Slack/Webhook llegue
- Asegúrate de que los filtros de severidad no bloqueen la alerta
El mayor problema de los incidentes de fin de año suele ser que nadie se dio cuenta.
“Nadie supo que había un fallo.”
10. Documento de referencia: “¿Dónde empezar cuando algo falla?”
El último punto es un documento, no una configuración.
- Lista de servicios principales
- Métodos de acceso a servidores/contenedores
- Ubicación de logs (nginx, app, BD, colas, etc.)
- Procedimientos de reinicio/rollback
- Secuencia de respuesta de emergencia
Tener este documento cambia la respuesta a un fallo de modo difícil → modo normal.
Checklist de revisión de servidores de fin de año
Para que puedas revisarlo fácilmente, aquí tienes una tabla resumida.
| Ítem | Qué revisar | Ejemplo de verificación | Estado recomendado |
|---|---|---|---|
| Uso de disco | Espacio libre en logs/datos | df -h, tamaño de /var/log |
>20 % libre |
| Rotación de logs | Logrotate activo, logs Docker | Configuración de logrotate, logs Docker |
Rotación periódica |
| Backup/restore | Backup reciente y restaurable | Restaurar en entorno de prueba | Éxito en 24‑48 h |
| Certificados SSL | Próxima expiración, renovación automática | certbot renew --dry-run |
>30 días de margen |
| Firewall/puertos | Puertos abiertos innecesarios | ufw status, iptables -L |
Sólo puertos esenciales |
| Acceso SSH | Login por clave, claves limpias | sshd_config, lista de claves |
Sólo claves autorizadas |
| Scheduler | Tareas sin errores recientes | Logs de cron/systemd |
Sin errores recientes |
| Picos de recursos | CPU, memoria, conexiones | Dashboard, htop |
Capacidad suficiente en picos |
| Servicios dependientes | Estado y alertas | Páginas de estado, logs | Alertas activas |
Con esto, deberías poder descansar durante las vacaciones con la tranquilidad de que tu servidor está preparado.
No hay comentarios.