Éviter le bruit dans la gestion des incidents

Suppression. Selon le thésaurus , ce mot est synonyme de termes comme suppression, élimination et annihilation.

Cependant, dans le contexte de la gestion des incidents, la suppression a une signification bien différente. Il ne s'agit pas de supprimer définitivement les données. Il s'agit plutôt de garantir que les administrateurs se concentrent sur les bonnes alertes au bon moment, en atténuer le bruit .

Voici un aperçu de la façon dont suppression contribue considérablement à rationaliser la gestion des incidents.

Pourquoi la répression est importante

Pourquoi la suppression est-elle utile dans la gestion des incidents ? En résumé, c'est parce que infrastructures modernes génère un volume considérable d'alertes, et les administrateurs ne peuvent raisonnablement pas espérer examiner chaque alerte. S'ils essayent, ils seront rapidement soumis à des sanctions. fatigue d'alerte , ce qui signifie qu'ils commenceront à ignorer des alertes potentiellement importantes, car ils sont débordés et épuisés. Et s'ils cessent d'y prêter attention, c'est tout le processus de gestion des incidents qui s'effondre.

Suppression des alertes Il existe un moyen d'éviter ce problème. En supprimant certains types d'alertes, les administrateurs peuvent s'assurer que les alertes prioritaires et exploitables reçoivent la plus grande attention. Ils peuvent également réduire le nombre total d'alertes affichées sur leurs tableaux de bord, ce qui contribue à prévenir le risque de lassitude.

Prenons l'exemple d'une organisation dont les postes de travail redémarrent une fois par semaine la nuit suivant l'installation des mises à jour. Ce redémarrage génèrerait une série d'alertes lors de la mise hors ligne et de la remise en service des postes. L'ajout de ces alertes au tableau de bord des incidents accessible aux administrateurs ne serait pas utile, car elles reflètent un événement procédural de routine ne nécessitant aucune action. Pour éviter ce bruit inutile, les administrateurs peuvent configurer leur logiciel de gestion des incidents pour supprimer les alertes liées au redémarrage d'un poste de travail.

La répression : pas une question de choix entre l'un ou l'autre

Il est important de comprendre que la suppression des alertes n'est pas une question de choix. Autrement dit, les administrateurs ne peuvent pas se limiter à activer toutes les alertes d'un certain type ou à les supprimer définitivement.

Ils peuvent plutôt prendre une décision plus approche nuancée de la suppression La suppression des alertes pourrait être configurée de manière à ce que les alertes d'un type donné soient supprimées, sauf si elles se produisent de manière répétée au cours d'une période donnée, par exemple. Les alertes pourraient également être configurées pour être signalées si elles se produisent à une heure précise de la journée, mais supprimées à d'autres moments. De même, les administrateurs pourraient souhaiter supprimer les alertes d'un type particulier si elles se produisent sur certains appareils, mais pas sur d'autres.

Cette flexibilité est importante car elle permet aux administrateurs d'optimiser l'efficacité des alertes. Au lieu d'appliquer des politiques de suppression trop larges et trop strictes, ils peuvent ajuster les paramètres de suppression afin d'optimiser la visibilité des événements importants sans alourdir inutilement le système de gestion des incidents.

Une suppression nuancée pourrait être utile dans l'exemple ci-dessus. Comme je l'ai indiqué, les administrateurs ne souhaitent généralement pas recevoir d'alertes lorsqu'un poste de travail redémarre en pleine nuit après une mise à jour logicielle. Cependant, si le logiciel de gestion des incidents détecte un poste de travail qui redémarre plusieurs fois au cours de la même période, cela pourrait signaler un problème (comme une mise à jour logicielle défectueuse) dont les administrateurs voudront être informés. Dans ce cas, configurer la suppression de manière à ce que seuls les redémarrages récurrents génèrent des incidents qui apparaissent dans le tableau de bord central contribuerait à optimiser l'efficacité de la gestion des incidents.

La suppression ne signifie pas la perte de données

Il convient également de souligner que la suppression, dans le cadre de la gestion des incidents, ne signifie pas la disparition définitive des alertes supprimées. Au contraire, elles continuent de se produire et les données qui leur sont associées doivent être conservées. La seule différence entre une alerte supprimée et une alerte non supprimée réside dans le fait que la première n'est pas envoyée aux tableaux de bord prioritaires du système de gestion des incidents.

Il est important de comprendre cela, car cela signifie que les administrateurs conservent la possibilité de consulter les alertes supprimées pour mieux comprendre un incident si nécessaire. Cela leur permet également de mieux ajuster leurs seuils d'alerte. De plus, les alertes supprimées sont toujours comptabilisées dans les données historiques de gestion des incidents, ce qui peut révéler de nombreuses informations précieuses sur l'efficacité et l'état de santé de l'infrastructure.

Avec la suppression, vous pouvez alors avoir vos alertes et les manger aussi, ou quelque chose comme ça.

Les alertes supprimées peuvent être exploitées de toutes les manières dont les administrateurs ont besoin pour identifier et gérer les incidents, sans encombrer les tableaux de bord d'informations non exploitables qui entravent la résolution des incidents potentiellement prioritaires. De plus, la suppression peut être ajustée pour que les alertes ne soient supprimées que dans les circonstances les plus appropriées, tout en étant systématiquement signalées, vous offrant ainsi une visibilité complète sur votre infrastructure.