Réflexions sur la gestion des SLA dans GLPI.

Questions

  • yllen :
    • SLA
      • Comment enregistre-t-on les infos des SLA indispensables au suivi du ticket (impact, délais...) ? Je pense qu'il manque des champs de saisi
        • cf. objet SLA
      • Actuellement on peut choisir un applicatif au sens CI. Demain, comment avoir un service au sens SLA ?
      • Comment trouvé le service fonctionnel d'un utilisateur ? En effet, le groupe est plus un groupe de compétence. Enfin, il faut les 2 notions : groupe de compétence et groupe fonctionnel.

Règles SLA

Un SLA (accord de qualité de service) s'applique aux tickets (Requêtes : incidents ou demandes). Il est décrit par un titre et un descriptif.

Un SLA définit sur une entité, pouvant être récursif.

Attribution SLA

En utilisant le système de règle générique on attribue un SLA à un ticket suivant certaines règles.

On décide si le ticket doit vérifier toutes les règles (AND) ou seulement certaines règles (OR).

Une règle vérifie un et/ou plusieurs critères.

  • Auteur du ticket
  • Groupe
  • Élément d'inventaire
  • Priorité
  • Catégorie
  • Descriptif
  • Source de la demande
  • ...
  • Entité
  • Période : entre telle date et telle date pour gérer les SLAs spécifiques pour une ou plusieurs période (vacances)

Si les critères correspondent, le SLA est affecté au ticket.

Peut-être : étudier évolution mixage critères et/ou sur moteur de règles

Définition d'un SLA

Détermination du délai de résolution

Résolution : au moment de la résolution technique / pas clôture administrative

Il est nécessaire de spécifier en JJ/HH/MM le temps maximum de résolution du ticket auquel est affecté le SLA. (Option : Avec prise en compte ou non des heures d'exploitation et des jours fériés cf plus bas gestion des calendriers).

C'est ce délai de résolution qui servira au calcul de la première date d'échéance pour le ticket et servira de point temporel pour le passage vers un niveau d'escalade s'il existe.

Cas de délais possibles :
- sans calendrier : en heures calendaires
- avec calendrier : en heures ouvrées

Niveaux d'escalades

Un SLA est constitué de plusieurs niveaux d'escalades facultatifs : par exemple de 1 à 5

Le passage d'un niveau d'escalade à un autre se fait sur la base d'un temps dépassé dans la résolution du ticket.

Par défaut le niveau est à 1.

Chaque niveau est définit par :

  • son ordre (1-2-3-...)
  • l'action ou les actions (affecter le ticket à un autre techos, changement de priorités/urgences, autres actions ?)
  • Son instant d'exécution (lorsque le temps de résolution est écoulé) :
    • Avant : JJ/HH/MM -> escalade a priori
    • ou Aprés : JJ/HH/MM -> escalade a posteriori
  • ou pas d'ordre mais délai à partir du début de la date d'échéance

Horaires d'exploitation

Un calendrier facultatif associé par l'utilisateur.

Jours fériés

Détermination des jours fériés.

Date et description.

Heures d'exploitation

Détermination des heures effectives par jour ou d'un système 24/24.

Détermination des jours de fonctionnement du helpdesk sur la semaine.

Création d'un nouveau ticket

Préalable : création d'une table de travail SLA

1) Conditions :

  • Une date d'échéance a t'elle été définie à la création du ticket ? si oui on affecte pas de SLA.
    • Date d'échéance non définissable par la post-only

2) Calcul de la date d'échéance

Date d'échéance = date de création du ticket + délai SLA - horaires d'exploitation

Remarque : si le ticket est modifié et qu'on lui affecte une nouvelle date d'échéance, le ticket sort du système de SLA

3) Enregistrement de la date d'échéance.

4) Calcul des dates des actions à réaliser

date action à réaliser = Date d'échéance + ou - instant d'exécution de l'action SLA

exemple :

ticket crée le 01/01/08 , SLA 3 jours -> échéance au 04/01/08, action à réaliser 1 J avant (changer la priorité par ex)

03/01/08 = 04/01/08 - 1j

5) Enregistrement des dates des actions à réaliser

Gestion du Statut "en attente"

Associer à ce statut l'arrêt du chronomètre pour le calcul du SLA.

Le statut en attente provoque la sortie du ticket du circuit d'escalade mais on pose un marqueur de date_attente_begin.
A la sortie du statut en "attente", on calcule le délai d'attente. (date_attente_begin -> date_attente_fin).

Un nouvelle échéance est donc recalculée : Date de création du ticket + délai SLA + délai attente

Exemple : date de création 01/01/2008, SLA du ticket 3 jours, date échéance initiale 04/01/2008

Le ticket est mis en attente du 2/01/2008 au 3/01/2008 inclus soit deux jours. La nouvelle date d'échéance est le 06/01/2008.

Cette procédure est réalisée à chaque fois que le ticket passe sur le statut "en attente". Le délai d'attente est donc une valeur cumulée.

Un ticket en attente n'a plus de date d'échéance affichée. Utiliser pour le calcul du délai d'attente la même méthode de calcul que la date d'échéance.

Procédure de détermination des actions SLA à effectuer

Action Cron toutes les 5 minutes :

On parcourt la table de travail SLA pour déterminer les action à réaliser.

Modifications collatérales à prévoir

Liste des suivis (interface tracking)

Nouvelle colonne : Échéance

Nouveau tri : afficher les tickets arrivant à échéance, afficher les tickets en retard

Rapports SLA

Un certains nombre de statistiques et/ou de rapports sont à prévoir.

- Requêtes en retard par groupe/catégorie/par date d'échéance/par niveau/priorité/date d'ouverture/par technicien

- Requêtes en attente par groupe/catégorie/par date d'échéance/par niveau/priorité/date d'ouverture/par technicien

Mise en Œuvre

  • Affectation d'une SLA via les business rules.
  • Tickets : Date d'échéance / SLA / Niveau courant escalade
  • SLA :
    - caractéristiques : Nom / Description / Liste de niveaux d'escalade / calendrier (facultatif)
  • Niveaux d'escalade :
    - caractéristiques : action(s) à réaliser / instant d'exécution
  • Horaires d'exploitation / calendrier : GlpiCalendar
    - comment coder / stocker le calendrier ?
    - Horaires à la minute
    - multi horaires dans journée : 8h-12h + 14h-18h ? ou une plage par jour ? une plage pour tous les jours ?
    - Jours fériés / jours travaillés
    - Le calcul d'une date d'échéance doit être le plus simple possible (forcément complexe de toute manière)
  • Table de travail :
    - caractéristiques : date / action à réaliser (ticket / niveau escalade SLA)
    - actions possibles :
    - Changement niveau escalade : faire actions et changer niveau d'escalade du ticket -> création nouvelle action si nécessaire
    - Sortie statut en attente : mise à jour délai en attente / calcul nouvelle date échéance / création nouvelle action si nécessaire
  • gestion statut "En attente" :
    - ajout 2 champs dans ticket : début attente / durée totale attente