Blogs Technische Kennzahlen

Von MTTR zu Time-to-Reviewed-PR

Für die KI-gestützte Behebung könnte die nützlichste Betriebsmetrik darin bestehen, wie schnell aus einem Produktionssignal eine evidenzbasierte Pull-Anfrage wird, die zur Überprüfung bereit ist.

MTTRPull-Anfragentechnische KennzahlenBehebung von VorfällenZuverlässigkeit

MTTR ist immer noch nützlich. Es zeigt den Teams an, ob die Produktion schnell genug wieder in einen gesunden Zustand zurückkehrt.

Aber es ist nicht mehr die einzige Uhr, die zählt.

Wenn der Behebungsworkflow Beobachtbarkeit, Bereitstellungsverlauf, Codebesitz und KI-generierte Patches miteinander verbinden kann, wird eine neue Metrik praktisch: die Zeit bis zur Überprüfung der PR.

Was die Metrik bedeutet

Time-to-reviewed-PR misst den Weg von einem Produktionssignal zu einer Pull-Anfrage, die ein Code-Eigentümer ernsthaft bewerten kann.

Kein zufällig generierter Unterschied. Keine vage Zusammenfassung des Vorfalls. Eine überprüfbare PR.

Das bedeutet, dass die Pull-Anfrage Folgendes umfasst:

  • das Produktionssignal, das die Untersuchung auslöste
  • der verdächtige Dienst, die Datei, die Funktion oder der Codepfad
  • der aktuelle Bereitstellungs- oder Änderungssatz, der möglicherweise damit zusammenhängt
  • ein fokussierter Patch
  • die Tests, die ausgeführt wurden oder ausgeführt werden sollten
  • die Annahmen und das Konfidenzniveau
  • der richtige Rezensent oder Eigentümer

Die Metrik endet, wenn der PR für eine sinnvolle technische Entscheidung bereit ist.

Warum sich dies von MTTR unterscheidet

MTTR ist ergebnisorientiert. Time-to-reviewed-PR ist Workflow-orientiert.

MTTR fragt: „Wann haben wir uns erholt?“

Time-to-reviewed-PR fragt: „Wie schnell sind wir zu einem qualitativ hochwertigen Entscheidungspunkt gekommen?“

Diese Unterscheidung ist wichtig, da sich viele Vorfälle verzögern, bevor die Codeänderung überhaupt vorliegt. Ingenieure sammeln immer noch Beweise, ermitteln die Eigentümerschaft, vergleichen Bereitstellungen oder entscheiden, ob das Problem zu einem anderen System gehört.

Wenn das Team diese Phase verkürzen kann, verbessert sich die Erholung oft auf natürliche Weise. Selbst wenn die endgültige Antwort ein Rollback oder eine Eskalation ist, erfolgt die Entscheidung mit besseren Beweisen und weniger Verwirrung.

Die Qualitätsbar

Die Metrik funktioniert nur, wenn „überprüfte PR“ etwas Strenges bedeutet.

Eine schlechte Version dieser Metrik würde Tools belohnen, die verrauschte Pull-Requests schnell öffnen. Das führt zu Überprüfungsmüdigkeit und führt dazu, dass Ingenieure der Automatisierung misstrauen.

Eine gute Version belohnt vorbereitete, zielgerichtete und evidenzbasierte Arbeit.

Der PR sollte klein genug sein, um überprüft zu werden, klar genug, um abgelehnt zu werden, und ausreichend mit Produktionsnachweisen verbunden sein, damit der Prüfer den Vorfall nicht von Grund auf rekonstruieren muss.

Nützliche Companion-Metriken

Time-to-reviewed-PR sollte nicht allein stehen. Kombinieren Sie es mit Qualitätssignalen:

  • PR-Akzeptanzrate
  • Bearbeitungsrate des Rezensenten
  • Fehldiagnoserate
  • Rollback-Rate nach KI-gestützten Korrekturen
  • Rate doppelter Vorfälle nach der Zusammenführung
  • Zeit von der offenen PR bis zur Entscheidung des Gutachters

Zusammengenommen zeigen diese Kennzahlen, ob die Automatisierung Zeit spart oder die Arbeit lediglich in die Überprüfung verschiebt.

Wo dies Führungskräften hilft

Technische Führungskräfte müssen wissen, ob die Einsatzwerkzeuge den Betriebswiderstand verringern. Ein Diagramm, das besagt, dass die Erholung schneller erfolgt, ist hilfreich, erklärt aber nicht, wo die Zeit vergangen ist.

Time-to-reviewed-PR macht die Übergabe sichtbar. Es zeigt, ob das Team ohne manuelles Stitching von der Warnung zum Beweis, vom Beweis zum Code und vom Code zum Besitz übergehen kann.

Es deckt auch Schwachstellen auf. Wenn PRs schnell eröffnet, aber nicht überprüft werden, liegt das Problem an den Eigentumsverhältnissen oder der Personalausstattung. Wenn die Beweisführung zu lange dauert, liegt das Problem in der Integration. Wenn viele PRs abgelehnt werden, liegt das Problem an der Diagnosequalität.

Es geht nicht um mehr Kennzahlen

Das Ziel besteht nicht darin, ein weiteres Dashboard zu erfinden, das Ingenieure ignorieren können.

Ziel ist es, die Qualität der Sanierung sichtbar zu machen.

Produktionsfehler werden nicht behoben, wenn eine Warnung ausgelöst wird, und sie werden nicht behoben, wenn ein Modell Code schreibt. Sie bewegen sich auf eine Lösung zu, wenn der richtige Mensch mit den richtigen Beweisen vor ihm eine sichere Entscheidung treffen kann.

Das sind die Time-to-Review-PR-Maßnahmen.

Loop ausführen

Verwandle Produktionssignale in geprüfte Fixes.

Starte eine kostenlose Testversion und sieh, wie Prilog reale Incidents mit Pull Requests auf Code-Ebene verbindet.