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

Il est 2 heures du matin et vous êtes appelé alors que vous êtes encore éveillé. Comment parviendrez-vous à trouver ce dont vous avez besoin pour corriger la dernière erreur ? Lorsque l'incident commence, il se peut qu'il n'affecte qu'un seul service, mais au fil du temps, votre cerveau démarre, le café est versé, les documents sont lus, et pendant tout ce temps, l'incident se propage à d'autres services et équipes pour lesquels vous ne verrez peut-être pas les alertes s'ils ne relèvent pas de votre responsabilité. Bien que vous puissiez parcourir l'interface utilisateur de votre outil d'alerte et combiner les alertes qui sont toutes pertinentes pour le même incident, cela nécessite que vous sachiez que d'autres alertes 1) sont envoyées et 2) que l'incident dans cet autre service ou ces autres services est pertinent pour celui sur lequel vous travaillez actuellement.

Dans l'application PagerDuty , une partie de ce travail est effectuée pour vous, via le Groupement d'alertes intelligent (IAG) Fonctionnalité. Bien qu'il soit probablement formidable que cette fonctionnalité fonctionne au moins de manière automatique dès le départ, il y a probablement des moments où vous aimeriez pouvoir mieux l'utiliser. Vous souhaitez peut-être améliorer la manière dont les alertes sont associées à un incident ou empêcher que des alertes associées à tort comme faisant partie du même incident ne soient associées à l'avenir. Vous souhaitez peut-être même peaufiner la conception de vos alertes afin de ne pas avoir à effectuer autant de corrections après coup et pendant un incident actif. Si c'est ce que vous recherchez, ne cherchez pas plus loin ! Dans cette série d'articles de blog, nous aborderons les différentes manières dont vous pouvez améliorer la précision du regroupement d'alertes intelligent en fonction de vos besoins spécifiques.

Défis courants liés aux incidents

La complexité et l'échelle croissantes de la conception des systèmes signifient qu'il est de plus en plus difficile de concevoir des alertes qui transmettent suffisamment d'informations ou même qui sont correctement corrélées. Lorsque nous créons nos moniteurs et les alertes correspondantes, nous le faisons généralement en gardant à l'esprit le service en question, mais nous ne pouvons pas toujours cartographier efficacement la manière dont les dépendances réagiront aux latences et aux pannes des autres. Il est donc possible que lorsque vous voyez plusieurs alertes sur un service, un sous-ensemble de celles-ci soit causé par d'autres alertes et un sous-ensemble différent puisse être des alertes répétées pour le même problème. Selon la façon dont vous avez conçu vos notifications, il est également possible que plusieurs équipes reçoivent des notifications pour plusieurs services alors que la cause n'en est qu'une seule.

Lorsque nous réfléchissons à la manière dont nous configurons les alertes, la manière dont nous nous retrouvons dans ces situations du côté de la réponse commence à avoir du sens. Nous pouvons penser en termes de seuils auxquels un service peut budgétiser une quantité donnée de latence ou de temps d'interruption, mais ses services dépendants peuvent avoir des exigences plus strictes. Si ces situations ne sont pas prises en compte ou sont inconnues, nous pouvons nous retrouver dans des situations comme celle décrite ci-dessus, où différentes équipes travaillent sur différents aspects du même incident, sans en être conscientes. Nous pouvons également observer le comportement inverse, où une tempête d'alertes est déclenchée et il est difficile de se frayer un chemin à travers le bruit pour cartographier ce qui se passe et où, et comment les alertes doivent être regroupées en termes d'incidents.

Réduire (une partie) de la complexité

Ces défis ne sont pas nouveaux et il est fort probable que vous commenciez déjà à y répondre. Si vous lisez cet article, vous le faites probablement aussi au moins en partie à l'aide de la fonctionnalité IAG. En bref, IAG utilise l'apprentissage automatique pour créer des modèles à partir des données que vous envoyez à la plateforme afin qu'elle puisse commencer à regrouper les alertes en fonction de leurs incidents respectifs pour vous. L'objectif est de vous aider, ainsi que vos équipes, à mieux comprendre la topologie de ce qui ne va pas dans votre/vos système(s).

Lorsque vous débutez avec IAG, de nombreuses fonctionnalités fonctionnent « automatiquement » pour réduire la courbe d'apprentissage et vous permettre de commencer à améliorer votre processus de réponse dès que possible. Cela dit, vous atteindrez éventuellement un point où vous devrez corriger et ajuster la manière dont les alertes sont regroupées, ce qui est l'objet de cette série d'articles de blog. Nous allons aborder la manière dont vous pouvez interagir avec IAG pour améliorer sa capacité à regrouper les alertes par incident de niveau supérieur.

Où aller en partant d'ici

Il s'agit du premier article d'une série qui abordera la manière d'améliorer la conception de vos alertes et services dans l'application PagerDuty afin d'améliorer la capacité d'Intelligent Alert Grouping à regrouper les incidents. Plus précisément :

• Comment vous pouvez former les fonctionnalités d'apprentissage intégrées
• Comment créer des alertes
• Comment concevoir des services (dans l'application PagerDuty )

Dans notre prochain article, nous aborderons le premier sujet de l'apprentissage intégré, en expliquant son fonctionnement ainsi que la manière de fusionner et de dissocier des incidents. Nous passerons ensuite à la création d'alertes, en détaillant la manière dont les différents champs sont utilisés par IAG et les informations que vous devez vous assurer d'inclure. Dans le dernier article, nous aborderons la configuration des services dans l'application PagerDuty et les informations à inclure et à exclure.

Tous les articles de cette série seront sous le Étiquette de la série ei-architecture , alors assurez-vous de référencer cette page lorsque vous recherchez des articles ultérieurs !