Manuel de contenu prédéfini › Modules de logique applicative › Modules de logique applicative de gestion de disponibilité

Modules de logique applicative de gestion de disponibilité

Les sections suivantes décrivent les modules de logique applicative génériques, utilisés dans les métriques communes aux services du centre d'assistance.

Hypothèses relatives à la gestion de disponibilité

Les hypothèses les comportements de base suivants sont adoptés pour tous les modules sous le domaine Disponibilité :

• Le statut initial du composant, lors de la première période de calcul, est actif, avant la réception d'un événement sur l'état de ce composant
• Il existe un statut Aucun. Lorsque le statut d'une ressource est inconnu, les statuts jusqu'à celui d'Aucun sont considérés comme basés sur le dernier statut réel de la ressource
• Lorsqu'une période est définie en dehors de la période d'application, la période d'exception est traitée de la même manière.
• Si la période de calcul entière est définie en dehors de la période d'application, le résultat pour la période sera Nul.
• Evénements forcés : dans certains cas les informations relatives à la disponibilité de service provenant de l'outil de surveillance sont incorrectes ou non valides. Dans ce cas, un événement supplémentaire est défini, son statut est alors imposé sur tout événement préalablement reçu. Par exemple, si le service a été signalé comme actif, et qu'un événement Force Down (Forcer l'inactivité) est reçu, le service est considéré comme inactif.
• Evénements relatifs aux incidents : dans certains cas, les événements relatifs aux incidents indiquent le statut de disponibilité. Par exemple, Incident - Open (Incident ouvert) pour un ticket de priorité 1 indique un statut inactif (DOWN), alors que Incident - Resolved (Incident résolu) pour un ticket de priorité 1 indique un statut actif (UP).
• Lorsqu'un nouvel événement se produit, la formule vérifie le statut de l'événement précédent. Si le statut de l'événement précédent est défini sur inactif, la période entre cet événement et le nouveau est également considérée comme inactive.
• Les événements peuvent indiquer le statut d'un composant, d'une unité spécifique ou de l'ensemble du service. Si des événements à la fois globaux et relatifs à des composants sont signalés, les évènements globaux seront considérés disposant du statut réel.

Types d'événements de gestion de la disponibilité

Les types d'événement de la gestion de la disponibilité suivants fournissent le statut de la disponibilité d'un périphérique ou d'un service spécifique :

• Evénement de disponibilité UP
• Evénement de disponibilité DOWN
• Evénement de disponibilité Force UP
• Evénement de disponibilité Force DOWN
• Evénement de disponibilité Force NONE

De plus, les événements d'incident (comme décrits dans la partie Module de la gestion des incidents) peuvent être utilisés pour refléter le statut de disponibilité du service ou d'un périphérique. Par exemple, Incident - Open (Incident ouvert) peut représenter un statut inactif (DOWN), alors que Incident - Resolved (Incident résolu) représente un statut actif (UP).

Structure des types d'événements de disponibilité

Le tableau suivant indique la structure de tous les types d'événements de disponibilité :