La qualité de service TI – 1e partie

J’ai régulièrement des discussions sur la mesure de la qualité des services informatiques avec mes clients. Un projet de mise en place d’une solution de virtualisation (de serveur ou d’applications) est souvent lié à une volonté d’améliorer la disponibilité des services TI. Mesurer l’impact de la solution mise en place sur cette disponibilité peut cependant être une tâche difficile si aucune solution de supervision n’est en place dans la société.

Lors de mon dernier stage en entreprise, je me suis trouvé face à cette même problématique, ce qui en a fait l’un des sujets de mon mémoire. Ce sujet étant un thème récurrent, j’ai donc décidé de le traiter d’une manière plus générale dans ce blog, sans aborder la question d’un point de vue purement technique.

 

L’article est composé en trois parties :

  1. Définir la qualité d’un service,
  2. Améliorer la qualité d’un service,
  3. Créer des systèmes robustes.

 


Partie 1 – Définir la qualité d’un service

Comment définir et mesurer la qualité d’un service informatique ?


1.       Introduction

En informatique de production, chaque application fournit plus ou moins directement un service au client, qu’il soit interne à la société ou client final. L’informatique occupe une place de premier plan dans le fonctionnement de l’entreprise : Si les services informatiques sont indisponibles, les employés ne peuvent plus être aussi productifs et il y a perte de valeur. Il est donc important de mesurer la qualité du service fourni, et d’établir l’impact d’une indisponibilité. Cela permettra entre autres de prioriser les ressources et de cibler d’éventuels points faibles.

 

2.      Définition des services

La première étape à l’amélioration de la qualité de service consiste à définir les cibles à atteindre pour chacun de ces services.

 

Pour cela, il est faut tout d’abord définir la liste des applications gérées par les différentes équipes informatiques. Un service doit être décrit par les systèmes qui le composent, le propriétaire de ce service, le gérant (niveau technique), les dépendances vis-à-vis des autres services et idéalement la liste des personnes ou des équipes utilisant ce service.

Il faut préciser que cette liste sera également utile à une grande quantité de tâches, comme la gestion des changements ou des incidents (avec l’impact d’un arrêt de production et les personnes à contacter).

Les responsables de départements relatifs à un service sont définis comme propriétaires du service (business owner) et doivent être consultés pour toute modification du service fourni (interruption, modification des fonctionnalités…).

 

On doit ensuite déterminer la criticité de chaque élément, en fonction de l’impact sur la société et les clients. Cette criticité est la plupart du temps directement relative à l’impact business d’une interruption du service et peut être déterminée avec les propriétaires de services. Ceux engendrant directement une création de valeur sont les plus critiques, suivi des services de support des équipes internes.

 

Les services de base de l’infrastructure doivent hériter directement de la criticité des services qu’ils supportent. Ainsi, le réseau de backbone ou le service d’annuaire disposent souvent de la criticité maximale, même s’ils ne fournissent aucun service directement, car ils sont indispensables au fonctionnement d’un service critique (voire de tous les services…).

 

Une fois la liste des services et leur criticité établie, il faut définir une qualité de service cible, appelée niveau de service. Ce niveau cible sera le but à atteindre en terme de qualité de service.

 

Ce niveau de service peut être cadré par deux critères : la disponibilité et la performance. Ces deux critères définissent l’état de santé d’un service, une information essentielle, permettant par exemple de connaitre le fonctionnement d’un système sur une période, l’impact d’un changement, ou le ressenti des utilisateurs en temps réel.

 

Nous allons maintenant détailler les manières d’établir ces deux indicateurs.

 

3.      Disponibilité d’un service

a)     Définition

La disponibilité d’une application est un indicateur permettant d’établir les périodes pendant lesquelles le service est fonctionnel ou non.

 

Il peut s’agir d’un indicateur binaire (si certains composants d’une application sont indisponibles, c’est tout le service qui est considéré comme impacté) ou granulaire (chaque composant dispose d’une notion de disponibilité propre, mesurée en plus de la disponibilité globale.).

La disponibilité fournie est donc basée sur 3 niveaux :

  • Le service est l’ensemble des sous-services sont fonctionnels.
  • Le service est fonctionnel mais un sous-service (une fonctionnalité) est indisponible.
  • Le service principal est indisponible (et les sous-services inaccessibles).

 

b)     Les différents indicateurs

La disponibilité peut être mesurée de différentes manières. Selon le contexte, on peut utiliser des notions de disponibilité annuelle ou de disponibilité moyenne.

 

La disponibilité annuelle est la plus utilisée. Sa valeur indique le pourcentage de disponibilité sur un an :

  • 99,9% = 8h d’indisponibilité par an
  • 99,99% = 52 min d’indisponibilité par an
  • 99,999% = 5 min d’indisponibilité par an

 

