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.
Infraestructura y operación.
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
Las herramientas ya estaban instaladas. Había métricas y registros suficientes, pero en una plataforma de funcionamiento continuo los usuarios seguían detectando los problemas antes que los equipos de soporte. La línea base interna mostraba tiempos de detección y resolución incompatibles con la criticidad del servicio; además, muchas alertas no conducían a ninguna acción útil. Seguí una petición web y comprobé que no podía relacionarla con el componente, la tarea programada, la base de datos y la integración implicados. Tampoco existían objetivos de servicio ni pruebas sintéticas para los recorridos críticos. Organicé la observabilidad alrededor de esos recorridos: indicadores de 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 la serie necesaria para reproducir la comparación.
Cada nodo nuevo multiplicaba las comprobaciones sobre el sistema de ficheros compartido
Añadir nodos estaba empeorando una plataforma de aprendizaje. A partir de cierto tamaño, el tiempo de respuesta crecía con cada nueva instancia. La CPU y el balanceador no explicaban ese salto: la espera se acumulaba en las operaciones sobre los metadatos del directorio de datos de Moodle. Medí las entradas y salidas de los nodos, las operaciones del sistema de ficheros compartido y las llamadas al sistema. Cada nodo nuevo aumentaba la contención sobre una interfaz común que debía coordinar operaciones y metadatos entre todos ellos. Moví los ficheros grandes al almacenamiento de objetos y las cachés locales al disco efímero de cada instancia. Para lo que seguía necesitando 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 de respuesta y del coste del almacenamiento compartido; las cifras detalladas pertenecen al informe interno del caso.
El acuerdo prometía horas, pero la restauración completa necesitaba casi una jornada
La corrupción de las tablas del nodo principal obligó a comprobar por primera vez una restauración completa en un momento crítico. Las copias frecuentes limitaban la pérdida de actividad, pero el objetivo de recuperación se había fijado sin medir cuánto tardaban el aprovisionamiento, la carga de un volcado de cientos de gigabytes y la reconstrucción de índices. La recuperación real necesitaba casi una jornada, muy por encima de lo acordado. 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. También incorporé simulacros periódicos en un entorno de pruebas. En el siguiente ensayo a ciegas, la recuperación se completó en una fracción del tiempo anterior; 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
Durante un simulacro apagamos a propósito el centro de datos principal. 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. El balanceo y la base de datos disponían de redundancia y 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 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 confirmaron una conmutación breve 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
El tema corporativo compilaba sus hojas de estilo dentro de los procesos web de producción. La variedad de marcas hacía que un cambio de logotipo o de color invalidara la caché global y que las peticiones concurrentes intentaran regenerar muchos ficheros a la vez. Aparecían microcortes y todos los nodos agotaban su capacidad de proceso. La actividad de disco y el tiempo de ejecución se concentraban en esa compilación, no en una incompatibilidad del entorno ni en la descarga de los recursos estáticos. Desactivé la compilación durante las peticiones, trasladé la regeneración a una tarea en segundo plano y publiqué las hojas ya compiladas en almacenamiento estático, con invalidación por versión. Los cambios de personalización dejaron de provocar microcortes y desaparecieron los picos de consumo; no aporto 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.
Recorrido profesional
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.
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.
Contacto
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.