MTTR est toujours utile. Il indique aux équipes si la production revient assez rapidement à un état sain.
Mais ce n’est plus la seule horloge qui compte.
Lorsque le workflow de remédiation peut relier l'observabilité, l'historique de déploiement, la propriété du code et les correctifs générés par l'IA, une nouvelle mesure devient pratique: le temps de révision des PR.
Que signifie la métrique
Le délai de révision des PR mesure le chemin allant d'un signal de production à une demande d'extraction qu'un propriétaire de code peut évaluer sérieusement.
Pas une différence générée aléatoirement. Pas un vague résumé d’incident. Un PR révisable.
Cela signifie que la pull request comprend:
- le signal de production qui a déclenché l’enquête
- le chemin d'accès au service, au fichier, à la fonction ou au code suspecté
- le déploiement récent ou l'ensemble de modifications qui peut être lié
- un patch ciblé
- les tests qui ont été exécutés ou devraient être exécutés
- les hypothèses et le niveau de confiance
- le bon évaluateur ou propriétaire
La métrique se termine lorsque le PR est prêt à prendre une décision technique significative.
Pourquoi c'est différent du MTTR
MTTR est axé sur les résultats. Le délai de révision des relations publiques est axé sur le flux de travail.
MTTR demande: « Quand avons-nous récupéré?
La question Time-to-reviewed-PR demande: « En combien de temps sommes-nous arrivés à un point de décision de haute qualité? »
Cette distinction est importante car de nombreux incidents sont retardés avant même que le changement de code n’existe. Les ingénieurs continuent de collecter des preuves, d'en trouver la propriété, de comparer les déploiements ou de décider si le problème appartient à un autre système.
Si l’équipe parvient à raccourcir cette phase, la récupération s’améliore souvent naturellement. Même lorsque la réponse finale est un retour en arrière ou une escalade, la décision est prise avec de meilleures preuves et moins de confusion.
La barre de qualité
La métrique ne fonctionne que si « PR révisé » signifie quelque chose de strict.
Une mauvaise version de cette métrique récompenserait les outils qui ouvrent rapidement des requêtes d’extraction bruyantes. Cela crée une lassitude face aux révisions et incite les ingénieurs à se méfier de l’automatisation.
Une bonne version récompense un travail préparé, ciblé et étayé par des preuves.
Le PR doit être suffisamment petit pour être examiné, suffisamment clair pour être rejeté et suffisamment connecté aux preuves de production pour que l'examinateur n'ait pas à reconstruire l'incident à partir de zéro.
Mesures complémentaires utiles
Le délai de révision des relations publiques ne doit pas être isolé. Associez-le à des signaux de qualité:
- Taux d'acceptation des relations publiques
- taux de modification des évaluateurs
- taux de faux diagnostics
- taux de restauration après les correctifs assistés par l'IA
- taux d'incidents en double après la fusion
- délai entre la PR ouverte et la décision de l'évaluateur
Ensemble, ces mesures indiquent si l'automatisation permet de gagner du temps ou si elle permet simplement de réviser le travail.
Où cela aide les dirigeants
Les responsables de l'ingénierie doivent savoir si les outils adaptés aux incidents réduisent la traînée opérationnelle. Un graphique indiquant que la récupération est plus rapide est utile, mais il n’explique pas où s’est écoulé le temps.
Le délai de révision des relations publiques rend le transfert visible. Il montre si l'équipe peut passer de l'alerte à la preuve, de la preuve au code et du code à la propriété sans assemblage manuel.
Cela expose également les maillons faibles. Si les PR s'ouvrent rapidement mais ne sont pas examinés, le problème est celui de la propriété ou du personnel. Si les preuves prennent trop de temps, le problème est l’intégration. Si de nombreux PR sont rejetés, le problème est la qualité du diagnostic.
Le point n’est pas plus de métriques
Le but n’est pas d’inventer un autre tableau de bord que les ingénieurs pourraient ignorer.
L’objectif est de rendre observable la qualité de la remédiation.
Les bogues de production ne sont pas résolus lorsqu’une alerte se déclenche, ni lorsqu’un modèle écrit du code. Ils progressent vers une résolution lorsque la bonne personne peut prendre une décision en toute confiance avec les bonnes preuves devant elle.
C’est ce que mesure le délai de révision des relations publiques.
