Deux questions, deux outils
Un inventaire répond à : qu'est-ce que je possède, où, dans quel état. C'est une liste d'objets, et une bonne liste suffit à commander du matériel, à suivre des garanties et à préparer un budget.
Une CMDB (base de données de gestion des configurations : la carte de ce qui compose vos services et de ce qui dépend de quoi) répond à une autre question : si ceci tombe, qu'est-ce qui s'arrête, et pour qui ?
La différence n'est pas le nombre de champs. C'est que la seconde contient des relations, et que ce sont elles qui portent la réponse.
L'exemple qui rend la chose évidente
Un inventaire dit : un serveur nommé SRV-04, une machine virtuelle, une base de données, une application de gestion commerciale. Quatre lignes justes, aucune information.
Une CMDB dit : l'application de gestion commerciale s'appuie sur cette base, qui est hébergée par cette machine virtuelle, qui tourne sur SRV-04, et ce service est utilisé par le service commercial, soit quatorze personnes.
À trois heures du matin, devant une alerte sur SRV-04, la première vous laisse deviner. La seconde vous dit que quatorze commerciaux seront bloqués à neuf heures, ce qui décide de réveiller quelqu'un ou non.
Les quatre relations qui suffisent
La modélisation des relations peut occuper une carrière entière. Quatre types couvrent la quasi-totalité des besoins d'une PME.
Est hébergé par : une machine virtuelle sur un hôte, une application sur un serveur.
Dépend de : une application qui ne fonctionne pas sans un annuaire ou un service de courriel.
Est utilisé par : le lien vers les personnes ou le service métier. C'est celui qui permet de traduire une panne technique en impact, et c'est le plus souvent absent.
Est connecté à : le poste et le port de commutateur, remonté automatiquement par un inventaire réseau.
Ajouter des types au-delà de ceux-là est possible. Le faire avant de savoir en tirer quelque chose, en revanche, produit une modélisation que personne ne maintient.
Ce qu'il ne faut surtout pas modéliser
C'est la partie que les méthodes disent rarement, et c'est celle qui sauve les projets.
Ne modélisez pas ce que vous ne mettrez pas à jour. Une relation fausse est pire qu'une relation absente : elle donne une confiance injustifiée le jour où l'on décide sur sa foi.
Ne descendez pas plus bas que votre capacité d'action. Modéliser chaque barrette de mémoire n'a de sens que si vous les remplacez individuellement. Sinon, le poste suffit comme unité.
Ne modélisez pas ce que la découverte automatique sait faire mieux. Les logiciels installés, les adresses, les ports : laissez la machine, elle ne se lasse pas.
Le bon test avant d'ajouter un élément ou une relation : quelle décision prendrai-je grâce à cette information ? Sans réponse précise, on n'ajoute pas.
La fraîcheur, seul critère de qualité
Une CMDB se juge à un chiffre : la part de ses informations vérifiées récemment.
Une base exacte à quatre-vingt-quinze pour cent est utile ; à soixante, elle est dangereuse, parce que personne ne sait quels quarante pour cent sont faux et que l'équipe finit par tout revérifier à la main, ce qui annule son intérêt.
Deux moyens d'y arriver, dans cet ordre.
L'alimentation automatique partout où elle est possible. Ce qui se découvre ne se saisit pas.
Un propriétaire nommé pour ce qui reste manuel, et une revue datée. Sans propriétaire, une information manuelle est exacte le jour de sa saisie et fausse six mois plus tard.
À retenir
L'inventaire liste, la CMDB relie : la question qu'elle seule sait traiter est « si ceci tombe, qui est bloqué ». Quatre relations suffisent, dont celle vers les personnes, la plus souvent oubliée. Ne modélisez que ce que vous mettrez à jour, et jugez la base à sa fraîcheur, pas à son exhaustivité.