DevOps-Metriken
Erklärung des Warum, Was und Wie beim Messen des Erfolgs in DevOps
TOM HALL
DevOps-Fan und -Anwender
Das alte Sprichwort "Du kannst nicht verbessern, was du nicht messen kannst" gilt für DevOps genauso wie für jede andere Praxis. Um das Versprechen von DevOps zu erfüllen – schnellere Produkte mit höherer Qualität zu liefern – müssen Teams zahlreiche Metriken sammeln, analysieren und messen. Diese DevOps-Metriken liefern die wesentlichen Daten, die DevOps-Teams benötigen, um kontinuierlichen Einblick in ihre Entwicklungspipeline zu haben und diese zu kontrollieren.
Was sind DevOps-Metriken?
DevOps-Metriken sind Datenpunkte, die die Leistung einer DevOps-Softwareentwicklungspipeline direkt erkennen lassen und dabei helfen, Engpässe im Prozess schnell zu ermitteln und zu beseitigen. Diese Metriken können verwendet werden, um sowohl technische Fähigkeiten als auch Teamprozesse zu verfolgen.
Im Kern konzentriert sich DevOps darauf, die Grenze zwischen Entwicklungs- und Operations-Teams zu verwischen und eine bessere Zusammenarbeit zwischen Entwicklern und Systemadministratoren zu ermöglichen. Mithilfe der Metriken können DevOps-Teams kollaborative Workflows messen und bewerten und den Fortschritt bei der Umsetzung übergeordneter Ziele nachverfolgen, wie höhere Qualität, schnellere Release-Zyklen und verbesserte Anwendungsleistung.
Vier kritische DevOps-Metriken
Es gibt zahlreiche Metriken für die Messung der DevOps-Leistung, doch an den folgenden vier Schlüsselmetriken sollte sich jedes DevOps-Team orientieren.
1. Vorlaufzeit für Änderungen
Eine der wichtigsten DevOps-Metriken, die nachverfolgt werden müssen, ist die Vorlaufzeit für Änderungen. Die Vorlaufzeit für Änderungen, nicht zu verwechseln mit der Durchlaufzeit (siehe unten), ist die Zeitspanne zwischen der Übertragung einer Codeänderung (Commit) an den Trunk-Branch und dem Zeitpunkt, an dem sie sich in einem bereitstellbaren Status befindet. Das ist beispielsweise der Fall, wenn Code alle erforderlichen Tests vor dem Release besteht.
2. Änderungsfehlerrate
Die Änderungsfehlerrate ist der Prozentsatz der Codeänderungen, die nach der Produktion Hotfixes oder andere Korrekturen erfordern. Sie misst keine Fehler, die bei Tests erfasst und behoben wurden, bevor Code bereitgestellt wird.
3. Deployment-Häufigkeit
Nachvollziehen zu können, wie häufig neuer Code für die Produktion bereitgestellt wird, ist für die Messung des DevOps-Erfolgs entscheidend. Viele Fachleute verwenden den Begriff "Bereitstellung", wenn sie von der Freigabe von Codeänderungen in einer Staging-Umgebung vor der Produktion sprechen. "Deployment" bezieht sich wiederum auf Codeänderungen, die für die Produktion freigegeben werden.
4. Durchschnittliche Wiederherstellungszeit
Die mittlere Wiederherstellungszeit (MTTR) misst, wie lange es dauert, bis man sich von einer teilweisen Serviceunterbrechung oder einem Totalausfall erholt hat. Dies ist eine wichtige Metrik, die unabhängig davon verfolgt werden muss, ob die Unterbrechung das Ergebnis eines kürzlichen Deployments oder eines isolierten Systemausfalls ist.
Lösung anzeigen
Tools für ein spitzenmäßiges DevOps-Team
Zugehöriges Material
Die Bedeutung der Teamstruktur in DevOps
So werden DevOps-Metriken gemessen, verwendet und verbessert
Wie für andere Elemente des DevOps-Lebenszyklus gilt auch für DevOps-Metriken das Prinzip der kontinuierlichen Verbesserung. Leistungsstarke Teams zeichnen sich dadurch aus, dass sie in jeder Entwicklungsphase schnelles Feedback erhalten und dieses fachgerecht und eigenständig implementieren können. Im DevOps-Buch "Accelerate" merken die Autoren an, dass die vier oben aufgeführten Kernmetriken von 24 Fähigkeiten unterstützt werden, die leistungsstarke Softwareteams aufweisen. Wir werden gleich auf einen Großteil dieser Fähigkeiten (CI/CD, Testautomatisierung, Arbeiten in kleinen Batches, Überwachung und kontinuierliches Lernen) eingehen. Es lohnt sich aber, "Accelerate" zu lesen, um tiefer in die Forschungsergebnisse einzutauchen, die diese Praktiken unterstützen.
Vorlaufzeit für Änderungen
Leistungsstarke Teams messen in der Regel die Vorlaufzeiten in Stunden, während mittelmäßige und leistungsschwache Teams Vorlaufzeiten in Tagen, Wochen oder sogar Monaten messen.
Testautomatisierung, Trunk-basierte Entwicklung und die Arbeit in kleinen Batches sind wichtige Maßnahmen zur Verbesserung der Vorlaufzeit. Mithilfe dieser Praktiken können Entwickler schnelles Feedback zur Qualität des Codes erhalten, den sie committet haben, um Fehler zu identifizieren und zu beheben. Lange Vorlaufzeiten sind fast garantiert, wenn Entwickler an großen Änderungen in separaten Branches arbeiten, die auf manuelle Tests zur Qualitätskontrolle angewiesen sind.
Änderungsfehlerrate
Leistungsstarke Teams haben Änderungsfehlerraten im Bereich von 0 bis 15 Prozent.
Dieselben Praktiken, die kürzere Vorlaufzeiten ermöglichen, wie Testautomatisierung, Trunk-basierte Entwicklung und Arbeit mit kleinen Batches, gehen mit einer Verringerung der Änderungsfehlerraten einher. Denn all diese Praktiken erleichtern die Identifizierung und Behebung von Fehlern erheblich.
Die Nachverfolgung und Berichterstellung über Änderungsfehlerraten ist nicht nur wichtig, um Fehler zu identifizieren und zu beheben, sondern auch um sicherzustellen, dass neue Codeversionen die Sicherheitsanforderungen erfüllen.
Deployment-Häufigkeit
Leistungsstarke Teams können Änderungen bei Bedarf implementieren, und dies oft mehrmals am Tag. Leistungsschwache Teams beschränken sich häufig auf wöchentliche oder monatliche Bereitstellungen.
Wer Bereitstellungen bei Bedarf erreichen möchte, braucht eine automatisierte Deployment-Pipeline, die die in den vorherigen Abschnitten genannten automatisierten Test- und Feedbackmechanismen enthält und menschliche Eingriffe überflüssig macht.
Mittlere Wiederherstellungszeit
Leistungsstarke Teams erholen sich schnell von Systemausfällen – normalerweise in weniger als einer Stunde – während leistungsschwache Teams bis zu einer Woche dafür brauchen können.
Wie schnell man sich von einem Ausfall erholt, hängt von der Fähigkeit ab, auftretende Fehler schnell zu erkennen und Änderungen, die zu dem Fehler geführt haben, zu beheben oder rückgängig zu machen. Dies geschieht in der Regel durch die kontinuierliche Überwachung des Systemzustands und Alarmierung des Operations-Teams im Falle eines Ausfalls. Das Operations-Team muss über die erforderlichen Prozesse, Tools und Berechtigungen verfügen, um Vorfälle zu beheben.
Die Fokussierung auf MTTR ist eine Abkehr von der bisherigen Praxis, sich auf die mittlere Betriebsdauer zwischen Ausfällen (MTBF) zu konzentrieren. Sie spiegelt die erhöhte Komplexität moderner Anwendungen und damit eine erhöhte Ausfallerwartung wider. Sie stärkt auch die Praxis, kontinuierlich dazuzulernen und sich zu verbessern. Anstatt zu warten, bis die Bereitstellung perfekt ist, um Fehler zu vermeiden (und damit das alte MTBF-Scoreboard zurückzusetzen), sorgen Teams für kontinuierliche Bereitstellungen. Anstatt jemandem die Schuld dafür zu geben, dass er die perfekte MTBF-Bilanz ruiniert hat, werden beim MTTR-Ansatz Retrospektiv-Meetings ohne Schuldzuweisungen abgehalten. Dadurch soll Teams dabei geholfen werden, ihre vorgelagerten Prozesse und Tools zu verbessern.
Ähnliche Metriken
Eine weitere relevante Metrik ist die Durchlaufzeit, also die Zeit, die ein Team in ein Element investiert, bis es lieferfertig ist. In Entwicklungsumgebungen ist die Durchlaufzeit die Zeitspanne vom ersten Commit eines Entwicklers bis zu dem Zeitpunkt, an dem dieser für die Produktion bereitgestellt wird. Diese wichtige DevOps-Metrik hilft Projektleitern und Engineering-Managern dabei, besser zu verstehen, was in der Entwicklungspipeline gut funktioniert. Infolgedessen können sie ihre Arbeit besser auf die Erwartungen von Stakeholdern und Kunden ausrichten und sicherstellen, dass ihr Team schneller liefert.
Berichte zu Durchlaufzeiten ermöglichen es Projektleitern, eine Baseline für die Entwicklungspipeline zu erstellen, die zur Bewertung zukünftiger Prozesse verwendet werden kann. Wenn Teams die Durchlaufzeit optimieren, haben Entwickler in der Regel weniger Arbeit und weniger ineffiziente Workflows.
Beim schlanken Produktmanagement liegt der Schwerpunkt auf der Wertstromanalyse, bei der es sich um eine Visualisierung des Flusses vom Produkt- oder Feature-Konzept bis zur Auslieferung handelt. DevOps-Metriken bieten viele der wesentlichen Datenpunkte für eine effektive Wertstromanalyse und Verwaltung, sollten für eine echte End-to-End-Evaluierung jedoch durch andere Geschäfts- und Produktmetriken erweitert werden. Zum Beispiel geben Sprint-Burndown-Charts einen Einblick in die Wirksamkeit von Schätzungs- und Planungsprozessen. Ein Net Promoter Score (NPS) hingegen gibt Auskunft darüber, ob das endgültige Ergebnis den Anforderungen der Kunden entspricht.
Fazit
Kontinuierliche Verbesserung ist ein zentraler Grundsatz von Teams, die DevOps-Prinzipien anwenden. Wenn Teams die Leistung über die Vorlaufzeit von Änderungen, die Änderungsfehlerrate, Deployment-Häufigkeit und MTTR messen und nachverfolgen können, wird sich die Deployment-Geschwindigkeit und -Qualität erhöhen.
Open DevOps von Atlassian hat alles, was Teams brauchen, um Software zu entwickeln und zu betreiben. Dank Integrationen mit führenden Anbietern und Marketplace-Apps erhalten Teams genau die DevOps-Toolchain, die sie benötigen. Jetzt testen.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
DevOps-Lernpfad
