Plan de reversa
Se ejecuta si falla la verificación técnica (ítem 8) o si el protocolo funcional (ítem 10) detecta un fallo de severidad suficiente.
El plan aprobado tiene tres ítems y una duración total de 3 horas.
| Ítem | Actividad | Responsable | Min |
|---|---|---|---|
| 1 | Restaurar el snapshot de los servidores generado en la preparación | Infraestructura | 120 |
| 2 | Pruebas de despliegue | Aplicaciones Colombia Aprende | 30 |
| 3 | Retirar de mantenimiento la aplicación completa en el software de monitoreo | Monitoreo | 30 |
Ítem 1 — Restaurar el snapshot
Restaurar el snapshot de los cuatro servidores tomado en el ítem 3 de la preparación, incluido el de base de datos.
El snapshot se toma antes de tocar nada: precede al reemplazo del árbol de código (paso 1), al
upgrade.php que escribe las versiones en base de datos (paso 2) y a la configuración
administrativa (paso 3). Restaurarlo deja el ambiente exactamente como estaba al abrir la ventana.
Por eso no hacen falta reversas granulares por componente: revertir solo el código sin revertir las versiones registradas en base de datos dejaría el sitio en un estado inconsistente.
Ítem 2 — Pruebas de despliegue
Repetir las comprobaciones de la verificación técnica sobre el estado
restaurado. Las versiones en mdl_config_plugins deben ser las anteriores al despliegue, y las
páginas clave deben cargar sin errores.
Ítem 3 — Retirar de mantenimiento
Retirar de mantenimiento la aplicación completa en el software de monitoreo, para el DNS
https://applicationcert.colombiaaprende.edu.co y los cuatro servidores.
Recursos de reversa disponibles
Además del snapshot, la preparación deja disponibles otros dos recursos que no forman parte del plan de reversa aprobado, pero existen si el snapshot no resultara utilizable:
| Recurso | Origen | Qué revierte |
|---|---|---|
| Snapshot de los servidores | Ítem 3 | Los tres pasos, de una vez — es el plan aprobado |
Respaldo de la base de datos moodle | Ítem 4 | Versiones registradas y configuración administrativa |
| Respaldo del directorio de la aplicación | Ítem 4 | El código de los seis componentes |
Si se recurre a los dos últimos, el orden es base de datos primero, código después, y hay que purgar cachés al terminar.
Criterio de disparo
La decisión de revertir la toma el responsable técnico del cambio. Como referencia:
- Revertir: el sitio no carga,
upgrade.phpdejó componentes a medio registrar, aparecen errores fatales de PHP nuevos, o una feature del protocolo funcional falla de forma que impida el uso normal del campus. - No revertir: un defecto visual o una feature secundaria que no bloquea la operación. Se documenta como hallazgo y se corrige en una entrega posterior.