AFFICHER TOUT LE CONTENU

Table des matières

Articles reliés

Introduction

Le module Configurations, aussi connu sous le terme CMDB, constitue le cœur d'Octopus. Dans le sens que les CI qui le composent peuvent être reliés à tous les autres modules.

On identifie le CI en cause dans un incident, le CI impliqué dans un événement, on relie les CI à une demande de service, un problème ou un changement, les CI couverts sont inclus dans un contrat de service ou de location, on peut identifier quels utilisateurs utilisent un CI et on planifie leur maintenance dans les requêtes planifiées bref... ils sont partout.

C'est pour cette raison qu'ils contribuent activement à mieux évaluer les situations, les impacts, les risques et à identifier les forces et faiblesses de l'infrastructure.

Mise en place et maintien de la configuration des CI

Une fois que la création des CI sera complété dans le module Configurations, le principal défi sera de maintenir la configuration de ces CI.

C'est pour cette raison qu'on recommande de faire une analyse de l'information dont on a réellement besoin avant même de l'ajouter. Car bien souvent, la tendance est d'ajouter toute information disponible sans prendre le temps de se demander si elle a de la valeur. C'est donc bon, quand on en a la possibilité de se donner du recul pour planifier ce qu'on veut faire avec la CMDB.

Des questions à se poser peuvent être :

Quels sont les types de CI dont on a la responsabilité ?
Pour chaque type de CI, quels sont les informations et attributs dont on a besoin ?
- Le niveau d'information n'est pas le même d'un élément à l'autre.
Est-ce qu'on a le contrôle de l'information sur ces CI ?
- Car si on n'a pas accès à l'information, ça sera difficile à bâtir et maintenir la CMDB pour ces éléments.
Qui est responsable de recueillir l'information ?
Qui est responsable de faire la mise à jour ?
Comment est-ce qu'on prévoit faire le contrôle de cette information pour s'assurer qu'elle est à jour ?

Ce qu'il faut comprendre est que la mise en place et ensuite la mise à jour de ces informations prend beaucoup de temps et peut être fastidieuse, on doit donc s'assurer que ce qu'on garde vaut la peine.

Recommandations

Définir au préalable une structure claire du module Configurations. Ceci inclut les types de CI, les catégories et attributs disponibles, les relations autorisées, les états nécessaires ou toute autre information utile dans la gestion des CI.
Revoir les permissions accordées aux rôles afin d'appliquer une sécurité par rapport à l'ajout, la modification et le retrait des CI
- Voir l'article Gestion des rôles.
Former les intervenants impliqués pour les sensibiliser à l'importance de maintenir les configurations de chaque CI relié dans une requête et de leur expliquer les conséquences d'un laisser-aller.
Documenter la procédure, adaptée selon les différents rôles.
- Elle pourrait être différente pour le centre de services, les techniciens et les administrateurs de système.
Identifier un intervenant qui servira de gardien des configurations - sinon, le temps, et en général l'argument de "manquer de temps" aura raison de la qualité de l'information.

Mise à jour

Dans certains cas, la mise à jour peut être automatisée, mais parfois les données devront être modifiées manuellement afin que les informations soient intègres et fiables.

Garder ces points à l'esprit sera utile :

Viser la simplicité - ne traiter que les configurations nécessaires à la livraison des services TI.
Être rigoureux - chaque CI impliqué dans une requête doit être mis à jour au fur et à mesure.
Vérifier - seuls les CI autorisés font partie de la CMDB et leur configuration doit être à jour.

L'objectif est de pouvoir trouver l'information requise et d'être confiant qu'elle est à jour.

Mise à jour automatisée

L'importation d'actifs et de configurations dans le module peut être effectuée avec l'aide des programmes Octopus et la mise à jour automatisée assurée par la mise en place de tâches planifiées Windows.

La méthode à utiliser dépend des sources disponibles. Une combinaison de plusieurs sources est possible.

ADSIReader : Importe le nom des ordinateurs faisant partie de l'Active Directory dans le type de CI Station de travail.
- Par la suite, il faut les reclasser dans le bon type de CI (serveur, portatif, etc.).
- Consulter l'article ADSIReader - Impacts sur la gestion des ordinateurs qui présente différents scénarios qu'on rencontre.
WMIUpdater : Actualise la configuration technique des ordinateurs; ceci inclut le système d'exploitation, la mémoire, le type de processeur, les logiciels installés, etc.
DataImporter : Importe des données à partir d'un système externe avec lequel un lien ODBC peut être établi.

