Service Utilisateur : concept, configuration et bonnes pratiques

Objectif

L’objectif d’un Service Utilisateur (SU) est de faire de la macro supervision (supervision de niveau supérieur) pour assurer que les services utilisés par les utilisateurs : messagerie, accès Internet, impression,…, sont en état de fonctionnement pour pouvoir quantifier ce temps avec les taux de disponibilité et prendre des engagements.

Afin d’accroitre la cohérence des services utilisateurs il est recommandé de les définir avec le client en amont de la phase de déploiement de la supervision.

Les règles

Le statut d’un service utilisateur est défini par rapport aux statuts des éléments qui le composent et en fonction des règles listées ci-dessous :

• Si un SU ayant au moins un composant de relation bloquant est Hors d’usage/DOWN/CRITIQUE, alors il est Hors d’usage.
• Si un SU ayant au moins un composant de relation bloquant est Inconnu, et s’il n’y a pas de composant de relation bloquante en état hors d’usage/DOWN/CRITIQUE, alors le SU est en statut INCONNU.
• Si un SU est constitué uniquement de composant de relation dégradant, si tous les composants sont en état Hors d’usage/DOWN/CRITIQUE alors le SU est Hors d’usage.
• Si tous les composants d’un SU sont en indéterminé alors le SU est en statut INCONNU.
• Si au moins un composant de relation dégradant est en statut Hors d’usage/DOWN/CRITIQUE ou Alerte ou INCONNU, alors le statut du SU est Dégradé

Grâce à ces règles et aux éléments supervisés ServiceNav permet de modéliser le fonctionnement de n’importe quelle application métier, architecture réseau, architecture système,…

Création d’un service utilisateur

Pour créer un nouveau service utilisateur il faut aller dans : Configuration > Service Utilisateur puis cliquer sur « + Ajouter »

Configuration des informations générales

• Indiquer le nom qui sera visible dans la météo des services par tous les utilisateurs.
• Indiquer un cours complément d’information dans la description en plus du nom si nécessaire.
• Sélectionner dans le champ « Associé à » la société/site ou le service utilisateur est rattaché.
• Indiquer pour Période de disponibilité la plage horaire sur laquelle on souhaite calculer la disponibilité.
• Renseigner l’objectif de taux de disponibilité que l’on souhaite atteindre, à appliquer sur la période de disponibilité sélectionnée.
• Afficher ou cacher, permet de définir si le service utilisateur est visible dans la météo des services.
• Choisir la criticité du service utilisateur vis-à-vis du client.

Configuration de la notification

• Notification: Permet d’activer ou de désactiver les notifications pour ce service utilisateur.
• Type de notification : Choisir les événements sur lesquels le service utilisateur notifiera les contacts définis précédemment.
• Contacts/Groupe de contacts liés : Sélection des contacts à notifier. La liste de gauche contient les contacts disponibles et la liste de droite les contacts sélectionnés.

Configuration des éléments du service utilisateur

• Choisir les services utilisateurs dont dépendra celui en cours de création. Les listes  contiennent les services utilisateurs disponibles. En fonction de l’impacte il sera mis soit « bloquant », soit « dégradant ».
• Choisir les équipements dont dépendra le SU. Les listes contiennent les équipements disponibles. En fonction de l’impacte de l’équipement sélectionné, il sera mis soit « bloquant », soit « dégradant ».
• Choisir les services unitaires dont dépendra le SU. Les listes  contiennent les services unitaires disponibles. En fonction de l’impacte du service unitaire sélectionné, il sera mis soit « bloquant », soit « dégradant ».

Modélisation d’un service utilisateur

Nous allons par le biais d’un cas d’étude décomposer la modélisation d’un service utilisateur.

Environnement

Infrastructure : nous disposons de deux serveurs Windows faisant fonctionner un Active Directory en redondance, SRV CD1 et SRV CD2.

Service à modéliser

Nous souhaitons créer un service utilisateurs représentant le fonctionnement global du service « Active Directory ». Celui-ci est fourni par deux serveurs différents afin d’avoir un effet de redondance.

Etape 1 : Définir l’objectif final

