Ces configurations de service logiques sont mappées aux données de disposition physique du réseau et de l’infrastructure d’application de support dans chacun de vos domaines respectifs. Ils suivent l’état physique et logique des éléments de service IT et associent les incidents à l’état des éléments de service, ce qui aide à analyser les tendances et à réduire les problèmes et les incidents.

Les configurations sont stockées dans une base de données de gestion des configurations (ServiceNow CMDB) qui se compose d’entités, appelées éléments de configuration (CI), qui font partie de votre environnement. Un CI peut être :

• Une entité physique, telle qu’un ordinateur ou un routeur
• Une entité logique, telle qu’une instance d’une base de données
• Conceptuel, tel qu’un service de demande

Dans chaque cas, il existe des attributs du CI que vous souhaitez conserver, et il existe un contrôle que vous souhaitez avoir sur le CI. Certains changements peuvent devoir être apportés et suivis par rapport au CI. En outre, un CI n’existe pas en tant que tel. Les CI ont des dépendances et des relations avec d’autres CI. Par exemple, la perte de lecteurs de disque peut entraîner l’arrêt d’une instance de base de données, ce qui affecte le service de demande utilisé par le département RH pour commander du matériel pour les nouveaux employés.

Ce sont ces données relationnelles qui font de la CMDB un puissant outil d’aide à la décision. Comprendre les dépendances et autres relations entre vos CI peut vous indiquer, par exemple, exactement qui et quoi est affecté par la perte de ce parc de disques durs. Lorsque vous découvrez qu’un routeur est tombé en panne, vous serez en mesure d’évaluer l’effet de cette panne. Lorsque vous décidez de mettre à niveau le processeur d’un serveur, vous pouvez indiquer qui ou quoi sera affecté pendant la panne.

Les éléments de configuration diffèrent d’un environnement à l’autre, car chaque client a des besoins uniques. Des détails sur les attributs physiques exacts d’un ordinateur peuvent être nécessaires à un client, mais peuvent représenter des données dénuées de sens pour un autre. La Now Platform fournit un mécanisme permettant de définir facilement de nouvelles classes d’éléments de configuration et de nouvelles relations qui peuvent exister entre les CI. De nouvelles classes peuvent être définies qui étendent d’autres classes. Par exemple, il existe une classe laptop qui étend la classe computer. La classe computer proprement dite étend la classe CI de base. Les extensions de classe client font automatiquement partie de l’environnement ServiceNow et s’intègrent parfaitement aux points d’intégration pour d’autres processus ITIL.

Vous pouvez, par exemple, définir l’attribut Used for dans la table cmdb_ci_server sur une valeur telle que « développement », « test » ou « production ». Ces valeurs indiquent l’environnement pris en charge par le CI et permettent de suivre un CI tout au long de son cycle de vie dans un environnement changeant.

CMDB étendue

Dans les systèmes de base, CMDB fournit des fonctionnalités essentielles pour la base de données de gestion des configurations, y compris des modules pour le matériel et les éléments de configuration. Le module d’extension CMDB étendu distinct comprend une collection de modules pour les éléments de configuration spécialisés, tels que le matériel radio, l’équipement de test et le matériel de système vocal.

Pour étendre la CMDB, vous pouvez activer les modules d’extension suivants pour accéder aux modules des éléments de configuration spécialisés.

• Ordinateur central CMDB (com.snc.cmdb.mainframe)
• Catégorie de radio CMDB (com.snc.cmdb.radio.category)
• Catégorie de télécommunications CMDB (com.snc.cmdb.telecom.category)
• Équipement de test CMDB (com.snc.cmdb.test.equipment)

Hiérarchie CMDB et gestionnaire de classe de CI

Les ensembles de CI qui partagent des attributs sont stockés dans leur propre table de classes. Toutes les tables CMDB sont connectées par des relations et héritent d’attributs les unes des autres pour former un réseau de tables appelé hiérarchie CMDB.

Utilisez le pour gérer les Gestionnaire de classe de CI classes CMDB au sein de la hiérarchie CMDB, de l’intégrité CMDB et d’autres définitions liées aux classes. Par exemple, dans le gestionnaire de classe de CI, vous pouvez afficher les attributs de classe, les règles d’identification de classe et la liste des CI d’une classe spécifique. Pour afficher la liste des CI dans la CMDB, vous pouvez également entrer cmdb_ci_list.do dans le navigateur de filtre.

Architecture

Tables connexes

Il existe des tables qui ne font pas partie de la hiérarchie CMDB, mais qui sont tout de même qualifiées de données CMDB. Les tables connexes, telles que la table Numéro de série [cmdb_serial_number], ne sont pas inhérentes à la table Élément de configuration [cmdb_ci], mais ont au moins une colonne qui fait référence à un CI CMDB. Les tables connexes sont spécifiées dans la table Entrées associées [cmdb_related_entry].

Certains scénarios impliquant des tables connexes peuvent entraîner des enregistrements orphelins ou périmés dans les tables connexes. Un CI d’une table connexe peut, par exemple, devenir orphelin si le CI référencé dans la CMDB est supprimé. Vous pouvez utiliser le gestionnaire de données CMDB pour créer une politique du type de politique « Supprimer l’entrée connexe CMDB », qui supprimera en cascade les données des éléments connexes inutiles. Pour plus d’informations sur la création de cette politique de gestionnaire de données CMDB, reportez-vous à la section Créer une politique de gestionnaire de données CMDB dans CMDB Workspace.

Rôles requis