Pourquoi vos jobs planifiés ServiceNow entrent en collision
Chaque job semble raisonnable pris isolément. Personne ne regarde le planning dans son ensemble.
Comment les jobs entrent réellement en collision
Les jobs planifiés sont presque toujours configurés indépendamment, par des personnes différentes, à des moments différents - rien n'impose que l'ensemble reste cohérent.
Même table, fenêtres qui se chevauchent
Deux jobs écrivent sur les mêmes enregistrements dans la même fenêtre d'exécution - celui qui termine en dernier l'emporte silencieusement, et aucun des deux jobs n'a connaissance de l'autre.
Des jobs longs qui empiètent sur l'heure de démarrage du suivant
Un job qui terminait en deux minutes en prend maintenant vingt, à mesure que le volume de données augmente - et le planning autour n'a jamais été conçu pour cela.
Tempêtes de nouvelles tentatives
La logique de nouvelle tentative d'un job en échec chevauche sa prochaine exécution planifiée - le même travail tenté deux fois, simultanément.
Jobs dépendants sans ordonnancement explicite
Le job B suppose que le job A s'est déjà exécuté et a produit son résultat - rien sur la plateforme n'impose réellement cette hypothèse.
Comment le vérifier
Le planning configuré et l'historique réel d'exécution racontent deux histoires différentes - le conflit n'apparaît généralement que dans la seconde.
Lire les fenêtres d'exécution réelles, pas seulement l'expression cron
Le planning configuré d'un job indique quand il doit démarrer. Son historique d'exécution indique combien de temps il a réellement pris, et s'il a chevauché autre chose - seul le second indique ce qui s'est réellement passé.
Vérifier l'historique d'exécution pour les chevauchements, pas seulement les échecs
Un job peut réussir seul et avoir quand même chevauché un autre écrivant sur la même table au même moment - un succès ne signifie pas que les deux exécutions ne se sont pas interférées.
Schémas à vérifier en premier
- Jobs sur la même table avec des fenêtres configurées qui se chevauchent
- Jobs dont le temps d'exécution réel dépasse désormais l'écart avant le suivant
- Jobs avec logique de nouvelle tentative et sans délai progressif
- Jobs avec une dépendance non documentée au résultat d'un autre job
La version manuelle ne passe pas à l'échelle
Bien mener cette vérification implique de lire la fenêtre configurée réelle et l'historique d'exécution réel de chaque job actif - et de refaire cette comparaison à chaque nouveau job ajouté ou changement de durée d'un job existant. Sur une instance réelle avec des dizaines de jobs planifiés, ce n'est pas un audit ponctuel - c'est un engagement permanent pour lequel personne n'a le temps.
Cette vérification exécutée en continu, automatiquement
Notre propre plateforme, neo.ai, lit la fenêtre d'exécution réelle de chaque job planifié selon un calendrier et fait remonter les véritables chevauchements avant qu'ils n'entrent en collision en production - visualisés sur une heatmap, pas enfouis dans une table que personne n'ouvre. C'est l'une des sept catégories qu'elle surveille sur une instance ServiceNow.