Qué incluye el mantenimiento de un servidor

Lo que no se ve hasta que falla

Casi todo el mantenimiento sirve para que no pase nada, y por eso es lo primero que se recorta. Si llevas medio año sin sustos, es fácil pensar que el servidor se cuida solo. Suele ser al revés: lleva medio año tranquilo porque alguien está detrás.

Los problemas serios rara vez llegan por un ataque espectacular. Llegan porque un disco se llenó de registros y el servicio dejó de poder escribir, porque un certificado caducó sin que nadie se diera cuenta, o porque un parche publicado hace tres meses sigue sin aplicar y alguien lo encontró antes que tú. Nada de eso avisa con antelación si no hay quien mire.

Mantener un servidor es, en buena medida, adelantarse a esa lista de cosas aburridas antes de que se conviertan en una llamada a deshoras.

La prueba de un backup es restaurarlo

Todo el mundo hace copias. El problema aparece el día que hay que usarlas. Es entonces cuando se descubre que el volcado llevaba semanas truncándose sin avisar, que la tarea programada fallaba en silencio, o que la clave para descifrar la copia estaba en la misma máquina que acaba de morir.

Nadie tiene un problema de copias. Todo el mundo tiene un problema de restauración.

Un mantenimiento que se toma esto en serio hace tres cosas. Automatiza las copias para que no dependan de que alguien se acuerde. Guarda al menos una fuera del servidor, en otro sitio, porque una copia que vive en el mismo disco no protege de que ese disco falle. Y restaura una de vez en cuando en un entorno aparte: es lo único que confirma que los datos están completos y que el proceso funciona de principio a fin.

Actualizar sin sustos

El software cambia por dos razones muy distintas, y conviene tratarlas distinto. Están los parches de seguridad, que tapan agujeros ya conocidos y públicos: esos, cuanto antes, porque el reloj corre a favor de quien busca máquinas sin actualizar. Y están las versiones nuevas con funciones o cambios grandes, que pueden romper lo que ya funcionaba y piden más cuidado.

La forma sensata de aplicar un cambio con riesgo es probarlo antes en una copia del entorno, tener una instantánea o un punto de retorno por si algo sale mal, y aplicarlo cuando haya menos gente usando el servicio. Si un componente es delicado, a veces la mejor decisión es fijar una versión estable y no perseguir la última: ir un punto por detrás y funcionando gana a estar al día y caído.

Hay un caso que se olvida a menudo: las actualizaciones del núcleo del sistema solo entran del todo al reiniciar. Dejar el reinicio en automático puede tumbar el servicio sin previo aviso; dejarlo pendiente para siempre significa arrastrar un fallo ya parcheado. El mantenimiento decide y programa ese reinicio, no lo deja al azar.

Quién tiene llave

Con el tiempo, la lista de quién puede entrar en un servidor engorda sola. Se añade la clave de un colaborador para un trabajo puntual, entra un compañero para una urgencia, se abre un acceso «temporal» que nadie vuelve a cerrar. Meses después, media docena de llaves siguen ahí y nadie recuerda de quién son.

Revisar los accesos es parte del mantenimiento: quién puede entrar, con qué permisos y por qué sigue pudiendo. Lo razonable es entrar por clave y no por contraseña, tener el acceso directo de root desactivado, y quitar cada llave en cuanto deja de hacer falta, en lugar de guardarla «por si acaso».

El firewall es la otra mitad. La regla que envejece bien es simple: abierto solo lo que tiene que estar abierto, cerrado todo lo demás. Cada puerto expuesto es una puerta que alguien intentará; si un servicio solo lo usas tú, no tiene por qué escuchar a todo internet. A eso se suma un bloqueo automático de las direcciones que insisten con intentos de acceso fallidos, para que la fuerza bruta se tope con un muro antes de acertar.

Cada tarea tiene su ritmo

El mantenimiento no es una revisión anual que se hace y se olvida. Es un conjunto de tareas pequeñas, cada una con su frecuencia: algunas piden atención a diario, para otras basta una vez al mes. Esta es la forma de una lista de mantenimiento razonable — cada casilla vacía es algo por verificar, no algo ya resuelto:

