Skip to content

Runbook de operación diaria

Cuándo usar este documento

Cada mañana, después de las 09:00, cuando ya terminó la cadena automática que corre entre las 05:00 y las 08:30.

Audiencia

Soporte e infraestructura.

Estado documental

  • Estado: Borrador
  • Última actualización: 2026-08-02
  • Owner: Pendiente
  • SME requerido: soporte operativo / infraestructura
  • Fuente resumida: scheduler del sistema, configuración de workers y comandos de diagnóstico.

Antes de empezar

La revisión se hace por instancia de participante: hay una instancia por participante, cada una con su base de datos, sus colas y sus logs. Un problema en una no se ve desde la otra.

Revisión de la mañana

1. El motor está vivo

Sin esto, nada de lo demás corrió.

QuéCómo se ve bien
Cron del servidorLa entrada de schedule:run existe y está activa para cada instancia.
Workers de SupervisorTodos los programas en estado RUNNING.

Si el cron está caído, ninguna tarea programada se ejecutó y no habrá ningún error en los logs de la aplicación — simplemente no habrá nada. Un log vacío es un síntoma, no una señal de tranquilidad.

Si un worker está caído, los comandos que despachan trabajos habrán terminado "con éxito" sin que el trabajo se haya hecho.

2. Las colas están sanas

bash
php artisan queue:failed
ResultadoInterpretación
VacíoCorrecto.
Unos pocos, de hoyRevisar la causa antes de reintentar.
Muchos, acumulados de varios díasEl reintento automático de las 05:00 no está resolviendo el problema de fondo. Escalar.

A las 05:00 el sistema ejecuta queue:retry all de forma automática. Si a media mañana siguen apareciendo los mismos trabajos fallidos, reintentarlos otra vez no va a ayudar.

3. La cadena del día terminó

Revisar los logs en storage/logs de la instancia:

LogQué debió registrar
ecd-sync.logReintento de trabajos fallidos (05:00) y sincronización de ECD (05:05).
cenace-process.logCreación de facturas (05:30), carga a S3 (05:45), carga al SIM (06:45), estatus (08:15) y REA (08:30).
service-process.logSincronización de demanda (06:00).

Lo que hay que confirmar en cada uno: que la entrada del día existe y que no terminó en error.

Un log sin la entrada del día es más grave que un log con error: significa que la tarea no corrió.

4. Validación por dominio

DominioQué validarDónde
ECD / CENACELlegaron los ECD de la fecha de operación correspondiente. Recordar el desfase de 5 días.ecd-sync.log y el módulo de ECD.
FacturaciónSe crearon las facturas pendientes y no quedaron documentos atorados.cenace-process.log
Carga al SIMLas facturas del día llegaron al portal.php artisan ecd:invoices_status --from=… --to=…
DemandaSe sincronizó la demanda de los centros de carga y no hay huecos.service-process.log y el módulo de demanda.
BotsEl bot de REA respondió.cenace-process.log

5. Cierre

Registrar el resultado de la revisión: fecha, instancia, hallazgos y evidencia. Si algo quedó pendiente, dejarlo escrito con el siguiente paso concreto — no como "revisar mañana".

Acciones correctivas frecuentes

SituaciónAcción
Falta el ECD de una fecha de operaciónphp artisan ecd:sync-store <fecha> <subcuenta>
Quedaron facturas sin crearRevisar primero con php artisan ecd:create_invoice --csv, luego ecd:create_invoices.
Facturas creadas que no llegaron al SIMphp artisan ecd:upload_invoices_to_s3 seguido de ecd:upload_invoices.
Varios bots fallan a la vezphp artisan bot:queue --slug=cenace-notifications y reintentar.
Huecos en la demanda horariaphp artisan demand:fix-hourly <inicio> <fin> --rmu=<RMU>
Trabajos fallidos puntuales, causa ya entendidaphp artisan queue:retry all

No reejecutar dentro de la ventana automática

Entre las 05:00 y las 08:30 el scheduler está corriendo la cadena. Ejecutar a mano los mismos comandos en esa franja puede duplicar procesamiento. Si hay que intervenir, esperar a que la ventana cierre.

Escalamiento

Escalar a desarrollo, sin intentar corregir por cuenta propia, cuando:

  • se emitieron facturas incorrectas o duplicadas;
  • los trabajos fallidos se repiten día tras día con el mismo error;
  • falta información de CENACE de más de una semana;
  • un cálculo produce importes que no cuadran con el estado de cuenta.

Evidencia mínima de un incidente

  • Fecha y hora.
  • Instancia del participante.
  • Comando o proceso involucrado.
  • Fragmento de log sanitizado: sin credenciales, RFC ni datos personales.
  • Qué se intentó y qué resultado dio.

Riesgos y gaps

  • No existe un tablero único que muestre el estado de la cadena diaria; hoy la revisión es manual y depende de abrir varios logs.
  • No hay alertas automáticas cuando una tarea no corre.
  • No está definido el horario objetivo de la revisión ni quién la ejecuta.
  • No está documentado dónde se registra el resultado de la revisión diaria.

Próxima revisión

Tras la validación de soporte.