MTTR is nog steeds nuttig. Het vertelt teams of de productie snel genoeg weer gezond wordt.
Maar het is niet de enige klok die er nog toe doet.
Wanneer de herstelworkflow observatie, implementatiegeschiedenis, code-eigendom en door AI gegenereerde patches kan verbinden, wordt een nieuwe metriek praktisch: time-to-reviewed-PR.
Wat de metriek betekent
Time-to-reviewed-PR meet het pad van een productiesignaal naar een pull-verzoek dat een code-eigenaar serieus kan evalueren.
Geen willekeurig gegenereerd verschil. Geen vage incidentsamenvatting. Een reviewbaar PR.
Dat betekent dat het pull-verzoek het volgende omvat:
- het productiesignaal dat aanleiding gaf tot het onderzoek
- het vermoedelijke service-, bestand-, functie- of codepad
- de recente implementatie- of wijzigingsset die mogelijk verband houdt
- een gefocust stukje
- de tests die zijn uitgevoerd of zouden moeten worden uitgevoerd
- de aannames en het betrouwbaarheidsniveau
- de juiste recensent of eigenaar
De metriek eindigt wanneer de PR klaar is voor een zinvolle technische beslissing.
Waarom dit anders is dan MTTR
MTTR is resultaatgericht. Time-to-reviewed-PR is workflowgericht.
MTTR vraagt: "Wanneer zijn we hersteld?"
Time-to-reviewed-PR vraagt: "Hoe snel zijn we tot een kwalitatief hoogstaand beslissingspunt gekomen?"
Dat onderscheid is van belang omdat veel incidenten worden uitgesteld voordat de codewijziging zelfs maar heeft plaatsgevonden. Ingenieurs zijn nog steeds bezig met het verzamelen van bewijsmateriaal, het vinden van de eigenaar, het vergelijken van implementaties of het beslissen of het probleem bij een ander systeem hoort.
Als het team die fase kan inkorten, verbetert het herstel vaak op natuurlijke wijze. Zelfs als het uiteindelijke antwoord terugdraaien of escalatie is, wordt de beslissing genomen met beter bewijs en minder verwarring.
De kwaliteitsbar
De statistiek werkt alleen als 'beoordeelde PR' iets strikts betekent.
Een slechte versie van deze statistiek zou tools belonen die luidruchtige pull-aanvragen snel openen. Dat zorgt voor reviewmoeheid en zorgt ervoor dat engineers de automatisering wantrouwen.
Een goede versie beloont voorbereid, doelgericht en met bewijsmateriaal onderbouwd werk.
De PR moet klein genoeg zijn om te kunnen beoordelen, duidelijk genoeg om af te wijzen, en voldoende verbonden met productiebewijs zodat de recensent het incident niet helemaal opnieuw hoeft te reconstrueren.
Handige begeleidende statistieken
Time-to-reviewed-PR mag niet op zichzelf staan. Combineer het met kwaliteitssignalen:
- PR-acceptatiepercentage
- bewerkingspercentage van recensenten
- percentage valse diagnoses
- terugdraaipercentage na door AI ondersteunde oplossingen
- dubbele incidentpercentage na samenvoeging
- tijd vanaf PR open tot beslissing van de recensent
Samen laten deze statistieken zien of automatisering tijd bespaart of eenvoudigweg het werk onder de loep neemt.
Waar dit leiders helpt
Technische leiders moeten weten of incidenttools de operationele belemmering verminderen. Een grafiek die zegt dat het herstel sneller is, is nuttig, maar legt niet uit waar de tijd is gebleven.
Time-to-reviewed-PR maakt de overdracht zichtbaar. Het laat zien of het team van waarschuwing naar bewijs, van bewijs naar code en van code naar eigendom kan gaan zonder handmatig samenvoegen.
Het legt ook zwakke schakels bloot. Als PR's snel opengaan maar niet worden beoordeeld, is het probleem eigendom of personeel. Als bewijs te lang duurt, is het probleem integratie. Als veel PR's worden afgewezen, is het probleem de kwaliteit van de diagnose.
Het punt is niet meer statistieken
Het doel is niet om nog een dashboard uit te vinden dat ingenieurs kunnen negeren.
Het doel is om de kwaliteit van de sanering waarneembaar te maken.
Productiefouten worden niet opgelost wanneer er een waarschuwing wordt gegeven, en ook niet wanneer een model code schrijft. Ze komen in de richting van een oplossing wanneer de juiste mens een zelfverzekerde beslissing kan nemen met het juiste bewijsmateriaal voor zich.
Dat zijn de time-to-reviewed-PR-maatregelen.
