Back to top icon

DevOps-Erfolg messen

Obwohl DevOps anscheinend die einfache Integration von zwei funktionalen Rollen sind, kann das Messen der Ergebnisse einer neuen DevOps-Initiative eine Herausforderung sein. Im Grunde bilden Sie neue Teams mit neuen Verantwortlichkeiten, die bei schlechtem Management Risiken bergen und das Frustpotenzial erhöhen.


Daher ist es wichtig, in Ihrer DevOps-Umgebung vollständige Transparenz für Ihre Anwendungen, Infrastruktur, Zuverlässigkeit und Teamintegrität zu gewährleisten. Durch die gemeinsame Nutzung der wichtigsten Performance-Metriken mit allen Beteiligten in Ihrem digitalen Geschäft kann jeder Ihren DevOps-Aufwand und -Erfolg in jeder Phase überwachen. Führungskräfte müssen sichergehen können, dass alle gemeinsam dieselben Ziele anstreben. Und dank gemeinsamer Erkenntnisse können Teamkollegen einfacher und schneller zusammenarbeiten.


Was Sie messen sollten

Echter DevOps-Erfolg bedeutet, die Geschwindigkeit und Agilität Ihrer Teams zu erhöhen. So liefern Sie schneller und häufiger zuverlässige leistungsstarke Software für beeindruckende Kundenerlebnisse. Der Zugriff auf und die gemeinsame Nutzung von Echtzeit- und Verlaufsdaten über den gesamten Technologie-Stack hinweg – von der Performance von Infrastruktur und Anwendung bis hin zur Zuverlässigkeit und Teamintegrität – ist für die Erreichung dieser DevOps-Ziele von entscheidender Bedeutung.    

Es gibt zwar viele Metriken zum Verfolgen Ihrer DevOps-Möglichkeiten, aber diese 17 stellen einen guten Anfang dar. Wir haben sie in drei Hauptfunktionsbereiche unterteilt:

  1. DevOps-Messungen für den grundlegenden Anwendungs- und Infrastrukturzustand
  2. DevOps-Messungen für Zuverlässigkeit und Systemintegrität 
  3. Messungen für den DevOps- und DevOps-Teamzustand 

Beachten Sie, dass die Reihenfolge dieser Liste keine bestimmte Reihenfolge impliziert. Stattdessen wird von allgemeinen zu spezifischen Messungen übergegangen und eine ordnungsgemäß geplante DevOps-Initiative würde Metriken aus allen drei Gruppen verfolgen.

DevOps-Messungen für den grundlegenden Anwendungs- und Infrastrukturzustand

DevOps-Teams arbeiten unermüdlich daran, Probleme schnell zu erkennen. Dies erfolgt idealerweise, bevor sie auftreten und Kunden betreffen. Sie verfolgen und überwachen hierzu eine Reihe wichtiger Metriken zur Anwendungs-Performance und Infrastruktur. Diese Metriken sollten sowohl für Softwareentwickler als auch für Betriebsingenieure in DevOps-Organisationen Relevanz haben.

Apdex

Apdex misst die Zufriedenheit Ihrer Kunden in Bezug auf die Reaktionszeit von Webanwendungen und -diensten. Es wird insbesondere das Verhältnis von zufriedenstellenden zu unbefriedigenden – oder schlimmeren – Reaktionszeiten gemessen. Die Reaktionszeit beginnt, wenn ein Kunde eine Anfrage stellt, und endet, wenn die Anfrage abgeschlossen ist.

Um Apdex für eine Anwendung zu messen, müssen Sie in Ihrer Anwendung zunächst einen Reaktionszeitschwellenwert (T) gemäß der Performance-Baselines festlegen.

Apdex verfolgt drei Reaktionszahlen auf drei verschiedenen Ebenen:

  1. Zufrieden: Die Reaktionszeit ist kleiner oder gleich T.

  2. Toleriert: Die Reaktionszeit ist größer als T und kleiner oder gleich 4T.

  3. Frustriert: Die Reaktionszeit ist größer als 4T.

Wenn beispielsweise T 1,2 Sekunden beträgt und eine Reaktion in 0,5 Sekunden abgeschlossen ist, gilt der Benutzer als zufrieden. Reaktionen, die länger als 1,2 Sekunden dauern, gelten beim Benutzer als nicht zufriedenstellend. Reaktionen, die länger als 4,8 Sekunden dauern, frustrieren den Benutzer.

Weitere Informationen zum Verfolgen dieser Metrik finden Sie in den folgenden Einführungsvideos: Grundlegendes zu Apdex und Apdex: Messen der Benutzerzufriedenheit.

