La CMDB (Configuration Management DataBase)

Je n'arrête pas de le répéter, la documentation est l'élément le plus important dans la gestion d'un Système d'Information. C'est grâce à une bonne « documentation » que l'on va pouvoir :

• assurer la continuité des services que l'on délivre aux utilisateurs finaux,

• assurer un support réactif et de qualité,

• gérer correctement le patrimoine « informatique » de l'entreprise.

Encore faut-il savoir ce que l'on possède...et pour cela, il faut :

• faire l'inventaire des ses ressources matérielles,

• faire l'inventaire de son portefeuille d'applications (progiciels ou applications « maison »),

• faire l'inventaire de ses contacts (utilisateurs, clients et fournisseurs),

• faire l'inventaire de ses contrats et licences,

• faire l'inventaire des « services » fournis par le S.I, au sens large du terme...

Pour finir, il faut savoir « comment ça marche » tout ce bazar... ! Donc il faut de la documentation, que ce soit la vôtre ou celle de l'éditeur/constructeur.

On parle alors de CMDB lorsque l'on parvient à organiser toutes ces données et à les lier entre elles afin d'obtenir un véritable outil opérationnel de pilotage auquel on peut adjoindre d'autres fonctionnalités comme :

• le support utilisateur (outil de ticketting),
• la gestion des changements (au sens changement de configuration d'un élément du S.I),
• la supervision
• etc.

Alors vous me direz-vous : « mais je n'ai que 3 pauvres serveurs dans mon entreprise » je n'ai pas besoin de tout cela !

Que nenni ! Et c'est bien maintenant qu'il faut commencer, c'est à dire quand la tâche est encore surmontable et ce sera alors un jeu d'enfant...

Prenons un exemple tout simple : vous délivrez à vos utilisateurs finaux un outil de gestion de projet, full-web. Il s'agit donc d'un service que vous vous engagez à livrer en garantissant un temps de rétablissement en cas de problèmes et en fonction de l'importance que ce service peut avoir dans votre entreprise. Donc, si l'on souhaite correctement livrer ce service, et le maintenir...on commence alors à écrire des choses comme cela :

• il me faut l'application
  • Quelle Version ?
  • Qui la fournit ?
  • y a-t-il un contrat du support ? Qui est le contact ?
• il me faut un serveur web
  • Apache Version ?
  • MySQL Version ?
  • PHP Version ?
  • Qui maintient ?
  • etc.
• j'ai besoin d'un serveur (la machine)
  • OS ?
  • RAM ? CPU ? Volume/Taille ?
  • Emplacement ?
• Qui maintient ? Un contrat ? Jusqu'à quand ?
• J’ai besoin de l'annuaire LDAP de l'entreprise pour que les utilisateurs puissent se connecter à cette application (qui a le droit de se connecter à cette application ? Un groupe de l'Active Directory ?)
• J’ai besoin de la documentation de la solution et de son paramétrage (où est-elle ? Qui la met à jour ?)
• J’ai besoin de sauvegarder cette base de données
• j'ai besoin que l'application soit accessible depuis l'extérieur (reverse-proxy?)
• ...etc.

Comme vous pouvez le constater, la liste est déjà longue et si vous vous amusez à faire cet exercice, très consciencieusement avec une de vos applications, vous vous apercevrez rapidement que l'exercice n'est pas facile et c'est bien pour cela qu'il faut le faire maintenant sans attendre que ladite application ne soit plus accessible, au risque d'entendre vos oreilles siffler !

Pourquoi faut-il bien gérer ces données ?

• Parce que le serveur web n'héberge pas que cette solution de gestion de projets,

• parce que le serveur (la machine) délivre d'autres services que ce serveur web,

• parce-que vous ne serez peut-être pas le seul à faire du support pour cette solution de gestion de projets, que vous connaissez bien,

• parce qu’un des vos collègues pensent avoir fait une bonne action en mettant à jour la version de PHP de ce serveur, car il en avait besoin pour une autre application, du coup cette application de gestion de projets ne fonctionne plus correctement,

• parce que vous avez besoin d'ouvrir un ticket de support chez l'éditeur de la solution et que vous ne connaissez plus les éléments du contrat de support,

• parce que vous avez besoin de stopper l'application pendant 30min et que vous ne savez pas (ou plus) qui prévenir,

• parce que vous n'avez qu'une seule tête et que vous ne pouvez pas tout connaître par cœur !

Plus aucune excuse désormais pour ne pas s'y mettre, car, quelle que soit la taille de votre infrastructure vous serez littéralement bluffé par le nombre important d'informations qui sont nécessaires pour assurer une bonne continuité du « service » et un bon support !

Plus de 8 problèmes (incidents) sur 10 sont les conséquences d'un « changement » mal opéré par le fournisseur dudit service ! En clair, c'est le service informatique lui-même qui est à l'origine de 80 % des problèmes que vos utilisateurs rencontrent...

Alors, comment s'y mettre ? De grâce ne commencez pas à remplir un tableau Excel (beurk...) cela n'a aucun intérêt ! Diverses solutions s'offrent à vous en fonction de la taille de votre infrastructure en commençant par une « simple » solution de gestion de parc (GLPI ou OTRS par exemple) ou bien en utilisant une solution complètement dédiée à cette problématique ! Je ne peux que vous conseiller d'aller faire un tour du côté d'iTop (http://www.combodo.com/iTop.html) qui non seulement est en Open-Source (AGPL) mais est une solution française ! Sinon, tapez tout simplement « CMDB » dans votre moteur de recherche préféré (c'est bien DuckDuckGo n'est-ce pas?) et vous y trouverez votre bonheur !