Blog Metriche di ingegneria

Dall'MTTR al Time-to-Reviewed-PR

Per la riparazione assistita dall'intelligenza artificiale, la metrica operativa più utile potrebbe essere la rapidità con cui un segnale di produzione diventa una richiesta pull supportata da prove pronta per la revisione.

MTTRtirare le richiestemetriche ingegneristicheriparazione dell'incidenteaffidabilità

MTTR è ancora utile. Indica ai team se la produzione torna a uno stato sano abbastanza rapidamente.

Ma non è più l’unico orologio che conta.

Quando il flusso di lavoro di riparazione è in grado di connettere osservabilità, cronologia di distribuzione, proprietà del codice e patch generate dall'intelligenza artificiale, diventa pratica una nuova metrica: time-to-reviewed-PR.

Cosa significa la metrica

Il Time-to-reviewed-PR misura il percorso da un segnale di produzione a una richiesta pull che un proprietario del codice può valutare seriamente.

Non un differenziale generato casualmente. Non un vago riassunto dell'incidente. Un PR rivedibile.

Ciò significa che la richiesta pull include:

  • il segnale di produzione che ha dato il via all’indagine
  • il servizio, file, funzione o percorso del codice sospetto
  • la recente distribuzione o set di modifiche che potrebbe essere correlato
  • una patch focalizzata
  • i test che sono stati eseguiti o dovrebbero essere eseguiti
  • le ipotesi e il livello di confidenza
  • il recensore o il proprietario giusto

La metrica termina quando il PR è pronto per una decisione ingegneristica significativa.

Perché questo è diverso da MTTR

L’MTTR è orientato ai risultati. Il tempo necessario per la revisione delle PR è orientato al flusso di lavoro.

MTTR chiede: "Quando ci siamo ripresi?"

Time-to-reviewed-PR chiede: "Quanto velocemente siamo arrivati a un punto decisionale di alta qualità?"

Questa distinzione è importante perché molti incidenti vengono ritardati prima ancora che si verifichi la modifica del codice. Gli ingegneri stanno ancora raccogliendo prove, individuando la proprietà, confrontando le implementazioni o decidendo se il problema appartiene a un altro sistema.

Se la squadra riesce ad abbreviare quella fase, il recupero spesso migliora in modo naturale. Anche quando la risposta finale è il rollback o l’escalation, la decisione avviene con prove migliori e meno confusione.

La barra della qualità

La metrica funziona solo se "PR rivisto" significa qualcosa di rigoroso.

Una versione errata di questa metrica premierebbe gli strumenti che aprono rapidamente richieste pull rumorose. Ciò crea affaticamento nelle revisioni e spinge gli ingegneri a diffidare dell’automazione.

Una buona versione premia il lavoro preparato, mirato e supportato da prove.

La PR dovrebbe essere sufficientemente piccola da poter essere esaminata, sufficientemente chiara da poter essere rifiutata e sufficientemente connessa alla produzione di prove in modo che il revisore non debba ricostruire l'incidente da zero.

Metriche utili dei compagni

Il tempo per la revisione delle PR non dovrebbe essere isolato. Abbinalo a segnali di qualità:

  • Tasso di accettazione delle PR
  • tasso di modifica del revisore
  • tasso di false diagnosi
  • tasso di rollback dopo le correzioni assistite dall'intelligenza artificiale
  • tasso di incidenti duplicati dopo l'unione
  • tempo dall'apertura delle PR alla decisione del revisore

Insieme, questi parametri mostrano se l'automazione fa risparmiare tempo o semplicemente sposta il lavoro in revisione.

Dove questo aiuta i leader

I leader della progettazione devono sapere se gli strumenti per gli incidenti riducono la resistenza operativa. Un grafico che dice che il recupero è più veloce è utile, ma non spiega dove è andato il tempo.

Il PR Time-to-reviewed rende visibile il trasferimento. Mostra se il team può passare dall'avviso alle prove, dalle prove al codice e dal codice alla proprietà senza unione manuale.

Espone anche i collegamenti deboli. Se i PR aprono rapidamente ma non vengono revisionati, il problema è la proprietà o il personale. Se le prove richiedono troppo tempo, il problema è l’integrazione. Se molte PR vengono respinte, il problema è la qualità della diagnosi.

Il punto non sono più i parametri

L’obiettivo non è inventare un’altra dashboard che gli ingegneri possano ignorare.

L’obiettivo è rendere osservabile la qualità della riparazione.

I bug di produzione non vengono risolti quando viene attivato un avviso e non vengono risolti quando un modello scrive il codice. Si muovono verso la risoluzione quando l'essere umano giusto può prendere una decisione sicura con le giuste prove di fronte a loro.

Questo è ciò che misura il tempo di revisione delle PR.

Esegui il ciclo

Trasforma i segnali di produzione in fix revisionati.

Avvia una prova gratuita e scopri come Prilog collega incidenti reali a pull request a livello di codice.