15 DevOps-Metriken und Key Performance Indicators (KPIs) zum Verfolgen

DevOps machte sich zunächst als Option zur Rationalisierung der Softwarebereitstellung einen Namen. Heute gilt DevOps weithin als wesentlicher Bestandteil des Bereitstellungsprozesses. Wichtige DevOps-Prozesse sind an allen Bereichen beteiligt, von der Sicherung bis zur Wartung von Anwendungen.

DevOps-Praktiken und -Prinzipien allein gewährleisten keine Qualität und könnten sogar noch mehr Probleme verursachen, wenn sie nicht richtig integriert werden. Bei dem Bemühen, Software so schnell wie möglich auf den Markt zu bringen, riskieren Unternehmen, dass der Endbenutzer mehr Fehler entdeckt.

Die moderne Ära des End-to-End-DevOps erfordert die sorgfältige Integration von Key Performance Indicators (KPIs). Mit den richtigen Kennzahlen kann sichergestellt werden, dass Anwendungen ihr maximales Potenzial erreichen.

Im Idealfall stellen DevOps-Metriken und KPIs relevante Informationen klar und leicht verständlich dar. Gemeinsam sollten sie einen Überblick über den Bereitstellungs- und Änderungsprozess geben - und darüber, wo Verbesserungen vorgenommen werden können.

Die folgenden Kennzahlen sollten im Auge behalten werden, wenn Sie danach streben, sowohl die Effizienz als auch das Benutzererlebnis zu verbessern.

DevOps-Metriken und wichtige Leistungsindikatoren

1. Bereitstellungshäufigkeit

Die Bereitstellungshäufigkeit gibt an, wie oft neue Funktionen oder Fähigkeiten eingeführt werden. Die Häufigkeit kann täglich oder wöchentlich gemessen werden. Viele Unternehmen ziehen es vor, Bereitstellungen täglich zu verfolgen, insbesondere weil sie die Effizienz steigern.

Im Idealfall bleiben die Häufigkeitskennzahlen im Laufe der Zeit entweder stabil oder weisen einen leichten und stetigen Anstieg auf. Jeder plötzliche Rückgang der Bereitstellungshäufigkeit könnte auf Engpässe im bestehenden Workflow hinweisen.

Mehr Bereitstellungen sind in der Regel besser, jedoch nur bis zu einem gewissen Punkt. Wenn eine hohe Frequenz zu einer längeren Bereitstellungszeit oder einer höheren Ausfallrate führt, kann es sich lohnen, mit der Erhöhung der Bereitstellung zu warten, bis bestehende Probleme gelöst werden können.

2. Lautstärke ändern

Die Bereitstellungshäufigkeit bedeutet wenig, wenn die meisten Bereitstellungen nur geringe Auswirkungen haben.

Der tatsächliche Wert von Bereitstellungen spiegelt sich möglicherweise besser im Änderungsvolumen wider. DieserDevOps-KPI bestimmt das Ausmaß, in dem Code geändert wird und nicht statisch bleibt. Verbesserungen der Bereitstellungshäufigkeit sollten keine wesentlichen Auswirkungen auf das Änderungsvolumen haben.

3. Bereitstellungszeit

Wie lange dauert die Einführung von Bereitstellungen nach der Genehmigung?

Natürlich können Bereitstellungen häufiger erfolgen, wenn sie schnell implementiert werden. Dramatische Verlängerungen der Bereitstellungszeit erfordern weitere Untersuchungen, insbesondere wenn sie mit einem verringerten Bereitstellungsvolumen einhergehen. Eine kurze Bereitstellungszeit ist zwar unerlässlich, sollte jedoch nicht auf Kosten der Genauigkeit gehen. Erhöhte Fehlerraten können darauf hindeuten, dass Bereitstellungen zu schnell erfolgen.

4. Rate fehlgeschlagener Bereitstellungen

Diese Metrik wird manchmal auch als die mittlere Zeit bis zum Ausfall bezeichnet und bestimmt, wie oft Bereitstellungen zu Ausfällen oder anderen Problemen führen.