Durchschnittliche Reaktionszeit

Die Reaktionszeit ist die Zeit, die eine Anwendung zur Verarbeitung einer Transaktion benötigt. Diese Metrik ist ein guter Indikator dafür, wie Ihre Kunden Ihre Website erleben. Es ist wichtig, diese Metrik an mehreren Orten und mit den wichtigsten Arten von Interaktionen zu testen, die Ihre Benutzer mit Ihrer Website oder App haben können (es überrascht nicht, dass beispielsweise eine Aufforderung zum Anmelden eine andere Reaktionszeit aufweist als ein Dateidownload. Stellen Sie also sicher, dass beide Zeiten innerhalb eines akzeptablen Bereichs für diese Interaktion liegen).

In New Relic wird auf der Standardübersichtsseite in APM die durchschnittliche Reaktionszeit für alle Ihre Anwendungen als Teil des Zeitdiagramms für Webtransaktionen angezeigt. Darüber hinaus können Sie eine NRQL-Abfrage schreiben, um ein New Relic Insights-Widget zu erstellen. Mit diesem können Sie die durchschnittliche Reaktionszeit für einzelne Anwendungen verfolgen.

Zur Ermittlung der durchschnittlichen Reaktionszeit Ihrer Anwendung über einen bestimmten Zeitraum können Sie den  New Relic API Explorer (v2) verwenden.

CPU-Auslastung in Prozent

Die CPU-Auslastung ist ein wichtiger Indikator für die Verfolgung der Anwendungsverfügbarkeit. In einer On-Premise-Umgebung kann es mit zunehmender CPU-Auslastung zu einer Verschlechterung Ihrer App kommen – was sich negativ auf das Kundenerlebnis auswirken könnte. Wenn Sie jedoch die CPU-Auslastung in der allgemeinen Cloud nicht maximieren, nutzen Sie wahrscheinlich auch nicht die Ressourcen aus, für die Sie bezahlen. In New Relic APM misst die prozentuale CPU-Auslastung die gesamte CPU-Auslastung aller Instanzen Ihrer App oder Ihres Dienstes auf einem bestimmten Server. In New Relic Infrastructure wird die prozentuale CPU-Auslastung nach Host oder Prozess gemessen. Die Metrik für die CPU-Auslastung in Prozent wird standardmäßig erfasst und in Infrastructure in einem Host-Performance-Diagramm angezeigt.

Sie können auch die New Relic REST API (v2) verwenden, um die durchschnittliche CPU-Auslastung für Ihre Anwendung auf einem einzelnen Host zu ermitteln.

Fehlerquoten

Allgemein wird jede nicht behandelte Ausnahme als Fehler betrachtet. Eine Metrik zur Fehlerrate verfolgt den Prozentsatz der Transaktionen, die in einem bestimmten Zeitfenster zu Fehlern führen. Wenn Ihre Anwendung beispielsweise in einem bestimmten Zeitraum 1000 Transaktionen verarbeitet und 50 davon nicht behandelte Ausnahmen aufweisen, liegt die Fehlerquote bei 50 ‰ oder 5 %.

New Relic bietet eine Reihe von Möglichkeiten, um Fehlerquoten zu ermitteln, darunter ein APM-Fehlerquotendiagramm und die New Relic Browser Javascript-Fehleranalyse.

Durchschnittliche Last

Mit dieser Metrik können Sie die durchschnittliche Anzahl von Systemprozessen, Threads oder Tasks messen, die auf die CPU warten und dafür bereit sind. Durch die Überwachung der durchschnittlichen Last können Sie besser nachvollziehen, ob Ihr System überlastet ist oder ob es Prozesse gibt, die zu viele Ressourcen verbrauchen. Mit New Relic Infrastructure können Sie die durchschnittliche Last in Intervallen von 1, 5 oder 15 Minuten verfolgen. Die Daten werden auf der Seite Infrastruktur-Host angezeigt.

Speicherauslastung in Prozent

Die Verwendung von zu viel Speicher auf einem Host kann zu schlechter Anwendungs-Performance führen. Die dauerhafte Verwendung von zu wenig Speicher kann dagegen dazu führen, dass teure Ressourcen, insbesondere in der Cloud, nicht ausreichend genutzt werden.

Für die prozentuale Speichernutzung wird dann die Menge der freien Speicherbytes mit der Menge der verwendeten Speicherbytes für jeden Host in Ihrer Infrastruktur verglichen. Die Metrik für die prozentuale Speichernutzung wird standardmäßig erfasst und in Infrastructure in einem Host-Performance-Diagramm dargestellt.

