Base de Données de Gestion des Configurations

Un élément de configuration (CI) est tout composant qui doit être géré pour fournir un service : serveur, poste de travail, commutateur réseau, application, schéma de base de données, licence, contrat, ou la documentation qui explique comment l'ensemble s'articule. Chaque CI porte des attributs comme le propriétaire, l'emplacement, la version, le numéro de série et le statut de cycle de vie. Dans la plupart des conceptions, il conserve aussi l'historique de ses états dans le temps.

Ce qui distingue une CMDB, c'est que les relations ont le même poids que les éléments eux-mêmes. Une fiche de CI indique ce qu'est un composant. Une relation indique que l'application de paie fonctionne sur un cluster précis, que ce cluster dépend d'une baie de stockage et qu'une agence se connecte via un routeur particulier. Lues ensemble, ces liens forment un graphe de dépendances. Il répond à des questions qu'une liste plate ne peut pas traiter : si cet appareil tombe en panne, quels services s'arrêtent et qui est touché ?

Dans l'ITSM, la CMDB est le point de référence dans lequel d'autres processus écrivent et à partir duquel ils lisent. La gestion des incidents relie chaque incident aux CI concernés. Cela accélère le tri et rend visibles les pannes récurrentes sur un même composant. La gestion des problèmes analyse ces regroupements pour trouver les causes racines. La gestion des changements est le principal processus d'écriture : un changement approuvé consigne les CI qu'il va toucher, et la CMDB doit refléter le nouvel état une fois le changement terminé.

C'est le graphe de dépendances qui transforme les fiches en décisions. Avant d'approuver un changement, on peut estimer son rayon d'impact en suivant les relations depuis les CI concernés. Après un incident, le même parcours indique quoi vérifier pour détecter les effets secondaires. Une CMDB consultée uniquement lors des audits ne livre qu'une fraction de cette valeur.

Les deux sont liés, mais ils répondent à des questions différentes. L'inventaire des actifs, élément central de la gestion des actifs IT (ITAM), indique ce que l'organisation possède, où se trouve chaque actif et qui en est responsable. Ses utilisateurs naturels sont la finance, les achats et les services généraux. La CMDB indique comment les composants sont liés entre eux et ce qu'un changement sur l'un d'eux affecte. Ses utilisateurs sont les équipes incidents, problèmes et changements.

En pratique, la frontière est progressive. De nombreuses organisations partent d'un simple inventaire et y ajoutent des relations à mesure que leurs processus de gestion des services mûrissent. Un test simple s'applique : un référentiel où rien n'est relié à rien est un inventaire avec des champs supplémentaires, quel que soit son nom.

La plupart des CMDB combinent la découverte automatisée et la saisie manuelle des fiches. La découverte repose sur une collecte par agents, un balayage réseau et des intégrations avec les plateformes cloud et d'annuaire. Elle trouve ce qui existe réellement et repère les écarts entre l'état enregistré et l'état réel. Les contrats, les définitions de services et les autres éléments qui ne peuvent pas être scannés sont saisis et maintenus à la main.

Lorsque plusieurs outils détiennent chacun une partie de la vérité, la CMDB les fédère ou les réconcilie. Une source fait autorité pour chaque type d'attribut. Les conflits se règlent par une règle, non par la discussion. L'exactitude est le résultat d'un processus continu, pas d'un chargement ponctuel. Sans propriétaire désigné, elle se dégrade vite.

Dans l'Anexet Inventory, la fiche de chaque poste de travail liste les appareils et les applications installées, avec le type d'appareil, le fabricant, la version et la date d'installation. Ces enregistrements sont la matière première à partir de laquelle une CMDB construit ses éléments de configuration.

1 / 2

• 
• 

Le schéma d'échec est bien connu. Le périmètre initial couvre tout d'un coup, et le projet se noie dans la qualité des données avant d'avoir livré quoi que ce soit. Les fiches ne sont mises à jour que lorsque quelqu'un y pense. Avec le temps, la base ne correspond plus à la réalité et le personnel cesse de lui faire confiance. Elle est alors techniquement vivante et pratiquement morte. Les pratiques suivantes distinguent les déploiements qui survivent des autres.

Une CMDB est une donnée de référence, pas un collecteur. Elle observe rarement l'environnement par elle-même. Elle agrège plutôt ce que signalent les outils de découverte, de supervision et de gestion. En retour, elle les enrichit. Les alertes de supervision gagnent du contexte sur ce qu'est un hôte et le service qu'il rend. Les investigations de sécurité partent d'une cartographie connue de ce qui devrait exister. La planification de reprise sait quels composants restaurer et dans quel ordre.

Ses limites découlent de la même conception. Une CMDB ne détecte pas les intrusions, ne contrôle pas les appareils et ne remplace pas la visibilité sur les postes. Elle indique à l'organisation à quoi son environnement devrait ressembler, afin que les autres contrôles puissent interpréter ce qu'ils voient. Des contrôles comme la prévention des pertes de données (DLP) agissent là où les données circulent réellement, comme le montre le tableau.

Commencez par les services dont l'interruption coûterait le plus cher, et modélisez les composants dont ils dépendent. Garder le modèle proche de la réalité est la discipline centrale de la gestion des configurations, donc n'étendez le périmètre qu'après un audit d'exactitude concluant.