Aller au contenu

Sujets populaires

Par enjeu
CMDB ServiceNow

Une CMDB ne vaut
que ce qui l’alimente.

Certero ServiceNow Application synchronise l’inventaire enrichi de la plateforme vers votre CMDB.

Les ordinateurs Windows, macOS et Linux arrivent avec leurs disques, cartes réseau, modules mémoire, volumes, logiciels et installations de logiciels. Les équipements réseau SNMP arrivent lors de la même exécution.

Synchronisation CMDB · exécution planifiée

À titre indicatif

Certero ServiceNow Application

Tables intermédiaires vidées, sources de données interrogées, transformations exécutées

Tables intermédiaires vidées avant la première requête
terminé
Ordinateurs Windows disques, cartes, mémoire, volumes
en zone intermédiaire
Ordinateurs macOS et Linux les mêmes types d’enregistrement, la même exécution
en zone intermédiaire
Équipements réseau SNMP leur propre source de données
en zone intermédiaire
Transformations vers la CMDB une transform map par source de données
en cours

Enregistrement d’historique

en attente → en cours → terminé

Application certifiée

ServiceNow Certified App

Certero, sur le ServiceNow Store

Voir la liste

ServiceNow Partner

Inventaire Certero synchronisé dans la CMDB ServiceNow

En bref

Un enregistrement que personne ne met à jour est un enregistrement auquel personne ne se fie.

Une base de configuration est exacte le jour où quelqu’un la remplit, puis elle dérive au fil des changements sur les machines. Les décisions de service, de sécurité et de changement finissent par reposer sur des informations dépassées, et chaque projet de nettoyage relance la dégradation. CerteroX l’alimente automatiquement à chaque exécution : elle reste exacte sans que personne ait à y penser.

  • Coût

    Cessez de payer des projets de nettoyage.

    L’exactitude vient d’une alimentation automatique régulière plutôt que d’efforts manuels ponctuels : vous ne payez donc pas deux fois le même travail.

  • Risque

    Des décisions fondées sur ce qui existe réellement.

    Les équipes changement, incidents et sécurité travaillent sur des enregistrements à jour pour les machines Windows, Mac et Linux et les équipements réseau, pas sur un instantané.

  • Effort

    Rien ne dépend de la mémoire.

    Chaque exécution est journalisée et traçable : les lacunes sont visibles et corrigées, au lieu d’être découvertes pendant un incident.

Le problème

Une CMDB ne devient pas fausse. Elle devient obsolète.

Elle était exacte la semaine où quelqu’un l’a remplie. Puis les machines ont changé, pas l’enregistrement, et le centre de services s’est mis à travailler à partir d’un document plutôt qu’à partir de la réalité.

  1. 01 saisi une fois, exact une fois

    L’enregistrement était exact le jour où une personne l’a créé.

    Depuis, la machine a reçu plus de mémoire, perdu un disque et gagné neuf applications. Personne n’aurait pu suivre à la main, et l’enregistrement s’éloigne discrètement du matériel depuis.

    Agent d’inventaire natif pour Windows, macOS, Linux, AIX, HP-UX et Solaris ITAM

  2. 02 un scan ne voit que ce qui répond

    L’ordinateur portable était en veille : pour la CMDB, il n’existe donc pas.

    Un balayage de découverte enregistre ce qui répond pendant qu’il tourne. L’ordinateur portable en déplacement, le segment verrouillé et la machine pour laquelle personne n’a d’identifiants sont tous absents, et une absence dans une CMDB se lit exactement comme une machine que vous ne possédez pas.

    Inventaire sans agent et en ligne de commande (csinvcli) pour les environnements verrouillés ITAM

  3. 03 un nom et rien en dessous

    Le CI existe. Ouvrez-le : il n’y a rien dedans.

    Pas de disques, pas de cartes, pas de mémoire, pas de systèmes de fichiers, pas de logiciels. Un technicien prend l’incident et va chercher le détail ailleurs : c’est à ce moment que la CMDB a cessé d’être l’endroit que l’on consulte.

    Disques, cartes réseau, modules mémoire et volumes comme sources de données par défaut ITAM

  4. 04 deux enregistrements, une machine

    La réinstallation est revenue sous la forme d’un second CI, et le premier n’est jamais parti.

    Doublons et enregistrements obsolètes depuis longtemps : voilà ce qu’accumule une CMDB alimentée à la main. Chacun d’eux fait que la personne suivante se fie un peu moins à l’enregistrement suivant.

    Détection des systèmes en double et archivage des appareils obsolètes ITAM

  5. Aucun nouveau projet de nettoyage ne règle cela. On le règle en donnant à la CMDB une alimentation et en laissant chaque exécution faire le nettoyage.
Ce qui fait le travail

Deux des cinq disciplines.

Chacune fonctionne de façon autonome et partage un modèle d’actifs unique : les volets qui couvrent plusieurs produits ne demandent aucun travail d’intégration.

