Les incidents complexes sont à la fois épuisants et fréquents. Dans ce contexte, j'entends par « incidents complexes » ceux qui génèrent de multiples notifications disparates sur votre plateforme de gestion des alertes. Ces incidents peuvent être logiquement séparés car les systèmes ou services sous-jacents étaient perçus comme moins interdépendants qu'ils ne l'étaient en réalité. Il se peut aussi que le comportement mis en évidence par les notifications ait de multiples causes potentielles, rendant ainsi difficile l'établissement de liens entre les incidents.

Notre comportement par défaut

Le comportement par défaut consiste à regrouper les titres textuellement similaires. Il est important de comprendre la différence entre « textuellement similaire » et la façon dont notre esprit regroupe logiquement les types d'alertes courants. Par exemple, si vous avez des messages comme « Utilisation de la mémoire sur l'hôte élevée (> 90 %) et « l’utilisation de la mémoire sur l’hôte est élevée (> 95 Ces messages, par exemple « %) », seraient probablement regroupés car ils ne diffèrent que par un seul mot (le pourcentage mis en évidence). En revanche, prenons l'exemple de messages d'alerte tels que « Utilisation de la mémoire élevée (>X %) sur le serveur $NAME dans la région $REGION ». Ces messages nous sembleraient similaires car ils suivent un modèle, mais ils contiennent trop de mots différents et distincts pour être correctement regroupés par défaut par le regroupement intelligent des alertes. Dans le prochain article, j'expliquerai en détail comment créer des titres que le regroupement intelligent des alertes reconnaît plus facilement et plus efficacement par défaut ; ce paragraphe a simplement pour but de vous donner un point de départ.

Améliorer la précision par la fusion

L'objectif de la configuration par défaut est de vous fournir un point de départ. Lorsque vous utiliserez régulièrement le regroupement intelligent des alertes, il est probable que vous deviez l'adapter à votre environnement. Il est important de noter que l'apprentissage automatique s'effectue uniquement sur le champ « Titre ». Dans notre prochain article, je décrirai plus précisément comment optimiser la dénomination des incidents pour cette fonctionnalité. Il faut également savoir que le regroupement intelligent des alertes utilise la fusion pour renforcer ou réapprendre les modèles. Afin d'éviter une correspondance de modèles trop agressive, le regroupement intelligent des alertes modifiera son comportement après 5 à 10 fusions.

Comment fusionner les incidents

Il existe plusieurs façons de fusionner des incidents. L'une d'elles consiste à sélectionner un ou plusieurs incidents dans l'interface utilisateur de PagerDuty ; un bouton « Fusionner les incidents » apparaît alors.

Voici la liste des incidents actifs :

J'ai sélectionné la case du haut à côté de « Statut » pour tout sélectionner et fusionner :

Une fois les incidents sélectionnés, une boîte de dialogue s'affiche et vous demande de choisir l'incident avec lequel vous souhaitez les fusionner. Dans cet exemple, j'ai sélectionné le plus récent :

Par souci de clarté, j'ai modifié le titre de l'incident pour indiquer que les incidents ont été fusionnés. Le résultat est le suivant :

Il est important de savoir que lorsque des incidents sont fusionnés, l'incident de niveau supérieur reste non résolu et tous les incidents fusionnés sont résolus, ce qui ressemble à ceci :

L'autre méthode pour fusionner des incidents consiste à ouvrir l'incident et à sélectionner l'option « Fusionner avec un autre incident » dans le menu déroulant « Plus » :

Lorsque vous utilisez cette méthode, les incidents ne seront pas préremplis dans une liste déroulante ; vous devrez donc connaître le numéro d’incident et cliquer sur « Trouver l’incident » :

Pour plus d'informations sur les incidents de fusion, veuillez consulter notre Documentation d'assistance sur ce sujet Il est important de noter que vous ne pouvez pas dissocier les incidents pour le moment — fusionnez avec précaution !

Si les alertes doivent être séparées

Il peut arriver que vous ayez besoin de déplacer des alertes provenant d'incidents fusionnés par erreur, que ce soit par regroupement ou via la procédure manuelle décrite ci-dessus. Il est important de noter qu'il est impossible de replacer les alertes dans leurs incidents sources d'origine. En effet, les incidents sont résolus (clôturés) lors de leur fusion, et il est impossible de déplacer des alertes vers un incident résolu.

Vous devez créer un nouvel incident et y déplacer les alertes souhaitées, car il est impossible de déplacer des alertes vers un incident résolu. Les utilisateurs peuvent créer manuellement un nouvel incident à l'aide du bouton bleu « Nouvel incident » dans l'interface. Pour plus d'informations, veuillez consulter notre documentation. Documentation d'assistance sur la création et la gestion des incidents .

Points clés à retenir et perspectives d'avenir

Cet article était long ! Ce qu'il faut retenir :

• Le regroupement intelligent des alertes utilise le champ « Titre de l’incident » pour déterminer les incidents à regrouper.
• La fusion des incidents qui devraient être regroupés vous permet de modifier manuellement le comportement de correspondance.
• Il faut 5 à 10 fusions pour que le regroupement intelligent des alertes commence à modifier son comportement par défaut.
• Soyez prudent lors de la fusion d'incidents, car il est impossible de les dissocier directement. Vous devrez créer un nouvel incident et y déplacer les alertes nécessaires.

Dans cet article, j'ai mentionné que le regroupement intelligent des alertes utilise le champ « Titre » pour déterminer quels incidents fusionner ou distinguer. Dans notre prochain article, j'expliquerai comment tirer parti de cette fonctionnalité lors de la création des titres de vos incidents.

Tous les articles de cette série utiliseront le balise ei-architecture-series , n'oubliez pas de consulter également les autres articles de cette série.