• Diario Vigilancia con avisos — que salte una alerta cuando el servidor deja de responder, en vez de enterarte por un usuario molesto.
• Diario Espacio en disco — un disco al 95 % es una caída con fecha; el aviso tiene que llegar mucho antes de llegar ahí.
• Semanal Revisión de logs — leer los registros buscando errores que se repiten, accesos que no cuadran y picos raros que aún no han dado la cara.
• Semanal Parches de seguridad — aplicar las actualizaciones críticas del sistema sin dejar que se amontonen.
• Mensual Restauración de prueba — que la copia exista no basta; hay que restaurarla y comprobar que los datos están enteros.
• Mensual Accesos y firewall — repasar quién puede entrar y por qué puertos, y retirar llaves y reglas que ya no pintan nada.
• Trimestral Rotación de credenciales — cambiar contraseñas de servicio, tokens y claves que llevan demasiado tiempo sin tocarse.
• Trimestral Simulacro de respuesta — repasar el plan de «se ha caído» en frío, para que el día que toque nadie improvise.

Las frecuencias no son sagradas: un servicio con mucho tráfico querrá mirar los logs a diario, y uno tranquilo aguanta con menos. Lo que no cambia es que cada tarea tenga dueño y calendario. Lo que no está agendado no se hace.

Ver venir los problemas

Un buen mantenimiento se entera de las cosas antes que los usuarios. Eso significa medir de forma continua unos pocos números que cuentan casi toda la historia: cuánta CPU y memoria se están usando, cuánto disco queda libre, cuánto tarda el servicio en responder y si sigue vivo. Cuando alguno se sale de lo normal, salta un aviso a una persona, no a un panel que nadie mira.

El caso de manual es el disco. Se llena poco a poco, sin ruido, hasta que una madrugada no cabe un registro más y el servicio se cae en cadena. Con un aviso al 80 % eso es un recordatorio tranquilo un martes por la tarde; sin él, es una caída a las tres de la mañana. Lo mismo vale para los certificados: caducan en una fecha conocida, así que no hay excusa para que pillen a nadie por sorpresa.

Los logs son el otro sistema de alarma temprana, y el más infravalorado. Un goteo de intentos de acceso desde el otro lado del mundo, un error que empieza a repetirse, una tarea programada que lleva días fallando en silencio: todo eso está escrito ahí antes de convertirse en un problema visible. Mirarlos con regularidad es lo que convierte una sorpresa en un aviso a tiempo.

El plan para el día malo

Por bien cuidado que esté, un servidor puede caerse: un fallo de hardware, un corte del proveedor, un error humano. La diferencia entre un susto de diez minutos y un día perdido no es la suerte, sino tener pensado de antemano qué se hace.

Ese plan responde a preguntas concretas antes de que hagan falta. ¿Cada cuánto se hace copia, y por tanto cuántos datos se pueden perder como mucho? ¿Dónde está la copia de fuera y cómo se restaura, paso a paso? ¿Quién se entera de que algo va mal y quién decide qué hacer? Cuando esas respuestas están escritas, la recuperación es seguir un guion; cuando no, es improvisar bajo presión, que es justo cuando se cometen los errores caros.

Aquí es donde el trabajo aburrido de los meses anteriores paga la factura. La copia de fuera existe y se ha restaurado antes, así que funciona. El procedimiento está documentado, así que no depende de que una persona concreta conteste el teléfono. Volver a estar en pie pasa a ser cuestión de tiempo — y de poco tiempo.

Cómo saber si el tuyo está bien cuidado

No hace falta ser técnico para intuir si un servidor está atendido. Un par de preguntas suelen bastar. ¿Cuándo se restauró una copia por última vez para comprobar que sirve? ¿Quién recibe el aviso si el servicio se cae de madrugada, y cuánto tarda en reaccionar? ¿Hay una lista de quién tiene acceso, y se ha repasado este año? Si esas preguntas se contestan con un silencio incómodo, el servidor no está roto —todavía—, pero funciona de prestado.

La parte buena es que ponerse al día casi nunca es empezar de cero. Suele ser ordenar lo que ya hay: automatizar las copias que se hacían a mano, poner los avisos que faltan, cerrar los accesos viejos y escribir el plan que hasta ahora vivía en la cabeza de alguien.