Vous consultez le détail technique complet. Désactivez-le pour afficher la version courte.

Masquer le détail technique
Comment cela se passe concrètement

De la machine au CI, en cinq étapes.

L’application fait un seul travail, selon un calendrier : lire l’API de la plateforme, placer ce qui en revient en zone intermédiaire, le transformer dans la CMDB et garder la trace de ce qu’elle a fait.

  1. Compléter l’enregistrement avant qu’il quitte la plateforme

    Tout ce que la CMDB doit savoir, la plateforme doit d’abord le voir. Dix méthodes de découverte aboutissent dans un seul schéma : les machines qu’un balayage réseau n’atteint jamais figurent dans le même inventaire que celles qu’il atteint.

    • Découverte réseau via NetBIOS, SNMP et ICMP ITAM
    • Agent d’inventaire natif pour Windows, macOS, Linux, AIX, HP-UX et Solaris ITAM
    • Inventaire sans agent et en ligne de commande (csinvcli) pour les environnements verrouillés ITAM
    • Inventaire autonome pour les systèmes isolés et hors ligne ITAM
    • Détection des systèmes en double et archivage des appareils obsolètes ITAM
    • Software Recognition Database avec catégorisation des titres gérée de façon centralisée SAM
  2. Installer l’application, définir trois paramètres

    API Url, API Username et API Password suffisent pour la faire fonctionner. La taille de page et la rétention de l’historique sont disponibles si vous voulez les ajuster ; sinon, l’application fonctionne telle quelle.

    • Certero ServiceNow Application, installée dans votre instance ServiceNow
    • Trois paramètres pour démarrer : API Url, API Username, API Password ServiceNow
    • API Page Size et History Retention, tous deux configurables ServiceNow
    • API Certero en lecture seule comme source unique lue par la synchronisation ServiceNow
    • Accès au menu réservé au rôle x_certero.administrator ServiceNow
  3. L’exécuter selon un calendrier, ou tout de suite

    Le calendrier repose sur une exécution de script planifiée ServiceNow, qui lance la synchronisation en arrière-plan. Sync Now couvre les cas où vous en avez besoin avant la prochaine échéance.

    • Exécution de script planifiée déclenchant la synchronisation en arrière-plan ServiceNow
    • Sync Now sur les pages des sources de données et de l’historique ServiceNow
  4. Le placer en zone intermédiaire, puis le transformer dans la CMDB

    Chaque exécution commence par purger l’historique au-delà de la rétention que vous avez définie. Les tables intermédiaires sont ensuite vidées, chaque source de données interroge l’API page par page jusqu’à épuisement, et chaque transform map écrit ses enregistrements dans ServiceNow.

    • Sources de données par défaut pour les ordinateurs Windows, macOS et Linux ServiceNow
    • Disques inscrits comme périphériques de stockage CMDB, volumes comme systèmes de fichiers CMDB ServiceNow
    • Cartes réseau, modules mémoire, logiciels comme packages CMDB, et installations de logiciels ServiceNow
    • Équipements réseau SNMP sur leur propre source de données ServiceNow
    • Une transform map créée pour chaque source de données par défaut ServiceNow
  5. Garder la trace de chaque exécution

    Chaque synchronisation écrit un enregistrement d’historique qui passe de « en attente » à « en cours » puis « terminé », avec un journal des messages système associé, conservé pendant la durée de rétention que vous avez définie.

    • Enregistrement d’historique par synchronisation : en attente, en cours, terminé ServiceNow
    • Journal des messages système pour chaque exécution, pour le débogage ServiceNow
    • Ancien historique purgé selon la rétention configurée ServiceNow
    • Métadonnées des sources de données stockées dans une table, extensibles à d’autres points de terminaison de l’API ServiceNow

Demandez à voir n’importe lequel de ces points en action dans le produit, sur l’écran concerné.

Une machine, sept enregistrements

Un élément de configuration doit arriver avec ses composants.

L’application est livrée avec une source de données pour les ordinateurs Windows, macOS et Linux et, pour chacun, les disques, cartes réseau, modules mémoire, volumes, logiciels et installations de logiciels. Chaque source de données par défaut dispose d’une transform map qui l’écrit dans la CMDB.

Dans CerteroX

Une machine, inventoriée une seule fois.

Quelle que soit la méthode de découverte, parmi les dix, qui l’a atteinte, l’enregistrement a la même forme : la machine et tout ce qu’elle contient.

  • Windows
  • macOS
  • Linux

Chacun des trois est livré avec sept sources de données, une pour chacun des sept types d’enregistrement.

Dans ServiceNow

Sept enregistrements, chacun avec sa source de données et sa transform map.

  • L’ordinateur lui-même
  • Disques Périphériques de stockage CMDB
  • Cartes réseau
  • Modules mémoire
  • Volumes Systèmes de fichiers CMDB
  • Logiciel Packages CMDB
  • Installations de logiciels

