Operación de server-configs

Cuándo usar este documento

Cuando haya que verificar, reiniciar o modificar los workers de cola, las entradas de cron o los respaldos de base de datos del servidor.

Audiencia

Infraestructura y soporte.

Estado documental

• Estado: Borrador
• Última actualización: 2026-08-02
• Owner: Pendiente
• SME requerido: DevOps
• Fuente resumida: crontab, script de respaldo y configuración de Supervisor del repositorio.

Tareas recurrentes

Cada minuto

Tarea	Qué hace
schedule:run de cada instancia de sy-energy	Dispara las tareas programadas del sistema principal.
schedule:run de mem-api	Dispara las tareas programadas del MEM.

Es el motor de toda la automatización del ecosistema. Si se detiene, ninguna tarea programada corre y no se genera ningún error.

Diarias

Hora	Tarea	Qué hace
05:20	Limpieza de volcados SQL	Elimina los volcados locales acumulados por la rutina de respaldo.

Semanales

Respaldos de base de datos. Uno por servicio, escalonados para no saturar el servidor:

Día y hora	Servicio
Domingo 00:30	Instancia de participante
Domingo 01:00	Instancia de participante
Domingo 01:30	Base del MEM

Cada ejecución:

1. Lee las credenciales desde AWS Secrets Manager.
2. Genera un volcado comprimido con transacción única, rutinas, triggers y eventos.
3. Lo sube a S3, a un prefijo por servicio y base de datos.
4. Elimina el archivo local.

Dos mecanismos de respaldo coexisten

Además del cron de este repositorio, el proyecto data-base-dumper define sus propias entradas de cron para volcar las mismas bases los sábados por la mañana.

No está claro si ambos están activos, si uno reemplazó al otro, o si se complementan. Es un gap abierto: hay que confirmar cuál es el mecanismo vigente antes de confiar en cualquiera de los dos como respaldo de referencia.

Verificaciones

¿Están vivos los workers?

sudo supervisorctl status

Todos los programas deben estar en RUNNING. Un programa en FATAL o STOPPED significa que ese proceso asíncrono está detenido — y los comandos que lo alimentan seguirán reportando éxito.

¿Está vivo el cron?

crontab -l

Debe existir una entrada de schedule:run por cada instancia de aplicación.

¿Se hizo el último respaldo?

Verificar en S3 que existe el archivo de la semana en curso para cada base.

Acciones frecuentes

Situación	Acción
Un worker está caído	sudo supervisorctl restart <programa>
Todos los workers de un servicio están caídos	sudo supervisorctl restart <grupo> y revisar el log del worker.
Se cambió la configuración de Supervisor	sudo supervisorctl reread && sudo supervisorctl update
Un worker consume demasiada memoria	Los workers ya tienen límite de tiempo de vida y de trabajos; se reinician solos. Si aun así crece, escalar.

Después de cada despliegue

El despliegue de una aplicación reinicia sus workers. Si un worker no vuelve a levantar, es aquí donde se detecta. Verificar el estado de Supervisor después de cada liberación.

Modificar la configuración

1. Cambiar el archivo en el repositorio, nunca directamente en el servidor.
2. Abrir el cambio a revisión: afecta a varios servicios a la vez.
3. Desplegar con el flujo de GitHub Actions correspondiente.
4. Verificar el estado de todos los programas de Supervisor, no solo del modificado.
5. Confirmar que el cron sigue completo.

Nunca editar en el servidor

Un cambio hecho directamente en el servidor se pierde en el siguiente despliegue, sin aviso. El síntoma es un worker que "funcionaba" y dejó de existir.

Logs

Componente	Dónde
Workers	Archivo de log por worker, en storage/logs de la aplicación correspondiente.
Respaldos	Log por servicio, en el directorio del proyecto de respaldo.
Scheduler	Log declarado por cada tarea en la aplicación.

Riesgos y gaps

• No hay alerta cuando un worker cae ni cuando el cron se detiene.
• No está confirmado cuál de los dos mecanismos de respaldo es el vigente.
• No está documentada la política de retención de los respaldos en S3.
• No está documentado el procedimiento de restauración desde un respaldo, que es lo que realmente importa el día que se necesite.
• No hay verificación automática de que los respaldos se completaron.

Próxima revisión

Al aclarar el mecanismo de respaldo vigente y documentar la restauración.