Blog

Résumé de la série sur le regroupement d'alertes intelligentes

par Quintessence Anx 7 avril 2022 | 4 minutes de lecture

Co-écrit par Chris Bonnell, PagerDuty Data Scientist VI

Bienvenue dans notre dernier article de notre série sur l'architecture EI et le regroupement d'alertes intelligent. J'espère que vous avez apprécié cette série et si vous souhaitez consulter l'un de nos articles précédents, veuillez utiliser le lien série ei-architecture tag. Prenons un moment pour récapituler tout ce que nous avons appris.

Points clés à retenir

Les comportements par défaut du regroupement d'alertes intelligent sont basés sur des modèles abstraits de gestion des incidents et sur l'utilisation de modèles d'apprentissage automatique. Cela signifie que l'outil peut faire de nombreuses suppositions éclairées, pour ainsi dire, lors de la mise en œuvre, mais peut ne pas générer de correspondances parfaites dans chaque environnement individuel. Pour compenser cela, vous pouvez améliorer les comportements de regroupement en utilisant la fusion, les titres et la conception de services.

Comportement de fusion

Les incidents sont regroupés via un processus appelé fusionner dans l'application PagerDuty . De manière générale, tout incident peut être fusionné avec n’importe quel autre incident. Intelligent Alert Grouping analyse en particulier le champ Titre de l'alerte lorsqu'il tente de déterminer si une alerte individuelle doit être fusionnée ou séparée en un nouvel incident, comme nous l'avons examiné dans ce post . Dans le cas où des alertes sont fusionnées de manière inappropriée dans un incident commun, vous pouvez prendre des mesures pour les séparer et les déplacer là où elles doivent être. Le modèle d'apprentissage automatique renforce le comportement à chaque itération, de sorte que le fait que les alertes restent, soient fusionnées ou déplacées améliorera le comportement futur.

Titres d'alerte

Étant donné que le regroupement d'alertes intelligent base le comportement de fusion sur le champ Titre de l'alerte, nous avons couvert les bases des titres d'alerte avec quelques principes généraux d'apprentissage automatique dans un post précédent Il y a trois points importants à retenir ici :

  • Les titres d’alerte doivent bénéficier à la fois aux humains et à l’apprentissage automatique, avec une préférence pour l’apprentissage automatique puisque le reste des détails de l’incident doit figurer dans la description.
  • N’oubliez pas que, puisque les machines ne peuvent pas comprendre le contexte, il est important de tirer parti de ce qu’un ordinateur peut identifier comme « unique » par rapport à « commun ».
  • Étant donné que la limite de caractères concernant la partie du titre de l'alerte qui s'affiche dans une notification push est courte, placez le texte destiné à l'humain plus tôt dans le titre plutôt que plus tard.

Pour découvrir comment les mettre en œuvre, veuillez consulter la partie sur l'apprentissage automatique de l'article ainsi que la Introduction au traitement du langage naturel pour le texte article de blog sur le blog Towards Data Science.

Conception de services

Le dernier concept que nous avons introduit était une discussion sur conception de services . L'idée générale est que les alertes similaires sur le même service sont, par défaut, supposées être plus fortement corrélées que les alertes sur d'autres services. Il y avait beaucoup à dire ici, car déterminer le degré de granularité à appliquer à vos définitions de service détermine réellement la manière dont vous implémentez « service » dans l'application PagerDuty . En règle générale, si vous ne savez pas si deux « choses » doivent être des services distincts ou non, imitez la voie de remontée souhaitée. S'ils appartiennent tous les deux à la même équipe ou aux mêmes personnes, alors les considérer comme un seul service dans l'application PagerDuty continuera à honorer cette escalade avec l'avantage supplémentaire d'avoir leurs alertes plus fortement corrélées. Si différentes équipes en sont responsables, ou si elles sont logiquement distinctes de telle sorte que vous ne souhaitez pas que leurs alertes soient plus fortement corrélées, définissez-les comme des services distincts. En ce qui concerne les équipes propriétaires, si vous souhaitez en savoir plus sur les meilleures pratiques en matière de définition des services et de propriété en général, veuillez consulter notre Guide des opérations de propriété à service complet .

Où aller en partant d'ici

Et c'est tout ! Merci beaucoup d'avoir pris le temps d'en savoir plus sur la façon d'utiliser pleinement le regroupement d'alertes intelligent. Si vous souhaitez référencer ces articles à plus long terme, veuillez ajouter le lien Étiquette de la série ei-architecture . Si vous souhaitez d'autres discussions, veuillez consulter notre Forums communautaires Pour des questions et réponses approfondies, veuillez contacter notre équipe d'assistance.