Close

ThinkTilt rejoint la famille Atlassian. En savoir plus.

Ready for ITSM at high velocity?

Guide des bases de données de gestion des configurations (CMDB)

Selon ITIL 4, une base de données de gestion des configurations (CMDB) « est utilisée pour stocker les enregistrements de configuration tout au long de leur cycle de vie et… pour maintenir les relations entre [eux] ».

En d'autres termes, votre CMDB stocke des informations sur la configuration des éléments au sein d'une organisation, y compris le matériel, les logiciels, les systèmes, les installations et parfois le personnel. Il appartient à l'organisation informatique de définir les éléments à suivre et la façon de le faire. Ces données de configuration peuvent inclure des relations et des interdépendances entre les éléments, l'historique des changements apportés à chaque élément, ainsi que la classe et les attributs (type, propriétaire et importation) de chaque élément.

Dans une CMDB, ces éléments suivis sont appelés « éléments de configuration » (CI). ITIL 4 définit les éléments de configuration comme « tout composant qui doit être géré pour fournir un service informatique ».

L'objectif d'une CMDB est de fournir à une organisation les informations nécessaires pour prendre de meilleures décisions métier et exécuter des processus ITSM efficaces. En centralisant toutes les informations de configuration, les dirigeants peuvent mieux comprendre les éléments de configuration (CI, configuration item) critiques et leurs relations. Les CMDB sont importantes dans les domaines de l'analyse d'impact, de l'analyse des causes profondes, de la conformité juridique, de la gestion des incidents et de la gestion des changements.

Gestion des actifs informatiques (ITAM) et gestion de la configuration

Maintenant, lorsque nous parlons des actifs et des éléments de configuration, de la gestion des actifs informatiques (ITAM) et de la gestion de la configuration, la confusion peut rapidement s'installer. À première vue, il semble que les termes soient interchangeables, mais en vérité, ils peuvent concerner les mêmes composants d'une entreprise, mais sous différents angles.

Alors, quelle est la différence entre ces pratiques ? Prenons l'exemple d'une voiture, qui peut être à la fois un actif (quelque chose représentant une valeur financière pour une entreprise) et un élément de configuration (un composant dynamique important pour les services d'une organisation).

Les considérations relatives à cette voiture varient dans les différentes pratiques :

Considérations relatives à l'ITAM

Considérations relatives à la gestion de la configuration

  • Quand avez-vous acheté la voiture ?
  • Chez quel concessionnaire ?
  • À quel prix ?
  • Quels sont la marque, le modèle et la finition ?
  • Quelle est sa dépréciation ?
  • Que couvre la garantie ?
  • Quel type d'huile doit être utilisé ?
  • À quelle fréquence l'huile doit-elle être vérifiée ?
  • Combien de kilomètres avant le prochain changement d'huile ?
  • Quelle est la configuration du moteur ?
    • A-t-il été modifié ?

Mais tous les actifs ne sont pas systématiquement des éléments de configuration. Pour certaines entreprises, il peut être logique de suivre des actifs qui ne disposent pas de la configuration et des dépendances qui les rendent intéressants à suivre en tant qu'éléments de configuration. Par exemple, une compagnie d'électricité peut suivre des poteaux électriques individuels en tant qu'actifs. Ceux-ci ont une valeur financière pour l'organisation, et il peut être intéressant de les suivre dans la gestion des actifs pour savoir quand ils sont endommagés ou encore remplacés.

En revanche, le poteau électrique peut ne pas être un élément de configuration pertinent. Il n'existe aucun réseau d'interdépendances à suivre. Un morceau de bois ne se configure pas. En outre, essayer de saisir des poteaux électriques en tant qu'élément de configuration dans votre CMDB peut ne pas ajouter suffisamment de valeur au système pour justifier le temps et les efforts investis.

Caractéristiques d'une CMDB

Nous comprenons donc l'utilité d'une CMDB, son rôle dans la gestion de la configuration, et comment elle se rapporte à la gestion des actifs et diffère de celle-ci. Mais à quoi ressemble la fonctionnalité de CMDB à un niveau plus pratique ?

Les caractéristiques fonctionnelles essentielles d'une CMDB sont les suivantes :

Des tableaux de bord homogènes avec des métriques et des analyses sur les éléments de configuration facilitent le suivi de l'état des éléments de configuration, de leurs relations, de l'impact des changements, des tendances qui mènent aux incidents ou aux problèmes, et du coût (en argent et en ressources) de la création et de la maintenance de chaque service au sein d'une organisation.

Des fonctionnalités de conformité qui vous fournissent des enregistrements détaillés et une visibilité pour les auditeurs, non seulement sur l'état actuel des éléments de configuration, mais aussi sur leurs changements historiques, les contrôles ou encore les incidents.

La création d'éléments de configuration et la saisie en temps opportun de leurs données, prises en charge par trois méthodes différentes : saisie manuelle, intégrations (basées sur l'API, SCCM) et outils de découverte qui effectuent des analyses automatisées de toutes les adresses IP dans le réseau d'une organisation afin de collecter efficacement des informations logicielles et matérielles et de constituer un inventaire de chaque appareil physique et virtuel de l'entreprise.

