Auditoría de la plataforma Moodle
Una plataforma que va lenta, exámenes que se cuelgan y un equipo de TI que lleva meses investigando. En la mayoría de los casos con los que nos encontramos, el problema no es Moodle. Eso es lo que hemos construido en torno a ello y que nadie ha examinado aún con detenimiento.
Una auditoría de Moodle realizada por un equipo que conoce a fondo la plataforma es algo muy distinto a una revisión de la configuración. Se trata de un repaso de todo lo que se ha acumulado, con una jerarquización clara de lo que hay que tratar con prioridad.
Lo que se examina
Una auditoría de Pimenko abarca varias dimensiones complementarias.
-
La infraestructura y la arquitectura
Servidor web, configuración de PHP, base de datos, sistema de caché, gestión de sesiones, almacenamiento de archivos. Son estas capas las que determinan lo que ocurre bajo carga y, a menudo, es ahí donde se encuentran las verdaderas causas de los problemas en la producción.
-
La propia plataforma Moodle
Versión instalada y retraso respecto a la versión estable, complementos activos y su estado de mantenimiento, base de preguntas, esquema de la base de datos, tareas programadas (cron) y parámetros de seguridad. Una plataforma puede acumular silenciosamente una deuda técnica considerable sin que nadie se dé cuenta.
-
La organización en torno a la plataforma
Gobernanza, procesos de integración de sistemas de información, gestión de funciones y derechos, política de archivo de cursos, procedimientos de actualización. Los problemas técnicos suelen tener casi siempre una dimensión organizativa subyacente.
Lo que se encuentra: algunos ejemplos
Cada auditoría es diferente. Lo que sigue no es una lista de problemas generales, sino situaciones reales extraídas de misiones recientes para ilustrar el tipo de cuestiones que no se aprecian desde la interfaz de Moodle.
-
Los exámenes que fallan, y Moodle no es el culpable
En una gran escuela a la que prestamos apoyo, los registros muestran una secuencia muy concreta: 120 workers de PHP se saturaron en menos de 6 segundos durante un pico de exámenes simultáneos. Sin embargo, el equipo cuenta con 64 GB de RAM. La causa real: sin un sistema de caché, cada proceso bloquea su archivo de sesión y consulta la base de datos sin utilizar la caché. La solución: implementar un sistema de caché eficaz que cambie radicalmente el comportamiento bajo carga.
Este caso ilustra algo que se suele repetir: los fallos que se producen durante los exámenes casi siempre tienen una causa arquitectónica concreta. -
El banco de preguntas invisible
En otra misión, descubrimos 22 millones de entradas en la base de datos de preguntas. El centro no lo sabía. La causa: un error documentado de Moodle 4.5 que duplica de forma silenciosa las preguntas cada vez que se duplica un curso. Cada ciclo de preparación para el inicio del curso escolar suma millones. En un proyecto similar, redujimos una base de datos análoga de 2,5 millones a 400 000 entradas: el rendimiento de los cuestionarios volvió a la normalidad de inmediato.
-
La tarea cron que lo bloquea todo
En otra plataforma, una tarea de sincronización de inscripciones se ejecuta cada noche durante varias horas y bloquea el resto de tareas programadas. El motivo: la plataforma alberga cursos de una década que Moodle recorre íntegramente en cada ciclo. Es imprescindible contar con una política de archivo clara (solo lectura, exportación, eliminación progresiva) y con la implantación de una infraestructura capaz de gestionar correctamente las tareas programadas.
Estos tres ejemplos tienen algo en común: ninguno de ellos era visible desde la interfaz de Moodle. Los equipos internos no habían identificado a ninguno de ellos. Y en los tres casos, la resolución fue rápida una vez establecido el diagnóstico.
No se trata de casos excepcionales. Se trata de situaciones con las que nos encontramos habitualmente, aunque de formas diferentes según las plataformas.
Nuestro enfoque
Una auditoría de Pimenko se lleva a cabo en varias fases.
Análisis
Acceso a la administración de Moodle, a los registros del servidor (PHP, cron, base de datos) y a la configuración técnica. Analizamos la volumetría real de la plataforma —usuarios, cursos, complementos, tareas programadas y esquema de la base de datos— y la comparamos con los parámetros de referencia.
Entrevistas
Complementamos el análisis técnico con el intercambio de opiniones con los equipos de TI y pedagógicos. Los problemas de rendimiento suelen tener casi siempre una dimensión organizativa que los registros por sí solos no revelan.
Restitución
Un informe escrito, estructurado por orden de prioridad e impacto. Cada recomendación va acompañada de una estimación del grado de dificultad de su aplicación. Sabe exactamente qué hacer primero y por qué.
Esta presentación es objeto de reuniones con su equipo.
¿En qué casos resulta útil una auditoría?
La auditoría no se limita a las plataformas que presentan problemas declarados. Resulta especialmente útil en las siguientes situaciones.
-
Antes de un aumento significativo del volumen de trabajo (expansión de sus actividades de formación en línea, inicio del curso escolar, campaña nacional), para comprobar que la plataforma está preparada.
-
Antes de realizar una migración a una nueva versión principal de Moodle, con el fin de identificar la deuda técnica que debe abordarse con antelación.
-
Al hacerse cargo de una plataforma desarrollada por otro proveedor, para comprender qué se ha hecho y evaluar los riesgos.
-
Cuando el rendimiento se deteriora progresivamente sin causa aparente. Y tras un incidente en la producción, para comprender su causa real y evitar que se repita.
Si tiene alguna duda sobre el estado de su plataforma o un proyecto que requiera que esta sea compatible con ella, póngase en contacto con nosotros.
Hablemos de una auditoría de Moodle¿Necesita una auditoría?
Si tiene alguna duda sobre el estado de su plataforma o un proyecto que requiera que esta sea compatible con: póngase en contacto con nosotros.