11. Couche 3 : les services d’opérations – définition proposée #

Partie du catalogue de services interne au fournisseur de services (qui comprend les équipes internes et les sous-traitants), les services d’opérations (ou services techniques dans la terminologie ITIL®) sont décrits très sommairement dans la documentation ITIL®.

La description d’un service d’opérations proposée ici est personnelle et correspond à une proposition pratique ayant un intérêt dans les activités du fournisseur de services.

L’application du référentiel ITIL® peut néanmoins aboutir à d’autres définitions du service d’opérations.

La définition proposée d’un service d’opérations part des ressources techniques associées au service d’opérations.

Un service d’opérations est un ensemble de prestations fournies par différentes équipes informatiques (internes ou sous-traitées) sur un ensemble de ressources techniques similaires (serveurs Linux par ex. ou bases de données Oracle) opérées avec le même niveau de service.

La principale difficulté d’un service d’opérations est d’ « exister » entre les services d’affaires d’un côté et les ressources techniques de l’autre côté.

Cette définition permet de bien préciser l’intérêt des services d’opérations. Un service d’affaires (par ex. la gestion commerciale d’un magasin) se basera sur des services d’opérations (serveur Linux critiques, réseau, bases de données critiques, etc.).

Cela n’est pas suffisant pour aboutir à un modèle clair de catalogue de services d’opérations. Il est nécessaire d’y ajouter des contraintes supplémentaires pour définir le périmètre d’un service d’opérations et clarifier leur utilisation.

Sur un ensemble de ressources similaires à opérer, il existe différentes actions à réaliser et différentes responsabilités à assurer par les équipes internes et les sous-traitants.

Nous allons catégoriser les responsabilités et ajouter la contrainte suivante : une seule équipe (interne ou externe) ayant une responsabilité particulière sur les ressources du service d’opérations.

Par exemple, une seule équipe qui réalise l’exploitation au quotidien des ressources du service. Si des serveurs Linux sont gérés pour partie en interne par un service d’exploitation et pour une autre partie par un infogérant, il est alors nécessaire de scinder les serveurs Linux en deux services d’opérations, chacun étant exploité par une équipe spécifique.

Nous allons voir ensuite la typologie des responsabilités habituelles sur un service d’opérations.

12. Couche 3 : les services d’opérations – rôles d’opérations et modèle AXER #

Nous allons faire une analogie avec les rôles de processus qui interviennent dans les activités d’un processus.

Le modèle RACI (Responsible-Accountable-Consulted-Informed) est une aide à la conception d’un processus et une aide à la clarification de qui fait quoi dans les différentes activités du processus.

Il est facile de déterminer des rôles classiques intervenant sur les ressources d’un service d’opérations :

• quelqu’un ou une équipe est le propriétaire du service (terminologie ITIL®)
• une équipe a l’expertise sur les ressources techniques (expertise Linux, expertise Oracle, etc.)
• une équipe réalise l’exploitation au quotidien des ressources techniques
• enfin, une équipe réceptionne et traite les demandes des utilisateurs du service d’opérations sur les ressources techniques associées

Il est possible de définir d’autres responsabilités mais celles-ci sont les principales.

Ces rôles sont appelés rôles d’opérations et, afin d’avoir une homogénéité dans la terminologie, les services techniques (selon ITIL®) sont appelés services d’opérations.

Ceci est formalisé dans le modèle AXER (similaire au modèle RACI pour les processus) :

• Autorité : propriétaire du service
• eXpert : équipe ayant l’expertise sur les ressources techniques associées
• Exploitant : équipe opérant au quotidien les ressources techniques
• Réceptionnaire : équipe réceptionnant et traitant les demandes sur le service d’opérations

Chaque responsabilité sera ensuite associé à une et une seule équipe du fournisseur de services (interne ou externe).

Cela impose, par exemple :

