Mais je ne vois pas trop l'intérêt d'une tel base pour le travail quotidien, donc son alimentation va encore attendre un peu.
Cela permet au service desk, par exemple, de savoir quand quelqu'un des études lui parle de la base de données qui est vautrée pour son appli trucmuche qu'elle est sur le serveur tartempion (avec les informations de type OS / type de base de données) pour faire appel à la bonne personne pour intervenir.
Cela peut paraître anodin quand tu as 4-5 applications, mais dès que tu en as des dizaines voire centaines, ça devient vite ingérable ;-)
Cela permet aussi, quand tu planifies une intervention sur un serveur, d'identifier les applications qui vont être impactées et de prévenir les personnes concernées (ah oui, il n'y a pas que le côté technique, il y a le volet organisationnel qui apparaît assez vite).
Par exemple, cela permet de répondre à la question "il y a une coupure électrique en salle 1 du datacenter, quelles applications sont impactées, lesquelles étaient en cluster avec un serveur dans une autre salle, cela-a-t-il bien basculé, lesquelles restent à basculer en manuel ?" (bon ce n'est jamais si simple hein, mais au moins ça donne un début d'information).
Comme tu pourras le lire dans la littérature autour de ITIL, il y a deux logiques à mettre en place :
- coupler l'alimentation de la CMDB à la gestion des changements, en profiter pour valider les données régulièrement
- limiter au maximum l'ajout de données qui "pourraient être utiles", soit elles répondent à un besoin concret, soit (idéalement) elles peuvent être obtenues automatiquement à partir des données déjà rentrées (tout aspect manuel sera un frein à la mise à jour et la base devient vite obsolète). Des revues régulières de la qualité des données (avec un responsable par périmètre ou par type de données entrées) permettent d'éviter l'obsolescence de la base.
Concernant ITIL, ce n'est pas que pour les dissaïdor ; étant un "ensemble de bonnes pratiques", il y a tout le volet "hype" à enlever, mais il reste pas mal de bonnes recommandations à prendre en compte tout de même et à adapter à son contexte bien sûr. Cela permet d'avoir un vocabulaire commun entre plusieurs équipes déjà.
[^] # Re: ITIL ?
Posté par BAud (site web personnel) . En réponse au journal Application web de cartographie applicative. Évalué à 3.
Cela permet au service desk, par exemple, de savoir quand quelqu'un des études lui parle de la base de données qui est vautrée pour son appli trucmuche qu'elle est sur le serveur tartempion (avec les informations de type OS / type de base de données) pour faire appel à la bonne personne pour intervenir.
Cela peut paraître anodin quand tu as 4-5 applications, mais dès que tu en as des dizaines voire centaines, ça devient vite ingérable ;-)
Cela permet aussi, quand tu planifies une intervention sur un serveur, d'identifier les applications qui vont être impactées et de prévenir les personnes concernées (ah oui, il n'y a pas que le côté technique, il y a le volet organisationnel qui apparaît assez vite).
Par exemple, cela permet de répondre à la question "il y a une coupure électrique en salle 1 du datacenter, quelles applications sont impactées, lesquelles étaient en cluster avec un serveur dans une autre salle, cela-a-t-il bien basculé, lesquelles restent à basculer en manuel ?" (bon ce n'est jamais si simple hein, mais au moins ça donne un début d'information).
Comme tu pourras le lire dans la littérature autour de ITIL, il y a deux logiques à mettre en place :
- coupler l'alimentation de la CMDB à la gestion des changements, en profiter pour valider les données régulièrement
- limiter au maximum l'ajout de données qui "pourraient être utiles", soit elles répondent à un besoin concret, soit (idéalement) elles peuvent être obtenues automatiquement à partir des données déjà rentrées (tout aspect manuel sera un frein à la mise à jour et la base devient vite obsolète). Des revues régulières de la qualité des données (avec un responsable par périmètre ou par type de données entrées) permettent d'éviter l'obsolescence de la base.
Concernant ITIL, ce n'est pas que pour les dissaïdor ; étant un "ensemble de bonnes pratiques", il y a tout le volet "hype" à enlever, mais il reste pas mal de bonnes recommandations à prendre en compte tout de même et à adapter à son contexte bien sûr. Cela permet d'avoir un vocabulaire commun entre plusieurs équipes déjà.