La plataforma se cae en los picos previsibles
La matrícula, el examen o el cierre de un plan concentran la carga en unas horas concretas y el sistema no está dimensionado para ellas.
Preparo la plataforma para la convocatoria y compruebo la recuperación antes de necesitarla.
La formación tiene picos previsibles: una convocatoria, un examen, el cierre de un plan anual. Preparo la infraestructura para esos picos y para los imprevistos, con una recuperación probada, un coste explicable y un equipo capaz de operar el sistema sin depender de una sola persona.
Dónde se concentra la complejidad
La infraestructura se vuelve un asunto de dirección cuando el servicio ya no aguanta lo prometido.
Una caída en la semana de matrícula, un examen que no carga o una factura de nube que sube sin explicación dejan de ser incidencias técnicas: pasan a ser un problema de confianza con quien ha comprado la formación.
El último incidente no se puede reconstruir
Faltan trazas, métricas y registros suficientes para explicar el fallo. Mientras no se instrumente el sistema, será más difícil diagnosticar un incidente similar si se repite.
El coste de la nube sube sin explicación
La factura crece cada mes y no hay forma de atribuir el gasto a un servicio, a un entorno o a una decisión concreta.
Cada despliegue es un acontecimiento
Publicar exige una ventana, varias personas y una noche. La vuelta atrás, si existe, no se ha ejecutado nunca.
Hay copia de seguridad, pero no se ha restaurado
Existe el respaldo y no existe la prueba: ni tiempo de recuperación acordado, ni pérdida de datos admisible, ni ensayo.
La seguridad aparece al final
Las revisiones llegan justo antes de salir a producción, cuando corregir ya es caro y el calendario no admite cambios.
Responsabilidades concretas
Respondo de que la disponibilidad y la recuperación se comprueben y de que el coste se mida, se atribuya y pueda explicarse.
Acuerdo con el negocio cuánta caída y cuánta pérdida de datos son admisibles y qué rango de coste se acepta. Comparo la capacidad base y de pico, las licencias, la operación humana y la recuperación; cualquier desviación debe poder explicarse por la carga, el servicio, el entorno o una decisión concreta. A partir de ahí decido la redundancia, el dimensionado, la automatización de los entornos y la forma de desplegar y volver atrás.
Alta disponibilidad, donde hace falta
El diseño no es uniforme: un catálogo puede admitir unos minutos de interrupción, mientras que un examen en curso suele exigir un objetivo mucho más estricto. Acuerdo esas tolerancias con el negocio y aplico réplica, conmutación o una recuperación más sencilla según el impacto comprobado de cada servicio. Redundar todo por igual sale caro y no protege lo que importa.
Escalado de lo que escala y de lo que no
La base de datos no suele escalar con la misma sencillez que la capa web. Antes de añadir nodos, reviso consultas, índices y caché; cuando las medidas lo justifican, valoro réplicas de lectura o un clúster y su coste operativo. Un pico de matrícula se prepara con capacidad reservada y con colas para lo que puede esperar.
Entornos reproducibles en código
Los entornos se describen en código versionado y pueden reconstruirse de forma comparable, con las diferencias inevitables documentadas. Cuando preproducción y producción divergen, las pruebas pierden capacidad para anticipar lo que ocurrirá en producción. Esa divergencia suele empezar en un cambio manual que alguien hizo con prisa y no anotó.
Despliegue con interrupción acotada y respuesta probada
Publico cambios pequeños y defino para cada uno si admite una vuelta atrás automática, una corrección hacia delante o un procedimiento compensatorio; las migraciones de datos se prueban por separado. La automatización de la construcción y las pruebas hace viable ese ritmo.
Seguridad dentro del ciclo, no al final
Análisis de dependencias, gestión de secretos, endurecimiento de la configuración y revisión forman parte de cada integración. Una plataforma educativa guarda datos personales de menores en muchos casos, así que el control de accesos y el registro de quién hizo qué no son un extra.
Observabilidad con responsables y coste bajo control
Métricas, trazas y registros correlacionados, con alertas que alguien atiende y no silencia. El gasto se atribuye a servicios y entornos, porque una factura que no se puede descomponer termina recortándose por donde no debe.
Casos de uso
Casos de infraestructura, continuidad y coste
Los relatos siguientes son casos profesionales sin identificar al cliente. Las cifras proceden de informes internos que esta página no incorpora: explican el método aplicado, pero no constituyen evidencia independiente, un valor de referencia ni una garantía para otra plataforma.
Las alertas vigilaban servidores, pero no seguían ningún recorrido completo
Trabajé en una plataforma crítica, con funcionamiento continuo y varios equipos de soporte, donde los usuarios solían detectar los problemas antes que el equipo técnico. En la línea base interna, la detección tardaba entre 60 y 90 minutos, la resolución media rondaba las cuatro horas y muchas alertas no conducían a ninguna acción útil. Parecía que faltaban herramientas de monitorización. Descarté esa hipótesis porque ya había métricas y registros suficientes. Detecté el problema real: no existía una forma de correlacionar una petición web con el plugin, la tarea programada, la base de datos y la integración implicados. Tampoco encontré objetivos de servicio ni pruebas sintéticas para los recorridos críticos. Implanté indicadores orientados al servicio, trazabilidad entre componentes, pruebas sintéticas y procedimientos de respuesta. Las mediciones internas posteriores mostraron una reducción clara de los tiempos de detección y resolución; no publico aquí la serie necesaria para reproducir la comparación.
Cada nodo nuevo multiplicaba las comprobaciones sobre el sistema de ficheros compartido
En una plataforma global de formación corporativa alojada en AWS, ampliar de 4 a 32 nodos empeoraba el rendimiento: con más de ocho nodos activos, el tiempo hasta el primer byte pasaba de 200 ms a más de 4,5 segundos. Medí el tiempo de espera de las operaciones de entrada y salida en los nodos de aplicación, las operaciones por segundo en el sistema de ficheros compartido y las llamadas al sistema sobre el directorio de datos de Moodle. Descarté la falta de potencia de las instancias y la saturación del balanceador porque la espera crecía al acceder a los metadatos del almacenamiento, no en la CPU ni en la distribución del tráfico. La causa era la contención de metadatos en un sistema de archivos compartido que exponía una interfaz POSIX y coordinaba entre nodos las operaciones y los metadatos. Moví los ficheros de gran tamaño al almacenamiento de objetos mediante el plugin de la comunidad, pasé las cachés locales al disco efímero de cada instancia y, donde aún necesitaba el sistema compartido, reservé capacidad de transferencia y activé una caché de ficheros en memoria. La prueba posterior confirmó una gran reducción del tiempo hasta el primer byte y del coste del almacenamiento compartido; las cifras detalladas pertenecen al informe interno del caso.
El acuerdo prometía recuperar en menos de 2 horas, pero la restauración real tardaba catorce horas
En una universidad privada, el almacenamiento corrompió las tablas del nodo principal de base de datos a mitad de la semana de exámenes finales. Medí el aprovisionamiento de la infraestructura desde código, la carga del volcado de 800 GB y la sincronización de la réplica. Se perdieron doce minutos de actividad, dentro del máximo prometido de 15 minutos. El acuerdo garantizaba la recuperación en menos de 2 horas y las copias cada quince minutos funcionaban, pero nadie había probado una restauración completa. La reconstrucción de índices y la velocidad de disco hacían que cargar 800 GB en una instancia nueva llevase más de catorce horas. El tiempo real de recuperación era de catorce horas, no de dos. Sustituí los volcados lógicos por copias físicas del almacenamiento combinadas con el archivado continuo del registro de escritura anticipada, automaticé el aprovisionamiento del clúster secundario y la restauración en caliente mediante clonación de almacenamiento. Además, introduje un simulacro mensual en el entorno de pruebas. Según las mediciones internas, en el siguiente simulacro a ciegas el tiempo de recuperación bajó de catorce horas a veintidós minutos; esta página no incluye la serie ni el protocolo necesarios para reproducir el resultado.
La alta disponibilidad dependía de una única instancia de Redis
En una entidad pública apagamos a propósito el centro de datos principal durante un simulacro. La plataforma quedó inaccesible, cerró las sesiones de los usuarios y les impidió volver a entrar. Medí la disponibilidad de la capa de aplicación, el estado de las sesiones y el tiempo de conmutación de cada componente. Sobre el papel había dos nodos de balanceo, cuatro de aplicación y un clúster de base de datos activo-pasivo. Sospeché de la redirección del balanceador y de la sincronización de la base secundaria, pero ambos componentes conmutaban correctamente. El punto único de fallo estaba en las sesiones: residían en una sola instancia de Redis, sin réplica ni reparto entre zonas. Desplegué un almacén de sesiones replicado entre varias zonas y con conmutación automática; además, incorporé reintentos y un modo de funcionamiento degradado y controlado. Después automaticé ensayos de inyección de fallos previamente definidos en un entorno aislado, bajo tráfico sintético y con criterios de parada. Cada ejecución registraba el nodo afectado, el tiempo de conmutación y la conservación de las sesiones. Las mediciones internas situaron la conmutación por debajo de tres segundos sin perder sesiones activas; la serie detallada no se publica en esta página.
Cada cambio de marca obligaba a todos los nodos a recompilar cientos de ficheros a la vez
En una plataforma de formación corporativa con más de 100 marcas por departamento, las mediciones internas mostraban que cada cambio de logotipo o color provocaba microcortes de entre 30 y 60 segundos y llevaba la CPU al 100 % en todos los nodos. Revisé el uso del sistema de ficheros, las llamadas a los procesos de compilación de hojas de estilo y el tiempo de ejecución. Parecía una incompatibilidad de la versión de PHP o una avalancha de recursos estáticos, pero descarté ambas causas al comprobar que el tiempo de ejecución y la actividad de disco se concentraban en la compilación que lanzaban los propios procesos web. El tema compilaba las hojas de estilo en tiempo de ejecución. Cada cambio invalidaba la caché global y todas las peticiones concurrentes intentaban recompilar a la vez cientos de ficheros. Desactivé esa compilación en producción, trasladé la regeneración a una tarea en segundo plano por línea de comandos y publiqué el CSS ya compilado en almacenamiento estático servido desde una red de distribución, con invalidación por versión. Los cambios de personalización dejaron de provocar microcortes y desaparecieron los picos de CPU; esta página no aporta la serie completa para reproducir la comparación.
Cómo trabajo
Convierto la continuidad y el rendimiento en criterios que se pueden comprobar antes de necesitarlos.
Un ensayo completo y periódico aporta evidencia sobre el plan de recuperación. Solo considero recuperable una copia después de restaurarla y comprobar que cumple los objetivos vigentes de tiempo y pérdida de datos. También pruebo la carga en las horas críticas y documento el sistema para que operarlo no dependa de una sola persona.
- 01
Fijar el objetivo de recuperación antes que la arquitectura
El negocio define el impacto y las tolerancias que necesita; las personas responsables del servicio, la seguridad y el cumplimiento las contrastan con los contratos, las obligaciones aplicables y las dependencias. De los objetivos acordados salen la réplica, la frecuencia de copia, los ensayos y el gasto, y no al revés.
- 02
Probar la carga en la hora que importa
No mido el sistema en un martes tranquilo, sino en el escenario que lo va a romper: la apertura de matrícula, el examen simultáneo, la carga masiva de calificaciones al cierre.
- 03
Restaurar, no comprobar que existe la copia
La restauración se ejecuta y se cronometra. Una copia que nunca se ha restaurado solo demuestra que el archivo existe; hasta probar la recuperación, no hay evidencia de que permita restablecer el servicio en el plazo acordado.
- 04
Dejar el sistema operable por el equipo
Guías de actuación, alertas con una persona responsable y automatización de lo repetitivo. Si para resolver un incidente hay que llamarme a mí, el trabajo está a medias.
Experiencia y trabajo propio
Mi experiencia procede de operar y hacer evolucionar plataformas de aprendizaje en producción, incluidos sus despliegues e incidentes.
Ver trayectoria y perfil- Operación, despliegue y evolución de plataformas de aprendizaje en producción.
- Trabajo con infraestructura en la nube, contenedores, automatización, rendimiento, seguridad e integración en plataformas Moodle.
- Diseño de telemetría y registro de auditoría para gobernar varias instalaciones desde un único sistema.
- Criterios de operación incorporados a las decisiones de arquitectura y de producto, en lugar de añadidos al final.
Trabajo propio relacionado
Estos proyectos propios muestran cómo observo y gobierno plataformas desde fuera.
La telemetría, el registro de auditoría y las comprobaciones automáticas permiten saber qué ocurre sin entrar a mano en cada instalación. Para actuar a distancia hace falta además un canal de operación con acciones delimitadas, permisos, registro y procedimientos de reversión.
Plataforma y operación
Conector de telemetría y operación para Moodle
Recogida del estado, las métricas y el inventario de cada instalación.
Ver la ficha de Conector de telemetría y operación para Moodle ↗Plataforma y operaciónGobierno de ecosistemas multi-LMS
Un plano de control separado de las plataformas que gobierna.
Ver la ficha de Gobierno de ecosistemas multi-LMS ↗Ingeniería y calidadCalidad automatizada de extensiones de Moodle
Comprobaciones que se ejecutan antes de que el código llegue a producción.
Ver la ficha de Calidad automatizada de extensiones de Moodle ↗Blog
En el blog cuento cómo se mantiene una plataforma en producción.
Escalado, recuperación, coste y operación, a partir de decisiones concretas y no de recetas generales.
Ir a blog.albertolarah.comHablamos
Si la última caída sigue sin explicación, además de recuperar el servicio falta poder reconstruir lo ocurrido.
Conviene revisar qué se mide, qué se ha probado de la recuperación y qué parte de la operación depende de una sola persona.