Soporte y mantenimiento Drupal: qué debe revisarse cada mes

En corto: un mes de soporte y mantenimiento Drupal debe demostrar cinco cosas, no solo reportarlas. Que cada aviso de seguridad que toca su sitio se evaluó y se atendió. Que las actualizaciones salieron a tiempo y probadas. Que cada despliegue cambió de verdad el sitio en producción. Que se restauró un respaldo, no solo que se sacó. Y que usted recibió todo eso por escrito. Un tablero en verde, por sí solo, no demuestra ninguna. Abajo va cada revisión, con lo que encontró en nuestros propios sitios.

¿Por qué no basta con un tablero en verde?

Porque un tablero dice lo que una herramienta cree, y las herramientas se equivocan en silencio. Dos casos de nuestros propios sitios:

• Un pipeline que no publicó nada durante un mes. Uno de nuestros sitios, Zero-Shot Games, sirvió una imagen vieja durante un mes porque su paso de despliegue estaba escrito para advertir, y no para fallar, cuando faltaba un secreto. Todas las ejecuciones salieron en verde. Lo contamos en su página.
• Una purga de caché que dijo "éxito" y no borró nada. El 20 de octubre de 2026, la API de Cloudflare respondió "success": true a una purga en otro de nuestros sitios, y la página siguió en la caché, igual de vieja. La regla de caché de ese sitio solo cubría peticiones GET y HEAD, y purgar una sola dirección es una petición PURGE. Desde entonces, una purga se comprueba pidiendo otra vez la página y leyendo sus encabezados de caché.

Los dos casos aparecieron por mirar el resultado y no el reporte. Para eso sirve un mes de mantenimiento.

¿Se evaluaron los avisos de seguridad del mes contra su sitio?

El equipo de seguridad de Drupal publica sus avisos en drupal.org/security. Los módulos contribuidos tienen ventana de publicación todos los miércoles, y el núcleo un miércoles al mes, casi siempre el tercero, entre las 11:00 y las 17:00 hora de Colombia (16:00 a 22:00 UTC). Un problema altamente crítico puede salir por fuera de esa ventana.

Evaluar es preguntarse, aviso por aviso, si el sitio usa ese módulo en una versión afectada. Cada aviso recibe una de tres respuestas, por escrito: aplicado; mitigado mientras se puede aplicar; o no afecta, y por qué. "Aplicado" merece su propia definición, y la damos en qué debería significar "aplicado". El mes también debe cubrir los avisos que Drupal no publica: los del propio PHP y los de las librerías de Composer que hay debajo de Drupal.

¿Las actualizaciones salieron a tiempo, y se probaron antes?

En nuestros sitios, el calendario vive en el código y no en la memoria de alguien:

• En cada cambio y cada lunes, un composer audit revisa las dependencias de producción. En un cambio, un aviso conocido frena la construcción.
• Cada lunes llega un pull request con lo que nuestra plantilla compartida corrigió para todos los sitios. Antes de proponerse, pasa la auditoría y las pruebas sobre una instalación limpia.
• Cada lunes, un escaneo base de OWASP ZAP lee el sitio en producción. Es pasivo: lee páginas y no ataca. Corrió por primera vez el 26 de octubre de 2026.

Esa lista trae dos lecciones. La primera: el escaneo de ZAP nunca marca su ejecución como fallida, así que solo sirve si una persona lee el informe, y eso se hace en la nota del mes. La segunda: un calendario solo ayuda si lo que actualiza sigue recibiendo actualizaciones. La base PHP 8.3 de nuestra imagen se había quedado en PHP 8.3.29 desde enero de 2026, así que reconstruirla no cambiaba nada. Cuando PHP corrigió dos fallas críticas el 21 de octubre de 2026, pasamos la imagen a PHP 8.4 el 26 de octubre.

Una revisión más toma un minuto: ¿los avisos de actualización del propio Drupal le llegan a alguien? El 20 de octubre de 2026 encontramos cuatro de nuestros sitios enviándolos a una dirección de relleno. No le llegaban a nadie. Ahora cada sitio toma esa dirección de la configuración de su servidor.

¿Cada despliegue llegó de verdad al sitio en producción?

Cada control de un pipeline demuestra una cosa, y no la siguiente. En nuestros sitios:

• la auditoría de dependencias demuestra que nada de lo publicado tiene un aviso conocido;
• la construcción de la imagen demuestra que el código se instala;
• el despliegue demuestra que corre una imagen nueva y que drush deploy se ejecutó;
• el control de salud demuestra que la página de inicio responde HTTP 200, con al menos 5.000 bytes y sin errores fatales de PHP.

Ninguno demuestra que el cambio que usted pidió esté en la página. Por eso, un mes de mantenimiento hace tres cosas más:

• Lee qué pasos de cada ejecución corrieron de verdad, y no el color de la ejecución. Un despliegue que se saltó puede dejar la ejecución en verde.
• Abre la página que cambió, en producción.
• Lee los encabezados de caché después de una purga, cuando hay una caché delante.

Un cambio que agrega o quita módulos se ensaya antes en una copia llenada desde producción. Después, su configuración no debe mostrar diferencias.

¿Se restauró un respaldo, o solo se sacó?

Un respaldo que nadie ha restaurado es un rumor. El 20 de agosto de 2026 restauramos el respaldo nocturno de uno de nuestros sitios, y eso mostró que ninguno de los respaldos sacados hasta entonces servía. La importación terminó limpia, el blog volvió vacío y no hubo ningún error: al respaldo le faltaban las tablas de revisiones que Drupal necesita para cargar el contenido. Ese mismo día se corrigió. El 18 de septiembre de 2026, el primer ensayo completo restauró todo el servidor desde una copia, con cada base de datos cargada y los conteos de contenido iguales a los de producción.

Nuestros sitios respaldan la base de datos y los archivos cada noche y guardan una copia fuera del servidor, así que lo máximo que se arriesga es un día de contenido. Nuestro propio procedimiento pide una restauración completa cada mes. Lo que cuenta es que el contenido cargue desde la copia restaurada, no que el registro del respaldo diga "listo".

¿Qué debe pedirle a su proveedor de soporte?

Al final de cada mes, una nota corta y por escrito con:

• qué cambió (actualizaciones, correcciones, despliegues), cada cosa con su commit;
• qué avisos se evaluaron, y qué se decidió con cada uno;
• qué despliegues se comprobaron en producción, y cómo;
• qué respaldo se restauró, y qué se revisó;
• qué encontró el escaneo;
• qué viene el mes siguiente, por ejemplo el fin de soporte de Drupal 10 el 9 de diciembre de 2026.

Esa nota también es documentación. Quien cuide el sitio después de nosotros la puede leer sin tener que preguntarnos.

Varios proveedores de Drupal, en Colombia y afuera, publican planes mensuales de soporte por horas incluidas y tiempos de respuesta. Al compararlos, compare qué revisa y qué demuestra cada plan, no solo las horas.

¿Qué no prometemos?

Hoy el ingeniero es nuestro fundador. Por eso el soporte va en horario hábil de Colombia (UTC-5), el mismo huso horario suyo si está aquí, y sin guardias 24/7. Cuando un aviso toca su sitio, empezamos a atenderlo el mismo día hábil. Eso es una condición del servicio, no un récord medido. El alojamiento sigue siendo suyo. Los planes se cotizan después de leer su sitio. El único precio fijo es una hora con el fundador: 75 dólares.

Si quiere saber qué revisa hoy el mes de su sitio, escríbanos o pregúntele al concierge en la página de inicio. Nuestra oferta explica cómo recibimos un sitio.