Où s'accumule réellement la dette technique ServiceNow
Chaque personnalisation semblait correcte au moment de sa mise en production. La dette réside dans ce que personne n'a regardé de nouveau.
Cinq endroits où la dette se cache
Aucun d'entre eux ne semble faux isolément. Le coût n'apparaît que lorsqu'il y en a des centaines dans une instance que personne n'a entièrement cartographiée.
Business rules sans condition
S'exécutent à chaque insertion ou mise à jour sur une table très sollicitée, la plupart du temps sans rien faire - et coûtent à chaque fois une part du temps de transaction.
Logique dupliquée entre les script includes
La même validation écrite de trois façons légèrement différentes - corriger l'une ne corrige pas les deux autres.
Usage d'API obsolètes qui survit aux mises à niveau
Des schémas qui fonctionnent encore techniquement aujourd'hui, mais qui compliquent discrètement une future mise à niveau de la plateforme.
sys_id codés en dur
Un enregistrement précis intégré directement dans le script au lieu d'une vraie recherche - se casse silencieusement dès que cet enregistrement change ou est recréé.
Gestion d'erreurs manquante autour des appels d'intégration
Un appel REST sans try/catch - à une réponse lente ou malformée près d'une transaction bloquée.
Comment le vérifier
La plupart de ces points sont vérifiables mécaniquement - c'est le volume sur une instance réelle qui rend l'exercice fastidieux, pas la difficulté d'une vérification donnée.
Lire les conditions des business rules, pas seulement leurs scripts
Compter rapidement combien de business rules actives sur une table très sollicitée ont un champ Condition vide est l'un des signaux les plus rapides disponibles - chacune s'exécute à chaque insertion/mise à jour, pertinente ou non.
Rechercher les sys_id codés en dur
Une vérification réelle et mécanique - une chaîne hexadécimale de 32 caractères dans un script est presque toujours une référence codée en dur, et presque toujours digne d'être remplacée par une vraie recherche.
Vérifier les appels synchrones sans timeout ni catch
Un appel REST ou SOAP sortant sans gestion d'erreur ne risque pas seulement l'échec d'une intégration - il risque de bloquer toute la transaction jusqu'à ce que la plateforme elle-même l'interrompe.
Dettes à prioriser
- Business rules avec un champ Condition vide sur des tables très sollicitées
- Script includes avec des corps de fonction quasi identiques
- Toute boucle
GlideRecordsanssetLimit() - Appels sortants sans try/catch
- Personnalisations modifiées pour la dernière fois par quelqu'un qui n'est plus dans l'entreprise
La version manuelle ne passe pas à l'échelle
Une véritable revue de code signifie lire chaque business rule, script include, client script et UI action pertinents - pas une seule fois au lancement, mais à nouveau après chaque changement significatif, indéfiniment. La plupart des équipes le font de façon réactive, quand quelque chose casse, plutôt qu'en continu - ce qui signifie que la dette est découverte par un incident, pas par une revue.
Cette revue exécutée en continu, automatiquement
Notre propre plateforme, neo.ai, examine les business rules, script includes, UI actions et client scripts selon un calendrier pour leur correction, leur sécurité et les bonnes pratiques - et ne fait remonter que ce qui est réellement actionnable. C'est l'une des sept catégories qu'elle surveille sur une instance ServiceNow.