Vous faites partie d’une équipe informatique soucieuse de livrer des services de qualité à vos utilisateurs, qu’ils soient internes ou externes (clients). Que vous ayez ou non un ou plusieurs SALA en place, cet article est pour vous.
Généralités sur le SLA
Le SLA, Service Level Agreement, est une entente de niveau de service (au sens de la qualité) proposée par la Direction des Services d’Information (DSI) à son client (interne ou externe).
Cet outil permet de mesurer la qualité du service rendu en objectivant le niveau de performance attendu d’un service. Par exemple, deux objectifs de SLA de messagerie pourraient être : disponibilité de 99.9% et délai de reprise sur incident inférieur à 2 heures.
Il est encore très fréquent de ne pas avoir de SLA, en particulier pour les services informatiques internes. C’est une situation risquée, qui joue presque toujours en défaveur du service IT pour deux raisons :
- En l’absence d’entente sur le niveau de service, l’attente des utilisateurs sera spontanément celle d’une disponibilité parfaite et d’une résolution immédiate des incidents… ce qui est impossible. En mettant en place un SLA, vous habituez l’utilisateur à l’existence de limites au possible en fonction des moyens disponibles.
- La perception subjective des temps d’interruption est souvent exagérée, en particulier sur les temps longs. Par exemple, si l’utilisateur ne peut pas accéder à sa messagerie pendant 2 heures, il sera vraisemblablement agacé et insatisfait du service pour quelques temps. Pourtant, si cela n’arrive que trois ou quatre fois par an, cela reste conforme à un objectif de disponibilité de 99.9%, qui peut être aisément acceptable.
Quatre cas où l’existence de SLA peut s’avérer précieuse pour la DSI
- Lors de l’évolution des besoins du client : Quand le niveau de service attendu en fonction du coût est bien défini, il est plus facile de justifier un équilibrage nécessaire lors d’une augmentation du nombre d’utilisateurs, de la plage de fonctionnement ou du volume de données, par exemple.
- Dans le renforcement de votre image : Avec un SLA dont découle des objectifs de performance, il est possible de valoriser chaque mois, trimestre et année la qualité du service rendu.
- Lors d’opération de maintenance : Le fait d’avoir des SLA de disponibilité permet d’avoir un cadre négocié avec des plages de maintenance, ce qui vous offre plus de souplesse opérationnelle et diminue l’inconfort perçu par les utilisateurs lors des interventions.
- En cas de litige. C’est ce que l’on souhaite tous éviter, bien entendu… mais on doit s’y préparer. Quand un client mécontent demande réparation, le SLA permet de déterminer de façon claire et objective dans quelle mesure la qualité de service est conforme ou non aux objectifs fixés.
La principale motivation des utilisateurs pour mettre en place un SLA, lorsqu’ils sont à l’origine de la demande, est d’avoir une disponibilité plus forte, combinée à une capacité de montée en charge et une reprise dans un temps court en cas d’incident. Être proactif sur ces questions vous aidera à éviter de prendre des engagements qui ne sont pas en adéquation avec vos moyens.
Les informations que doivent contenir un SLA
Voici les éléments clés que vous devez intégrer dans chaque entente de niveau de service que vous établirez avec vos clients et utilisateurs :
- Le type de service à fournir : l’ensemble des prestations assurées par le fournisseur. Dans le cas de la DSI, il s’agit en principe de l’installation et maintenance en état de marche de l’ensemble des systèmes d’information de l’entreprise.
- Le niveau de performance exigé, à commencer par la réactivité et la fiabilité générale du service.
- Le processus client à suivre pour signaler les problèmes et ainsi permettre une prise en compte plus rapide : Qui fait la demande, à qui, par quel moyen et en joignant quelle information.
- Les temps de réponse et de résolution des anomalies.
- Les moyens d’analyse de la performance du service (KPI) et modalité de communication avec le client (en interne, la direction générale par exemple).
- Les répercussions pour le fournisseur en cas de défaillance, en particulier dans le cas de prestataire extérieur. L’apport de l’analyse d’impact dans la rédaction d’un SLA.
L’apport essentiel de l’analyse d’impact pour vos SLA informatiques
Afin d’assurer un niveau de qualité en accord avec les attentes des utilisateurs, il est essentiel pour la DSI de maîtriser l’infrastructure des services sur trois aspects :
- La configuration technique : liste des assets, configuration des composants et interdépendances (un audit d’infrastructure informatique peut être utile)
- L’impact des interventions qui peuvent être réalisées.
- L’impact de chaque changement sur le fonctionnement du service.
Avant chaque intervention pouvant entraîner une discontinuation (ou un fonctionnement dégradée) du service, une analyse d’impact doit être réalisée, afin de la valider ou la rejeter en fonction de ses conséquences y compris vis-à-vis des objectifs de disponibilité des SLA. (NB : Si vous avez adopté les bonnes pratiques ITIL, vous avez réalisé l’analyse d’impact durant le CAB (Change Advisory Board).)
Concernant le domaine des systèmes d’information, il existe deux types d’analyses d’impact que vous pouvez mener : la CFIA et la BIA, détaillés ci-dessous.
L’analyse d’impact de l’indisponibilité d’un composant (CFIA – Component Failure Impact Analysis)
L’intervention sur un composant de vos systèmes d’information peut avoir des répercussions plus ou moins grandes sur le reste de l’infrastructure, et donc la bonne marche d’un ou plusieurs services. Qu’il s’agisse de tester un disjoncteur ou de migrer une base de données, l’analyse d’impact CFIA sert à maîtriser les risques et conséquences de vos interventions pour le métier.
Le Bilan d’Impact sur l’Activité (BIA) comme base de référence
L’analyse BIA (Business Impact Analysis en version originale) permet d’assurer la pertinence dans la planification de vos interventions en fonction de l’agenda métier de votre client.
En effet, l’interruption d’un service n’aura pas le même impact pour le business en fonction de l’heure de la journée ou la période de l’année où elle a lieu.
Par exemple, chez un e-commerçant, une intervention majeure sur le réseau a été rejetée car elle devait être réalisée pendant la semaine des soldes flottantes.
Ces éléments préparatoires à toute mise en production apportent une baisse substantielle du nombre d’incidents, et donc une qualité accrue de la qualité des services rendus, qui sera mesurée par les SLA.
Enfin, si vous maîtrisez la maintenance systématique de votre infrastructure informatique, il est possible grâce à l’analyse d’impact d’intégrer directement dans votre SLA des plages d’indisponibilité requises pour réaliser les interventions périodiques.
Nous discuterons dans un prochain post de la bonne manière de réaliser ces analyses d’impact (BIA et CFIA), notamment avec l’usage d’une CMDB (Configuration Management DataBase, Base de Données de Gestion de Configuration) comme Corrium ou d’un DCIM (DataCenter Infrastructure Management) comme Nlyte.