Lier les composants techniques avec les services d

La pratique de la gestion des services
Lier les composants techniques avec les
services d’opérations dans la CMDB
Création : octobre 2013
Mise à jour : octobre 2013
A propos
A propos du document
Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL et d'autres référentiels
dans des directions informatiques en France au travers des missions qui me sont confiées depuis
2004.
Il est mis à la disposition de la communauté francophone ITIL pour diffuser quelques conseils et
notes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels.
Ce document peut être utilisé de manière libre à condition de citer le nom du site
(www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).
A propos de l'auteur
Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets
d'une direction informatique ayant comme facteur de succès la mise en œuvre des bonnes
pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un
outil de gestion des configurations ou la définition des normes et standards techniques des
environnements de production.
Ces projets requièrent :



la connaissance des différents métiers du développement et de la production informatique
la pratique de la conduite de projets techniques de la direction informatique
la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter
les méthodes de travail au sein de la direction informatique
A propos de mission et de formation
Si vous pensez que l’expérience de l’auteur sur la gestion des services informatiques (ITSM) peut
vous aider dans vos projets sur l’organisation ou sur la production informatique, n’hésitez pas à le
contacter pour toute question ou demande :


par mail : [email protected]

Missions d’étude ITSM :
 Analyse de l’existant, comparaison à ITIL et préconisations
 Réaliser un cahier des charges pour un outil ITSM
 Analyser le contenu d'une CMDB et faire des préconisations

Missions d’accompagnement ITSM :
 Mettre en oeuvre la chaîne de valeur ITSM
 Définir les processus de transition des services alignés avec la méthodologie
projet
 Elaborer le catalogue de services informatiques et les niveaux de service

Formations pratiques en entreprise :
 Introduction à la gestion des services informatiques
 Conduite du changement dans un projet ITSM
 Elaboration du catalogue de services et des niveaux de service"
 Processus et documentation centre de production