Le deuxième indicateur, la fiabilité moyenne, est basé sur 3 mesures :

  • Le MTTF (Mean Time To Fail), qui est le temps d’occurrence d’une panne,
  • MTTR (Mean Time To Repair), le temps de réparation,
  • MTBF (Mean Time Between Failure), le temps moyen entre chaque défaillance,

Remarque : Cette méthode de calcul est utilisée dans de nombreuses industries et n’est pas seulement appliquée à l’informatique. La méthode AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité), est également utilisée pour quantifier les risques).


Afin d’augmenter la disponibilité d’un système, deux axes de travail sont possibles : réduire le taux de panne, ou réduire le temps de traitement des pannes.

Cette deuxième série d’indicateurs met en avant l’importance du temps de réparation d’une panne (MTTR).  En informatique, ce temps peut être décomposé en plusieurs étapes, dont les deux principales sont le temps de détection et le temps de réparation.

Il est facile de réduire le temps de détection grâce à un système de monitoring efficace :

  • Dans le pire des cas, la détection des incidents est faite par les utilisateurs eux même, qui contactent le support.
  • Dans l’idéal, le monitoring est proactif et les problèmes sont anticipés par l’équipe grâce à des informations remontées par le système de monitoring. Plus de détails seront donnés à ce sujet dans la partie 2.

Le temps de rétablissement peut quand à lui être réduit grâce à des systèmes de hautes-disponibilité, des sauvegardes efficaces, ou un PRA.

 

4.     Performance d’un service

a)     Définition

En dehors de la disponibilité, la qualité d’un service peut être définie par la performance de l’application.

La performance d’un service peut être basée sur plusieurs critères : Cela peut notamment être la fluidité d’exécution, le nombre de clients simultanés, ou encore le temps d’exécution d’un traitement. On peut également considérer la performance d’un point de vue du système, en mesurant les ressources (processeur par exemple) utilisées pour la réalisation d’une tâche.

 

La mise en place d’une mesure de la performance est importante dans les phases de mise en production, car elle permet de valider le ressenti utilisateur, qui reste une donnée subjective et variable si aucune mesure n’est effectuée.

 

b)     Choisir ses indicateurs

Pour chacun des services, il faut d’abord définir les indicateurs de performance à mesurer. Il faut choisir des mesures le plus proche possible du ressenti du client. En effet, le temps d’exécution d’un rapport lancé une fois par mois aura moins de valeur que le temps de chargement d’un calendrier affiché chaque matin sur tous les postes de travail.

 

Une fois ces indicateurs choisi, il faut définir les valeurs correspondantes à différentes qualités de service. On peut par exemple choisir une échelle à trois niveaux : qualité bonne, moyenne, et basse, où chaque niveau correspond à un temps de chargement d’une page web ou d’une application.

Ces valeurs doivent être relevées sur une base régulière, enregistrées et conservées pendant une longue période, de manière à pouvoir constater l’évolution des performances avec le temps. Cela implique bien sûr la possibilité de sortir des données de performance des applications de manière automatisée.

 

Idéalement, ce système de monitoring (aux fonctionnalités limitées) sera couplé avec un système de reporting (Cacti ou SCOM par exemple), permettant de sortir facilement des graphiques de la performance des applications sur une période donnée.

 

5.      Fixer des objectifs

En fonction de la criticité des services définis précédemment, on peut finalement définir un niveau de service attendu pour chaque application.

 

Les niveaux de services sont définis par un Service Level Agreement (SLA). Cet accord, établissant une disponibilité et un indice de performance cible peut être conclu en interne ou avec un client externe, mais également être établis pour la fourniture d’un service par un prestataire.

 

Il est primordial, lors de la négociation d’un SLA avec un client, d’avoir établi un contrat similaire avec tous les prestataires dont dépendent le service garanti. En effet, si vous garantissez un niveau de service pour un site web, il est indispensable que vos fournisseurs d’électricité, de réseau, ou votre hébergeur soit capable de fournir un service d’une qualité au moins égale à celle que vous souhaitez produire et garantir.

 


Une fois les indicateurs et la qualité de service cible définis et mesurés, il faut mettre en place des méthodes pour atteindre ces objectifs. La partie 2 traitera des axes de travail possibles, en se basant sur les méthodes ITIL.

par .

4 Commentaires

  1. JBrison dit :

    Bien cette article. Vivement la Part II.

  2. Ammesiah dit :

    Clair, ça rox du poney !
    Tu vois que c’est une bonne idée de les publier :p

  3. goma dit :

    Bonjour,
    je trouve votre article interéssant ,et j’ai vu que cela avait fait l’objet de la redaction de votre mémoire de fin d’étude.
    je suis confronté à la meme problématique.
    pourriez vous me faire parvenir un exemplaire de votre mémoire SVP.

    CORDIALEMENT

Laisser un commentaire

*