• que les ressources techniques associées ne requièrent qu’un seul domaine d’expertise, assuré par une équipe unique
• qu’elles sont exploitées par une seule et même équipe
• que des ressources techniques gérées à l’extérieur par un sous-traitant nécessitent un point d’entrée chez le sous-traitant à qui soumettre les demandes et les incidents liés aux ressources techniques (le sous-traitant doit avoir un centre de services qui joue le rôle de réceptionnaire)

Le modèle AXER peut être enrichi s’il est opportun de séparer des responsabilités plus fines.

13. Couche 3 : les services d’opérations – exemples #

13.1. Exemple de liste #

Puisque les ressources techniques associées sont gérés selon un même niveau de service, il est intéressant de nommer ce niveau de sevice et de l’intégrer dans le nom du service d’opérations.

Voici quelques exemples simples de services d’opérations :

• serveurs Linux opérés selon un niveau Gold
• serveurs Linux opérés selon un niveau Silver

Il pourrait avoir d’autres critères discrimants en fonction de l’organisation du fournisseur de services :

• serveurs Linux opérés en interne
• serveurs Linux externalisés chez XXX

Les outils d’exploitation sont eux-mêmes à décrire sous la forme de services d’opérations :

• système de supervision AAA
• système de sauvegarde
• logiciel anti-virus

Les environnements physiques sont aussi à décrire sous la forme de services d’opérations :

• salles informatiques

Les applications représentent un nombre important de services d’opérations.

Enfin, n’oubliez pas que le nom d’un service d’opérations doit d’abord décrire la prestation autour des ressources techniques plutôt que les ressources techniques elles-mêmes.

13.2. Exemple : gérer les serveurs Linux/bases de données selon le niveau Gold #

Ensuite, il va être possible de définir le niveau de service selon lequel les ressources techniques associées sont opérées en précisant les critères habituels de disponibilité, de capacité, de sécurité de l’information et de continuité de service.

13.3. Exemple de matrice de responsabilités AXER #

Le modèle AXER permet aussi de présenter synthèse des responsabilités de chacune des équipes sur l’ensemble des services d’opérations sous la forme d’une matrice de responsabilités.

C’est l’équivalent de la matrice de responsabilités du modèle RACI et permet, d’un seul coup d’œil, de voir qui fait quoi sur chacun des services d’opérations.

Parmi les particularités de l’exemple proposé :

• serveurs Linux de niveau de service CRITIQUE et NORMAL : le directeur informatique en est l’autorité mais ils sont opérés chez l’infogérant
• serveurs Linux de niveau de service BASIQUE : l’infogérant en est l’autorité, a l’expertise en interne, les opère au quotidien et a un centre de services associé (il s’agit d’une prestation de type PaaS)
• bases de données Oracle : celles qui sont critiques sont opérées en interne alors que les autres sont externalisées
• l’application de gestion commerciale (tous les modules) a pour autorité l’editeur du logiciel et les équipes internes ont un niveau d’expertise sur le module encaissement (probablement pour accélérer les temps d’intervention en cas d’incident, le module encaissement étant critique) mais pas sur le module de gestion des stocks (module non critique pour les affaires)

14. Couche 3 : les services d’opérations – critères structurant les services d’opérations #

Parmi les critères permettant de regrouper les services d’opérations, en voici quelques uns :

• les composants techniques gérés : aucun (prestation pure comme par ex. la réalisation d’un cahier des charges par une équipe de chefs de projet), un seul (serveur central ou mainframe par ex.), plusieurs
• les équipes intervenant sur le service d’opérations dans le respect du modèle AXER (une seule équipe par responsabilité, interne ou externe)
• les niveaux de service à opérer sur les composants techniques : un seul niveau de service par service d’opérations, ils peuvent aussi être nommés OR, ARGENT, BRONZE par ex. ou CRITIQUE, NORMAL, BASIQUE)
• habituellement, les services d’opérations sont associés à des documentations techniques telles que : documentations d’installation, d’exploitation, de support, d’administration, etc.

