PagerDuty

PagerDuty expose plusieurs types d'objets : incidents, services, plannings d'astreinte, plages on-call, politiques d'escalade, équipes et journaux d'événements. Cette intégration se concentre exclusivement sur les incidents, qui constituent l'unité fondamentale du travail d'astreinte et le seul type d'objet où la performance individuelle est directement attribuable. Les objets de niveau service capturent la configuration et la topologie plutôt que la contribution individuelle ; les objets de planning décrivent les affectations de plages sans mesurer ce qui se passe durant ces plages. Six KPIs ont été retenus, sélectionnés selon trois critères : capacité d'attribution à un ingénieur individuel, résistance au contournement, et équilibre entre indicateurs avancés de discipline de processus et indicateurs retardés de résultats de fiabilité.

Discipline de réponse : lire la vitesse et la qualité ensemble

Le Mean Time to Acknowledge mesure le temps moyen écoulé entre la création d'un incident et sa prise en charge par l'ingénieur assigné. C'est l'indicateur le plus direct de la réactivité en astreinte et le seul KPI de cet ensemble qui capture le comportement dans les premières minutes d'un incident. Le Mean Time to Resolve mesure le temps moyen écoulé entre la création d'un incident et sa résolution. Ces deux indicateurs doivent être lus en relation l'un avec l'autre. Un Mean Time to Acknowledge court combiné à un Mean Time to Resolve long indique que les ingénieurs s'engagent rapidement mais mettent un temps significatif à diagnostiquer et corriger, ce qui peut signaler une complexité système, des lacunes d'outillage ou des déficits de connaissance. Le schéma inverse — un temps de prise en charge long suivi d'une résolution rapide — peut suggérer que les ingénieurs retardent leur engagement jusqu'à être certains de pouvoir résoudre immédiatement, une forme de réponse sélective qui biaise les deux métriques.

Qualité de résolution et gardes contre le détournement

Incidents Resolved comptabilise le volume total d'incidents qu'un ingénieur a clôturés. P1/P2 Incidents Resolved isole la sous-partie des incidents de priorité critique au sein de ce total. Les deux indicateurs servent des finalités analytiques distinctes : Incidents Resolved capture le débit, tandis que P1/P2 Incidents Resolved capture la contribution aux pannes les plus conséquentes. Un ingénieur avec un nombre élevé d'Incidents Resolved mais une faible part de P1/P2 traite peut-être un volume disproportionné d'incidents peu sévères ; un ingénieur avec peu de résolutions au total mais une forte part de critiques porte un risque systémique supérieur à la moyenne.

Le Reopen Rate répond au principal risque de contournement du Mean Time to Resolve. Lorsqu'un ingénieur résout un incident prématurément — en fermant le ticket avant que le problème sous-jacent soit corrigé — le système re-déclenche le même incident en quelques minutes. Le Reopen Rate mesure ce schéma directement : il comptabilise les incidents re-déclenchés dans l'heure suivant leur résolution comme proportion des résolutions totales. Un Reopen Rate croissant associé à un Mean Time to Resolve décroissant est un signal fiable de comportement de résolution superficielle, non d'amélioration réelle. Ensemble, les deux indicateurs rendent analytiquement coûteux d'optimiser l'un au détriment de l'autre.

Santé du processus d'astreinte : le signal de l'escalade

L'Escalation Rate mesure la proportion des incidents assignés qu'un ingénieur escalade au niveau suivant de la politique d'escalade plutôt que de résoudre de manière autonome. Un taux d'escalade faible indique généralement que l'ingénieur traite les incidents dans son périmètre de responsabilité, ce qui correspond au fonctionnement attendu d'une rotation d'astreinte. Un taux d'escalade durablement élevé pour un ingénieur donné peut signaler un manque de compétences, un runbook insuffisamment spécifié ou une inadéquation entre les services couverts et son domaine de connaissance. Parce que les escalades ont des coûts visibles — elles réveillent d'autres ingénieurs et prolongent le temps de résolution — cet indicateur est structurellement résistant au contournement : un ingénieur qui évite d'escalader quand il le devrait génère d'autres défaillances qui remontent dans le Mean Time to Resolve et le Reopen Rate.

Périmètre et limites de l'intégration

PagerDuty enregistre les événements du cycle de vie des incidents et les attributions, mais ne mesure pas la qualité de l'investigation ni la pérennité du correctif. Un incident résolu peut correspondre à une analyse de cause racine approfondie ou à un contournement temporaire ; les données de l'API ne font pas la distinction. Le filtre P1/P2 dépend de l'activation de la fonctionnalité de priorité sur le compte et de l'application cohérente des classifications par les équipes : sans étiquetage rigoureux, P1/P2 Incidents Resolved sous-comptera ou produira du bruit. De même, le Mean Time to Acknowledge reflète le fonctionnement du système d'alerte tel qu'il est configuré — si les ingénieurs ne sont pas alertés rapidement, la métrique mesure la latence de l'infrastructure plutôt que la réactivité individuelle. La fiabilité de ces six KPIs dépend directement de la discipline des équipes dans la tenue des données d'incident : attribution cohérente des priorités, prise en charge dans les délais, et résolution précise sans clôture prématurée.