La prise en charge des ensembles de données fédérés, y compris la normalisation et le rapprochement des éléments de configuration et de leurs données.

La cartographie des services informatiques (généralement une illustration graphique des relations et des dépendances).

Des contrôles d'accès qui vous permettent d'accorder différents niveaux d'accès à différentes personnes ou équipes selon les besoins, et de retracer les changements jusqu'à leur source en cas de questions ou d'incidents.

Les avantages d'une CMDB

Une CMDB contribue essentiellement à résoudre deux problèmes : le cloisonnement des données et l'obsolescence des informations. Avant d'implémenter une CMDB, la plupart des organisations disposent de données dispersées dans divers systèmes avec différents propriétaires, ce qui les empêche de se faire une vue d'ensemble des tâches de configuration et de leurs interdépendances, et complique encore davantage l'identification des informations à jour (ou non).

Les équipes passent alors à côté d'un contexte important lors de la prise de décisions. Cela peut avoir une incidence sur l'évaluation des risques et les rapports, nuire à la prise de décision, ralentir la résolution des tickets et, en fin de compte, se répercuter tant sur les finances que sur la réputation de l'entreprise.

Par exemple, supposons que les données de l'élément de configuration A soient hébergées dans un service et que celles de l'élément de configuration B le soient dans un autre. Le bon fonctionnement de l'élément de configuration B dépend de l'élément de configuration A. Mais lorsque le service responsable de l'élément de configuration A décide de la mettre hors ligne pour une maintenance, il n'a aucune visibilité sur l'impact de cette opération sur l'élément de configuration B.

Au mieux, une certaine confusion s'installe entre les équipes. Au pire, cela peut engendrer un incident majeur. Et une bonne CMDB suffirait à éviter ce scénario.

Forrester identifie trois cas d'usage dans lesquels une CMDB revêt une importance vitale de nos jours :

Planification

Les responsables technologiques ont besoin des données de la CMDB pour planifier, à la fois à un niveau général (architecture d'entreprise, gestion de portefeuille) et à un niveau plus détaillé (gestion des actifs et des capacités).

Comptabilité

L'équipe financière informatique exige des enregistrements des apps ou des codes de service afin d'allouer les documents de facturation et de gérer correctement les finances de l'entreprise.

Opérations

Une CMDB améliore un certain nombre de pratiques ITSM essentielles, notamment la gestion des changements, la gestion des incidents et la gestion des problèmes.

Dans le domaine de la gestion des changements, une CMDB peut améliorer l'évaluation des risques en anticipant les utilisateurs, systèmes et autres tâches de configuration susceptibles d'être touchés. Dans les secteurs réglementés, elle peut également contribuer à la conformité, aider les équipes à gérer les contrôles et fournir une piste d'audit claire.

Dans la gestion des incidents, une CMDB peut aider à identifier les changements qui ont conduit à un incident et à en accélérer la résolution. Les dossiers d'incident peuvent être associés aux éléments de configuration pertinents, ce qui aide les équipes à suivre l'évolution des incidents parallèlement aux actifs qu'ils affectent.

Dans la gestion des problèmes, une CMDB peut vous aider à analyser les causes profondes, et aider les équipes à identifier la source d'un problème plus rapidement. Elle peut également prendre en charge une gestion des problèmes proactive en aidant les équipes à identifier les actifs qui doivent être mis à niveau afin de réduire les coûts de service et les temps d'arrêt imprévus.

En fin de compte, une CMDB devrait réduire la complexité, prévenir les erreurs, augmenter la sécurité et favoriser la bonne exécution des pratiques ITSM telles que la gestion des changements et des incidents.

Les défis des CMDB

Les statistiques du secteur nous indiquent que seuls 25 % des organisations tirent une valeur significative de leurs investissements dans une CMDB. Un taux d'échec aussi élevé est relativement problématique pour la réputation de cette technologie.

La bonne nouvelle ? Les raisons de cet échec sont évitables et se répartissent généralement en six catégories prévisibles :

Culture

Comme pour tout au sein d'une organisation, la culture et l'engagement de l'équipe sont parmi les facteurs les plus importants pour déterminer la réussite des nouvelles technologies et des nouveaux processus. 93 % des dirigeants interrogés dans une étude récente de Harvard Business Review ont déclaré que le plus grand défi de la transformation numérique axée sur les données était le personnel et les processus. Cela vaut pour les projets de CMDB.

Pertinence

Les CMDB sont souvent appelées « sources de référence unique », ce qui peut parfois mener les organisations à essayer de regrouper toutes leurs données sans réfléchir aux cas d'usage pertinents à leurs besoins.

Comme pour tout dépôt de données, une CMDB doit contenir des données ciblées et utiles qui soutiennent les processus internes tels que la gestion des changements. Assurez-vous que votre CMDB a un objectif de valeur clairement défini, un propriétaire et une méthode de mise à jour des données pour refléter tous les changements.

Centralisation

Lorsque nous affirmons qu'une CMDB est un endroit centralisé pour afficher les données d'actifs, cela ne signifie pas que toutes les données d'actif doivent uniquement se trouver dans la CMDB. Cette idée fausse courante peut engendrer beaucoup de travail pour les équipes qui tentent de déplacer toutes leurs données dans cette « source de référence unique ». La vraie bonne pratique ici consiste à fédérer les données provenant d'autres outils afin que l'outil le plus approprié soit utilisé pour soutenir chaque cas d'usage.

Par exemple, il est souvent plus logique de conserver les données financières dans un outil de gestion financière informatique (ITFM) et des informations de licence logicielle dans un outil de gestion des actifs logiciels (SAM). Les données peuvent être importées et mises en miroir dans votre CMDB, même s'il ne s'agit pas de l'espace de stockage principal.

Précision

De nombreuses organisations ont du mal à développer et à maintenir une CMDB précise. Les problèmes les plus courants sont les outils de découverte qui s'exécutent trop rarement, l'absence de règles d'automatisation ou la dépendance aux entrées manuelles. La réponse type à ces défis est la découverte basée sur des événements qui renforce la découverte traditionnelle et ascendante.

Pour ceux qui ne sont pas familiers avec ces termes, la découverte ascendante désigne une situation dans laquelle les actifs sont cartographiés en commençant par l'infrastructure pour se déployer dans les éléments de configuration orientés client. La découverte pilotée par des événements implique que quelque chose se produise (un événement au sein d'un système, un problème, etc.) qui amène les systèmes à communiquer les uns avec les autres. Ensuite, en fonction de cet événement, le système cartographie les éléments de configuration associés et leurs connexions.

