Mantenimiento de Moodle

Una plataforma caída se detecta sola: alguien llama. El mantenimiento serio se ocupa de lo otro, de lo que funciona mal sin que nada lo indique. Éstas son reales, encontradas auditando nuestra propia casa:

Un formulario que responde perfectamente y no captó un solo contacto

Un ajuste de configuración hacía que el servidor rechazara cada envío por venir de un origen que no reconocía. El formulario se veía bien, el código estaba bien escrito, todas las comprobaciones automáticas daban verde — porque leían ficheros, y ninguna llegaba a enviar el formulario. Estuvo días sin captar nada. La lección: una comprobación que no hace una petición de verdad no comprueba nada.

Copias que restauran en un estado roto

Uno de nuestros desarrollos guardaba en la copia de seguridad la lista de contenidos de una actividad, pero no el catálogo al que esa lista apuntaba. Restaurando en la misma plataforma funcionaba. Restaurando en otra, las referencias apuntaban a contenidos que no existían — o peor, a otros distintos que casualmente tenían ese identificador. Sin ningún error por medio.

Ajustes que no ejecutan nada

Encontramos un módulo que declaraba soportar el seguimiento de finalización por visita. La casilla aparecía en el formulario, se podía marcar y guardar, y en todo el código no había una sola llamada que la disparase: esa condición no se cumplía nunca. Lo mismo con el trabajo por grupos, anunciado y sin lógica detrás.

Imágenes que funcionan hasta el día que mueves el dominio

Contenido enlazado con la dirección completa del sitio en vez de con una ruta relativa. Funciona mientras el dominio apunte donde apuntaba. El día del cambio, todo lo que no se hubiera copiado se queda en blanco, y ninguna comprobación se entera: el código no ha cambiado, sólo ha dejado de existir lo que había al otro lado.

De estos casos sale un método, y es lo que aplicamos:

• Restaurar una copia de verdad, con calendario. A un entorno limpio y comprobando que la plataforma arranca y los datos están. Una copia sin restaurar es una hipótesis.
• Comprobar con peticiones reales, no leyendo ficheros. Enviar el formulario, pedir la página que redirige, provocar el error 404. Es la única forma de ver lo que sólo existe con el servidor en marcha.
• Vigilar que las tareas programadas corren. Y avisar cuando lleven más de una hora sin hacerlo, en vez de esperar a que se note.
• Medir el rendimiento antes del día grande, no durante.
• Entorno de pruebas y registro de cambios. Para poder responder «qué cambió» sin adivinar.
• Actualizar seguido y en pequeño. Doce actualizaciones pequeñas cuestan mucho menos que una grande aplazada dos años.