Depuis que nous avons lancé notre fonctionnalité d'alerte multi-utilisateur la semaine dernière, nous avons reçu de nombreux retours positifs et avons constaté une forte adoption à tous les niveaux. L'alerte multi-utilisateur était notre fonctionnalité la plus demandée et nous voulions nous assurer de la mettre en œuvre correctement tout en maintenant nos normes de fiabilité. Nous avons apporté des modifications importantes à notre architecture et à notre flux de travail pour jeter les bases des futurs cas d'utilisation des alertes.

Élaborer un plan

Le plus grand défi auquel nous avons été confrontés a été la nécessité de restructurer notre modèle de données d'alerte pour attribuer les incidents à plusieurs utilisateurs et permettre à plusieurs utilisateurs d'accuser réception des incidents. Nous avons dû effectuer cette restructuration tout en gardant tout en état de fonctionnement pour nos clients (c'est-à-dire que nous n'avons pas le concept de temps d'arrêt de service chez PagerDuty). Notre équipe produit a documenté la manière dont elle souhaitait que PagerDuty évolue et a travaillé avec notre équipe en temps réel et notre équipe Web pour créer un calendrier de déploiement. Bien que les changements que nous apportions étaient importants, nous avons élaboré un plan de déploiement afin que chaque élément du déploiement soit incrémentiel et rétrocompatible.

Suivi des accusés de réception multiples et des délais d'attente d'accusé de réception

Grâce aux alertes multi-utilisateurs, les incidents sont attribués à plusieurs utilisateurs et peuvent être reconnus par plusieurs utilisateurs. Les alertes multi-utilisateurs aident les équipes à recueillir des informations sur la réactivité aux incidents : vous pouvez savoir qui est à la hauteur de la situation et qui ne reçoit pas d'alerte. Étant donné que les incidents peuvent désormais être attribués et reconnus par plusieurs utilisateurs, nous avons dû ajouter de nouvelles tables à notre base de données pour suivre ces informations.

Les incidents sont associés à des services et, au sein de chaque service, l'équipe peut définir le délai d'expiration de l'accusé de réception de l'incident. Les délais d'expiration de l'accusé de réception d'incident font revenir l'incident à l'état Déclenché et empêchent les incidents d'être oubliés. Les services hautement critiques sont donc configurés avec des délais d'expiration plus courts. Le délai d'expiration est relatif au moment où l'incident a été reconnu pour la première fois et, avec plusieurs accusés de réception, le délai d'expiration sera réinitialisé chaque fois que l'incident est à nouveau reconnu. Par exemple, si le délai d'expiration de l'accusé de réception d'incident est défini sur 5 minutes et que l'utilisateur A accuse réception d'un incident à 2 h 00 et que l'utilisateur Back le même incident à 2 h 04, le délai d'expiration de l'accusé de réception de l'incident fera revenir l'incident à l'état Déclenché à 2 h 09 au lieu de 2 h 05. Cela empêche les utilisateurs A et B de recevoir une autre alerte seulement 1 minute après que l'utilisateur B l'a reconnue. Nous avons ajouté ce comportement pour éviter que les utilisateurs ne soient submergés par des alertes pour des incidents reconnus qu'ils résolvent activement.

Instantanés d'incident pour la garantie d'alerte minute zéro

Le pipeline d'alertes PagerDuty a été conçu pour envoyer des alertes contenant des informations sur les incidents aussi à jour que possible. Si un utilisateur n'a qu'une seule règle de notification avec un délai d'une minute et qu'un incident est résolu 30 secondes après son déclenchement, nous n'enverrons pas d'autre alerte à l'utilisateur, car il a déjà été résolu. L'une des conséquences des alertes multi-utilisateurs est qu'elles ont introduit la possibilité qu'un utilisateur d'une politique d'escalade puisse accuser réception/résoudre/réaffecter un incident avant qu'un autre utilisateur n'en soit informé.

Pour résoudre ce problème, nous avons modifié notre pipeline pour implémenter un comportement spécial « minute zéro ». Si un utilisateur a configuré une règle de notification avec un délai de zéro minute, nous en déduisons qu'il souhaite être informé d'un incident dans tous les cas. Même si l'incident est modifié dans un court laps de temps entre le moment où il a été déclenché et le moment où la notification est envoyée, la notification sera quand même envoyée. Par exemple, si l'utilisateur A et l'utilisateur B sont au même niveau d'escalade avec une règle de notification immédiate, et que l'utilisateur A accuse réception d'un incident immédiatement après son déclenchement, cela n'empêchera pas une alerte d'être envoyée à l'utilisateur B.

Temps entre les niveaux d'escalade

Avant l'arrivée de l'alerte multi-utilisateur, les clients de PagerDuty utilisaient une solution de contournement consistant à ajouter des règles d'escalade à une politique d'escalade, séparées par un délai d'escalade très court (par exemple, 1 minute), ce qui permettait d'alerter efficacement un groupe d'utilisateurs dans un court laps de temps. Avec l'alerte multi-utilisateur, cette solution de contournement n'est plus nécessaire et nous encourageons tous les clients qui l'utilisaient à reconfigurer leurs politiques d'escalade : vous pouvez désormais ajouter jusqu'à 10 cibles d'escalade (utilisateurs ou plannings) à un niveau d'escalade.

Multi-User Alerting a étendu les scénarios d'alerte pour nos clients afin qu'ils puissent atteindre les bonnes personnes qui ont besoin d'être informées au bon moment. Y a-t-il des scénarios d'alerte que vous souhaitez aborder mais que vous ne pouvez pas ? Faites-le nous savoir dans les commentaires.