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

2

A propos

A propos du documentCe 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'auteurPascal 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 : pascal.delbrayelle@itilfrance.com par téléphone : +33 (0)6 61 95 41 40

Quelques exemples de mission : 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

3

Table des matières 1 La démarche de ce dossier ............................................................................................................... 4

2 De la théorie à la pratique ................................................................................................................. 5

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

3 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

4

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.

5

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

6

- 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.

7

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.

8

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.

9

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 sous-traitant

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, lui-même branché sur tel réseau local (ou plusieurs), etc.

10

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.

11

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).

12

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.