15. Couche 3 : les services d’opérations – données essentielles #

Cette liste propose des données essentielles minimales pour décrire un service d’opérations.

Elle contient les informations de cartographie, à savoir :

• les services d’affaires se basant sur le service d’opérations
• les composants techniques associés

Ces liens sont gérés plus globalement par le processus de gestion des configurations et des actifs de service dans la CMDB.

De même que pour les rôles de processus, la description du service d’opérations ne contient pas le nom des équipes associés aux rôles mais seulement un lien entre le rôle et les équipes dans l’organisation.
Il sera donc nécessaire, pour être performant, de décrire la structure organisationnelle du fournisseur de services (organigramme interne et sous-traitants) dans la CMDB afin de gérer le plus efficacement possible ces liens.

16. Couche 3 : les services d’opérations – liens avec les composants techniques #

16.1. 4 types proposés #

Il existe quatre types de liens fréquents entre un service d’opérations et ses composants techniques.

Nous allons les décrire en détail juste après.

16.2. Service non lié à un composant technique #

Certains service d’opérations ne sont pas liés à un composant technique. Il s’agit là des prestations pures comme celles du centre de services (prise d’appel, etc.) ou d’une équipe projet (élaboration de cahier des charges, etc.).

16.3. Service lié à un seul composant technique #

Certains services d’opérations portent sur la gestion un seul composant technique. Ce peut être le cas d’une salle informatique, d’un serveur central, du SAN/NAS, de la virtualisation des serveurs, du système de sauvegarde, etc.

16.4. Service lié à une série de composants techniques indistinguables #

Certains services d’opérations sont liés à une série de composants techniques indistinguables de l’extérieur. Il s’agit par ex. de la gestion d’un cluster de serveurs. Le système est un service d’opérations à part entière vu de l’extérieur (il a un comportement spécifique).

Prenons l’exemple d’un cluster de serveurs gérant des moteurs de bases de données. A un instant donné, un moteur de base de données tourne sur l’un des serveurs constituant le cluster.

Cependant, de l’extérieur, je n’ai pas besoin de savoir précisément sur quel serveur tourne actuellement le moteur de base de données, le service m’est rendu par le cluster avec un niveau de service défini au niveau cluster.

Ce comportement est similaire aux fonctions d’onde en physique quantique : un comportement spécifique apparaît lorsque je conçois une particule comme étant la superposition d’états dictés par la fonction d’onde (notamment des ondes d’interférences) qui disparaît dès lors que je m’intéresse directement à la particule.

Un autre exemple est l’hébergement de machines virtuelles sur un cluster d’ESX VMware proposant par ex. une disponibilité de 100%. Pour cela, je devrai activer certaines options spécifiques du cluster (HA et FT) pour obtenir une disponibilité de VM de 100%, alors que je sais parfaitement qu’une VM seule peut planter et ne peut pas m’assurer un taux de disponibilité de 100%.

16.5. Service lié à une série de composants techniques distinguables selon un critère utilisateur #

Le dernier type de service d’opérations est celui qui est lié à des composants techniques distinguables selon un critère directement ou indirectement à l’utilisateur.

En fait, dès que me sont précisés le service d’opérations et l’utilisateur concerné, je peux connaître le composant technique unique concerné par ma recherche.

Quelques exemples classiques :

• le service d’opérations « Gérer le poste bureautique utilisateur » : à chaque utilisateur attaché à ce service d’opérations correspond un et un seul poste bureautique
• d’autres services d’opérations associés à une caractéristique utilisateur, par ex. « Gérer les routeurs réseaux d’étage » est associé à l’ensemble des routeurs réseaux et je peux associer un routeur d’étage à un utilisateur selon sa localisation géographique (données associées à l’utilisateur)

Tout ceci nécessite un outillage logiciel conséquent et on voit mal comment tout cela serait géré dans une feuille Excel par ex.