Au moyen d’exemples pratiques, voyons comment la CMDB peut rapprocher l’infrastructure et les services, et permet de créer de la valeur.

Les relations entre éléments d’infrastructure constituent une partie importante de la CMDB car elles apportent de l’information cruciale pour la description du Système d’Information. Dans le choix d’une CMDB, il est important d’évaluer les fonctionnalités de gestion des relations. Par exemple : l’import et l’export massif de relations doivent être aisés ; la visualisation des relations est un atout supplémentaire et permet une navigation intuitive dans la CMDB.

Au travers de deux exemples, voyons quelles peuvent être les utilisations des relations dans un environnement opérationnel, et les bénéfices qui en découlent.

Exemple 1 - Utilisation des relations pour configurer la supervision

Les informations de relation permettent de déterminer quels sont les éléments d’infrastructure critiques pour un processus métier donné. Ceci permet de générer de manière automatique un paramétrage optimisé de la supervision.

Le pilotage automatique de la supervision par la CMDB engendre des réductions de coûts opérationnels :
 la mise en production d’un nouvel élément d’infrastructure ou d’une application sont contrôlés de façon centrale à partir de la CMDB, quelle que soit la complexité de l’infrastructure de supervision (exemple : multiples serveurs de supervision en cascade) ;
 les alarmes remontées par la supervision intègrent de l’information métier (priorité, impact métier), qui sera prise en compte pour optimiser le traitement de l’incident.

Exemple 2 - Calcul des contacts à notifier

Lorsque une alarme est générée par le système de supervision, les relations stockées dans la CMDB peuvent être utilisées pour évaluer l’ensemble des composants impactés, jusqu’au processus métier. On peut alors en déduire la liste des personnes à notifier.

En étant intégrée à la CMDB, la supervision pourra exploiter ces relations, et à partir d’une alarme déterminer automatiquement la liste des personnes à notifier :
 Dans 80% des cas, un incident est directement lié à un changement. En informant le responsable technique de switch2 (Contact1) , celui-ci pourra, le cas échéant, faire le lien avec un changement récemment effectué sur cet équipement, et faciliter la résolution de l’incident
 Un incident sur le réseau entraîne à coup sûr une indisponibilité de serveurs. Le responsable des serveurs (Contact2) va être sollicité au sujet de cette panne. Puisqu’il est notifié dès l’apparition de l’incident, il n’aura pas à mener d’investigation supplémentaire.
 Lorsqu’un incident technique survient, les utilisateurs finaux non informés vont contacter l’équipe de support, qui doit établir la corrélation entre ces appels et l’incident technique, puis gérer la communication avec les utilisateurs. En informant les utilisateurs de manière pro-active (comme Contact3), on supprime ces appels inutiles, on améliore la satisfaction des utilisateurs, et enfin on permet à ces derniers de mettre en place une solution de contournement.

Si, de plus, les relations sont différenciées en fonction du rôle de chaque interlocuteur, alors le contenu des notifications pourra être adapté à la cible. Cette différenciation prend tout son sens lorsqu’il s’agit d’un client externe. Cela permet d’envisager un traitement des alarmes très automatisé, avec création d’un ticket d’incident et possibilité d’envoyer des rapports sur l’état de cet incident aux acteurs concernés.

On voit ici les gains suivants :
 amélioration de la satisfaction des utilisateurs, rapidement informés de l’arrêt et de la reprise de l’application ;
 amélioration de la pertinence des rapports de disponibilité, qui prennent en compte l’origine des incidents ;
 accélération de la résolution des incidents ;
 diminution du nombre d’appels au support.

Conclusion

Ces deux exemples simples permettent de mieux cerner l’importance de modéliser dans la CMDB les relations entre actifs pour la gestion opérationnelle du SI.

Néanmoins, on constate que ces informations font défaut dans beaucoup de cas. On peut avancer les explications suivantes :

 Le chargement initial des données s’effectue souvent à partir de listes plates. C’est presque toujours le cas à la première installation d’une CMDB, ou l’on dispose en général de fichiers type Excel.
 La solution de gestion SI se focalise souvent sur la collecte automatique des données techniques. Mais d’une part, il est complexe d’agréger automatiquement les données pour construire des relations pertinentes. D’autre part, certaines informations ne sont pas disponibles dans l’infrastructure technique. Il s’agit par exemple de la relation entre un responsable opérationnel et les équipements qui sont sous sa responsabilité. Cette information doit donc être renseignée manuellement.
 Les personnes qui sont chargées de mettre à jour la CMDB ne sont pas toujours celles qui en tireront un bénéfice, ce qui peut constituer un frein à l’actualisation des informations.
 Les contrôles de saisie classiques (par exemple champs obligatoires lors de la création d’un nouveau composant dans la CMDB) ne se transposent pas facilement pour la saisie de relations. Cela est même totalement inapproprié lorsque l’information est répartie entre plusieurs personnes et doit donc être saisie de manière collaborative.

Pour disposer d’information sur les relations, l’enjeu est donc d’adapter outils et processus pour que cette information soit décrite dans la CMDB, mais aussi pour qu’elle soit pérennisée, à travers son utilité pour les équipes opérationnelles.

La solution Combodo s’appuie sur le logiciel iTop, qui a été conçu pour répondre à ce défi.

Romain Quetiez

Co-fondateur de Combodo et contributeur au projet iTop