La qualité de service TI – 2e partie

Dans la première partie de cette article, nous avons vu comment établir une liste de services et mesurer leur disponibilité. Nous allons maintenant passer en revue quelques conseils afin de gérer au mieux les systèmes qui composent ces services.

 

Les autres chapitres :

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


Partie 2 -Améliorer la qualité d’un service

Comment structurer son travail pour améliorer la qualité de service ?


1.       Introduction

Malgré le fait que l’aspect technique soit prédominant dans les métiers de l’informatique, un encadrement des méthodes de travail de l’équipe TI peut aider grandement à améliorer la qualité du service fourni et faciliter la gestion de la plateforme.

 

a)     Utiliser ITIL comme base de travail

La librairie de bonnes pratiques ITIL (Information Technology Infrastructure Library) est une bonne base pour mettre en place un fonctionnement par processus et industrialiser les méthodes. Cependant, une rigueur de travail et quelques bonnes habitudes restent toujours indispensables.

En dehors des méthodes ITIL, de nombreuses bonnes pratiques peuvent en effet aider à la gestion quotidienne d’une plateforme, surtout dans une équipe. Ces recommandations ne peuvent pas être définies dans des procédures, et sont plus une notion d’éducation de l’équipe.

 

b)     Guider l’équipe

Dans une compagnie où ITIL est en cours de mise en place, il est nécessaire de montrer à chaque membre de l’équipe TI les avantages de travailler avec les bonnes méthodes et avec une rigueur d’exploitation. Même si documenter son infrastructure et suivre des procédures peut paraitre une contrainte au premier abord, de nombreuses situations peuvent être simplifiées lorsque l’on travaille ainsi, notamment la passation de compétence, la gestion de projet, ou la réinstallation d’une application sur un nouveau serveur…

Dans cet article, nous allons passer en revue de nombreuses bonnes pratiques basée sur les processus fournis par la librairie ITIL, qui peuvent donner des axes de travail afin d’améliorer la qualité de service.

 

2.      Les processus ITIL

a)     Introduction à ITIL

ITIL est un ensemble d’ouvrages définissant des bonnes pratiques pour la gestion des services informatiques. Depuis plusieurs années, de nombreux managers TI implémentent ces méthodes de gestion dans leurs services, en intégrant un certain nombre de processus ITIL dans leurs équipes dans le but d’améliorer la qualité de service.

 

Les principes définis par cette librairie ne doivent pas être considérés comme des normes rigides qu’il faut appliquer à la lettre mais comme des éléments vers lesquels orienter ses pratiques.

Le référentiel ITIL décrit une dizaine de processus, cadrants chacun un aspect d’un service informatique. La plupart de ces processus ne sont pas applicables aux services TI de toutes les entreprises. Il est donc important de prioriser les pratiques à mettre en place et de fixer des objectifs de manière réaliste.

 

D’après l’étude « ITIL et la performance en entreprise 2010 » menée par DevoTeam, les méthodes les plus développés par les entreprises sont la gestion des incidents et la gestion des changements. Il s’agit en effet des processus donc la mise en place aura potentiellement le plus d’impact sur la qualité de service dans une entreprise n’appliquant pas encore les processus ITIL.

Ces deux processus sont tous les deux importants pour la gestion de la disponibilité, mais abordent le problème d’un point de vue différent : Alors que la gestion des incidents permet de traiter les problèmes signalés par le système de supervision ou les utilisateurs, la gestion des changements permet de cadrer les modifications effectuées sur les systèmes dans le but de prévenir les incidents.

 

b)     Gestion des changements

De nombreux analystes indiquent que 60% à 80% des changements non planifiés échouent en causant un incident et 50% des changements ne sont pas planifiés. En partant de ce constat, il devient évident que la stabilité d’un système dépend, entre autres, des changements effectués et de la manière dont ils sont effectuées.

 

Une gestion des changements complète est basée sur un système des suivi des demandes (RFC – Request For Change), d’approbation par les personnes responsables, et de mise à jour des outils de gestion.

