Après la mise en production : supervision, incidents, SLA et satisfaction

Après la mise en production, le service entre dans une période de surveillance rapprochée : on renforce le support, on supervise ses composants, on traite vite les incidents de démarrage, puis on mesure s'il tient ses engagements et s'il satisfait ses utilisateurs. Au bout de quelques semaines, un bilan décide si le service est stable, et il passe alors entre les mains de l'équipe d'exploitation. Ce chapitre organise ce suivi, définit les indicateurs d'un service et les calcule, puis rédige le bilan de mise en service.

La période de support renforcé

Les premiers jours concentrent les questions, les incidents et les défauts que la recette n'a pas vus. La période de support renforcé (on dit aussi hypercare) mobilise l'équipe qui a construit le service à côté du support habituel, pendant une durée fixée à l'avance.

Le critère de sortie est aussi important que la durée. Sans lui, le support renforcé s'arrête quand l'équipe est appelée ailleurs, pas quand le service est stable.

Superviser le nouveau service

Un service ouvert doit être surveillé avant que les utilisateurs ne signalent une panne. Reprends le tableau des dépendances du chapitre 2 : chaque dépendance forte donne au moins un élément supervisé, avec un seuil et un destinataire d'alerte.

Le cours Supervision montre comment écrire un scénario web dans Zabbix et comment régler les déclencheurs. Ajoute le nouveau service au tableau de bord que l'équipe regarde chaque matin : un service qu'on ne voit nulle part est un service qu'on oublie.

Traiter les incidents des premiers jours

Chaque problème remonté passe par l'outil de tickets, même si l'utilisateur a appelé ou est venu voir l'équipe dans le couloir. C'est la seule façon de mesurer, d'analyser et de prouver (gestion des incidents).

Pendant le support renforcé, trie chaque ticket en trois familles :

Quand le même incident revient, ouvre un problème pour en chercher la cause (gestion des problèmes). La correction passe par une nouvelle version, recettée et déployée comme la première, au moins pour ses cas de non-régression : la discipline du chapitre 4 ne s'arrête pas le jour de l'ouverture.

Les indicateurs d'un service

Un indicateur est une mesure chiffrée, calculée toujours de la même façon, qui dit si le service tient ses promesses. Les indicateurs utiles après une mise en service couvrent la garantie (le service est-il là et rapide ?), le support (les problèmes sont-ils réglés vite ?) et l'adoption (les utilisateurs s'en servent-ils, et en sont-ils contents ?).

Le calcul de la disponibilité de Prêt'Matos sur son premier mois : 22 jours ouvrés de 8 h à 18 h donnent une plage de 22 × 10 = 220 heures, soit 13 200 minutes. Le service a été indisponible 40 minutes, un matin où l'hôte Proxmox a redémarré pour une mise à jour non annoncée.

Disponibilité = (13 200 − 40) ÷ 13 200 ≈ 0,99697, soit environ 99,70 %

L'objectif de 99 % sur la plage autorisait 1 % de 13 200 minutes, soit 132 minutes (2 h 12 min) d'arrêt : il est tenu. L'incident a quand même un enseignement : la maintenance de l'hôte touche tous les services qui y tournent, elle doit être annoncée et placée hors de la plage de service.

SLA : l'engagement et son calcul

Le SLA (service level agreement, accord de niveau de service) est l'engagement écrit entre le fournisseur d'un service et son client : ce que le service fait, sur quelle plage, avec quelle disponibilité, en combien de temps un incident est pris en charge et résolu. Dans une PME, il tient souvent en quelques lignes de la fiche service ; avec un prestataire, il fait partie du contrat (contrat de service et SLA). L'OLA est l'engagement interne entre deux équipes qui concourent au service, et le contrat de sous-traitance celui d'un fournisseur extérieur (SLA, OLA et contrat de service).

Le même pourcentage de disponibilité ne promet pas du tout la même chose selon la plage de service sur laquelle il s'applique :

Un SLA réaliste se fixe avec le propriétaire du service, à partir de ce dont il a besoin et de ce que l'infrastructure peut tenir. Promettre 99,9 % pour un service qui repose sur une seule VM, sans supervision la nuit, c'est s'engager à échouer. Le cours Supervision détaille ces calculs, et le cours GLPI les délais de prise en charge et de résolution des tickets.

Mesurer la satisfaction

L'indicateur de l'E5 le dit : le service déployé doit « donner satisfaction à l'utilisateur ». La satisfaction ne se devine pas, elle se demande.

Quand. Assez tard pour que les utilisateurs aient vraiment utilisé le service, assez tôt pour corriger : entre J+15 et J+30. Pour le support, une enquête courte après chaque ticket résolu (GLPI la propose : clôture automatique et enquête de satisfaction).

Comment. Une enquête de trois à cinq questions, pas plus, qui prend deux minutes. Celle de Prêt'Matos, à J+18 :

1. Dans l'ensemble, êtes-vous satisfait de Prêt'Matos ? (de 1, pas du tout, à 5, tout à fait)
2. Réserver est-il plus simple qu'avant ? (oui, pareil, non)
3. Avez-vous trouvé l'aide dont vous aviez besoin ? (oui, non, je n'en ai pas eu besoin)
4. Qu'est-ce qui vous gêne le plus ? (réponse libre)
5. Qu'aimeriez-vous pouvoir faire de plus ? (réponse libre)

Ce qu'on calcule. Le taux de réponse (12 réponses sur 14 salariés : 85,7 %), puis le CSAT (customer satisfaction score), la part des réponses 4 ou 5 à la première question. Les douze notes reçues sont 5, 5, 4, 4, 4, 4, 4, 3, 5, 4, 2, 4 : dix sont à 4 ou 5, le CSAT est donc de 10 ÷ 12 ≈ 83,3 %, et la moyenne de 48 ÷ 12 = 4,0. Les réponses libres comptent autant que les chiffres : deux salariés demandent à pouvoir prolonger un prêt, ce qui rejoint une story déjà au backlog.

Le bilan de mise en service

À la fin de la période de suivi, le bilan de mise en service (ITIL parle de revue post-implémentation) répond à trois questions : le service atteint-il ses objectifs ? Qu'avons-nous appris ? Que reste-t-il à faire ? Il clôt la demande de changement et le projet, et il nourrit les prochaines mises en service.

Le retour d'expérience (REX) est la partie « enseignements » : ce qui a bien marché, ce qui a moins bien marché, et ce qu'on changera la prochaine fois. Il se fait sans chercher de coupable : on corrige un processus, pas une personne.

Le passage en exploitation

Le projet se termine, le service continue. Le passage en exploitation (ou transfert en production, handover) remet le service à l'équipe qui le fera vivre au quotidien. Il est réussi quand cette équipe peut l'exploiter sans appeler ceux qui l'ont construit :

Dans un contrat avec un prestataire, ce moment coïncide souvent avec la fin de la vérification de service régulier (VSR, chapitre 4) et le début de la période de garantie ou de maintenance.

Exercices