Wichtige Metriken für DevOps-Teams: DORA und MTTx

Viele von euch haben es im Arbeitsalltag mit komplexen Umgebungen zu tun. Doch wie stellt ihr sicher, dass eure Anwendungen und Geschäftsprozesse wie geplant funktionieren? Woher wisst ihr, ob eure Kunden zufrieden sind? Und wie findet ihr heraus, wann es Zeit für infrastrukturelle Erweiterungen oder sogar für ein Anwendungs-Refactoring ist?

Die Antwort liegt auf der Hand: Für alle diese Dinge braucht ihr Metriken. Verlässliche Kennzahlen, mit denen ihr den Zustand eurer Anwendungen und Infrastruktur kontinuierlich im Blick behalten könnt. Sie geben Auskunft darüber, ob ihr die richtigen Softwareentwicklungspraktiken anwendet, und zeigen Verbesserungspotenziale auf. Außerdem lassen sich mit Metriken ausfallbedingte Kosten beziffern, darunter der Aufwand für euer Troubleshooting-Team und der Schaden für eure Kunden.

In diesem Artikel möchte ich euch zwei der wichtigsten Metriken im DevOps-Bereich nahebringen: DORA und MTTx.

DORA

DORA steht für „DevOps Research and Assessment“ und ist der Name eines Teams, das basierend auf jahrelanger Forschung vier wesentliche Kennzahlen für die Performance eines Softwareentwicklungsteams entwickelte. Hier eine kurze Übersicht, welche Kennzahlen das sind und was sie bedeuten:

Bereitstellungshäufigkeit

Wie oft werden Releases für die Produktionsumgebung bereitgestellt? Diese Frage lässt sich recht einfach beantworten: Es wird gezählt, wie viele Produktionsreleases innerhalb einer bestimmten Zeitspanne auftreten, und dieser Wert wird dann fortlaufend getrackt. Erfolgreiche DevOps-Teams arbeiten nach dem Prinzip der „kontinuierlichen Bereitstellung“, d. h., es gibt täglich oder sogar stündlich mehrere Bereitstellungen. Diese Vorgehensweise gilt als DevOps-Goldstandard – aber auch wenn ihr noch nicht so weit seid, ist das Tracken der Bereitstellungshäufigkeit euer erster Schritt auf dem Weg dorthin.

Vorlaufzeit (für Änderungen)

Wie viel Zeit vergeht zwischen einem Commit für die Codebasis und dessen Bereitstellung in der Produktionsumgebung? Dieser Kennwert hängt zwar mit der Bereitstellungshäufigkeit zusammen, ist aber nicht ganz dasselbe. Viele Unternehmen entwickeln Code für neue Funktionen in separaten Branches. Selbst wenn recht häufig Bereitstellungen stattfinden, verweilen neue Features mitunter noch längere Zeit in diesen Branches, während andere Änderungen wie z. B. Bugfixes im Main Branch umgesetzt werden. Wenn ihr wisst, wie lange ein durchschnittlicher Commit in der Warteschleife hängt, bevor er live geht, könnt ihr daran die Geschwindigkeit eurer Entwicklungspraktiken insgesamt ablesen. Es geht also darum, wie schnell neue Features bei den Usern ankommen.

Ausfallrate von Änderungen

Wie hoch ist der prozentuale Anteil von Bereitstellungen, die in der Produktion einen Ausfall verursachen? Auch diese Kennzahl ist einfach ermittelt: Man zählt schlicht, wie viele Bereitstellungen rückgängig gemacht, gepatcht oder anderweitig nachgebessert werden mussten, weil sie in der Produktionsumgebung zu einem Fehler geführt haben. Der ideale Zielwert liegt natürlich bei null, aber Vorsicht: Eine Ausfallrate von null Prozent kann auch bedeuten, dass ihr beim Umsetzen von Änderungen etwas zu zögerlich seid. Die große Kunst besteht für DevOps-Teams letztlich immer darin, die richtige Mischung aus Stabilität und Innovation zu finden.

Wiederherstellungszeit

Wie lange dauert eine durchschnittliche Wiederherstellung nach einem Produktionsausfall? Angenommen, euer Service fällt aus, sei es, weil in einem Release der Wurm drinsteckt, ein Bagger ein Glasfaserkabel erwischt hat oder euer Rechenzentrum ausgefallen ist – wie lange dauert es, bis eure User wieder normal arbeiten können? Eine möglichst kurze Wiederherstellungszeit ist von kritischer Bedeutung. Eine fehlerfreie Architektur gibt es zwar nicht, aber eine robuste Infrastruktur kann dafür sorgen, dass eure Anwendungen schnell wieder verfügbar sind, und so den Schaden für eure User gering halten.

MTTx

Die DORA-Metriken sind vor allem für Softwareentwicklungszwecke gedacht. Demgegenüber beschreiben MTTx-Kennzahlen eher den Betrieb. „MTT“ steht dabei für „Mean Time To“, und „x“ ist ein Platzhalter. Hier einige der gängigsten MTTx-Metriken:

