esedark
Racks de servidores que representan workers fiables

linux / workers / systemd / operaciones

Cómo montar workers como servicio para que no se caigan

Mantener un proceso vivo no basta. Un servicio debe terminar o liberar trabajos, mostrar fallos y soportar despliegues controlados.

Un worker consume trabajos de una cola fuera de la petición web. Puede enviar notificaciones aprobadas, procesar archivos o sincronizar sistemas. La fiabilidad depende del diseño conjunto de trabajo, cola, worker y supervisor.

Elige un único responsable

En Linux, systemd suele ser la opción más clara: controla arranque, usuario, entorno, reinicios y logs. PM2 resulta cómodo en Node.js y Supervisor en configuraciones sencillas. Evita supervisores anidados con decisiones independientes.

Ejecuta con un usuario sin privilegios, directorio explícito y secretos desde un archivo protegido o gestor de secretos. Nunca guardes credenciales en la unidad, repositorio o historial.

Configura reinicios conservadores

Reinicia ante fallos inesperados, no después de cualquier salida limpia. Añade espera y límite de frecuencia para evitar bucles. Define CPU, memoria y archivos. Un cierre por falta de memoria señala capacidad insuficiente o una fuga, no debe ocultarse con reinicios infinitos.

Gestiona apagado y despliegue

Al recibir SIGTERM, deja de reservar trabajos, termina el actual dentro de un plazo o libéralo, vacía logs y cierra conexiones. El timeout del supervisor debe superar esa ventana. Los trabajos largos necesitan checkpoints, leases o reanudación.

Despliega pausando entrada, drenando workers antiguos e iniciando la versión probada. Haz trabajos idempotentes para no duplicar acciones. Limita reintentos, aplica backoff y envía fallos permanentes a dead letter.

Monitoriza trabajo, no solo procesos

Un estado verde solo confirma que el proceso existe. Mide profundidad y edad de cola, throughput, éxito, reintentos, dead letters, duración, memoria y última finalización. Usa IDs de correlación y logs seguros. Alerta por edad creciente, fallos repetidos o heartbeat detenido. Consulta la monitorización mínima para producción.

Errores comunes

  • ejecutar como root
  • usar varios supervisores
  • reiniciar siempre sin backoff
  • guardar secretos en la definición
  • matar trabajos durante despliegues
  • reintentar acciones no idempotentes
  • mirar uptime pero no edad de cola
  • desplegar versiones incompatibles
  • ignorar dead letters y capacidad

Checklist práctico

  • elegir un supervisor
  • usar cuenta sin privilegios
  • definir rutas y límites
  • limitar reinicios
  • implementar SIGTERM y drenaje
  • hacer trabajos idempotentes
  • limitar reintentos con backoff
  • medir edad de cola y resultados
  • probar reinicios
  • documentar rollback y dead letters

Cuándo contratar a una persona técnica

Contrata a un responsable cuando los workers ejecutan acciones críticas, procesan datos personales o regulados, necesitan despliegues sin parada o acumulan reintentos. Un especialista alinea ciclo de vida, cola, seguridad, capacidad y monitorización.

Conclusión

Un servicio duradero hace visibles los fallos y recuperables los trabajos. Si tus procesos dependen de sesiones manuales o reinicios a ciegas, revisa mis servicios de infraestructura o contacta conmigo.