Verwenden Sie die New Relic REST API (v2), um die durchschnittliche Speichernutzung für Ihre Anwendung auf einem einzelnen Host zu ermitteln.

Throughput

Der Throughput ist die Messung der Benutzeraktivität für eine überwachte Anwendung. In New Relic APM protokolliert der Throughput für Ihre Anwendung Requests pro Minute (RPM). Durch Verfolgen des Throughputs können Sie beispielsweise feststellen, ob sich durch eine neue Funktion, eine Verbesserung oder eine architektonische Änderung die Art und Weise ändert, in der Ihre Anwendung Anfragen verarbeitet.

Verwenden Sie die New Relic REST-API (v2), um den durchschnittlichen Throughput für Ihre App zu ermitteln, einschließlich des Throughput von Webanwendungen und Nicht-Webanwendungen. Dieselben Werte werden im Throughput-Diagramm auf der Übersichtsseite Ihrer App in APM angezeigt.

DevOps-Messungen für Zuverlässigkeit und Systemintegrität

DevOps-Teams können die Zuverlässigkeit, Qualität und den Gesamtzustand des Systems mithilfe einiger wichtiger Metriken verfolgen. Mit Sicherheit werden Ingenieure für Seitenzuverlässigkeit, Betriebsingenieure, Softwareentwickler, Projektmanager und technische Führungskräfte in DevOps-Organisationen diese Messungen als wertvoll erachten.

Fehlermetriken

Fehlerraten-Metriken erfassen die Anzahl der Probleme oder Fehler, die bei der Softwareproduktion gemeldet wurden oder während der Bereitstellung Ihrer Software auftreten. Diese Probleme können auf der Infrastruktur-, Anwendungs-, Mobilanwendungs- oder Browser-Ebene basieren. Normalerweise werden diese Fehler in Form von Fehlertickets oder Supporttickets nachverfolgt.

Sie können New Relic in ein „Bug-Tracking“-System wie Atlassian JIRA, Lighthouse oder Pivotal Tracker integrieren, um schnell Tickets, Probleme und Storys zu Performance-Schwächen zu erstellen, die Sie mit New Relic erkannt haben.

Mittlere Zeit bis zur Erkennung (MTTD)

Diese Metrik verfolgt die Zeitspanne zwischen dem Auftreten und dem Erkennen eines Problems. Idealerweise werden zu diesem Zeitpunkt bereits Maßnahmen ergriffen. DevOps-Teams sollten daran arbeiten, ihre MTTD so kurz wie möglich zu halten.Mit den richtigen Instrumentierungs-, Alert- und Benachrichtigungskanälen in Ihren Teams können Sie schneller auf jede Fehlererkennung reagieren.  

Beachten Sie dabei, dass MTTD nicht die Zeit einrechnet, die zur Behebung des Problems benötigt wird.

Nutzen Sie New Relic Alerts und legen Sie Ihre Bedingungen und Alert-Richtlinien fest, damit Entwickler, Betriebspersonal und Softwarebesitzer auf dem neuesten Stand bleiben und bei Problemen direkt Maßnahmen ergreifen können. Alerts sind besonders dann wertvoll, wenn sie mit einem Benachrichtigungssystem wie Slack oder PagerDuty gekoppelt sind, das bei der Kommunikation rund um die Fehlererkennung und -prävention unterstützend wirken kann.

Mittlere Zeit bis zur Fehlerbehebung (MTTR)

MTTR zeichnet die durchschnittliche Zeit auf, die zum Reparieren einer ausgefallenen Komponente in Ihrem System benötigt wird und berechnet die Zeit ab der Feststellung des Ausfalls bis zum Zeitpunkt, an dem das System wieder normal arbeitet. Verwenden Sie diese Metrik, um die Kommunikationsmechanismen in Ihrem Wiederherstellungsprozess zu messen und zu verbessern. Wenn Sie über direkte Kommunikationskanäle verfügen, können Fixes schneller identifiziert, getestet, validiert und bereitgestellt werden. Dies minimiert Downtimes.

Zum Beispiel sammelt New Relic Infrastructure Metriken in Echtzeit, um die MTTR zu reduzieren, indem Änderungen der Host-Performance mit Konfigurationsänderungen in Ihrer Infrastruktur in Verbindung gebracht werden. Stellen Sie New Relic Alerts für die von Ihnen erfassten Infrastrukturmetriken ein, um Informationen zu potenziellen Problemen zu erhalten, bevor sie sich auf Ihre Systeme auswirken.

