La CMDB que personne ne croit

Il est deux heures du matin et une application critique est en panne. L'ingénieur de garde ouvre la CMDB, trouve le serveur et voit un propriétaire qui a quitté l'entreprise il y a un an. La base de données dont l'application dépend n'est pas enregistrée du tout. Ce qui suit est une série d'appels téléphoniques, une recherche dans des feuilles de calcul partagées et un débat sur qui est responsable de quoi. L'incident se prolonge, et le lendemain matin, quelqu'un dit à nouveau : « De toute façon, on ne peut pas se fier à la CMDB. »

Nous voyons souvent le même schéma. La base de données de configuration existe, elle coûte des efforts réels à maintenir, et pourtant personne ne lui fait confiance. Les gens gardent donc leurs propres enregistrements dans des feuilles de calcul, des wikis ou dans leur tête. Cela boucle la boucle : moins la CMDB est utilisée, moins elle est mise à jour, et moins elle mérite d'être trustée. Derrière tout cela, il y a des personnes fatiguées qui reconstruisent une image de l'infrastructure à partir de zéro chaque fois que quelque chose casse.

Pourquoi les solutions habituelles ne durent pas

La réponse typique est un projet de nettoyage. Une équipe passe des semaines à examiner les enregistrements, les données semblent bonnes pendant un certain temps, et six mois plus tard, c'est reparti pour un tour. Le problème ne se situe pas dans une mauvaise importation. C'est la façon dont les données sont créées et la façon dont elles vieillissent.

• Saisie manuelle sans vérification. Plusieurs personnes créent des éléments de différentes manières, et personne ne vérifie si le résultat a du sens.
• Pas d'historique. Lorsqu'une valeur est incorrecte, il n'y a aucun moyen de savoir qui l'a modifiée, quand, ou d'où elle vient.
• Plus d'une vérité. L'organisation conserve une CMDB primaire dans un outil et des données opérationnelles dans un autre. Sans lien fiable, les enregistrements divergent.
• Pas de boucle de rétroaction. Les incohérences apparaissent au pire moment possible : lors d'un incident.

Une meilleure façon de penser à la qualité des données

La confiance dans une CMDB ne vient pas de la perfection. Elle vient de la transparence. Les gens se fieront aux données lorsqu'ils pourront voir d'où elles viennent, quand elles ont été confirmées pour la dernière fois et ce qui ne va pas avec elles. Nous recommandons de bâtir sur quatre principes :

1. Automatiser autant que possible. La découverte automatique et les importations battent la copie manuelle.
2. Chaque changement a un auteur et une source. L'historique des versions est la base pour tracer les erreurs et pour les audits.
3. Vérifier la qualité en continu. Il est bien préférable de trouver une incohérence un mardi après-midi calme que lors d'une panne nocturne.
4. Être clair sur l'enregistrement primaire. Si une autre CMDB est le système d'enregistrement, il doit être clair quel élément correspond à quel autre.

Comment Eywo Stratum gère cela

Eywo Stratum fonctionne avec 34 classes d'éléments, des services métier et des applications aux bases de données, serveurs virtuels et physiques, IBM Power, conteneurs et stockage, en passant par les périphériques réseau et OT. Vous pouvez le peupler de plusieurs manières et les combiner :

• via l'API de découverte, qui est alimentée par des outils de scan et d'inventaire,
• en important des fichiers CSV ou Excel, généralement lors d'un déploiement ou d'une migration,
• en créant des éléments manuellement là où rien d'autre ne peut les capturer,
• en synchronisant avec une CMDB primaire telle que ServiceNow ou SMAX via des ID externes, de sorte qu'il soit toujours clair quel enregistrement correspond à quel autre.

Chaque changement apporté à un élément crée une nouvelle version. L'historique montre qui a effectué le changement, quand, exactement ce qui a changé et d'où viennent les données : découverte automatique, importation, synchronisation ou une personne. Lorsqu'une valeur s'avère incorrecte, son origine peut être tracée en quelques instants.

En plus de cela, il y a des vérifications de qualité des données. Stratum signale les incohérences et les enregistrements incomplets afin que l'équipe puisse les corriger dans le cadre du travail normal plutôt que sous la pression d'un incident. Au fil du temps, la CMDB devient le premier endroit où les gens regardent, parce qu'ils savent ce qu'ils y trouveront.

Conclusion

Une CMDB à laquelle personne ne fait confiance n'est pas vraiment un problème technique. C'est un problème de confiance, et la confiance ne peut pas être imposée. Elle ne peut être gagnée que par la population automatisée, l'historique transparent, les vérifications continues et un lien clair vers l'enregistrement primaire. La récompense est une opération où l'ingénieur de garde trouve la réponse dans les données la nuit, et non sur le téléphone d'un collègue.

La gestion de la CMDB, l'historique des versions, les importations et les vérifications de qualité des données font partie de l'édition Standard ; la synchronisation avec une CMDB primaire via des ID externes est disponible dans l'édition Enterprise.