Diese Zahl sollte möglichst gering sein. Die Rate fehlgeschlagener Bereitstellungen wird häufig zusammen mit dem Änderungsvolumen angegeben. Ein geringes Änderungsvolumen in Verbindung mit einer steigenden Rate fehlgeschlagener Bereitstellungen kann auf eine Störung irgendwo im Arbeitsablauf hindeuten.

5. Ändern Sie die Ausfallrate

Die Änderungsfehlerrate bezieht sich auf das Ausmaß, in dem Releases zu unerwarteten Ausfällen oder anderen ungeplanten Ausfällen führen. Eine niedrige Änderungsfehlerrate deutet darauf hin, dass Bereitstellungen schnell und regelmäßig erfolgen. Umgekehrt deutet eine hohe Änderungsfehlerrate auf eine schlechte Anwendungsstabilität hin, was zu negativen Ergebnissen für den Endbenutzer führen kann.

6. Zeit bis zur Erkennung

Eine niedrige Änderungsfehlerrate bedeutet nicht immer, dass mit Ihrer Anwendung alles in Ordnung ist.

Während die ideale Lösung darin besteht, fehlgeschlagene Änderungen zu minimieren oder sogar zu beseitigen, ist es wichtig, Fehler schnell zu erkennen, wenn sie auftreten. Mithilfe von KPIs zur Zeit bis zur Erkennung können Sie feststellen, ob die aktuellen Reaktionsbemühungen angemessen sind. Eine lange Zeit bis zur Erkennung kann zu Engpässen führen, die den gesamten Arbeitsablauf unterbrechen können.

7. Mittlere Zeit bis zur Wiederherstellung

Wenn fehlgeschlagene Bereitstellungen oder Änderungen erkannt werden, wie lange dauert es tatsächlich, das Problem zu beheben und wieder auf Kurs zu kommen?

Die mittlere Wiederherstellungszeit (MTTR) ist eine wesentliche Kennzahl, die Ihre Fähigkeit anzeigt, angemessen auf erkannte Probleme zu reagieren. Eine schnelle Erkennung bedeutet wenig, wenn ihr nicht eine ebenso schnelle Wiederherstellungsmaßnahme folgt. MTTR ist eine der bekanntesten und am häufigsten zitierten DevOps Key Performance Indicator-Metriken.

8. Vorlaufzeit

Die Durchlaufzeit misst, wie lange es dauert, bis eine Änderung eintritt.

Diese Metrik kann von der Ideeninitiierung bis hin zur Bereitstellung und Produktion verfolgt werden. Die Vorlaufzeit bietet wertvolle Einblicke in die Effizienz des gesamten Entwicklungsprozesses. Es zeigt auch die aktuelle Fähigkeit an, den sich ändernden Anforderungen der Benutzerbasis gerecht zu werden. Lange Vorlaufzeiten deuten auf schädliche Engpässe hin, während kurze Vorlaufzeiten darauf hindeuten, dass auf Feedback umgehend reagiert wird.

9. Fehlerfluchtrate

Bei jeder Softwarebereitstellung besteht das Risiko, dass neue Fehler entstehen. Diese werden möglicherweise erst entdeckt, wenn die Abnahmetests abgeschlossen sind. Schlimmer noch: Sie könnten vom Endbenutzer gefunden werden.

Fehler sind ein natürlicher Teil des Entwicklungsprozesses und sollten entsprechend eingeplant werden. Die Fehlerfluchtrate spiegelt diese Realität wider, indem sie anerkennt, dass Probleme auftreten werden und dass diese so früh wie möglich entdeckt werden sollten.

Die Fehlerfluchtrate gibt an, wie oft Fehler in der Vorproduktion im Vergleich zum Produktionsprozess aufgedeckt werden. Diese Zahl kann ein wertvoller Indikator für die Gesamtqualität von Software-Releases sein.

10. Defektvolumen

