Cet article est le deuxième de notre série sur comment vous pouvez utiliser les données pour améliorer vos opérations informatiques. Notre premier article portait sur alerte fatigue .

Il y a quelques semaines, nous avons blogué sur les indicateurs de performance clés qui Les meilleures équipes d'exploitation suivent . En discutant avec nos bêta-testeurs pour Advanced Reporting, nous avons appris beaucoup de choses sur la façon dont les équipes mesurent le temps de reconnaissance (MTTA) et le temps de réponse (MTTR). La façon dont votre équipe utilise PagerDuty peut avoir un impact significatif sur l'apparence de ces mesures. Nous avons donc souhaité partager quelques bonnes pratiques pour rendre ces mesures significatives.

1. Élaborer des lignes directrices pour reconnaître les incidents

Le temps nécessaire pour répondre à un incident est un indicateur de performance clé. Pour comprendre votre temps de réponse dans PagerDuty, nous vous recommandons de reconnaître un incident lorsque vous commencez à travailler dessus. De plus, si vous utilisez une politique d'escalade multi-utilisateurs, cette pratique est encore plus importante. Nous venons de publier une mise à jour pour qu'une fois que vous aurez reconnu un incident, vos coéquipiers seront informés qu'ils n'ont plus à se soucier de l'alerte.

De nombreuses équipes d'exploitation performantes fixent des objectifs en matière de temps d'accusé de réception, car il s'agit d'une mesure sur laquelle les équipes ont généralement beaucoup de contrôle. Le rapport d'équipe de PagerDuty peut vous montrer les tendances de votre TTA afin que vous puissiez voir si vous respectez vos objectifs et comment le TTA varie en fonction du nombre d'incidents.

2. Définir quand résoudre

Nous vous recommandons de résoudre les incidents lorsqu'ils sont entièrement fermés et que le service a repris son état pleinement opérationnel. Si vous utilisez une intégration API, PagerDuty résoudra automatiquement les incidents lorsque nous recevrons un message « tout va bien » du service. Cependant, si vous résolvez les incidents manuellement, assurez-vous que votre équipe sait qu'elle doit résoudre les incidents dans PagerDuty lorsque le problème est résolu. Pour faciliter encore davantage la résolution des incidents, nous publierons bientôt une mise à jour de nos intégrations par e-mail pour résoudre automatiquement les incidents à partir de l'e-mail.

3. Utilisez les délais d'attente avec précaution

Lorsque vous créez les paramètres d'un service, vous pouvez définir deux délais d'expiration : le délai d'expiration de l'accusé de réception de l'incident et le délai d'expiration de la résolution automatique. Ces délais d'expiration peuvent avoir un impact sur vos mesures MTTA et MTTR. Il est donc important de comprendre comment ils sont configurés.

Un délai d'expiration de l'accusé de réception d'incident fournit un filet de sécurité si une alerte vous réveille au milieu de la nuit et que vous vous rendormez après l'avoir accusé réception. Une fois le délai d'expiration atteint, l'incident se rouvrira et vous avertira à nouveau. Si s'endormir après avoir accusé réception d'un incident est un gros problème pour votre équipe, vous devez conserver le délai d'expiration de l'accusé de réception d'incident en vigueur. Cependant, cela peut rendre vos mesures MTTA plus complexes. Le délai d'expiration de l'accusé de réception d'incident peut être configuré indépendamment pour chaque service, et le paramètre par défaut est de 30 minutes.

Si vous n'avez pas l'habitude de résoudre les incidents une fois le travail terminé, des délais de résolution automatique sont en place pour fermer les incidents qui ont été oubliés. Ce délai d'expiration est également configurable dans les paramètres du service et la valeur par défaut est de 4 heures. Si vous utilisez ce délai d'expiration, vous devez vous assurer qu'il est plus long que le temps nécessaire pour résoudre la plupart de vos incidents (vous pouvez utiliser nos rapports système ou d'équipe pour voir le temps de résolution de votre incident). Pour vous assurer de ne pas oublier les incidents ouverts, PagerDuty vous enverra également un e-mail toutes les 24 heures si vous avez des incidents ouverts depuis plus d'une journée.

4. Traiter les alertes de battement d'ailes

Une alerte de flottement est une alerte qui est déclenchée, puis résolue rapidement par la suite. Le flottement est généralement provoqué lorsque la mesure surveillée oscille autour d'un seuil. Les alertes de flottement peuvent encombrer vos mesures MTTR et MTTA. Sur le rapport d'équipe, vous pouvez voir un nombre élevé d'alertes avec un temps de résolution faible ou un temps de résolution inférieur au temps d'accusé de réception (les incidents résolus automatiquement ne sont jamais acquittés). Il est judicieux d'enquêter sur les alertes de flottement, car elles peuvent contribuer à la fatigue des alertes (sans parler du fait qu'elles provoquent des désagréments). Souvent, elles peuvent être résolues en ajustant le seuil. Pour plus de ressources sur les alertes de flottement, consultez ces ressources. Nouvelle relique et Nagios des articles.