Service-Level-Vereinbarungen (SLA):

Ganz gleich, ob Sie ein einzelnes Entwicklungsteam oder ein gesamtes Unternehmen verwalten – SLAs sind der (manchmal rechtlich bindende) Vertrag zwischen Ihnen und Ihren Benutzern oder Kunden.

Einige der in diesem Handbuch erörterten Metriken sollten in Ihre SLAs integriert werden, einschließlich Apdex und der durchschnittlichen Reaktionszeit. New Relic APM fertigt SLA-Berichte an, in denen Anwendungs-Downtimes und Entwicklungen im Laufe der Zeit aufgezeichnet werden, damit Sie die Performance Ihrer Anwendungen besser verstehen. Sie können auch SLA-Berichte für Schlüsseltransaktionen in APM und für Synthetics-Monitore erhalten.

Service-Level-Ziele (SLOs)

SLOs sind Ziele, die Ihre Teams festlegen. Dabei berücksichtigen sie, was Sie und Ihre Kunden von Ihrem System in Bezug auf Verfügbarkeit, Performance, Fehlerraten und alles andere, was laut Vereinbarung gemessen werden soll, erwarten können. Ihre SLO-Ziele sollten widerspiegeln, was Ihr Team und Ihr Unternehmen tatsächlich unterstützen und was Sie gemäß den technischen Möglichkeiten tatsächlich unterstützen können. Ein SLO-Beispiel für ein Team, das einen API-Service bereitstellt, wird möglicherweise eine Payload-Akzeptanzrate von 99,99 % angeben.

Natürlich können sich Ihre SLOs im Laufe der Zeit ändern. Wenn Sie beispielsweise ein unausgereiftes System haben, fangen Sie vielleicht mit relativ bescheidenen SLOs an und erhöhen diese mit der Zeit.

New Relic ist eine großartige Möglichkeit für Ihre Teams, grundlegende Metriken für den Anwendungs- und Infrastrukturzustand zu messen. So können Sie SLOs festlegen, die unter anderem die prozentuale CPU-Auslastung, die Verfügbarkeit und die Fehlerrate sowie die durchschnittliche Reaktionszeit abdecken.

DevOps-Messungen für Teamintegrität

Erfolgreiche DevOps-Organisationen erfassen nicht nur technische Metriken, sondern untersuchen auch den Zustand und die Performance von Teams. Diese Messungen sind von besonderem Interesse für Softwareentwickler, Betriebsingenieure, Projektmanager und technische Führungskräfte in DevOps-Organisationen.

Code-Festschreibungen

Durch Verfolgen der Festschreibungen, die ein Team an einem Artefakt in einem Entwicklungs-Lifecycle ausführt, bevor dieses Artefakt in der Produktion bereitgestellt werden kann, kann diese Metrik als Indikator für die Teamgeschwindigkeit und die Codequalität dienen. Zu viele Festschreibungen oder umgekehrt auch zu wenige Festschreibungen können bedeuten, dass ein Projekt durch die Teammitglieder nicht ordnungsgemäß verwaltet wird. Zum Beispiel kann eine hohe Anzahl von Festschreibungen bedeuten, dass die Teammitglieder keine klare Richtung für die Lösung eines Problems haben und planlos auf der Suche nach einer Lösung vorgehen. Zu wenige Festschreibungen können bedeuten, dass sie durch andere Verpflichtungen oder zu viel Arbeit abgelenkt sind.

In New Relic können Sie mit der Insights-API ein Custom-Event für jede Git-Festschreibung erstellen, diese mit einer NRQL-Abfrage verfolgen und die Ergebnisse in einem Dashboard anzeigen. Darüber hinaus können Sie Festschreibungen nachverfolgen, indem Sie Bereitstellungen mit der New Relic Rest API v2 aufzeichnen.

Bereitstellungszeit und Bereitstellungshäufigkeit

Die schnelle Iteration und eine kontinuierliche Bereitstellung – letztendlich die Dauer und Häufigkeit der Bereitstellung Ihrer Software – werden häufig als Schlüsselparameter für den Erfolg von DevOps betrachtet. DevOps-Experten wie Gene Kim, Mitautor des DevOps-Handbuchs, sind der Ansicht, dass diese Metriken in hohem Zusammenhang mit positiven Ergebnissen für DevOps-Organisationen stehen.

