ServiceNow ITOM : Discovery et Service Mapping simplement

Comprendre la différence entre ITSM et ITOM

L’ITSM structure la fourniture des services et le traitement des demandes ; l’ITOM apporte une visibilité opérationnelle sur les composants qui les soutiennent. Les deux se rencontrent lorsqu’un incident doit être relié à une infrastructure et à un service métier. Une liste de serveurs ne suffit pas à expliquer pourquoi les clients ne peuvent plus réserver. Il faut connaître les applications, les dépendances et les responsables. L’objectif de Discovery et de Service Mapping est de fournir une partie de ce contexte, avec des données suffisamment fiables pour aider les équipes à décider.

Définir le périmètre avant de lancer Discovery

Inventoriez les environnements autorisés, les plages réseau, les comptes cloud et les types de composants recherchés. Identifiez les propriétaires et les contraintes d’exploitation. Un périmètre trop large peut générer des résultats difficiles à vérifier et solliciter inutilement des équipements sensibles. Commencez par un environnement représentatif, avec une liste d’éléments attendus pour comparer les résultats. Vérifiez les prérequis des technologies concernées et des fonctionnalités souscrites. Discovery dépend de configurations et d’accès appropriés : il ne découvre pas automatiquement n’importe quel équipement simplement parce qu’il se trouve sur le réseau.

Le rôle du MID Server dans les environnements concernés

Un MID Server est un composant installé dans un environnement disposant des accès nécessaires pour communiquer avec les ressources ciblées et l’instance ServiceNow. Selon le scénario, il participe à la collecte d’informations via des protocoles et des API pris en charge. Son placement, sa disponibilité et ses permissions doivent être étudiés. Évitez de lui accorder des droits illimités par commodité. Documentez les flux réseau autorisés et la gestion des identifiants. Les architectures cloud peuvent utiliser des mécanismes de collecte différents ; il faut choisir le schéma adapté plutôt que reproduire systématiquement une installation unique.

Identifier, reconnaître et collecter les informations

La découverte cherche à déterminer ce qu’est une ressource et quelles informations peuvent être collectées. Les mécanismes disponibles varient selon la technologie et les patterns utilisés. Un résultat partiel peut provenir d’un accès refusé, d’un protocole indisponible ou d’une application non reconnue. Il faut distinguer ces situations d’une ressource réellement absente. Conservez les erreurs de collecte et traitez-les par catégorie. La qualité de l’inventaire progresse quand l’équipe corrige les prérequis et vérifie les résultats avec les responsables, pas lorsqu’elle augmente simplement la fréquence des scans.

Alimenter la CMDB sans multiplier les doublons

Les informations découvertes doivent s’intégrer aux autres sources de la CMDB. Définissez les identifiants, les règles de rapprochement et les responsabilités de mise à jour des attributs. Un même serveur peut être décrit par Discovery, un outil cloud et un import d’inventaire. Sans gouvernance, ces sources peuvent créer plusieurs fiches ou écraser des valeurs utiles. Les mécanismes d’identification et de réconciliation sont donc aussi importants que la collecte. Contrôlez les doublons, les valeurs manquantes et les ressources obsolètes, en tenant compte du fait que toutes les sources ne sont pas actualisées au même moment.

Passer de la ressource au service avec Service Mapping

Une cartographie de service relie les composants techniques à un service applicatif. Pour un portail de réservation, on peut retrouver un point d’entrée web, une application, une base et des échanges externes. La carte doit montrer les dépendances utiles au diagnostic, pas seulement produire un dessin impressionnant. Selon les capacités et la configuration disponibles, plusieurs approches de découverte des relations peuvent être utilisées. Le responsable du service doit vérifier les composants trouvés et les dépendances manquantes. Une carte générée automatiquement reste une hypothèse opérationnelle tant que sa fidélité n’a pas été contrôlée.

Exemple : analyser l’impact d’une base indisponible