Etape 2 : Définir les éléments nécessaires au bon fonctionnement du service utilisateur

SVR CD1 : représente le bon fonctionnement du premier serveur fournissant le service d’active directory.

AD-check sur CD1 : représente le bon fonctionnement du premier service active directory.

SVR CD2 : représente le bon fonctionnement du deuxième serveur fournissant le service d’active directory.

AD-check sur CD2 : représente le bon fonctionnement du deuxième service active directory.

Etape 3 : Décomposition en sous-service utilisateur

Q : Dans quels cas mon service utilisateur est-il opérationnel ?
R : Il est opérationnel quand le premier service active directory est OK, ET/OU le deuxième service active directory est OK, et réciproquement.

Q : Dans quels cas mon service utilisateur est-il hors d’usage ?
R : Il est hors d’usage quand les deux services « active directory » sont en état hors d’usage.

Q : Comment fonctionne chacun des services « active directory » ?
R :

Annuaire-CD1 : fonctionne UNIQUEMENT si l’équipement « SRV CD1 » ET le contrôle « AD-check sur CD1 » sont fonctionnels. Chacun deux étant obligatoire au bon fonctionnement du service utilisateur Annuaire-CD1 leurs relations avec le service sera donc de type « Bloquant ».

Annuaire-CD2 : fonctionne UNIQUEMENT si l’équipement « SRV CD2 » ET le contrôle « AD-check sur CD2 » sont fonctionnels. Chacun deux étant obligatoire au bon fonctionnement du service utilisateur Annuaire-CD2 leurs relations avec le service sera donc de type « Bloquant ».

La règle qui s’applique est :

Si un SU ayant au moins un composant de relation bloquant est Hors d’usage/DOWN/CRITIQUE, alors il est Hors d’usage.

 La décomposition en sous-services utilisateurs n’est pas 
toujours nécessaire cela dépend de la complexité du service 
utilisateur à modéliser.

Etape 4 : Définir la relation des sous-services utilisateurs

Les sous-services utilisateurs représentent chacun d’eux le fonctionnement d’un service active directory. Pour que les utilisateurs aient accès aux ressources du système d’information (mail, partages réseaux, …) il faut qu’au moins un des deux sous-services utilisateurs soit fonctionnel. Ils ont donc une relation de type « dégradant ».   Si un des deux sous-services utilisateurs est hors d’usage alors le service utilisateur Annuaire sera en statut dégradé suivant cette règle :

Si au moins un composant de relation dégradant est en statut Hors d’usage/DOWN/CRITIQUE ou Alerte ou INCONNU, alors le statut du SU est Dégradé.

Par contre si les deux sous-services utilisateurs sont en statut hors d’usage alors c’est la règle suivante qui s’applique :

Si un SU est constitué uniquement de composant de relation dégradant, si tous les composants sont en état Hors d’usage/DOWN/CRITIQUE alors le SU est Hors d’usage.

  Grâce à ces règles nous pouvons modéliser la redondance 
et le fonctionnement de n’importe quelle application métier.

Questions à répondre avant de créer un service utilisateur

Nous rappelons que nous nous plaçons toujours à la place d’un utilisateur pour se poser les questions suivantes :

Quels sont les services fournis par le système d’information nécessaire à la production de l’entreprise ?

Cette question permet de définir les services utilisateurs à créer.

Dans quels cas le service n’est pas disponible pour l’utilisateur ?

Cette question permet de comprendre le fonctionnement technique du service. L’objectif est de recenser tous les contrôles à mettre en place dans la supervision, ainsi que leurs impacts sur le service (bloquant ou dégradant) pour le modéliser par un service utilisateur. Une fois que l’on a répondu à cette question il faut configurer la supervision de sorte à avoir les bonnes remontées.

Quand ce service est-il consommé ?

La réponse permet de définir la plage horaire qui sera configurée pour le paramètre « période de disponibilité », qui permet de calculer le taux de disponibilité.

Quel est le pourcentage de disponibilité à réaliser sur lequel le partenaire s’engage?

Représente le niveau de service souhaité par le client. Ce niveau doit être défini contractuellement, en fonction du besoin du client, de son infrastructure, et de la prestation qu’il achète.