Un contrato de mantenimiento de servidores serio se mide por lo que garantiza que está ocurriendo cuando nadie mira, más que por las horas que incluye. Importan las tareas preventivas que se ejecutan cada mes sin pedirlas, los tiempos de respuesta comprometidos cuando algo falla y el reparto explícito de responsabilidades sobre parches, copias y seguridad. Lo que el contrato deja fuera pesa lo mismo, porque ahí es donde aparecen las facturas inesperadas y los malentendidos. Aquí desglosamos qué debería estar dentro, qué queda fuera de forma legítima y qué preguntar antes de firmar.
Qué es el mantenimiento de servidores
El mantenimiento de servidores es el conjunto de tareas periódicas que mantienen un servidor actualizado, vigilado, respaldado y con capacidad suficiente para el trabajo que soporta. Incluye la parte preventiva (parches, revisiones, copias, informes) y la correctiva (atender incidencias cuando algo se rompe), y se contrata para que ese trabajo no dependa de que alguien se acuerde.
Se suele usar como sinónimo de administración de servidores, aunque no son exactamente lo mismo. La administración abarca también el diseño y los cambios, quién crea máquinas, cómo se dimensiona la plataforma o cómo se organiza el acceso; el mantenimiento es la operación continua de lo que ya existe. En un contrato de servidores gestionados las dos cosas suelen ir juntas, y ese es el modelo que describe la figura del proveedor de servicios gestionados, o MSP.
Qué incluye un contrato serio
Estos son los bloques que esperamos encontrar en un contrato bien planteado, con independencia de quién lo firme. Si alguno no aparece por escrito, conviene preguntar por qué.
- Inventario y documentación al día. Qué servidores hay, qué corre en cada uno, qué versiones y de qué depende cada servicio. Sin inventario, el mantenimiento se limita a reaccionar cuando algo falla.
- Actualizaciones y parches con ventana pactada. Un calendario de aplicación de parches de sistema operativo y componentes críticos, con ventana acordada, aviso previo y plan de vuelta atrás. Los parches de seguridad urgentes deben tener su propio procedimiento, más rápido y sin esperar al ciclo mensual.
- Monitorización con umbrales y avisos. Disco, memoria, carga, servicios, certificados y copias, con alertas que llegan a alguien que las lee y actúa. La que solo pinta gráficas no evita nada.
- Copias con objetivos declarados. Frecuencia, retención, ubicación y, sobre todo, RTO y RPO acordados por servicio, es decir, cuánto se tarda en volver y cuántos datos se pueden perder como máximo. Con al menos una copia inmutable fuera del alcance de las credenciales del día a día.
- Prueba de restauración periódica. Una restauración real, medida y documentada con la frecuencia que se pacte. Sin esa prueba nadie sabe si esos ficheros sirven para recuperar el servicio.
- Revisión de seguridad y hardening. Endurecimiento de la configuración del sistema con una referencia reconocida, normalmente los CIS Benchmarks, revisión de accesos y usuarios, y comprobación de que lo que se abrió para una prueba hace ocho meses sigue cerrado.
- Capacidad y control del gasto. Seguimiento de crecimiento para anticipar ampliaciones antes de que el disco se llene un viernes. Si hay nube de por medio, revisión de coste bajo criterios FinOps, que suele ser la partida que más se descontrola sin que nadie la mire.
- Gestión de incidencias con tiempos comprometidos. Un canal de entrada, niveles de severidad y tiempos de respuesta distintos según la gravedad. Y quién decide que algo es crítico, que es donde se discute de verdad.
- Informe y revisión periódica. Un documento breve con lo hecho, lo que ha fallado, lo que preocupa y lo que hay que decidir. Es la única forma de que quien paga sepa qué está comprando.
Lo que no incluye, aunque a veces se dé por hecho
Un contrato honesto acota lo que no cubre con la misma claridad con la que enumera lo que sí. Estos son los límites habituales y razonables.
- Los puestos de trabajo y los usuarios. Portátiles, impresoras, teléfonos y las incidencias del día a día de la plantilla son otro servicio, con otra carga de trabajo y otro precio.
- La aplicación de negocio. El ERP, el CRM o el software vertical los mantiene su fabricante. El proveedor de infraestructura mantiene la plataforma sobre la que corren, coordina con el fabricante y aporta los datos técnicos, pero no corrige errores del programa.
- Las licencias y suscripciones de terceros. Sistemas operativos de pago, bases de datos comerciales, antivirus o el consumo de nube se facturan aparte, a coste.
- Los proyectos. Migraciones, cambios de versión mayores o el despliegue de una plataforma nueva son trabajo con presupuesto propio. Meterlos en la cuota acaba recortando lo preventivo para poder atenderlos.
- El hardware y la infraestructura. El servidor, el almacenamiento o la factura del proveedor cloud son coste del cliente. El contrato cubre gestionarlos, no comprarlos.
- Los cambios hechos por otros. Si un tercero entra al servidor y modifica la configuración sin avisar, resolver las consecuencias no debería entrar en la cuota. Es incómodo escribirlo y evita la mitad de los conflictos.
Modelos de contratación y qué riesgo tiene cada uno
Casi todo lo que se ofrece en el mercado encaja en uno de estos cuatro modelos. El precio de partida importa menos que hacia dónde empuja el incentivo de cada parte.
| Modelo | Qué se paga | Cuándo encaja | Riesgo principal |
|---|---|---|---|
| A demanda, sin contrato | Horas cuando algo falla | Un servidor secundario, sin datos críticos | Nadie hace prevención y la disponibilidad depende de la agenda de otro |
| Bolsa de horas | Un paquete de horas mensual | Volumen pequeño y estable, con criterio técnico interno | Las horas se van en incidencias y lo preventivo no se llega a hacer |
| Cuota fija gestionada | Servicio por servidor o por plataforma | Infraestructura de la que depende el negocio | Alcance mal definido, con discusiones sobre qué entra |
| Equipo interno | Una o varias personas en nómina | Plataforma grande y en cambio continuo | Vacaciones, bajas y rotación sin nadie que releve |
A nuestro juicio, para la infraestructura de la que depende la facturación, la cuota fija gestionada es el único modelo cuyo incentivo está alineado con el del cliente, porque al proveedor le interesa que no haya incidencias, mientras que la bolsa de horas le paga precisamente por las que hay. La bolsa de horas tiene sentido como complemento para trabajo puntual, no como forma de sostener servidores críticos. Y el equipo interno funciona bien cuando hay al menos dos personas capaces de cubrirse, no cuando todo depende de un único técnico que también atiende los puestos de trabajo. Sobre cómo comparar candidatos, escribimos aparte una guía para elegir empresa de soporte IT.
Un escenario típico: una bolsa de horas que solo apagaba fuegos
Una empresa de distribución de unas sesenta personas con el ERP en un servidor, la base de datos en otro y un tercero para ficheros y correo interno. Contrato de diez horas al mes con un proveedor local, que se consumían casi enteras atendiendo lo que iba surgiendo. Copias configuradas hacía tres años, con avisos por correo a una dirección que ya no leía nadie, y parches pendientes desde el último cambio de versión porque el reinicio exigía coordinar con el fabricante del ERP y nunca era buen momento.
El aviso llegó por el lado más tonto. Un sábado se llenó el disco del servidor de base de datos por el crecimiento de los ficheros de registro y el ERP dejó de funcionar el lunes a primera hora. Al ir a restaurar, la copia más reciente utilizable tenía nueve días, porque el trabajo nocturno fallaba desde entonces avisando a un buzón muerto. Se recuperó el servicio a media tarde y hubo que reintroducir a mano los albaranes de una semana.
Lo que cambió fue el modelo de servicio. Se pasó a una cuota fija por servidor con inventario documentado, parches en ventana mensual pactada con el fabricante del ERP, monitorización con avisos a un turno con personas de guardia, copias con retención de treinta días y una copia inmutable fuera de la oficina, y una prueba de restauración trimestral con su tiempo medido. La primera prueba tardó cinco horas en levantar el ERP completo, dato que permitió a la dirección decidir con criterio si ese tiempo era aceptable. En la segunda, tras ajustar el procedimiento, bajó a algo menos de dos horas.
Cláusulas que marcan la diferencia
- Niveles de servicio por severidad. Un tiempo de respuesta único para todo no sirve. Debe distinguir entre una parada total, una degradación y una petición ordinaria, y decir qué pasa si no se cumple.
- Horario real de cobertura. Conviene dejar por escrito qué se atiende en horario de oficina y qué queda cubierto 24/7 mediante la opción de guardia para incidencias críticas, que es un servicio adicional y se paga como tal. Contratar vigilancia continua sin nadie que responda de madrugada es pagar por gráficas.
- Propiedad de credenciales, datos y documentación. Las cuentas de administración, las copias y la documentación son del cliente. Debe poder recuperarlas en cualquier momento sin negociar.
- Salida ordenada. Un plazo de preaviso y una entrega documentada al siguiente proveedor. Si el proveedor no quiere poner por escrito cómo se sale, es mala señal.
- Compromiso de prueba de restauración. Con periodicidad escrita y un informe con el tiempo medido. Es la cláusula que más se omite y la que más se echa en falta el día malo.
Por dónde empezar
Antes de pedir presupuestos, responde a tres preguntas sobre lo que tienes hoy. Cuándo se aplicó el último parche de seguridad en cada servidor, cuándo se restauró por última vez una copia completa y cuánto se tardó, y a quién le suena el teléfono si algo se cae un domingo. Si alguna respuesta es no lo sé, ya sabes qué tiene que cubrir el contrato y con qué comparar las ofertas que recibas. Eso es exactamente lo que definimos en nuestro servicio de servidores gestionados, empezando siempre por un diagnóstico de la situación real. Si quieres una lectura honesta de en qué punto estás, cuéntanos tu caso y lo revisamos contigo.
Si lo que quieres es empezar por asegurar lo que ya tienes, aquí explicamos las buenas prácticas de hardening en servidores Linux.