Une alerte indique qu’une base de données ne répond plus. L’inventaire permet de retrouver son propriétaire et son environnement ; la cartographie aide à identifier les applications qui en dépendent. Le support peut alors relier les symptômes signalés par différents utilisateurs au même composant. Ce contexte améliore la coordination, mais ne prouve pas à lui seul la cause de la panne. Il faut encore examiner disponibilité, métriques et changements récents. Une dépendance cartographiée décrit une relation ; elle ne remplace pas les mesures nécessaires pour confirmer qu’elle explique l’incident en cours.

Concevoir une exploitation sécurisée et maintenable

Organisez la rotation des identifiants, les validations des changements réseau et la surveillance des collecteurs. Protégez les comptes techniques et évitez de conserver leurs secrets dans des documents ou des scripts non contrôlés. Définissez les fenêtres de découverte et la conduite à tenir lorsqu’une collecte échoue plusieurs fois. Documentez la responsabilité des équipes plateforme, réseau et applicatives. Les mises à jour doivent être testées sur un périmètre maîtrisé. La visibilité opérationnelle devient fragile si elle dépend d’un seul compte personnel, d’un serveur non supervisé ou d’une configuration que personne ne sait reproduire.

Mesurer la couverture et la fraîcheur des cartes

Comparez les ressources attendues aux ressources reconnues, puis évaluez la complétude des attributs et des relations importantes. Une couverture élevée sur des équipements sans importance ne compense pas l’absence d’une base critique. Mesurez aussi l’ancienneté de la dernière collecte réussie et le temps de correction des erreurs. Vérifiez les cartes après les changements applicatifs majeurs. Le bon indicateur est la capacité des équipes à retrouver rapidement les composants et les responsables d’un service réel. Le nombre total de CI découverts n’est qu’une mesure de volume, pas une preuve de qualité.

Construire une feuille de route par services

Choisissez quelques services prioritaires, définissez leurs propriétaires et validez les prérequis. Mettez en place la découverte, corrigez les erreurs puis vérifiez la cartographie avec les équipes concernées. Intégrez ensuite ces informations aux parcours d’incident et de changement. Tuplify Studio peut accompagner le cadrage des intégrations, les traitements de données et les automatisations autour de ServiceNow. Les capacités exactes dépendent de votre instance et de vos abonnements. Un déploiement progressif fournit des résultats vérifiables et une méthode reproductible avant d’étendre la couverture à l’ensemble de l’infrastructure.

Atelier : valider une découverte sur un périmètre connu

Choisissez quelques ressources dont l’équipe connaît l’existence, les propriétaires et les dépendances. Préparez une liste attendue, autorisez les accès puis lancez la collecte dans le périmètre convenu. Comparez chaque résultat : absent, reconnu partiellement, correctement identifié ou dupliqué. Pour une ressource absente, vérifiez séparément réseau, identifiants et capacité de reconnaissance. Reliez ensuite les éléments au service étudié et demandez à son responsable de vérifier la carte. Modifiez un composant dans un environnement de test et observez la mise à jour. Cet atelier mesure la fidélité et la fraîcheur du processus, alors qu’un simple décompte de milliers de ressources ne montre pas si les données critiques sont utilisables.

Questions fréquentes : automatisation et cause des incidents

La cartographie est-elle toujours automatique ? Les capacités disponibles et les approches varient ; une préparation, une configuration et une validation restent nécessaires. Les exceptions et technologies non reconnues doivent être traitées explicitement.

Une dépendance prouve-t-elle la cause d’un incident ? Non. Elle indique un chemin possible d’impact, à confronter aux mesures et aux événements réels.

Faut-il découvrir toute l’infrastructure dès le début ? Un périmètre progressif réduit les erreurs et permet d’apprendre. Commencez par des services prioritaires, avec des responsables capables de valider les résultats. La couverture peut ensuite s’étendre sur la base d’une méthode de collecte, de réconciliation et de correction déjà éprouvée.