MTTR

Diese Kennzahl kennen wir bereits: MTTR ist die Mean-Time-To-Resolve oder mittlere Wiederherstellungszeit – die letzte DORA-Metrik. Der Begriff ist im Grunde selbsterklärend: Wie lange dauert es, bis ein System nach einem Ausfall wieder vollständig einsatzbereit ist?

MTTD

Der letzte Buchstabe steht für „Detect“ oder „Erkennen“ – die MTTD misst also, wie viel Zeit im Durchschnitt vergeht, bis ein Problem gemeldet oder erkannt wird. Das können wenige Sekunden sein, wenn etwa eine ganze Anwendung ausfällt und Fehlermeldungen vom Typ 503 ausgibt, aber auch Wochen, falls das Problem nur einen User betrifft, der es so lange ignoriert, bis nichts mehr geht. Wenn ihr diesen Wert minimiert, hat das in der Regel positive Auswirkungen auch auf alle anderen Metriken.

MTTA

Dies ist die Mean-Time-To-Acknowledge, und hier wird es etwas komplizierter: Die MTTA misst, wie lange es nach dem Erkennen eines Problems dauert, bis ein Network-Operations-Center-Mitarbeiter, ein Site Reliability Engineer oder irgendjemand sonst, der für den Triage- und Lösungsprozess zuständig ist, das Problem bestätigt. Und an „irgendjemand sonst“ scheiden sich die Geister. Reicht es wirklich, wenn irgendjemand den Alarm sieht, oder sollte es schon die Person sein, die das Problem am Ende auch behebt? Letzteres ist meiner Meinung nach sinnvoller, aber letztlich ist es Definitionssache – entscheidet also selbst.

MTTC

C steht hier für „Clue“, und gemeint ist: Wie lange dauert es, bis die Person, die den Vorfall bestätigt, auch verstanden hat, welche Ursache zugrunde liegt und wie diese sich beseitigen lässt? Wenn ihr hohe MTTC-Werte verzeichnet, kann dies daran liegen, dass eure Umgebung oder Anwendung zu kompliziert oder eure Bereitstellung zu intransparent ist. Lange MTTC-Zeiten können aber auch darauf hindeuten, dass eure Techniker zu viel um die Ohren haben und deshalb Fehlern nicht schnell auf den Grund gehen können.

MTTI

I wie „Innocence“, also „Unschuld“, hört sich zunächst so an, als hätte sich jemand einen Scherz erlaubt. Tatsächlich ist die Mean-Time-To-Innocence oder kurz MTTI aber eine wichtige Kennzahl in modernen Umgebungen mit vielen Teams, die für die Bereitstellung und den Betrieb von Software zuständig sind. Die MTTI ist ein Maß für die mittlere Zeit, die ein Team braucht, um zu erkennen, dass ein bestimmtes Problem nicht in seinen Verantwortungsbereich fällt. Wer schon einmal eine moderne Anwendung bereitgestellt hat, weiß, dass das für die Netzwerkinfrastruktur zuständige Team bei verschiedensten Problemen oft als Prügelknabe herhalten muss. Dabei bringt es gar nichts, immer sofort das Network-Operations-Team einzuspannen, denn der Fehler liegt in vielen Fällen woanders – die Fehlerbehebung wird dadurch nur unnötig hinausgezögert. Eine kurze MTTI für Infrastrukturteams senkt daher die MTTR und erspart den Mitgliedern dieser Teams einigen Aufwand.

Wie ermittle und verwende ich diese Metriken?

Viele dieser Metriken lassen sich mit Observability- und Monitoring-Tools berechnen, entweder standardmäßig oder mithilfe von Plug-ins. Möglich ist natürlich auch eine manuelle Berechnung, aber der Aufwand dafür würde den Sinn und Zweck des Ganzen konterkarieren.

Wenn ihr diese Metriken fortlaufend trackt, erhaltet ihr wichtige Einblicke zur Performance eures Teams, eurer Infrastruktur und eurer Anwendungen. Auf dieser Grundlage könnt ihr dann weitere Ressourcen oder mehr Zeit anfordern.

Zu guter Letzt ist die Kombination aus MTTx und DORA ideal für DevOps-Zwecke, denn damit könnt ihr Erfolgs- und Leistungsdaten sowohl aus entwicklungstechnischer als auch aus betrieblicher Perspektive überwachen – Dev und Ops in Harmonie vereint. Das ermöglicht eine gemeinsame Sprache und gemeinsame Ziele, sorgt für besseres Teamwork und verbessert unterm Strich die Qualität eurer Softwarebereitstellungen.

MTTx- und DORA-Kennzahlen findet ihr in der Splunk Observability Cloud, ganz egal, wo eure Anwendung bereitgestellt wird und wie komplex sie ist. Probiert es am besten selbst aus: mit der 14-tägigen kostenlosen Testversion – ihr braucht dafür keine Kreditkarte!

*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.