Le but de ce système de demandes est de planifier les changements, d’anticiper chaque étapes d’une maintenance, et de prévoir la possibilité d’un retour arrière. Des changements cadrés permettront d’obtenir un rapport taux de changement / risque d’incident faible.

 

Dans un premier temps, une description des changements effectués, de leur impact, des possibilités de retour en arrière et de la planification permettra de cadrer les changements réalisés par les équipes.

 

c)      Gestion des incidents

La gestion des incidents a pour but de réduire le temps d’indisponibilité des applications dus aux incidents. En effet, une disponibilité de 100% est impossible : L’occurrence d’incident étant inévitable, comment maitriser l’incident ?

 

Comme nous l’avons vu dans la première partie, la durée d’un incident peut être décomposée en plusieurs étapes : la détection, la prise en charge et la résolution.

La détection des incidents est la phase qu’il est le plus facile de minimiser. En effet, la mise en place d’un logiciel de supervision permet de surveiller chaque composant des systèmes et de prévenir les équipes concernées au plus vite. Un système efficace sera même capable d’anticiper les incidents en signalant les problèmes avant qu’ils ne deviennent critiques (espace disque en diminution, latence élevée), permettant ainsi une gestion proactive des incidents. Il pourra également lancer des tâches pour tenter de résoudre automatiquement un incident (en redémarrant d’un service par exemple).

 

Les alertes sont un point clé d’un système de supervision. Il est donc primordial de ne pas noyer les équipes sous une avalanche de mails et de prioriser les incidents.

 

Une décomposition des services par couche permet par exemple de répartir les différentes alertes selon la responsabilité de chacun et la priorité :

 

L’infrastructure de base (réseau, hardware, virtualisation…) peut être regroupée dans un socle commun servant de base au reste des services. L’ensemble de ces systèmes est considéré comme un seul service, fourni aux services de niveaux supérieurs, et qui n’atteint pas directement le client.

Les alertes émises pour ces systèmes sont donc d’une priorité maximale, tandis que chacun des autres services disposent d’un autre niveau de priorité.

 

Une fois les incidents priorisées, l’utilisation de pratiques simples peut permettre de traiter différemment les alertes en fonction de leur gravité : Une règle de messagerie, basée sur la criticité signalée dans l’objet du mail d’alerte, peut par exemple permettre de faire ressortir en rouge les alertes importantes, ou de les escalader à l’ensemble d’une équipe ou sur un téléphone pendant les périodes d’astreinte.

 

Si un événement n’a pas été signalé par le système, c’est que la supervision n’est pas 100% efficace. Son amélioration est donc une tâche quotidienne, qui doit être réalisée suivant la vie de la plateforme. Il est donc important de ne pas s’arrêter à une configuration basique et d’impliquer les équipes, qui doivent apprendre à mettre en place les surveillances qui les intéressent.

 

d)     Gestion des demandes

Lorsque les utilisateurs signalent des problèmes, il est faut que les incidents remontés puissent facilement être mis en relation avec les alertes en cours. Afin de simplifier ce processus et pour permettre aux utilisateurs d’accéder au support d’une manière simplifiée, il faut que, quelque soit les moyens de communication, les informations signalés soient traitées dans un seul et même outil par l’équipe TI.

Les points d’entrée (appelés SPOC – Single Point of Contact), peuvent comprendre une adresse mail (support@societe.com par exemple), le téléphone (un numéro unique sonnant en rotation sur l’ensemble des postes des techniciens), ou un portail web.

Cela permet aux utilisateurs d’obtenir une meilleure réactivité vis-à-vis de leur demandes et d’en obtenir un suivi, et aux techniciens de recevoir des tâches pré-assignées selon les compétences de chacun.

 

e)     Gestion des connaissances

