Mantenimiento y hosting

El mantenimiento se nota cuando falla. El resto del tiempo consiste en tres cosas aburridas y necesarias: que las copias se puedan restaurar, que las actualizaciones se prueben antes de tocar producción y que haya alguien localizable cuando algo se cae.

Una copia de seguridad que nunca se ha restaurado no es una copia, es una suposición. La prueba es restaurarla en otro sitio y comprobar que el sitio arranca, que la base de datos está completa y que los ficheros subidos siguen ahí. Lo mismo vale para las actualizaciones: el núcleo, los plugins y la versión de PHP se prueban en un entorno aparte, y solo entonces se aplican donde hay clientes mirando.

Del lado de la infraestructura, la mayoría de los sitios de una pyme no necesitan un clúster. Necesitan un servidor bien configurado, certificados que se renueven solos, correo que llegue a la bandeja de entrada y no a spam, y límites de recursos que no revienten el día que entra tráfico de verdad. Cuando el proyecto sí requiere más —despliegues sin corte, varios entornos, escalado— existe la experiencia de operar plataformas de ese tamaño, y se aplica solo si el problema lo justifica.

La parte menos técnica es la que más se echa de menos: saber a quién escribir. Un contrato de mantenimiento sirve para eso, para que la respuesta a "la web no carga" no sea buscar en el correo quién hizo el sitio hace cuatro años.

La otra mitad del trabajo es que publicar un cambio deje de dar miedo. Un entorno de vista previa por cada cambio propuesto, una copia que se restaura de verdad y no solo se genera, y una vuelta atrás ensayada convierten el despliegue en un trámite. Sin eso, lo que ocurre es lo de siempre: se acumulan los cambios porque nadie quiere tocar nada, y cuando por fin se tocan van todos juntos, que es exactamente cuando algo se rompe y nadie sabe cuál de los quince fue.