Éviter le bruit dans la gestion des incidents

Suppression. D'après le thésaurus , ce mot est synonyme de termes comme suppression, élimination et annihilation.

Mais dans le contexte de la gestion des incidents, la suppression signifie quelque chose de tout à fait différent. Il ne s'agit pas de se débarrasser définitivement des données. Il s'agit plutôt d'un moyen de s'assurer que les administrateurs se concentrent sur les bonnes alertes au bon moment en atténuation du bruit .

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

Pourquoi la répression est-elle importante ?

Pourquoi la suppression est-elle utile dans la gestion des incidents ? En termes simples, c'est parce que Infrastructures modernes génère un volume énorme d'alertes et les administrateurs ne peuvent raisonnablement pas s'attendre à pouvoir examiner chaque alerte. S'ils essaient, ils seront bientôt soumis à alerte fatigue , ce qui signifie qu'ils commenceront à ignorer des alertes potentiellement importantes parce qu'ils sont débordés et épuisés. Et s'ils cessent de prêter attention aux alertes, alors tout le processus de gestion des incidents s'effondre.

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

Prenons par exemple une organisation dont les postes de travail redémarrent une fois par semaine pendant la nuit après l'installation des mises à jour. Le redémarrage génère une série d'alertes lorsque les postes de travail se déconnectent et se réactivent. L'ajout de ces alertes au tableau de bord des incidents que les administrateurs voient ne serait pas utile, car les alertes dans ce cas reflètent un événement procédural de routine qui ne nécessite aucune action. Afin d'éviter d'ajouter ce bruit inutile aux tableaux de bord des administrateurs, ces derniers 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. En d'autres termes, les options des administrateurs ne se limitent pas à 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 répression . La suppression des alertes peut être configurée de telle manière que les alertes d'un type donné soient supprimées à moins qu'elles ne se produisent de manière répétée au cours d'une certaine période de temps, par exemple. Les alertes peuvent également être configurées de manière à être signalées si elles se produisent à une certaine heure de la journée, mais supprimées à d'autres moments. De même, les administrateurs peuvent vouloir supprimer les alertes d'un type particulier si elles se produisent sur un certain type d'appareil, mais pas sur d'autres.

Cette flexibilité est importante car elle permet aux administrateurs de maximiser l'efficacité des alertes. Au lieu d'appliquer des politiques de suppression larges et brutales, ils peuvent modifier les paramètres de suppression afin de maximiser la visibilité des événements importants sans ajouter de bruit inutile au 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 au milieu de la nuit après une mise à jour logicielle. Mais 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 peut signaler un problème (comme une mise à jour logicielle défectueuse) dont les administrateurs voudront être informés. Dans cette situation, la configuration de 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 contexte de la gestion des incidents ne signifie pas que les alertes supprimées disparaissent définitivement. Au contraire, les alertes supprimées se produisent toujours et les données qui leur sont associées doivent être enregistrées. La seule différence entre une alerte supprimée et une alerte non supprimée est 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 rechercher les alertes supprimées pour obtenir un aperçu d'un incident s'ils en ont besoin. Cela les aide également à mieux ajuster leurs seuils d'alerte. En outre, les alertes supprimées figurent toujours dans les données historiques de gestion des incidents, qui peuvent être utilisées pour révéler de nombreuses informations précieuses sur l'efficacité de l'infrastructure et les tendances en matière de santé.

Avec la suppression, vous avez alors la possibilité d'avoir vos alertes et de 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 répondre aux incidents, mais elles n'encombrent pas les tableaux de bord avec des informations non exploitables qui empêchent de résoudre les incidents susceptibles d'être prioritaires. De plus, la suppression peut être modifiée de manière à ce que les alertes ne soient supprimées que dans les circonstances exactes, mais soient toujours signalées afin que vous obteniez une visibilité complète sur votre infrastructure.