Gestion des événements (ITIL) – Wikipedia wiki

Pratique informatique formelle

Gestion d’événements , tel que défini par ITIL, est le processus qui surveille tous les événements qui se produisent via l’infrastructure informatique. Il permet un fonctionnement normal et détecte et dégénère également les conditions d’exception.

Un événement Peut être défini comme une occurrence détectable ou perceptible qui a une signification pour la gestion de l’infrastructure informatique ou la prestation du service informatique et l’évaluation de l’impact qu’un écart pourrait provoquer aux services. Les événements sont généralement des notifications créées par un service informatique, un élément de configuration (CI) ou un outil de surveillance.

But / portée [ modifier ]]

• Le but est la capacité de détecter les événements, d’étudier et de déterminer l’action de contrôle correcte
• Les événements (avertissements et exceptions) peuvent être utilisés pour automatiser de nombreuses activités de routine
• La gestion des événements peut être appliquée à tous les aspects de la gestion des services qui peuvent être contrôlés et peuvent être automatisés (éléments de configuration)
• Fournir des mécanismes pour la détection précoce des incidents.
• Certains types d’activités automatisées peuvent être surveillés par exception, ce qui réduit les temps d’arrêt.

Gestion des événements [ modifier ]]

Notification et détection des événements [ modifier ]]

Les notifications d’événements peuvent être propriétaires, seuls certains outils de gestion peuvent être utilisés pour détecter les événements. La plupart des éléments de configuration (CIS) génèrent des notifications d’événements à l’aide du protocole Open SNMP (protocole de gestion de réseau simple).
Les CI sont configurés pour générer un ensemble d’événements en fonction de l’expérience du concepteur.
Une fois une notification d’événement générée, elle sera détectée par l’outil spécifique (lire et interpréter)

Filtrage des événements [ modifier ]]

Le filtrage signifie que la notification de l’événement peut être ignorée ou communiquée à l’outil de gestion. S’il est ignoré, l’événement sera généralement enregistré dans un fichier journal sur l’appareil, mais aucune autre action ne sera prise.
Au cours de l’étape de filtrage, l’événement recevra un niveau de corrélation (type: informationnel, avertissement ou exception).
L’étape de filtrage n’est pas toujours obligatoire, certains IC ont des événements importants qui sont communiqués directement à l’outil de gestion (même s’ils sont dupliqués).

Signification de l’événement [ modifier ]]

Catégorisation standard basée sur la signification d’un événement:

• Informationnel (Info): L’événement ne nécessite aucune action immédiate et ne représente pas une exception. Ils sont enregistrés dans les fichiers journaux et maintenus pour une période prédéterminée. Ce type d’événement est utilisé pour vérifier l’état d’un appareil ou d’un service, pour confirmer l’état d’une activité, pour générer des statistiques (connexion de l’utilisateur, travail par lots terminé, mise à jour de l’appareil, nombre d’utilisateurs connectés à une application)
• Avertissement (Warn / Alert): L’événement est généré lorsqu’un appareil ou un service (application / utilitaire), approche d’un seuil convenu (KPI). Les avertissements sont destinés à informer le groupe / processus / outil afin de prendre les mesures nécessaires pour éviter une exception qui se produit.
• Exception (Erreur): signifie qu’un service ou un appareil fonctionne actuellement sous les paramètres / indicateurs normaux (prédéfinis). Cela signifie que le service commercial est affecté et que l’appareil ou le service présente un échec, des dégradations de performances ou une perte de fonctionnalité (serveur Web Down, couverture CS perdue pour plusieurs sites). Une panne de périphérique est une erreur.

Remarque L’ajout ci-dessous n’est pas un type d’événement mais une analyse qui peut être effectuée à partir des journaux d’événements:

• Analyse de tendance Les journaux d’événements doivent être régulièrement analysés pour indiquer que les modèles d’événements [info, avertir, alerte, erreur] peuvent indiquer un problème sous-jacent qui peut être résolu avant une perturbation de service grave.

Réponse [ modifier ]]

À ce stade du processus, un certain nombre d’options de réponse sont disponibles. Certaines des options disponibles sont:

• Journalisation des événements: quel que soit le type d’événement, une bonne pratique devrait être d’enregistrer l’événement et les actions prises. L’événement peut être enregistré en tant qu’enregistrement d’événement ou il peut être laissé comme une entrée dans le journal système de l’appareil.
• Alerte et intervention humaine: pour les événements qui nécessitent une intervention humaine, l’événement doit être dégénéré. Le but de l’alerte est d’informer la ressource (personne) correcte de gérer l’événement.

Record de l’incident: Un incident peut être généré lorsqu’une exception est détectée.

• RFC: En cas de RFC, il y a deux scénarios soulignés:
  • Pour une exception (deux nouveaux appareils réseau ont été ajoutés sans l’autorisation nécessaire)
  • Pour un changement (afin d’éviter une défaillance du système de fichiers, le serveur doit être mis à niveau. Il peut prendre un certain temps pour que le changement commence à fonctionner.)

Événement proche [ modifier ]]

• Dans le cas des événements qui ont généré un incident, un problème ou un changement, ceux-ci doivent être officiellement fermés avec un lien vers l’enregistrement approprié de l’autre processus
• Les événements d’information sont simplement enregistrés puis utilisés comme entrée dans d’autres processus, tels que la gestion de la sauvegarde et du stockage. Les événements de réponse automatique seront généralement fermés par la génération d’un deuxième événement.

Voir également [ modifier ]]

Les références [ modifier ]]