La divergencia scheduler-destino mide cuántas veces el reloj dice que corrió pero el vivo no cambió

Dos sistemas pueden contar historias distintas. El scheduler sabe que una tarea se disparó; Drive sabe qué bytes están publicados. Cuando ambas señales no coinciden, aparece una divergencia scheduler-destino. Medirla evita una conclusión peligrosa: asumir que un job ejecutado equivale a un resultado entregado. En workflows con herramientas externas, la distancia entre ambos estados puede crecer por permisos, referencias, timeouts o respuestas aceptadas que no terminan en el recurso que el usuario consume.

La métrica necesita una expectativa explícita. Cada run debe declarar qué cambio espera dejar: feedDate, hash, número de items o identificador de versión. Después de la ejecución, una lectura independiente del destino compara ese estado contra la expectativa. Si el scheduler registra una corrida pero el recurso mantiene la versión anterior, el caso suma divergencia. Esta definición permite distinguir un run que legítimamente no debía cambiar nada de uno que prometía una mutación y no la produjo.

Segmentar por frontera encuentra la causa. No basta saber que existe divergencia. Conviene separar generación, staging, promoción a vivo, backup y correo. Si staging recibe el archivo pero vivo no cambia, la falla está en la frontera de promoción, no en investigación ni redacción. Si vivo cambia y el correo falta, el contenido ya está entregado y regenerarlo sería una mala recuperación. La segmentación convierte un porcentaje global en una ruta de diagnóstico práctica.

El hash evita interpretaciones. Comparar nombres o fechas de modificación puede producir falsos positivos. Un hash de los bytes validados y otro del archivo descargado después de la mutación permiten demostrar si el mismo artefacto llegó al destino. El hash no reemplaza validar semántica, pero sí responde una pregunta precisa: ¿son exactamente los mismos bytes? Esa propiedad vuelve más fuerte la correlación entre run y efecto y reduce discusiones sobre si una operación “probablemente” funcionó.

La métrica también sirve para cambios de infraestructura. Si una nueva versión del conector aumenta la divergencia aunque mantenga la misma tasa de jobs verdes, existe una regresión real. Un equipo puede comparar periodos antes y después y decidir rollback basándose en efectos, no en logs internos. Esta perspectiva es especialmente útil cuando el proveedor cambia manejo de archivos o referencias, porque la aplicación puede seguir ejecutando llamadas que ya no producen la misma consecuencia.

Un umbral puede disparar recuperación. Cuando la divergencia aparece, el sistema no necesita reiniciar todo. Puede releer staging, reconstruir una referencia fresca y repetir solo la promoción. La métrica se convierte así en una señal operativa y no únicamente en un reporte. Si la recuperación también verifica destino, el circuito cierra: detectar, reparar y demostrar que el estado volvió a coincidir con la expectativa.

La tasa debería observarse junto al tiempo de corrección. Una divergencia que se resuelve en un minuto tiene impacto distinto a otra que congela el feed dos días. Combinar frecuencia con duración muestra mejor el riesgo. El objetivo es reducir tanto cuántas veces se separan scheduler y destino como cuánto tarda el sistema en volver a alinearlos. Esa dupla aproxima la experiencia real del usuario, que solo percibe durante cuánto tiempo recibió un estado incorrecto.

La conclusión es simple pero exigente. Automatizar no significa programar; significa producir un efecto verificable de forma repetible. El scheduler es necesario para iniciar el trabajo, pero nunca debería ser la autoridad final sobre si terminó. La autoridad la tiene el recurso que el negocio quería cambiar. Diseñar métricas alrededor de ese destino hace que la confiabilidad deje de depender de actividad interna y se mida donde realmente importa.