Unter Verwendung der New Relic REST API v2 können Sie neue Bereitstellungen aufzeichnen sowie alte auflisten und löschen. Einige Agenten verfügen auch über agentenspezifische Methoden, um Bereitstellungen automatisch aufzuzeichnen. Nach dem Aufzeichnen von Bereitstellungen können Sie diese auf der Seite „APM-Bereitstellungen“ und in der Liste „Letzte Ereignisse“ auf der Seite „Übersicht“ anzeigen. Das Bereitstellungs-Dashboard auf der Bereitstellungsseite von New Relic APM zeigt alle aktuellen Bereitstellungen mit Datum und Zeit an. Dazu listet es die Auswirkungen auf Ihre Endbenutzer, die Apdex-Punktzahl des App-Servers sowie Reaktionszeiten, Throughput und Fehler auf. Sie können noch mehr ins Detail gehen, indem Sie Such- und Sortieroptionen anwenden, einen Fehler ausblenden oder löschen, diesen mit anderen teilen oder ein Ticket zum Fehler anlegen.

Iterationslänge

Verwenden Sie diese Metrik, um die Zeitspanne zwischen Entwicklungszyklen während der Ausführung eines Projekts zu verfolgen. In modernen Agile-Workflows dauern Entwicklungszyklen in der Regel ein bis zwei Wochen. Dabei wird jeder Zyklus (oder Sprint) durch Planung und Rückblicke unterbrochen. (Nach jedem Sprint kann ein Team ein lieferbares Artefakt haben oder nicht.) Die Verfolgung der Iterationslänge ermöglicht ein besseres Verständnis für Änderungen im Projektumfang, in der Teamgeschwindigkeit und der Arbeitsbelastung sowie für Ihre Fähigkeit, sich im Verlauf eines Projekts an Änderungen anzupassen.

Bestandene/nicht bestandene Unit-Tests

Eine Unit ist die kleinste testbare Komponente Ihrer Software. Verfolgen Sie die Anzahl der bestandenen oder fehlgeschlagenen Unit-Tests während eines Entwicklungszyklus, um die Qualität des Codes von Ihrem Team zu beurteilen.

Wenn Sie beispielsweise PHPUnit zum Verwalten und Ausführen Ihrer Unit-Tests verwenden, kann der New Relic PHP-Agent die Testergebnisse automatisch erfassen und diese an Insights senden. Dort können Sie dann Testdaten auf einen Blick abfragen und visualisieren.

Ein anderer Ansatz wäre die Verwendung einer NRQL-Abfrage zum Erstellen eines Dashboard-Widgets, das das Verfolgen von bestandenen/nicht bestandenen Unit-Tests ermöglicht.

Projektvorlaufzeit

Diese Metrik wird auch als MTTC (Mean Time to Change) bezeichnet und erfasst die Zeitspanne zwischen dem Start eines Projekts und der tatsächlichen Produktionsbereitstellung des Artefakts dieses Projekts. Dies kann dazu beitragen, im Verlaufe der Geschäftsentwicklung die Anpassungsfähigkeit Ihres Teams zu messen.

Eine Möglichkeit zum Verfolgen der Projektvorlaufzeit besteht darin, mithilfe der Insights-API ein Custom-Event für jedes Git-Commit zu erstellen und anschließend mithilfe einer NRQL-Abfrage ein Dashboard-Widget zu erstellen. 

Sind Sie bereit, Ihren DevOps-Weg zu messen?

Unabhängig davon, wo Sie sich in der Umstellung auf DevOps befinden – ob Sie gerade erst anfangen, bereits mit kleinen Pilotprojekten Erfolg hatten oder einen vollständigen DevOps-Shop betreiben –, die New Relic-Plattform kann Ihnen dabei helfen, Ihre Fortschritte zu verfolgen und Ihre DevOps-Anstrengungen zu optimieren. Weitere Informationen finden Sie in den Guides zur Messung von DevOps-Erfolgen. Dabei handelt es sich um eine Reihe technischer Tutorials zur Verwendung von New Relic und zur Messung Ihres DevOps-Weges.


 

 

Ihr modernes DevOps-Toolset

New Relic ist nur eine von vielen wichtigen Technologien, die Sie für Ihre DevOps benötigen.

Tools anzeigen >

Artikel

Einführung in den New Relic Guide zur Messung des DevOps-Erfolgs

E-Book

DevOps ohne Erfolgsmessung ist ein Fehler: So messen und verfolgen Sie die fünf kritischen Treiber des DevOps-Erfolgs

Artikel

Dashboards für DevOps: Beispiele für zu messende Elemente

Fallstudie

Riskified nimmt die Geschwindigkeit und das Ausmaß von E-Commerce-Betrug mit Insights von New Relic ins Visier