Une fois le problème identifié, l’équipe prend en charge sa résolution. Afin d’aider le travail des autres, chaque membre de l’équipe doit documenter les problèmes qu’il rencontre dans une base de connaissances (une KB : Knowledge Base), organisée selon chaque système. Ainsi, chaque alerte peut référer à un article ou une catégorie de la KB, dans le but d’aiguiller les personnes prenant en charge les alertes vers des pistes à explorer.

Idéalement, chaque alerte émise doit référer à un article ou une rubrique de la base de connaissance, afin de ne pas laisser les administrateurs sans une piste de résolution.

En dehors de l’aide à la résolution des incidents, cette démarche aide à la passation des connaissances et permet à chacun d’obtenir les informations de base pour gérer un système.

 

f)       Gestion des configurations

La gestion des configurations est un autre aspect important des bonnes pratiques ITIL, cependant, c’est l’un des plus difficiles à déployer si la société n’a jamais eu de base de données concernant son parc informatique.

Les apports de ce composant sont multiples : il apporte une aide à la gestion du parc, au déploiement des nouveaux systèmes et postes de travail ou encore à l’installation des applications.

 

La base de ce processus est l’outil d’inventaire, permettant de peupler la base de gestion de configuration : la CMDB (Configuration Management DataBase). La CMDB contient le détail de la configuration de chaque serveur, poste de travail ou application présente dans le parc et les lient à un service TI. Dans les déploiements ITIL poussés, la CMDB est également capable de s’interfacer avec chaque processus ITIL et avec les différents outils de gestion TI (monitoring, support, gestion des achats…) et de présenter une vue de ces composants par service.

 

Une des premières taches effectuées lors de la mise en place d’un outil d’inventaire consiste à renseigner l’ensemble des systèmes déjà existants. La plupart des applications de monitoring et d’inventaire disposent d’outils de découverte des systèmes (en scannant une plage d’adresses IP ou l’annuaire d’entreprise) permettant de peupler rapidement la CMDB.

 

Une fois les systèmes enregistrés, il peut être intéressant de raisonner avec des configurations modèles. Ces modèles (appelés parfois masters ou templates) peuvent concerner des serveurs, des postes de travail ou encore des systèmes d’exploitation, et définissent des contraintes qui doivent être respectés pour que le composant soit considéré comme correspondant au modèle.

L’utilisation des configurations modèle permet une meilleure gestion quotidienne et simplifie grandement l’administration du parc. Cela peut être pour valider facilement les pré-requis d’une application ou encore faciliter le remplacement du matériel.

 

Afin d’établir un système de configuration modèle, l’ensemble de l’équipe doit raisonner afin d’industrialiser ses méthodes de travail. L’idée de base est d’automatiser au maximum l’ensemble des tâches liées au déploiement d’un système et les maintenances quotidiennes afin de minimiser les différences entre chaque serveur ou chaque poste de travail.

 

g)     Capacity planning

Le dernier volet d’ITIL que nous allons traiter est la gestion des capacités, dont le but est de faciliter la gestion de l’évolution des besoins informatique de la société.

Le capacity planning, même si il est souvent oublié ou utilisé uniquement lors des projets d’envergures, est pourtant un point important de la gestion d’une infrastructure et permet d’éviter les évolutions de systèmes difficiles. En effet, de nombreux problèmes sont liés à des systèmes qui ont atteints la limite de leur « zone de confort ». Penser à l’évolution d’un système dés sa conception permet de réduire ces problèmes.

 

La gestion des capacités est basée sur la mesure des consommations de chaque système. En relevant par exemple la charge mémoire, processeur, disque et réseau pendant une longue période, on peut facilement en tirer des graphiques et réaliser des projections sur l’évolution des consommations d’une application. Mise en relation avec le temps de réponse, ces relevés peuvent même servir à tracer un pic de charge ou identifier les goulots d’étranglement (bottlenecks).

 


Après avoir traité de l’amélioration de la qualité de service par les méthodes de travail, nous aborderons le problème sous un aspect plus technique dans la 3e partie, avec quelques conseils utiles lors de la conception de systèmes.

par .

Laisser un commentaire

*