par téléphone : +33 (0)6 61 95 41 40
Quelques exemples de mission :
2
Table des matières
1
La démarche de ce dossier ............................................................................................................... 4
2
De la théorie à la pratique ................................................................................................................. 5
3
2.1
Rappels de la théorie ITIL .......................................................................................................... 5
2.2
Ce qui est réellement utile à la pratique ...................................................................................... 5
2.3
Le « pont à deux piliers » entre clients et technologies ............................................................... 6
2.4
Rappel de la définition d’un service d’affaires ............................................................................. 6
2.5
Rappel de la définition d’un service d’opérations ........................................................................ 7
Typologie des liens entre services d’opérations et composants techniques....................................... 8
3.1
Renforcer l’intérêt de mettre en place un catalogue des services d’opérations ........................... 8
3.2
Les quatre types de liens............................................................................................................ 8
3.2.1
Service d'opérations non lié à un composant technique ...................................................... 9
3.2.2
Service d'opérations lié à un seul composant technique ...................................................... 9
3.2.3
Service d'opérations lié à une série de composants techniques indistinguables ................ 10
3.2.4
Service d'opérations lié à une série de composants techniques distinguables sur un critère
utilisateur ......................................................................................................................................... 11
4
Conclusion ......................................................................................................................................12
3
1 La démarche de ce dossier
Ce dossier présente quelques aspects des liens entre composants techniques de la CMDB et les
composants du catalogue de services et des niveaux de service.
Un éclairage sur la typologie de ces liens permet de disposer d’un élément supplémentaire dans le
découpage de l’offre client en services d’affaires et l’offre technique en services d’opérations.
Pour présenter ce dossier, disons que nous allons relier deux mondes déjà connus (bien avant ITIL) :
- les clients et, plus globalement, leurs affaires : déjà connus au travers ne serait-ce que des
applications développées et les logiciels métiers mis en place
- les composants techniques : déjà connus eux-aussi par l’intermédiaire d’outils logiciels de
gestion de parc, d’inventaire, d’auto-découverte sur le réseau, etc.
La démarche proposée dans ce dossier est la suivante :
- rappels de la théorie ITIL
- passage de la théorie à la pratique : ce qui est réellement utile pour mettre en place concrètement
ITIL et ce qu’il faut y ajouter pour bien maîtriser cette mise en œuvre
- bien comprendre la mécanique du « pont à deux piliers » entre les clients et la technologie
informatique mise en œuvre
- un focus particulier sur la typologie des liens entre les services d’opérations et les composants
techniques gérés
Ceci permettra à tout un chacun de préciser certains aspects complexes d’un cahier des charges
exprimant les besoins d’un catalogue de services et d’une CMDB technique.
4
2 De la théorie à la pratique
2.1 Rappels de la théorie ITIL
Dans la partie documentaire de la stratégie des services, le fournisseur de services délivre de la valeur
aux clients par le biais de services [d’affaires] incluant utilité et garantie et ce, au moyen des aptitudes
de service dont il dispose (ressources et aptitudes) :
Ce schéma synthétique permet de bien relier les différents concepts théoriques mais il nécessite une
description supplémentaire pour passer de la théorie à la pratique.
Une difficulté apparaît immédiatement à la mise en pratique : elle porte sur l’inventaire des services
fournis. Dans la partie conception des services, la personne qui veut réaliser en pratique le catalogue de
services se heurte rapidement à une faune très diversifiée de types de services :
- services business : que je traduis complétement en français par services d’affaires
- services techniques : que je traduis en service d’opérations, terme plus cohérent avec le reste du
modèle
- services de base
- services nécessaires
- services d’amélioration
- services externes
- services internes
- services de support,
- etc.
Je ne reviendrais pas sur la plupart de ces différents termes (à mon avis liés à des notions marketing et
une tentative maladroite de classifier les services fournis).
2.2 Ce qui est réellement utile à la pratique
Je vais me concentrer sur les deux premiers types : les services d’affaires et les services d’opérations.
Ces deux types de service vont permettre de relier en pratique d’un côté les clients et utilisateurs et de
l’autre les technologies et composants techniques gérés par le fournisseur de services.
Une vision claire du pont qui existe entre ces deux mondes va faciliter par la suite :
- la formalisation des processus informatiques
- le paramétrage des outils ITSM pour tous les processus informatiques gérés
5
-
une simplification de la recherche d’impact : diagnostic d’un incident, recherche de l’erreur pour un
problème, analyse d’impact d’un changement, etc. sans se noyer dans des considérations
métaphysiques du modèle de la CMDB et dans les arcanes parfois sombres des outils ITSM sur le
sujet.
2.3 Le « pont à deux piliers » entre clients et technologies
Ce pont se présente de la manière suivante :
Pour mémoire, ce pont est aussi visible dans la chaîne de valeur ITSM telle que je la représente :
2.4 Rappel de la définition d’un service d’affaires
Il s’agit d’une prestation fournie pour répondre aux besoins d'affaires des clients selon un engagement
préalablement négocié avec eux.
Cet engagement inclut l’utilité (partie fonctionnelle) et la garantie (partie niveau de service) du service.
D'une manière plus globale, le service d'affaires est un moyen de fournir une valeur à des clients en
facilitant les résultats que les clients veulent obtenir sans qu'ils aient à gérer directement le détail des
coûts et les risques liés aux composants techniques.
Concrètement, chaque unité d'affaires ayant besoin de ce service d'affaires verra les informations qui
l'intéresse (publiées dans le catalogue de services) et l'utilisera dans le cadre d'un ou plusieurs accords
de niveau de service (SLA).
Le fournisseur de services, de son côté maintiendra toutes les informations destinées à l'ensemble de
ses clients et se conformera aux niveaux de services validés dans l'ensemble des accords.
6
2.5 Rappel de la définition d’un service d’opérations
Il s’agit d’un ensemble de prestations fournies par les équipes internes du fournisseur de services et par
ses sous-traitants sur un ensemble de ressources techniques en production.
Un service d'opérations peut être utile dans la fourniture d'un seul service d'affaires (service d'opérations
dédié), plusieurs services d'affaires (service d'opérations partagé) ou une majorité de services d'affaires
(service d'opérations commun ou de base).
Un service d'opérations est avant tout une notion technique : serveur informatique, réseau, application,
environnement de virtualisation ou bases de données par exemple.
Les équipes internes et les sous-traitants interviennent dans la gestion opérationnelle du service
d'opérations dans le cadre respectivement d'accords de niveau opérationnel (OLA) et de contrats de
sous-traitance (UC).
Les responsabilités de base des intervenants sur un service d'opérations sont : l'exploitation, la
réception des incidents et des requêtes, l'expertise et l'autorité (propriétaire du service d'opérations).
Un service d'opérations est associé à une et une seule entité (équipe interne ou sous-traitant) pour
chaque responsabilité de base.
7
3 Typologie des liens entre services d’opérations et composants
techniques
3.1 Renforcer l’intérêt de mettre en place un catalogue des services
d’opérations
Dans d’autres articles, j’ai défini l’intérêt à définir les services d’opérations dans la simplification et la
rationalisation des interventions et des intervenants sur la gestion des différentes parties de
l’infrastructure.
Voici un autre aspect de l’intérêt de la mise en place de ces services d’opérations : structurer les
relations qui existent entre utilisateurs et composants techniques afin d’être plus rapide dans les
processus informatiques opérationnels.
Par exemple, lorsqu’un utilisateur appelle le centre de services pour signaler un incident, un logiciel
ITSM digne de ce nom « remonte » plus ou moins automatiquement à l’écran toutes les informations
liées à cet utilisateur : localisation géographique, organisation d’affaires, profil pour l’accès aux
application, etc.
Mais parfois, cela n’est pas suffisant si on veut encore accélérer le diagnostic de l’incident lorsque
l’interruption est liée à un élément d’infrastructure très technique assez éloigné de l’utilisateur tel qu’un
routeur sur le réseau.
Bien que l’on connaisse dans ce cas le site géographique de l’utilisateur, il faut « fouiller » dans la
CMDB technique pour identifier le routeur qui connecte le réseau local du site au réseau étendu de
l’entreprise par exemple.
La typologie proposée des liens entre services d’opérations et composants techniques permet aux
logiciels ITSM de s’aligner fonctionnellement et de monter en maturité. Le routeur réseau incriminé dans
cet exemple sera affiché sur une simple requête de la personne qui effectue le diagnostic : « quel est le
routeur réseau sur lequel passe le flux réseau de l’utilisateur ? ».
Un autre cas de figure, non lié à un utilisateur, existe aussi dans la CMDB. Je l’ai croisé il y a très
longtemps avant de connaître ITIL avec les serveurs web multiples utilisés pour répartir la charge de
traitement des requêtes internet avec, en frontal, un composant réseau faisant office de répartiteur de
charge (load balancing).
Dans cet exemple, comment représenter le lien entre service d’opérations et cet ensemble de serveurs
totalement similaires et pourtant, lorsqu’un utilisateur effectue une requête, cette requête est traitée par
un seul de ces serveurs, presque totalement au hasard (selon la décision du serveur de répartition de
charge en frontal) ?
3.2 Les quatre types de liens
J’ai identifié quatre types de liens entre service d’opérations et composants techniques, allant du plus
simple au plus complexe :
- service d'opérations non lié à un composant technique
- service d'opérations lié à un seul composant technique
- service d'opérations lié à une série de composants techniques indistinguables
- service d'opérations lié à une série de composants techniques distinguables sur un critère
utilisateur
Je vais décrire plus en détail ces quatre types de liens.
8
3.2.1
Service d'opérations non lié à un composant technique
Ce type n’est pas fréquent mais peut exister chez un fournisseur de services.
Il permet de décrire des services d’opérations de type prestation pure comme par exemple :
- le centre de services,
- lors de l’inauguration d’un magasin de la grande distribution, la présence sur site d’une personne
de l’organisation informatique pendant ce week-end qu’il ne faut pas gâcher avec des soucis
informatiques (d’où la présence sur site pour accélérer le traitement des incidents qui peuvent
survenir dans cette période critique)
- du conseil (comme je le fais en tant que consultant sur les organisations informatiques)
Pour résumer, certains services d’opérations ne sont pas liés à de la technologie mais portent sur
d’autres ressources du fournisseur de services telles que les personnes par exemple.
3.2.2
Service d'opérations lié à un seul composant technique
Ce service d’opérations est typiquement rencontré dans le cas d’équipements centralisés ou de boîtes
noires :
- serveur central (mainframe)
- SAN/NAS
- partie de l’infrastructure qui est externalisée et complètement prise en charge par un sous-traitant :
le sous-traitant aura sa propre CMDB (n’oubliez pas de ne travailler qu’avec des sous-traitants
appliquant les principes ITIL) et, du point de vue de la direction informatique, je n’aurais qu’un seul
composant technique boîte noire représentant l’intégralité de l’infrastructure gérée par le soustraitant
Dans la partie du schéma « Composants technologiques », la forme hexagonale représente les liens
internes reliant les différents éléments techniques entre eux. Ces liens sont classiques et représentés
dans le schéma ITIL de modèle des configurations : telle application est hébergée sur tel serveur, luimême branché sur tel réseau local (ou plusieurs), etc.
9
3.2.3
Service d'opérations lié à une série de composants techniques indistinguables
Ce type de lien est dû au comportement un peu particulier de certains composants d’infrastructure
techniquement identiques pour lesquels il est nécessaire d’en disposer un certain nombre afin
d’absorber une charge prévue (volumétrie, bande passante, puissance de calcul, etc.).
Cette particularité existe soit, parce que la technologie n’existe pas (encore) pour ne mettre en place
qu’un seul gros composant capable d’absorber à lui seul toute la charge prévue, soit parce que, même si
le gros composant existe, il reste économiquement plus rentable de mettre en place plusieurs
composants plus petits car beaucoup moins chers au total.
Il ne faut pas oublier dans le calcul financier la mise en place éventuelle d’un composant supplémentaire
qui sera le répartiteur de charge en amont. Ce « détail » peut, à lui seul, rendre l’ensemble beaucoup
plus cher en raison d’un coût élevé. Je me rappelle il y a quelques années d’une configuration à base de
deux serveurs intranet d’environ 3 000 euros chaque, beaucoup moins chère qu’un serveur deux fois
plus gros mais pour laquelle il a fallu ajouter un répartiteur de charge internet, d’un montant de … 20 000
euros, ce qui fait au final une architecture beaucoup plus chère qu’un seul gros serveur.
Finalement, c’est un autre critère qui a motivé le choix. Les tests de charge ont révélé que l’application
ne tenait pas la charge sur un seul serveur, les performances s’écroulaient bien avant d’avoir atteint le
nombre prévus d’utilisateurs en pointe. Il a donc bien fallu utiliser la configuration à deux serveurs,
d’autant plus que le logiciel en question était un logiciel de gestion des temps passés.
Il était très facile d’imaginer le profil d’activité d’affaires où tous les utilisateurs se connectent au tout
dernier moment de la période à saisir et, au moindre souci de performance, ils abandonnent la saisie en
prétextant que l’outil est trop lent.
Ceci aura permis au passage de démontrer l’intérêt du processus stratégique ITIL de gestion de la
demande.
Cet ensemble de composants similaires pour lesquels chaque utilisateur sera connecté indirectement à
un seul de ces composants peut être vu comme un item de configuration sous la forme d’un système à
plusieurs composants. Dans ce cas, le service d’opérations sera connecté à un unique composant
technique qui est le système dans sa globalité et cela nous fait revenir à notre type précédent.
Il est aussi possible de lier le service d’opérations à chacun des composants individuels. Dans ce cas, le
lien sera particulier car, pour un utilisateur donné, un seul des liens sera utilisé, différent d’un utilisateur
à l’autre.
Outre le cas de la répartion d’une charge, la sécurisation par redondance de composants techniques
conduit aussi à ce type de situation.
L’ensemble de composants techniques similaires va se comporter comme une particule en physique
quantique : tant que l’on ne s’intéresse pas à un utilisateur en particulier, le service d’opérations est
connecté à tous les composants individuels. Dès lors que l’on s’intéresse à un utilisateur et que l’on fait
une mesure pour connaître quel composant individuel est accédé, le service d’opérations se retrouve
connecté à un seul composant individuel.
C’est pour cela que j’ai représenté l’ensemble des composants techniques dans un rectangle avec une
onde, par analogie avec la fonction d’onde (ou fonction d’état) d’une particule en physique quantique.
10
Mais vous n’êtes pas obligé de parler de physique quantique dans le cahier des charges d’un outil
ITSM…
3.2.4
Service d'opérations lié à une série de composants techniques distinguables sur un
critère utilisateur
Ce lien complexe, qui fait intervenir des propriétés de l’utilisateur, concerne des services d’opérations
délocalisés et donc liés à un volume, qui peut être conséquent, de composants techniques identiques.
L’exemple typique est le service d’opérations « poste bureautique » : chaque utilisateur accédant à des
services informatiques a à sa disposition un poste de travail bureautique (tout du moins en faisant
abstraction des tablettes, des téléphones intelligents (smartphones) et aussi de la tendance BYOD
(Bring Your Own Device).
Dans ce cas, le critère pour identifier le composant technique utilisé sera l’identifiant unique de
l’utilisateur (matricule, etc.). Chaque composant technique qui sera affecté à un utilisateur aura en
attribut l’identifiant de l’utilisateur.
Voici d’autres exemples de services d’opérations faisant intervenir des critères utilisateurs différents :
- routeurs réseaux d’étage : la localisation géographique précise de l’utilisateur (étage, immeuble,
site)
- centres de services délocalisés : la zone géographique d’un utilisateur (trois centres de services
se répartissent le monde en trois zones : un utilisateur appartient forcément à l’une de ces
zones…)
- applications comptables installées : dans le cas où le service d’opérations « gestion comptable
locale » est lié à des occurrences locales de l’application comptable (chaque pays a un serveur
localement hébergeant l’application comptable), le pays de l’utilisateur est le critère distinctif.
Afin de gérer correctement tous ces services d’opérations et composants techniques, il est nécessaire
de définir un certain nombre de propriétés associées à l’utilisateur.
Beaucoup de logiciels ITSM le font indirectement avec la notion de filtre sur les données.
En effet, lors de la création d’un ticket d’incident par exemple, un filtre automatique est appliqué lorsque,
partant du service d’opérations « poste bureautique », je recherche le poste de travail associé à
l’utilisateur, je retrouve un seul élément dans le résultat de ma recherche : celui de l’utilisateur.Le
résultat a été filtré sur l’identifiant de l’utilisateur.
Ce principe devrait être étendu à d’autres propriétés distinctives de l’utilisateur pour d’autres services
d’opérations associés à des composants techniques non liés directement à l’utilisateur (un routeur
réseau d’étage ou l’installation nationale d’une application comptable par exemple).
11
4 Conclusion
Cette typologie de liens entre services d’opérations et composants techniques vous permettra d’enrichir
un cahier des charges pour votre futur outil ITSM sur des aspects méconnus mais indispensables des
liens entre composants de la CMDB.
Beaucoup de modèles existent pour décrire les liens entre les composants techniques avec, parfois, des
divergences d’opinion très marquées entre différentes personnes s’intéressant à cette problématique,
pouvant parfois tourner à la discussion métaphysique.
Il est rare de s’intéresser aux liens unissant services d’opérations et composants techniques, surtout
parce que les services d’opérations sont un peu les parents pauvres du référentiel ITIL car très mal
décrits (à part le fait qu’ils soient cités dans le processus de gestion du catalogue de services).
Décrire correctement cette typologie permettra ensuite :
- de gagner du temps lors de la création de ces liens et
- encore après de pouvoir les utiliser efficacement dans les processus opérationnels de gestion des
services sans se perdre dans les méandres d’une CMDB pléthoriques en liens jusqu’à ne plus rien
comprendre du contenu de cette CMDB.
N’hésitez pas à reprendre les éléments de cet article dans l’élaboration de votre cahier des charges pour
un outil ITSM.
Vous pouvez aussi me contacter si vous désirez être accompagné dans cette même démarche
logicielle.
12