Livre blanc Gestion de configuration IT Mettre en œuvre une CMDB (Configuration Management Database) Arnaud Bonneville Edition 4, Novembre 2011
Table des matières 1 Résumé... 3 2 Définitions... 4 3 De la gestion d inventaires à la CMDB... 8 4 Avant la mise en œuvre... 9 4.1 Pourquoi mettre en place une CMDB?... 9 4.2 Recensement de l existant... 10 4.3 Définition d un modèle cible... 11 4.4 Définition d un plan d implémentation... 13 5 L approche processus... 14 5.1 Les acteurs de la gestion de configuration... 14 5.2 Planification... 15 5.3 Identification et nommage... 15 5.4 Contrôle et maintenance... 17 5.5 Vérification et audit... 17 5.6 Production de rapports... 18 6 Conseils d implémentation... 19 7 A propos de Baccou Bonneville Consultants... 20 8 A propos de l auteur... 21 Page 2 / 21
1 Résumé La mise en œuvre dans une entreprise d une base de données de gestion de configuration, ou CMDB, associée aux processus de gestion de configuration et de gestion des changements, est une étape primordiale permettant au service informatique d améliorer la qualité de service fournie aux utilisateurs tout en augmentant son efficacité. Cette démarche, décrite dans les bonnes pratiques d IT Service Management (ITIL), ne peut être effectuée sans avoir préalablement bien défini les principaux objectifs de cette CMDB : analyse d impact, respect des régulations Sarbanes-Oxley, amélioration de l efficacité opérationnelle, etc. La mise en place d une CMDB part rarement de zéro ; souvent le service informatique dispose déjà de bases d inventaires qui décrivent l infrastructure informatique (serveurs, équipements réseau, applications ). L enjeu de la CMDB est de fédérer tous ces référentiels et de relier leurs informations à travers un réseau de relations. A travers une étude préalable consistant à recenser toutes ces informations, vous serez en mesure de définir les informations utiles pour l ensemble du service informatique, puis à en déduire un modèle de données cible qui servira de fil conducteur à l implémentation de la CMDB. Ce modèle cible ne pourra pas être réalisé en une seule étape, vous devrez définir une séquence d implantation en respectant les objectifs fixés par la DSI. Pour construire une CMDB, ce n est de loin pas qu une question d outils et d inventaires. La réussite d un projet de gestion de configuration est conditionnée par la mise en place d un processus effectif de gestion de configuration, dont les quatre activités identification et nommage, contrôle et maintenance, vérification et audit et production de rapports sont les garants d une CMDB maîtrisée dans le temps. L organisation est également fondamentale. Centrée autour d un Responsable de la Gestion de Configuration (Configuration Manager), d un Propriétaire du Processus (Process Owner) et de Responsables des CI (CI Owners), c est elle qui aura la charge de s assurer que le contenu de la CMDB sera toujours en phase avec la réalité. Ce livre blanc détaille les réflexions à mener avant de lancer un projet de mise en œuvre d une CMDB, aborde les problématiques d organisation et de processus, et contient des conseils d implémentation. Page 3 / 21
2 Définitions Terme / Acronyme ITIL Information Technology Infrastructure Library Gestion de Configuration Définition Constitué d'une série de modules, ITIL définit l'ensemble des processus nécessaires pour la prestation de services informatiques et fournit des règles de bonnes pratiques. Créé il y a plus de dix ans en Grande-Bretagne, ITIL est devenu de facto le standard international et fait partie du domaine public. Il est indépendant de la technologie et des fournisseurs, applicable à tout type d'entreprise. ITIL a vocation d établir un vocabulaire commun à l ensemble des acteurs de l industrie informatique, tout en proposant une démarche standard de mise en œuvre des services informatiques des organisations. ITIL est constitué de deux ensembles principaux de processus : Processus de soutien à la fourniture de services informatiques (IT Service Support) Processus de fourniture de services informatiques (IT Service Delivery). Parmi les processus de Service Support, à vocation opérationnelle, on retrouve les processus de Gestion d Incidents, de Gestion de Changements, de Gestion de Configuration, de Gestion des Problèmes et de Gestion des Versions. Au sein des processus de Service Delivery, à vocation stratégique, on trouve les processus de Gestion de Capacité, Gestion de Disponibilité, Gestion de Continuité, Gestion des Niveaux de Services ou Gestion Financière des Services Informatiques. C est l un des six processus ITIL de Service Support. On considère la gestion de configuration comme le processus au cœur de l efficacité d un service informatique. Elle a pour vocation de mettre à disposition de tous les autres processus opérationnels et stratégiques une base de données, la CMDB, qui contient une description des composants de l infrastructure et de leurs relations. Le processus de gestion de configuration est composé de cinq activités principales : planification, identification et nommage, contrôle et maintenance, vérification et audit, production de rapports. Contrairement aux autres processus de service support qui sont plus linéaires, à l instar de la gestion des incidents où chaque incident suit un parcours déterminé, la gestion de configuration est un processus cyclique, qui s inscrit dans des démarches d amélioration de la qualité utilisant la roue de Deming (PDCA - Plan, Do, Check, Act). Identification et Nommage Production de Rapports Contrôle et Maintenance Vérification et Audit La gestion de configuration n'est pas le processus qui déclenche les mises à jour de la CMDB c est la gestion des changements qui s'en charge, mais c'est le processus qui met à disposition Page 4 / 21
Terme / Acronyme CMDB Configuration Management Database Définition une CMDB et qui permet de la faire évoluer dans le temps. Base de données contenant toute l information pertinente sur les composants de l infrastructure informatique utilisés par l organisation, ainsi que les relations entre ces composants. Chaque composant est référencé en tant que Configuration Item (CI). Quelques exemples de CI : un serveur, une application métier, un routeur, une baie de disques, etc. Alimentée et mise à jour à travers le processus de gestion des changements, la CMDB est utilisée par un grand nombre de processus opérationnels ou stratégiques, tels que la gestion des incidents ou la gestion de capacité. Un grand nombre d éditeurs de logiciels ont inclus une CMDB dans leur offre, mais le Gartner a récemment défini quatre fonctionnalités indispensables pour réellement parler de CMDB : Réconciliation Mapping et visualisation graphique Fédération Synchronisation La réconciliation est une fonctionnalité fondamentale qui permet de confronter les données de la CMDB avec d autres sources de données, tels que des outils d inventaire automatique. Les mécanismes de réconciliation permettent de «raccrocher» un CI avec des données provenant d autres outils, à des fins d audit de la CMDB ou de rapprochement de sources de données hétérogènes. La visualisation graphique est sans conteste une fonctionnalité essentielle à l exploitation des données de la CMDB. Dans un contexte où les relations entre CIs prennent toute leur importance, il est important de pouvoir représenter les relations sous forme graphique afin de mieux appréhender l infrastructure en évitant de cliquer de manière fastidieuse d un CI à l autre pour obtenir une compréhension globale d un système. Le graphique ci-dessous montre par exemple les relations entre un CI serveur et des CI applicatifs, eux-mêmes reliés à d'autres CI serveurs ou applicatifs. Page 5 / 21
Terme / Acronyme Définition La fédération est un concept qui permet de donner à la CMDB une notion de base de données logique. Grâce à la fédération, il est inutile de recopier des données depuis des bases hétérogènes dans la CMDB, il suffit d établir les liens entre les deux bases en identifiant les clés de réconciliation, pour que l utilisateur puisse naviguer dans la CMDB comme si toutes les données étaient physiquement présentes dans la même base de données. La synchronisation est enfin le dernier élément important qui permet d échanger de manière régulière les données de référence de la CMDB vers d autres applications, qui doivent être alimentées avec des informations d inventaire pour leurs besoins propres. CI Configuration Item Un CI est un élément unitaire de la CMDB. On définit un CI par quatre composantes : Statut Traçabilité Attributs Relations Le statut fait référence au cycle de vie du CI. Pour un CI matériel, un cycle de vie peut être : Commandé, Livré, Installé, En production, Arrêté, En panne, Mis au rebut. Pour un CI applicatif, un exemple de cycle de vie serait : En production, Arrêté, Démissionné. La traçabilité fait référence à l historisation des modifications apportées au CI. Etant donné que la mise à jour d un CI est effectuée à travers le processus de gestion des changements, la traçabilité permettra de s assurer que le CI n a pas fait l objet de mises à jour non contrôlées (activité Vérification et Audit du processus de gestion de configuration). Les attributs sont les champs d information propres au CI, et qui varient selon la classe de CI. Ainsi, un numéro de série sera propre aux CI de type matériel, alors qu un numéro de version sera plutôt présent sur des CI de type logiciel. Les relations avec les autres CI font partie intégrante du CI. Une relation a donc une caractéristique particulière d appartenir à deux CI en même temps. Les responsables des CI ont donc la charge de veiller à ce que leurs CI et toutes leurs relations soient constamment à jour. Classe de CI Les CI de même nature sont groupés en classes, chaque classe disposant de caractéristiques propres. Tous les CI d une même classe auront des comportements similaires, comme par exemple le cycle de vie. Quelques classes typiques de CI : Matériel (avec des sous-classes de type Serveur, Equipement Réseau, Baie de disque, Lecteur de bande ), Application métier, Documentation. Responsable du CI CI owner Le Responsable du CI, ou CI owner, est la personne en charge de s assurer de la cohérence d un ou de plusieurs CI dans la CMDB. Ils jouent un rôle prépondérant dans les activités de contrôle et maintenance et de vérification et audit. Les Responsables de CI peuvent avoir en charge la tenue à jour d une classe de CI, d un périmètre géographique ou fonctionnel, ou de toute combinaison de ces éléments. Page 6 / 21
Terme / Acronyme Plan de gestion de configuration Configuration Management Plan Définition Document établi par le Responsable du Processus de gestion de configuration, en liaison avec le Responsable de la Gestion de Configuration. On retrouve dans ce document les éléments suivants : Périmètre, objectifs et justifications de la CMDB Plan d implémentation de la CMDB (issu de l activité de planification) Modèle de données (classes de CI, attributs applicables, types de relations, relations autorisées/interdites ) Règles de gestion de la CMDB Rôles et responsabilités des acteurs Règles d audit Indicateurs de performance (KPI Key Performance Indicators) Evolutions planifiées de la CMDB, en cours ou à venir. Page 7 / 21
3 De la gestion d inventaires à la CMDB La complexité toujours croissante des environnements informatiques et le maillage des applications dans les réseaux d entreprises rendent complexe la compréhension de l infrastructure. Au cours des dix dernières années, les grandes entreprises ont toutes structuré leurs services de support informatique pour accompagner leur développement et ont créé leur help desk. Parallèlement à ces help desks, elles ont mis en œuvre une gestion de parc pour tenir une liste d inventaires à jour, que ce soit des inventaires de serveurs ou de postes de travail. Certaines d entre elles ont également initié des procédures de gestion des changements afin de maîtriser les changements sur l infrastructure et limiter les impacts des arrêts non programmés de serveurs, invariablement suivis de nombreux incidents ouverts par les utilisateurs qui n étaient pas au courant. C est à ce moment qu est arrivé ITIL. Les responsables informatiques ont alors réalisé qu à l instar de Monsieur Jourdain, ils faisaient de l ITIL sans le savoir, du moins en partie. Tout au plus fallait-il remplacer un peu de vocabulaire (Help Desk par Service Desk, Intervention planifiée par Changement, etc). Mais il est un domaine pour lequel ITIL apporte un plus par rapport à ce que toutes ces entreprises faisaient de manière intuitive, c est la gestion de configuration IT et la CMDB. Les entreprises avaient déjà recours à la gestion de configuration logicielle en utilisant des outils de contrôle de source, mais ITIL a ouvert une formidable extension de la traditionnelle gestion des inventaires de matériel informatiques en y ajoutant une notion clé : la notion de relations. En fait la gestion d inventaires et la gestion de configuration n ont pas tout à fait les mêmes objectifs. La gestion d inventaires traditionnelle permet de : tenir à jour un inventaire des équipements physiques, de leur statut et de leur emplacement ; fournir aux services financiers des moyens de contrôler leur gestion d immobilisations ; fournir des métriques aux services informatiques qui pratiquent la refacturation. La gestion de configuration ne remet pas en cause ces objectifs, mais permet d en ajouter : inventorier les composants non physiques de l infrastructure (par exemple les serveurs virtuels, les applications métiers, les clusters, etc.) ; mais surtout, comprendre les interdépendances entre les composants de l infrastructure. Cette compréhension ouvre des portes à un grand nombre d utilisations : analyse de risques, gestion de capacité, gestion des problèmes La gestion de configuration n est pas un but en soi, elle doit être considérée comme un pré-requis visant à atteindre des objectifs beaucoup plus ambitieux. C est ce que nous allons développer par la suite dans ce document. Page 8 / 21
4 Avant la mise en œuvre Dans ce chapitre, nous aborderons les réflexions à mener avant de lancer un projet de mise en œuvre d une CMDB. 4.1 Pourquoi mettre en place une CMDB? La première question que le responsable de l étude chargé de la mise en place d une CMDB devra résoudre est de définir précisément les objectifs business à atteindre une fois la CMDB mise en place. Cette question, si logique qu elle soit, est en fait complexe à résoudre, car selon les responsables informatiques, on obtiendra différentes réponses : Ainsi, pour un responsable de Help Desk, la CMDB doit permettre d améliorer l efficacité des agents en leur donnant le moyen de corréler des incidents ouverts par des utilisateurs sur une application à des événements détectés sur des serveurs. Cette faculté d analyse d impact réactive est fondamentale pour réduire le temps de résolution des incidents. Pour un responsable de Data Center, la CMDB doit garantir que les changements soient faits de manière contrôlée, et qu il n y a pas d intervention «pirate» sur des composants de l infrastructure. Pour un responsable financier, la CMDB doit être un moyen de vérifier que les ressources informatiques sont correctement utilisées, par exemple en vérifiant si les contrats de maintenance souscrits pour des serveurs sont en phase avec le niveau de service attendu par l utilisateur de l application qui tourne sur ce serveur. Pour un responsable applicatif, la CMDB doit fournir aux opérationnels le moyen de comprendre l impact des changements d un composant de l architecture sur les applications qu il gère. Là où la question devient ensuite un casse-tête, c est que toutes les équipes citées ci-dessus seront des acteurs à part entière du processus de gestion de configuration, et que pour leur «vendre» l idée de la mise en place d une CMDB, ils doivent pouvoir y trouver un intérêt. C est là qu intervient le Directeur Informatique ou le DSI dans la définition des objectifs principaux de la mise en place d une CMDB et leur communication à tous les départements du service informatique. Si l objectif prioritaire de la CMDB est de permettre à l entreprise d atteindre les niveaux de conformité attendus par les régulations Sarbanes- Oxley (SOX), la manière d implémenter la CMDB et la gestion de configuration seront différents par rapport à un objectif prioritaire d améliorer l analyse d impact sur les incidents et changements sur l infrastructure informatique. Le DSI doit donc définir, dans la lettre de cadrage du projet, quel est l objectif prioritaire de la CMDB, pour que tous les acteurs du service informatique l intègrent lors de sa mise en place. Page 9 / 21
4.2 Recensement de l existant Avant la mise en œuvre de la CMDB, nous recommandons de mener une phase d étude d opportunité au cours de laquelle on déterminera le modèle de données cible de la CMDB ainsi que les priorités d implémentation. Dans une grande entreprise ou administration, il est très rare que l on parte d une page blanche, et il est à parier que chaque département dispose déjà de ses propres données d inventaire. Cela va du simple fichier Excel à une base de données élaborée, voire à l outil d administration qui dispose de son propre inventaire. Il est extrêmement important d identifier les inventaires et outils locaux, car ce sont eux qui causeront le plus de problèmes lors de la mise en œuvre, lorsque la nouvelle CMDB devra devenir une base de référence. La première étape consiste à recenser auprès de chaque équipe du service informatique les données dont elle dispose, la façon dont ces données sont maintenues, et surtout l utilité de ces données. Gardez à l esprit que lors de cette étape, une analyse exhaustive doit être menée. Ainsi, partez du principe que tous les départements du service informatique gèrent des données qui peuvent avoir vocation à se retrouver dans une CMDB ; les départements opérationnels (équipes système, réseau, applicatives, support ) sont évidemment à consulter, mais n omettez pas les fonctions support telles que la finance, la gouvernance IT ou la qualité. Gardez-vous d exclure à cette étape certains services, certains outils ou certaines données, ne présumez pas de leur utilité future pour la CMDB. Les questions à poser à chacun de ces départements sont les suivantes (le mieux est de toutes les regrouper dans un formulaire que vous ferez remplir à chaque équipe) : Quels sont les outils, bases, fichiers consultés/mis à jour par l équipe? Quelles sont les grandes classes d'informations manipulées par l'équipe (serveurs, contrats ) Vient ensuite l'inventaire proprement dit des informations utilisées par l équipe. Pour chaque donnée, demander : le nom de la donnée la provenance de cette donnée l'utilité de cette donnée pour l'équipe (vous découvrirez que certaines équipes maintiennent des données qui ne leur servent à rien, et ne servent à personne d'autre!) le processus de mise à jour de la donnée. Pour cet inventaire de données, proposez à vos interlocuteurs de vous fournir un export de leurs bases, en complément du remplissage du formulaire, afin que vous puissiez déterminer le type de données, leur fiabilité et taux de remplissage. Page 10 / 21
4.3 Définition d un modèle cible Sur la base des retours que vous obtiendrez, il vous sera possible de construire un dictionnaire des données consolidé, dans lequel vous référencerez chaque donnée que vous avez obtenue, les équipes qui en disposent, la source de l information, la manière dont la donnée est obtenue (remontée automatique ou processus manuel). Information Type Nom de la relation Cardinalité Mise à jour auto possible? Nombre de fois demandé Dept 1 Dept 2 Dept 3 Dept 4 HARDWARE ASSET CI CI 10 CI CI CI CI Inventory Number Attribut No 10 X X X X Serial Number Attribut No 10 X X X X Software configuration (OS, Service Pack ) Attribut Yes 5 X X Hardware configuration (Cpu, Ram, Disk ) Attribut Yes 5 X X Purchase cost Attribut No 3 X Location on site (office, room #) Attribut No 6 X X X X Product (brand, model, reference) Attribut No 9 X X X X Location Relation Located in (1) - (0,n) No 7 X X X X Software, patch installations Relation Contains (0,n) - (0,n) Yes 9 X X X X Changes, Incidents Relation Concerned by (0,n) - (0,1) Yes 6 X X X Maintenance Contract Relation Covered by (0,1) - (0,n) No 5 X X SLA Relation Ruled by (0,1) - (0,n) No 5 X X Config/Monitoring tools Relation Managed with (0,n) - (0,n) No 3 X X Administrators Relation Administrated by (0,n) - (0,n) No 5 X X X Documentation items (incl. monitoring instr.) Relation Documented with (0,n) - (0,n) No 5 X X X Activity/Destination Relation Asset usage (0,n) - (0,n) No 1 SOLUTION CI CI 8 CI CI CI CI Name Attribut No 8 X X X X Usage Attribut No 1 X Environment (preprod, prod, simu ) Attribut No 2 X Status (development, production, decommissionned, stopped) Status No 1 X Une fois le travail réalisé avec l ensemble des retours du service informatique, vous serez alors en mesure de fournir une première version de la modélisation de la CMDB. L approche à adopter pour cette modélisation est une approche objet - une approche de type Merise peut aussi convenir mais l approche objet est celle utilisée par la plupart des CMDB aujourd hui -. A partir des données recensées (1), regroupez-les par thème homogène (2) et supprimez les doublons en construisant des classes parentes (3), afin d élaborer progressivement vos futures classes de CI (4). Le petit exemple suivant illustre ce travail de modélisation. Dictionnaire de données Numéro de série du serveur Marque du serveur ❶ SERVEUR ROUTEUR PORT MATERIEL PORT Modèle du serveur N série N série N port N série N port Date de fin de garantie du serveur Marque Marque Routeur Marque Routeur Numéro de série du routeur Modèle Modèle Connexions Modèle Connexions Marque du serveur du routeur Fin garantie Modèle du routeur APPLICATION SERVEUR:matériel APPLICATION Numéro du port du routeur Nom Fin garantie Nom Connexions entre ports du routeur SLA SLA Nom de l'application Serveurs ROUTEUR:matériel Serveurs SLA de l'application Serveurs utiles pour l'application MATERIEL ❷ ❹ ❸ SERVEUR (n-n) APPLICATION ROUTEUR (0-n) PORT (n-n) Page 11 / 21
En ce qui concerne les attributs à retenir dans chacune des classes de CI, il n est pas conseillé de reprendre toutes les données recensées par chacun des services. Le conseil que nous vous donnons est de positionner une donnée comme «attribut candidat» dès lors que cette donnée est utilisée au moins par deux départements du service informatique. Nous avons ainsi eu l exemple d une équipe système qui recensait l inventaire complet de la configuration matérielle des serveurs (cartes, disques, barrettes mémoires et slots de connexion ), en utilisant des outils d inventaires automatiques. Par la suite nous avons vu que la plupart de ces données ne servaient qu à cette équipe système, et avons préféré ne pas inclure ces attributs qui alourdiraient la CMDB sans pour autant fournir une valeur ajoutée pour l organisation. Lors de la construction du modèle cible, demandez-vous également quel sera l effort à fournir pour maintenir les données dans la CMDB. En reprenant l exemple ci-dessus, nous avons fait apparaître la notion de port, ce qui signifie que chaque port de routeur sera géré comme un CI. Un routeur 48 ports générera donc 49 Cis et 48 relations, rien que pour décrire un seul routeur! Il est plus vraisemblable que face à ce choix, on préférera simplifier la description de la CMDB en ajoutant un attribut «nombre de ports» au CI routeur, et en positionnant les relations entre routeurs plutôt qu entre les ports des routeurs, surtout s'il n'y a aucun moyen de récupérer les données de manière automatique. La détermination de la granularité des CI est un facteur clé de succès essentiel à la réussite de votre CMDB. Au terme de cette analyse vous aurez défini les principales classes de CI qui devront être gérées dans votre CMDB, ainsi que les attributs et relations possibles pour chacune de ces classes. Ce modèle de données cible est à confronter au modèle proposé par la plateforme d'it Service Management que vous aurez choisie (ou que vous utilisez peut-être déjà). La plupart des solutions (BMC Remedy, HP ServiceCenter, CA UniCenter Service Desk ) proposent en effet un modèle prédéfini de CMDB. Vous devrez peut-être effectuer quelques ajustements pour que le modèle définitif soit compatible avec la philosophie de la CMDB de votre solution d'itsm. Page 12 / 21
4.4 Définition d un plan d implémentation Dans ce chapitre, nous aborderons les réflexions à mener avant de lancer un projet de mise en œuvre d une CMDB. Une fois le modèle de données cible défini, toute la question sera de se demander par quoi il faut commencer! En fonction des priorités et objectifs fournis par la DSI, vous ne serez peut-être pas en mesure de démarrer l'implémentation de toutes les classes de CI et les relations en une seule phase. L ordre d implémentation doit également permettre de répondre le plus rapidement possible aux objectifs de la DSI. Ici comme pour beaucoup d autres projets, on devra établir les «quick wins» qui permettront de rendre la CMDB efficace le plus rapidement possible. Voici quelques conseils de bon sens pour déterminer l'ordre d'implémentation des informations de votre CMDB : Avant de pouvoir créer des relations entre deux CI, les deux CI doivent exister! Il est donc nécessaire de commencer par un inventaire des principales classes de CI "physiques" (serveurs, baies de disques, équipements réseau ). Votre société dispose certainement déjà d'inventaires d'équipements informatiques, il s'agira donc de récupérer ces inventaires, de les reformater pour les rendre compatibles avec le modèle de données que vous avez défini, peut-être de lancer des campagnes d'inventaires physiques pour construire ou remettre à jour cette liste. Une fois les classes de base dans la CMDB, on pourra alors commencer à travailler sur les classes "non physiques" et les relier par des relations à des CI physiques. Par exemple, les serveurs virtuels ou logiques (clusters ) ne peuvent être documentés qu'une fois leurs nœuds physiques connus. La définition des classes suivantes dépendra ensuite des priorités fixées par la DSI : description des applications et de leurs relations, description de la topologie du réseau, description des interfaces, etc. Le plan d implémentation fera l objet d une documentation spécifique que l on trouve dans le plan de gestion de configuration (Configuration Management Plan). Il indiquera les phases successives à mettre en œuvre pour que le modèle cible de la CMDB soit atteint. Page 13 / 21
5 L approche processus La mise en œuvre d une CMDB ne se résume pas à un travail de modélisation de données et d imports dans une base de données. La définition des processus liés à la CMDB est un facteur clé de succès essentiel pour la réussite d un projet de CMDB. A l instar de tout inventaire, la CMDB n aura de valeur que si elle reflète une image la plus fidèle de la réalité. Pour cela, vous devez pouvoir garantir que tout changement sur l infrastructure sera reflété par une mise à jour de la CMDB ; à cette fin, votre projet de mise en œuvre doit élaborer les processus clés de maintien de la CMDB. 5.1 Les acteurs de la gestion de configuration Avant d entrer dans le détail des cinq activités de gestion de configuration, attardons-nous sur les principaux rôles qui entrent en œuvre dans un projet de CMDB. Nous avons identifié trois rôles-clés dans la conduite du processus de gestion de configuration. Le Chef de Projet aura un rôle prépondérant dans la mise en œuvre initiale de la CMDB. Il participe à toutes les phases de mise en œuvre initiale d une CMDB, de la définition de objectifs de la CMDB en passant par le recensement des données, la définition du modèle cible, des processus et de l organisation requis pour la gestion de configuration. Le succès d un projet de mise en place d une CMDB sera conditionné par une équipe projet efficace, communicante et ayant le soutien de la DSI. Le Propriétaire du Processus (Process Owner) sera en charge de définir et de tenir à jour le Plan de Gestion de Configuration, en ligne avec les objectifs fixés par le DSI. Il n a pas un rôle opérationnel mais un rôle stratégique. Le Responsable de Gestion de Configuration (Configuration Manager) sera le chef d orchestre de la gestion de configuration et de la CMDB, le «Gardien du Temple». Il devra veiller à la bonne exécution du Plan de Gestion de Configuration. Ayant un rôle opérationnel, il sera responsable des tâches suivantes : Définition et mise à jour du modèle de données (classes de CI, attributs, types de relations ) Participation aux actions de peuplement initial de la CMDB Formation des acteurs Contrôle de cohérence de la CMDB Production de rapports Détection d anomalies et contrôle de leur correction. Le Responsable du CI (CI Owner) est la personne qui veille à ce que les données relatives aux CI qu il gère soient toujours correctes dans la CMDB. Faisant partie d une équipe opérationnelle (administrateur système, responsable applicatif ), le Responsable du CI est la personne qui se porte garant de la justesse de la CMDB pour la partie qui le concerne. En fonction des organisations, la mise à jour de la CMDB sera effectuée soit par ses soins (modèle décentralisé), soit par une équipe centrale sur la base des indications que le responsable du CI fournira à travers les changements (modèle centralisé). Dans une CMDB, il est important de toujours savoir qui est le Responsable d un CI afin que l organisation informatique sache vers qui se tourner en cas de question ou de problème. La répartition des Responsables de CI peut être : Technique : on affectera les Responsables de CI par découpage technique : Serveurs Unix, Routeurs, Applications SAP Géographique : on affectera les Responsables de CI par localisation, pays ou continent Mixte : en utilisant une combinaison des deux premiers critères. Page 14 / 21
5.2 Planification L activité de planification constitue l approche stratégique de la mise en œuvre d une CMDB. Elle sous-tend bien entendu la définition du plan projet, mais cette activité à vocation à perdurer après le projet initial de mise en œuvre. Comme nous l avons déjà évoqué, le Responsable du Processus a vocation à maintenir le Plan de Gestion de Configuration, comportant notamment le phasage des évolutions à apporter à la CMDB. Si le projet initial est fondamental, une certaine forme d activité projet perdurera pour les évolutions ultérieures. En effet, il ne suffit pas de décider de lancer un inventaire pour ajouter une classe de CI, encore faut-il disposer des ressources et du budget pour étendre la CMDB. A ce titre, il conviendra pour les phases successives de les gérer en mode projet. 5.3 Identification et nommage Le processus d Identification et Nommage est la partie correspondant justement au mode projet décrit ci-dessus. Une fois que les processus et rôles sont définis, il faut implémenter la première phase de la CMDB, puis procéder aux extensions lors de phases ultérieures. Pour toutes ces phases, le processus à suivre sera toujours le même : Analyse du besoin : le Responsable du Processus et le Responsable de la Gestion de Configuration doivent en premier lieu analyser la demande d évolution qui est faite. Cette demande peut être très simple (par exemple ajout d un attribut à une classe de CI existante) ou beaucoup plus complexe (ajout de classes de CI et de relations). Cette analyse doit évaluer les éléments suivants : Pertinence du besoin : ce besoin exprimé a-t-il une justification par rapport aux objectifs de cadrage de la DSI? Peut-il servir à l amélioration de la compréhension de l infrastructure par l organisation? Complexité de mise en œuvre : ce besoin est-il facilement réalisable? (données disponibles ou nécessitant un inventaire, implication des équipes concernées dans la gestion de configuration, répartition géographique, etc.) Coût d implémentation : toute évolution de la CMDB est à considérer comme un projet, il s agit donc d évaluer le coût de l opération, et éventuellement de confronter ce coût à des possibilités d économies ou de gains pour prouver sa justification business. Définition et validation des évolutions du modèle de données : une fois le besoin justifié, le Responsable de Gestion de Configuration sera chargé de définir comment ce besoin se traduira dans la CMDB. Pour chaque nouvelle donnée ou classe de CI à ajouter, il faudra définir : Le nom et le type de la donnée Sa charte de nommage La liste de valeurs possibles (pour des listes fermées) Son caractère facultatif ou obligatoire Les contraintes particulières associées à la donnée. Lancement du projet d implémentation : une fois les évolutions du modèle de données validées, le projet d implémentation devra assurer les tâches suivantes : Mise en place initiale de la CMDB, ou modification de la CMDB existante en cas d évolution du modèle Collecte des données initiales (récupération de listes existantes ou projet complet d inventaire) Peuplement de la CMDB Mise en place de rapports spécifiques le cas échéant Mise en place d interfaces d échange de données spécifiques le cas échéant Formation des acteurs sur les modifications de la CMDB Mise à jour du Plan de Gestion de Configuration Page 15 / 21
Au terme de cette phase d identification et nommage, la CMDB ou son évolution est en production. Ce sont les activités de contrôle et maintenance, vérification et audit et production de rapports qui prennent le relais. Page 16 / 21
5.4 Contrôle et maintenance Cette activité est la clé de voûte du maintien à jour de la CMDB. Si vous échouez dans la mise en place de cette activité, votre CMDB perdra très vite de la valeur, et la photo qu elle présentera ne sera plus en phase avec la réalité. Comme nous l avons déjà évoqué, c est à cet endroit que la gestion de configuration s interface avec la gestion des changements. L activité contrôle et maintenance vise à s assurer que toute mise à jour de la CMDB est faite de manière contrôlée, en d autres termes qu il y a une demande de changement (RFC) associée à cette mise à jour. En fonction des outils disponibles et de votre stratégie de mise à jour de la CMDB, deux approches sont possibles : La mise à jour de la CMDB constitue une tâche à part entière du changement, et elle est faite manuellement par le Responsable du CI ou une équipe centrale, selon le modèle choisi (centralisé ou décentralisé) La mise à jour de la CMDB est faite de manière automatique grâce à des outils d inventaire et des méthodes de réconciliation. Dans ce cas, il y a tout de même une tâche dans le changement pour s assurer que la remontée automatique s est bien déroulée. Il est à noter que certains attributs ou relations ne pourront jamais être remontés de manière automatique, car ce ne sont pas nécessairement des données techniques (par exemple, une relation entre un CI et un contrat de maintenance). L approche retenue sera donc en général mixte : remontées d inventaire contrôlées pour des attributs ou relations techniques, mise à jour manuelle pour des attributs non techniques ou jugés trop critiques pour être mis à jour automatiquement. Quoi qu il en soit, si vous optez pour des mises à jour automatiques ou des mises à jour manuelles, vous devrez pouvoir détecter dans la CMDB les fameuses mises à jour de CI non contrôlées, par exemple en produisant un rapport sur les CI mis à jour alors qu aucun ticket de changement ne leur était associé. Ce qui constitue une très bonne transition pour l activité suivante. 5.5 Vérification et audit Parmi les tâches les plus importantes du Responsable de la Gestion de Configuration, la vérification et l audit ont leur place de choix. Sans ces activités, il serait difficile de contrôler la pertinence de la CMDB dans le temps, et de garantir aux acteurs de l organisation informatique que cette base de référence est en phase avec la réalité. Pour ce faire, plusieurs outils sont à la disposition du Responsable de la Gestion de Configuration : Détection d anomalies par les autres processus : les processus de gestion des incidents, de gestion des changements, de gestion des problèmes font tous appel à la CMDB à un moment donné. Lors de cette consultation de la base, l agent du service informatique peut détecter une incohérence dans la CMDB. Il lui appartient alors de la faire connaître, par exemple en ouvrant une demande de changement pour remettre à jour la base de données. Production de rapports d anomalies : une fois la CMDB en place, on peut imaginer un nombre important de rapports permettant de détecter des anomalies. Par exemple, en listant les serveurs qui ne font jamais l objet de demande de changement, ou en affichant les CI en statut arrêté/retiré, mais toujours reliés à un autre CI, ou encore en listant les CI qui ne sont pas affectés à un responsable de CI. Page 17 / 21
Quelle que soit la méthode de détection de l anomalie, le travail à réaliser par la suite est toujours le même : Comprendre l origine de l anomalie et en informer l auteur Ouvrir une demande de changement pour remettre à jour la base par rapport à la réalité Documenter les bonnes pratiques et conseils pour que ce problème ne survienne plus. 5.6 Production de rapports La dernière activité du processus de Gestion de Configuration est affectée au Responsable de la Gestion de Configuration. Elle consiste à mettre à disposition de l organisation informatique des rapports ou des extractions de la CMDB, pour différents usages. Cette mise à disposition peut prendre plusieurs formes : Création et envoi régulier ou ponctuel d un rapport suite à une demande d une équipe du service informatique Mise à disposition d outils permettant aux utilisateurs d effectuer leurs propres requêtes sur la base Création d interfaces pour synchroniser le contenu de la CMDB avec d autres référentiels. Nous insistons particulièrement sur le dernier point. En effet, l un des écueils à franchir lors de la mise en place d une CMDB est de susciter l adhésion des équipes opérationnelles. Souvent, celles-ci utilisent déjà leur propre base d inventaire ou outil d administration. Comme il n est pas possible de supprimer tous ces outils ou bases qui répondent à des besoins spécifiques, nous recommandons fortement de les coupler à la CMDB à travers des mécanismes de synchronisation. La CMDB doit toujours être considérée comme la base de référence, depuis laquelle les autres outils vont pouvoir remettre à jour leur référentiel de données de manière régulière. Page 18 / 21
6 Conseils d implémentation Pour terminer ce livre blanc nous souhaitons vous faire partager quelques conseils tirés de notre expérience d implémentation du processus de gestion de configuration et d une CMDB. Obtenez un sponsor fort auprès du DSI. Si l intérêt de la mise en œuvre de la CMDB n est plus perçu par la direction informatique, il le sera d autant moins par les opérationnels. La direction informatique doit offrir son support à la mise en œuvre d une gestion de configuration, au risque de perdre beaucoup de temps lors de l implémentation, voire de mener le projet à l échec. Sachez pourquoi vous mettez en œuvre une CMDB. Nous ne le répéterons pas assez, la définition des objectifs à atteindre est fondamentale pour savoir comment construire sa CMDB et quelles priorités de mise en œuvre définir. Mettez en place l organisation opérationnelle au plus tôt dans votre projet (Propriétaire du Processus, Responsable de la Gestion de Configuration), pour que ces nouveaux acteurs puissent travailler à la mise en œuvre initiale et prendre le relais efficacement par la suite pour les opérations d extension de la CMDB. Soyez modeste dans la définition du modèle cible et limitez le nombre d attributs. Positionnez les attributs absolument indispensables au fonctionnement des autres processus de service support, et évitez les attributs qui ne servent qu à peu de personnes. Recherchez les «quick wins». En mettant en place des briques qui apporteront vite de l aide aux acteurs du service informatique, vous susciterez plus facilement l adhésion des troupes. Connectez votre CMDB aux autres outils opérationnels, pour lui donner un caractère de référentiel unique de l entreprise et garantir sa mise à jour par l ensemble des acteurs. Ne laissez pas votre CMDB isolée! Dans chaque service, appuyez-vous sur les personnes qui ont mis en place, développé ou qui administrent les outils locaux, notamment lors des phases de validation du modèle de données et de collecte des inventaires. Ils joueront un rôle de prescripteur au sein de leur équipe. «Vendez» votre CMDB aux équipes du service informatique. Faites-le avant la mise en œuvre, une fois le modèle cible défini, pour présenter votre plan de mise en place, mais également en cours de mise en place et en fin de mise en œuvre. La communication projet autour de la CMDB, de la gestion de configuration et de leur apport pour le service informatique est importante pour obtenir une bonne implication des équipes. Une fois la CMDB initiale en place, adoptez la démarche des «petits pas». En améliorant petit à petit votre CMDB et en communiquant régulièrement sur les nouveautés, vous éviterez un effet tunnel entre deux évolutions majeures et maintiendrez un niveau d information régulier sur l avancement de la CMDB. Page 19 / 21
7 A propos de Baccou Bonneville Consultants Baccou Bonneville Consultants est un cabinet de conseil indépendant dédié aux directions informatiques des grandes entreprises et administrations. L entreprise a été créée en 1995 par Serge Baccou et Arnaud Bonneville. Basée à Paris, la société intervient en France et à l étranger. Nos consultants sont spécialisés dans les quatre domaines suivants : Continuité Informatique Le Conseil sur la Continuité Informatique permet de structurer et renforcer la démarche de Continuité Informatique en cohérence avec les dernières normes internationales en vigueur. Une telle démarche inclut notamment l analyse des impacts en cas de rupture de continuité (Business Impact Analysis), la rédaction des Plans de Secours Informatiques (PSI) et les exercices associés. IT Service Management Baccou Bonneville Consultants propose une gamme de prestations d accompagnement des entreprises dans la transformation de la Direction Informatique en tant que centre de Services informatiques. En structurant les Etudes et la Production informatique pour orienter son action autour de Services, pris en charge de bout en bout à travers le cycle de vie proposé par ITIL, Baccou Bonneville Consultants propose de vous l accompagner dans la définition de vos objectifs et la mise en œuvre d une stratégie d'it Service Management. Direction de Programme Le pôle compétences de Baccou Bonneville Consultants propose des profils pour la définition et la conduite de grands programmes de transformation. Management de Transition Nos managers de transition réponde à un besoin de direction d un département ou d un service informatique, généralement pour amorcer ou accompagner une phase de changement. Il peut s envisager dans des situations de crise ou dans des situations où il s agit davantage de mener un projet stratégique, de rentabiliser l outil de production ou encore de gérer une forte croissance. Le siège de Baccou Bonneville Consultants est situé à Paris. La société intervient en France et à l étranger. Page 20 / 21