Diese Metrik bezieht sich auf die oben hervorgehobene Escape-Rate, konzentriert sich jedoch stattdessen auf das tatsächliche Fehlervolumen. Während einige Mängel zu erwarten sind, sollten plötzliche Anstiege Anlass zur Sorge geben. Ein hohes Fehleraufkommen für eine bestimmte Anwendung kann auf Probleme bei der Entwicklung oder der Testdatenverwaltung hinweisen.

11. Verfügbarkeit

Die Verfügbarkeit verdeutlicht das Ausmaß der Ausfallzeit für eine bestimmte Anwendung.

Dies kann als vollständige (Lesen/Schreiben) oder teilweise (Nur-Lesen) Verfügbarkeit gemessen werden. Weniger Ausfallzeiten sind fast immer besser. Allerdings kann es aufgrund geplanter Wartungsarbeiten zu Verfügbarkeitsausfällen kommen. Verfolgen Sie sowohl geplante Ausfallzeiten als auch ungeplante Ausfälle genau und bedenken Sie, dass eine 100-prozentige Verfügbarkeit möglicherweise nicht realistisch ist.

12. Einhaltung der Service Level Agreements

Um die Transparenz zu erhöhen, arbeiten die meisten Unternehmen nach Service Level Agreements. Diese unterstreichen die Verpflichtungen zwischen Anbietern und Kunden. SLA-Compliance-KPIs bieten die nötige Rechenschaftspflicht, um sicherzustellen, dass SLAs oder andere Erwartungen erfüllt werden.

13. Ungeplante Arbeit

Wie viel Zeit wird für unerwartete Bemühungen aufgewendet? Die Unplanned Work Rate (UWR) misst dies im Verhältnis zur für geplante Arbeit aufgewendeten Zeit. Im Idealfall wird die ungeplante Arbeitsquote (UWR) 25 Prozent nicht überschreiten.

Ein hoher UWR kann auf verschwendeten Aufwand aufgrund unerwarteter Fehler hinweisen, die wahrscheinlich nicht frühzeitig im Arbeitsablauf erkannt wurden. Die UWR wird manchmal zusammen mit der Nacharbeitsrate (RWR) untersucht, die sich auf den Aufwand zur Behebung von in Tickets aufgeworfenen Problemen bezieht.

14. Kundenticketvolumen

Wie der KPI „Fehlerfluchtrate“ zeigt, sind nicht alle Fehler katastrophal. Im Idealfall werden sie jedoch frühzeitig gefangen. Dieses Konzept spiegelt sich am besten im Kundenticketvolumen wider, das angibt, wie viele Warnungen Endbenutzer generieren. Ein stabiles Benutzervolumen bei gleichzeitig erhöhtem Ticketvolumen deutet auf Probleme in der Produktion oder beim Testen hin.

15. Zykluszeit

Zykluszeitmetriken bieten einen umfassenden Überblick über die Anwendungsbereitstellung.

Dieser KPI verfolgt den gesamten Prozess, angefangen bei der Ideenfindung bis hin zum Benutzerfeedback. Kürzere Zyklen sind im Allgemeinen vorzuziehen, jedoch nicht auf Kosten der Entdeckung von Fehlern oder der Einhaltung von SLAs.

Beginnen Sie mit der Messung des Entwicklererfolgs

Konzentrieren Sie sich bei der Verfolgung wichtiger DevOps-Metriken weniger auf den wahrgenommenen Erfolg oder Misserfolg anhand eines einzelnen Indikators, sondern vielmehr auf die Geschichte, die diese Metriken erzählen, wenn sie zusammen betrachtet werden. Ein Ergebnis, das für sich genommen problematisch erscheint, könnte völlig anders aussehen, wenn es zusammen mit zusätzlichen Daten analysiert wird.

Eine sorgfältige Verfolgung der oben hervorgehobenen KPIs kann nicht nur eine höhere Effizienz in Entwicklung und Produktion gewährleisten, sondern, was noch wichtiger ist, das bestmögliche Endbenutzererlebnis. Machen Sie sich DevOps-Metriken zunutze und Sie könnten enorme Verbesserungen bei der Anwendungsbereitstellung und beim Feedback feststellen.