Tous les éléments de configuration ne sont toutefois pas détectables. Par exemple, votre équipe peut souhaiter cartographier des moniteurs dans votre CMDB. Étant donné que les moniteurs ne sont pas détectables par un système automatisé, ils doivent être saisis manuellement via une feuille de calcul (ou une méthode similaire).

Pour être précis, il est essentiel d'exploiter la puissance de la découverte ascendante et pilotée par des événements afin de vous faire une image la plus claire possible de vos actifs et de leurs connexions.

Processus

Certaines organisations ont l'impression que les CMDB servent à modéliser l'infrastructure et les logiciels hérités, plutôt que la nouvelle stack d'infrastructure cloud et à définition logicielle, ainsi que les workflows modernes qui y sont hébergés.

La vérité est que nous ne devrions pas laisser le débat sur la sémantique nous empêcher d'explorer la véritable valeur du suivi de nos tâches de configuration (héritées et modernes) dans un outil qui nous fournit une vue d'ensemble de nos écosystèmes techniques.

Outils

Il est essentiel de choisir le bon outil si vous voulez éviter de gonfler les tristes statistiques d'échec ci-dessus. Certains outils de CMDB ne représentent que des dépôts d'actifs : des structures de données fixes sur l'infrastructure physique héritée et des outils de découverte qui réagissent lentement à tout changement. Pour réussir, il vous faut une CMDB qui tient compte des nouveaux types d'actifs et capable d'évoluer rapidement.

Choisir les éléments à gérer dans votre CMDB

Il n'y a pas de réponse unique quant aux tâches de configuration que vous devriez gérer au sein de votre CMDB. La configuration de la CMDB doit dépendre des cas d'usage et des objectifs de chaque organisation. En général, il est logique de commencer à un niveau général et de bien configurer les services appropriés, puis d'approfondir partout où c'est nécessaire pour atteindre vos objectifs organisationnels.

Cela dit, les tâches de configuration peuvent être regroupées dans une large mesure en tant qu'entités techniques ou non techniques.

Les entités techniques comprennent les services aux entreprises, les services techniques, les apps, les logiciels, les bases de données, les conteneurs, les machines virtuelles, les systèmes d'exploitation, le matériel, les réseaux ou encore les ports.

Les entités non techniques peuvent également être modélisées dans votre CMDB si vous devez les représenter comme dépendantes ou affectées par d'autres actifs dans votre cartographie des services informatiques. Elles peuvent comprendre des utilisateurs, des clients, des organisations, des emplacements, des contrats de service ou encore des documents.

Enfin, les services cloud devraient être pris en compte dans la conception d'un modèle de CMDB. Tant les offres SaaS (par exemple, Google Apps, Dropbox ou encore Salesforce) que les offres IaaS (par exemple, DigitalOcean, Linode, Rackspace ou Amazon Web Services) peuvent être représentées en tant que tâches de configuration, si nécessaire.

Contrairement aux CMDB héritées, Insight pour Jira Service Management offre une structure de données flexible et ouverte qui vous permet de gérer toutes vos ressources.