Les équipements réseau SNMP arrivent par leur propre source de données, et les métadonnées des sources de données sont stockées dans une table : d’autres points de terminaison de l’API peuvent donc être ajoutés sans modifier l’application.

La situation finale

À quoi ressemble une bonne pratique.

Le vrai test d’une CMDB : est-ce que quelqu’un la consulte avant de décrocher le téléphone ?

  1. 01

    Le CI arrive avec ses composants.

    Les disques en périphériques de stockage, les volumes en systèmes de fichiers, les logiciels en packages, ainsi que les cartes réseau, les modules mémoire et les installations de logiciels. L’enregistrement répond à la question qui a poussé quelqu’un à l’ouvrir.

  2. 02

    Rien ne dépend de la mémoire de quelqu’un.

    L’exécution de script planifiée lance la synchronisation en arrière-plan. La CMDB évolue quand l’inventaire évolue, pas quand un nettoyage est planifié.

  3. 03

    Windows n’est pas le seul à compter.

    macOS et Linux sont livrés comme sources de données par défaut au même titre que Windows, avec les mêmes types d’enregistrement sous chaque machine, et les équipements réseau SNMP arrivent par leur propre source de données.

  4. 04

    Chaque exécution est traçable.

    Un enregistrement d’historique par synchronisation, de « en attente » à « terminé » en passant par « en cours », avec un journal des messages système pour tout ce qui mérite une explication et un paramètre de rétention qui empêche l’historique de grossir indéfiniment.

  5. 05

    Un nouveau point de terminaison ne nécessite pas une nouvelle application.

    Les métadonnées des sources de données résident dans une table : la synchronisation peut donc être orientée vers d’autres points de terminaison de l’API sans modifier l’application elle-même.

L’application découvre-t-elle quelque chose par elle-même ?

Non, et il vaut la peine d’être précis à ce sujet. La découverte et l’inventaire ont lieu dans CerteroX, avec dix méthodes et six familles de systèmes d’exploitation. L’application lit l’API de la plateforme et écrit des éléments de configuration dans la CMDB. C’est une alimentation, pas un second outil de découverte en concurrence avec celui que vous avez.

Quelle configuration faut-il avant la première synchronisation ?

Trois paramètres : API Url, API Username et API Password. L’application est livrée avec ses sources de données par défaut et leurs transform maps : elle fonctionne donc ensuite avec une configuration minimale. La taille de page de l’API et la rétention de l’historique sont les deux paramètres que vous voudrez peut-être ajuster par la suite.

Qu’est-ce qui arrive réellement dans la CMDB ?

Les ordinateurs Windows, macOS et Linux et, pour chacun, les disques, cartes réseau, modules mémoire, volumes, logiciels et installations de logiciels. Les disques deviennent des périphériques de stockage CMDB, les volumes des systèmes de fichiers CMDB et les logiciels des packages CMDB. Les équipements réseau SNMP arrivent par leur propre source de données.

À quelle fréquence la synchronisation a-t-elle lieu, et peut-on la forcer ?

Une exécution de script planifiée ServiceNow déclenche la synchronisation en arrière-plan selon le calendrier que vous définissez. Le bouton Sync Now, sur la page des sources de données et sur celle de l’historique, sert quand vous en avez besoin immédiatement.

Comment savoir ce qu’a fait une exécution ?

Chaque synchronisation écrit un enregistrement d’historique qui passe de « en attente » à « en cours » puis « terminé », avec un journal des messages système associé pour le débogage. Les anciens enregistrements sont purgés selon la rétention configurée : l’historique reste utile au lieu de devenir lui-même un problème de stockage.

Nous voulons des données que les sources de données par défaut ne contiennent pas. Est-ce une personnalisation ?

Pas pour l’application. Les métadonnées des sources de données sont stockées dans une table : d’autres points de terminaison de l’API peuvent donc être ajoutés comme sources de données sans modifier le code de l’application.

La position de licences passe-t-elle aussi dans ServiceNow ?

Non. La position de licences effective reste dans CerteroX SAM, là où se trouvent les droits d’utilisation, les preuves d’utilisation et les moteurs par éditeur. Ce qui passe dans ServiceNow, c’est l’inventaire : les éléments de configuration et le détail qui les compose.

L’inventaire, dans la CMDB

Ouvrez un CI.
Voyez ce qui est arrivé dessous.

Une synchronisation parcourue de bout en bout : tables intermédiaires vidées, chaque source de données paginée depuis l’API, chaque transform map écrivant dans la CMDB, et l’enregistrement d’historique laissé ensuite. Dites-nous quelles classes de la CMDB comptent le plus pour votre centre de services, et nous les ouvrons en premier.

Rien à connecter, et quelqu’un en ligne capable de répondre sur les sources de données et les transform maps.