Dans la configuration d'un type de CI, on spécifie dans l'onglet Configuration si ce type est un ordinateur, c'est-à-dire s'il peut être inspecté avec WMI dans Octopus. Dans l'onglet Attributs, on peut ajouter des attributs pour un CI donné. Ce sont eux qui seront chargés automatiquement lorsque la tâche planifiée de Windows lancera l'exécution de WMIUpdater.

Pour connaître le fonctionnement exact, consulter l'article ADSIReader - Impacts sur la gestion des ordinateurs.

Prendre le temps d'identifier les sources et de choisir celles qui contiennent de l'information de qualité. Quels que soient les efforts d'importation, si l'information source est erronée, elle sera importée dans Octopus et si elle est modifiée, elle sera réintégrée de nouveau lors de la prochaine importation. Il est donc primordial de mettre à jour la source des systèmes à partir desquels on importe.

Mise à jour manuelle

Dans un monde idéal, on aimerait automatiser la mise à jour des informations d'une CMDB et ne plus s'en occuper. Mais la réalité est toute autre. Bien sûr, on peut exploiter les possibilités d'automatisation - surtout celles qui ne requièrent pas d'intervention humaine à la source - et réduire au minimum les saisies manuelles afin d'optimiser le contenu de votre CMDB. Mais il existe des zones plus à risques, et ce sont celles où l'être humain intervient, que ce soit par de la saisie de données dans Octopus ou sur un système externe lié à Octopus.

C'est la raison pour laquelle on ne recommande de ne pas systématiquement tout inclure dans les attributs des CI et d'éviter le micromanagement de l'infrastructure.

Au début, la tentation est forte de tout centraliser dans le module Configurations, mais il est important de comprendre les conséquences d'une telle approche :

Il n'y a aucune valeur ajoutée pour l'ensemble de l'organisation - il faut mieux suivre et mesurer que ce qui est nécessaire dans la livraison des services TI, ou autre, aux utilisateurs.
L'enthousiasme du départ s'estompe avec le temps : Les ressources se découragent de cette administration qui prend du temps et la CMDB perd de son intégrité et de sa fiabilité.
Le coût de maintien des CI augmente, car la mise à jour manuelle des CI demande plus de temps et le contrôle-qualité est plus compliqué par rapport aux bénéfices qu'on en retire.

C'est en misant sur les ressources qu'on parvient à maintenir la CMDB à un niveau qui répond à aux besoins. Ce sont eux qui interviennent dans les requêtes et ce sont eux qui peuvent rapporter des erreurs au niveau de l'importation de données d'un système externe.

On doit établir des procédures claires à ce sujet. Un exemple simple pourrait être une erreur dans le nom de famille d'un utilisateur, si Octopus est relié à un système RH. La correction devra être effectuée sur ce système.

Une CMDB intègre et fiable profite à tous, améliore le quotidien, permet d'extraire des données fiables pour des analyses qui aident à la prise de décision éclairée.

Des efforts qui en valent la peine

Les efforts de maintien de la CMDB profitent à plus d'un point de vue :

Évaluation plus juste des impacts lors d'une panne ou de la planification d'un changement.
Établissement des budgets pour le remplacement d'actifs.
Un inventaire matériel à jour - on sait où est le matériel et qui le détient.
Le contrôle sur les logiciels autorisés.
La possibilité de centraliser dans la CMDB des politiques, des processus, des procédures et toute autre documentation utiles aux services ou aux utilisateurs, tels que des guides.
Audits plus faciles grâce à la disponibilité de l'information.
En bien d'autres encore!

L'amélioration continue

On recommande de faire une revue de la gestion de la CMDB sur une base régulière.

L'évolution de l'information relative aux CI est constante, tout comme les besoins face à cette information, on peut donc considérer la CMDB comme un organisme vivant qu'on se doit de bien connaître et prendre soin.

La revue devrait couvrir les éléments suivants :

Est-ce qu'un audit ou une vérification a été fait depuis la dernière fois ?
- Qu'est-ce qu'on a trouvé ?
Est-ce que les gens trouvent l'information dont ils ont besoin ?
Est-ce que l'information est à jour ?
Est-ce que certaines informations sont manquantes ?
Est-ce qu'au contraire, certaines informations ne sont pas ou plus utiles ?
- Si un type de CI ou certains attributs d'un CI ne sont plus utilisés ou finalement n'ont pas de valeur, il ne sert à rien de continuer d'en faire la mise à jour.
Est-ce que le processus est toujours clair pour tous ?
- Si de nouveaux employés se sont ajoutés à l'équipe, est-ce qu'il connaissent les rôles est responsabilités de chacun vis-à-vis la CMDB ?
Etc.

Aidez-nous à améliorer l’article

Maintien de la configuration d'un CI