MTTR smart reduzieren

Möchte man die Systemzuverlässigkeit allgemein nachvollziehbar quantifizieren, kommt man an der mittleren Lösungszeit bzw. ihrer Abkürzung MTTR für „Mean Time to Resolution“ kaum vorbei. Paradoxerweise ranken sich genau um sie aber auch etliche Missverständnisse. So tun sich zahlreiche Dev- und Operations-Teams schon reichlich schwer, wenn es darum geht, die Kennzahl überhaupt klar zu definieren. Und wie sie richtig einzusetzen oder konsequent zu verbessern ist, daran scheiden sich erst recht die Geister.

Angesichts der immer zentraleren Bedeutung von Software für betriebliche Abläufe jeder Art sind diese Diskrepanzen nicht nur lästig, sondern vielmehr ein nicht zu unterschätzender Risikofaktor für das Geschäftsergebnis: Nicht nur das digitale Kundenerlebnis – und in ihm ein mehr und mehr entscheidendes Erfolgselement – steht und fällt mit Software. Auch der Entwicklungsprozess selbst kann im Falle von Unklarheiten nur zu leicht an unnötiger Komplexität kranken und unter Kostenlast knarzen.

Die Lösung liegt in einem progressiven MTTR-Modell mit drei Grundfesten: Umfangreiche Instrumentierungsund Monitoring-Möglichkeiten müssen komplementiert werden von einem robusten und verlässlichen Incident Response Framework und einem Team, das die MTTR zur Optimierung von Anwendungsverfügbarkeit und -Performance einzusetzen weiß. Als Initialzündung liefern wir Ihnen in Form unserer 10 Best Practices passend hierzu Ansatzpunkte, um Ihre MTTR mit einem solchen Modell im Kontext Ihrer Incident Response smart und nachhaltig zu reduzieren. Ebenso zeigen wir auf, wie DevOps-Teams mit der New Relic Plattform strategisch bedeutsame MTTR-Ziele beschleunigt voranbringen.

Schwierigkeiten bereitet die MTTR schon bei ihrer Definition. Über weite Teile des Industriezeitalters hinweg drehte sich dabei alles um die Gerätewartung: Die MTTR erblickte das Licht der Welt als Kennzahl für die Reparaturzeit von Maschinen, schwerem Arbeitsgerät oder Fabrikanlagen.

Die Evolution hin zu Software hat natürlich auch sie mitgemacht und beschreibt nun passenderweise die Lösungszeit bzw. Wiederherstellungszeit im Anwendungskontext. Eine Unterscheidung der beiden Begriffe mag trivial erscheinen, beide zielen jedoch auf unterschiedliche Resultate ab und repräsentieren zwei gänzlich unterschiedliche Herangehensweisen an Performance-Probleme:

• Mit der mittleren Wiederherstellungszeit wird erfasst, wie schnell eine Anwendung infolge einer Performance-Schwäche oder Downtime wieder live in der Produktion verfügbar ist. Sie ist somit das spezifische digitale Äquivalent der mittleren Reparaturzeit.
• Bei der mittleren Lösungszeit hingegen geht es um das große Ganze: Wie viel Zeit verstrichen ist, bis ein Problem abgestellt und Folgeschritte zur Bereinigung sowie adäquate Präventivmaßnahmen für die Zukunft umgesetzt werden konnten. Bevor ein Problem als behoben deklariert werden kann, müssen beide Sequenzen vollständig adressiert sein.

Die zweite, weitreichendere Definition der MTTR legt ihr eine Identifikation und Behebung der für die Performance-Schwächen ursächlichen Probleme zugrunde. Explizit nicht gemeint sind dabei Quick-Fix- Lösungen, die zwar unmittelbar Abhilfe schaffen, aber eben kein erneutes Wiederauftreten verhindern.

Die MTTR ist und bleibt ein Mittel, ein statistischer Durchschnittswert. Wer sie effektiv nutzen will, muss auch ihre Grenzen verstehen.

Am meisten Aussagekraft besitzt die MTTR als Turnkey-Metric für Incident-Varianten (und Lösungswege) mit einer gewissen Ähnlichkeit. Im Kontext von Sonderfällen oder Ausreißern mit großen Divergenzen in punkto Lösungsdauer entsteht mit der MTTR allein hingegen ein eher verzerrtes Bild Ihres Response Frameworks.

Auch wird nur zu leicht übersehen, dass die MTTR den Faktor Zeit nicht situationsgenau berücksichtigt. Man mag das fast schon ein wenig ironisch finden, doch so wird bei ihr etwa nicht unterschieden zwischen Incidents zu Peak-Zeiten gegenüber solchen, die in weniger relevanten Momenten auftreten.

Weniger wichtig wird die MTTR bei alldem nicht, doch offenbart sich so nur allzu gut, wie tückisch es sein kann, auf nur eine Kennzahl zu schauen.

Zwei Best Practices haben sich bei der Mitigierung entsprechender Risiken äußerst bewährt gemacht:

1. Um ein korrektes, vollständiges und differenziertes Bild zu liefern, muss die MTTR im Verbund mit anderen Metrics betrachtet werden. Hier bietet sich zum Beispiel ein „Fehlerbudget“ an. Dieses könnte etwa definieren, dass eine Ausfalldauer von einer Minute zur Peak- Zeit so ins Gewicht fällt wie eine Downtime-Zeit von einer ganzen Stunde sonst. Gemeinsam mit der MTTR macht das Fehlerbudget Kosten und Auswirkungen von Downtime so weitaus greifbarer – ebenso wie auch Verbesserungen und Verschlechterungen in Sachen MTTR.
2. Anstrengungen rund um die MTTR verdienen eine nachhaltige Behebung von Incidents und bestmögliche Verfügbarkeit. Wird bei einem Anwendungsfehler nur dieser allein behoben, ohne eine Dauerlösung für den eigentlich ursächlichen Service oder die zugrunde liegende Infrastrukturkomponente herbeizuführen, geht dies am eigentlichen Problem vorbei. Der Aufwand für eine solche Dauerlösung ist freilich ungleich größer, aber für eine realistische MTTR umso wichtiger.

Eine Ausrichtung auf bestmögliche Verfügbarkeit hilft, Mängeln bei der Anwendungs-Performance mit langfristig angelegten Lösungsansätzen zu begegnen. Auch wenn Kosten und Implementierungsdauer so die von einem Quick Fix übersteigen: Wiederkehrende Fehler sollten entschieden vermieden, Problemstellungen im Kontext ihrer Bedeutung für das digitale Kundenerlebnis betrachtet werden.

Soweit die Grundregeln zur Einordnung der MTTR. Doch wie nutzen innovative DevOps-Teams sie in der Praxis zur Verbesserung ihrer Incident-Behebung? Und wie werden aus ersten Erfolgen dauerhafte Optimierungen?

Essenziell für DevOps-Teams sind primär diese Möglichkeiten:

1. Pro-aktive Anomalie-Erkennung, rasche Reaktion auf und Behebung von Incidents sowie auf zeitnahe Wiederherstellung getrimmte Workflows
2. Eine einheitliche Datenquelle mehrdimensionaler Informationen zu Performance und generellem Health-Status von Anwendungen und Infrastruktur mit Kontext für alle Bereiche des Gesamtsystems
3. Langfristig angelegte Servicezuverlässigkeit mit dem Credo „Einmal behoben, immer behoben“

Zugpferd dieser Möglichkeiten wiederum ist zwar Technologie, doch Ihre Strategie bedarf zudem auch unerschütterlicher Lösungsprozesse und der individuellen Kompetenz und Talente Ihres Teams.

Zu einem großen Ganzen verbinden sich diese Elemente schließlich in Ihrem Incident-Response-Prozess. Erfasst wird dabei nahtlos die gesamte Event-Sequenz von der Identifikation eines Performance-Problems bis hin zur Implementierung von Präventivmaßnahmen. Hieraus ergibt sich letztlich eine Komplettstrategie zur Reduzierung der MTTR, die auch bei weiterer Skalierung von Geschäft und Infrastruktur inkrementelle Verbesserungen ermöglicht.

Die Mutter aller Fragen für jedes Incident Response Framework lautet: Wie genau definiert sich ein Incident? Denn mit Entdeckung eines Incidents beginnt schließlich die MTTR-Uhr zu ticken.

New Relic definiert einen Incident als Problem im Hinblick auf die Performance einer Anwendung oder Infrastrukturkomponente, bei der die folgenden drei Kriterien erfüllt sind:

1. Hohe geschäftliche Relevanz. Bei Incidents werden Kunden in Mitleidenschaft gezogen, ob direkt oder indirekt.
2. Dringlichkeit. Incidents müssen sofort behoben werden. Zeitdruck kommt ins Spiel, die mit der Behebung betrauten Engineering-Teams agieren also anders als im normalen Tagesgeschäft.
3. Zusammenarbeit. Die Behebung von Incidents erfordert typischerweise das Zusammenwirken mehrerer Mitarbeiter, häufig abteilungsübergreifend. Konstellationen mit derart hoher Intensität bedürfen ganz spezieller Task Forces und sollten zudem finanziell bereits in den Budgets der involvierten Teams eingeplant sein.

Unsere 10 Best Practices basieren auf der Incident- Methodik von New Relic. Sie helfen Ihnen bei der Reduzierung Ihrer MTTR und vermitteln Ihrer Incident Response eine neue Qualität.

Ganz grundlegend benötigen Ihre Mitarbeiter zunächst eine klar nachvollziehbare Eskalationsfolge für Performance-Probleme: Wer ist zu kontaktieren? Was ist zu dokumentieren, welche Schritte wie in die Wege zu leiten?

Die meisten Unternehmen bauen dabei auf eine der drei folgenden Basisstrategien:

1. Ad hoc. Diese Variante kommt zumeist bei kleineren, jüngeren Unternehmen zum Einsatz. Bei Auftreten eines Incidents wird rasch der Kollege mit der größten Expertise im Hinblick auf das jeweilige System hinzugezogen und mit der Behebung betraut. Ein reichlich unstrukturiertes Vorgehen also – und ganz bewusst so gewählt.
2. Rigide. Hierbei handelt es sich um einen recht klassischen Ansatz zur Verwaltung von IT-Systemen, den man häufig bei größeren, traditionell organisierten Unternehmen antrifft. Für das Incident Management verantwortlich ist dabei zumeist direkt die IT-Abteilung, alle Beteiligten haben sich an strikte Prozessvorgaben und -abläufe zu halten. Die engmaschige Struktur ist hier jedoch keine Last, sondern Vorteil.
3. Fluide. Auf diese Vorgehensweise setzen viele moderne Unternehmen, insbesondere nach erfolgter digitaler Transformation. Die Reaktion auf einzelne Incidents ist exakt auf die situativen Gegebenheiten abgestimmt. Dank signifikanter abteilungsübergreifender Zusammenarbeit und hoher Schulungsdichte verläuft die Problemlösung höchst effizient. Das Gesamtkonzept basiert auf den Prinzipien des Lean Management rund um fortlaufendes Lernen bei Problemstellungen und Experimentieren mit Methoden, sodass sich die Prozesse stets weiterentwickeln.

Ein fluides Mantra wird zumeist von modernen Software-Unternehmen bevorzugt, sofern nicht spezifische Gründe für ein rigides oder Ad-hoc-Modell vorliegen. Mitarbeiter können so basierend auf ihrer Expertise optimal Aufgaben zugewiesen werden, was besonders bedeutsam ist in Situationen, deren Incident-Gemengelage zunächst noch nebulös ist.

Kristallisiert sich die exakte Zusammensetzung eines Performance-Problems genauer heraus, können mit einem fluiden Ansatz zudem rascher kreative Lösungen erarbeitet werden.

Bei New Relic hat jeder Incident-Response-Prozess seinen eigenen „Befehlshaber“. Er agiert als zentrale Koordinationsstelle und unterstützt im Gesamtverlauf alle involvierten Teams bei ihren Abwägungen in der Zusammenarbeit. Ebenso zeichnet er verantwortlich für die Steuerung der Engineering-Maßnahmen und Strukturen rund um die Incident-Kommunikation. Hierzu gehören auch externe Stellen wie Kunden – sowohl zum Informationsgewinn als auch zur Übermittlung von Updates im Hinblick auf die unternehmensseitig eingeleiteten Schritte. Über die Incident- Kommandostelle wird durchgängig gewährleistet, dass die richtigen Stellen adäquat über das Problem informiert sind.

In manchen Unternehmen obliegt die Leitung der Stelle mehr oder weniger permanent einem dedizierten Mitarbeiter, in anderen wechselt der Kommandostab in regelmäßigem Turnus. In der Organisationsstruktur von New Relic kommt diese Aufgabe üblicherweise dem Engineer zu, der einen Alert rund um einen Incident mit Auswirkungen auf den Kunden zuerst adressiert.

Zur Unterstützung der Kommandostelle kann es zudem von Vorteil sein, einen technischen Lead sowie einen Kommunikations-Lead zu benennen. Ersterer übernimmt dann für die Kommandoleitung ganz direkt die Definition spezifischer technischer Maßnahmen. Je nach Anzahl der betroffenen Systeme sind womöglich sogar mehrere technische Leads empfehlenswert. Es sollte sich hierbei um einen ausgewiesenen Experten für die jeweiligen Systeme handeln, denn seine Entscheidungen müssen die Problemlösung fundiert und rasch auf den Weg bringen und die damit verbundene MTTR möglichst gering halten.

Der Kommunikations-Lead gehört zumeist dem Kundenservice-Team an. Er versteht sich bestens darauf, Incidents im Kontext ihrer Auswirkungen auf Kunden zu evaluieren und die Kommandostelle entsprechend zu briefen. Die technischen Updates für die Kunden wiederum kanalisiert er in für sie verständliche und relevante Informationen rund um den internen Fortschritt.

Die Vorteile eines fluiden Modells lassen sich in Form von themenübergreifenden Schulungen für alle Engineering-Mitarbeiter am besten ausschöpfen: So können sie verschiedene Rollen und Funktionen im Incident-Response-Prozess übernehmen. Für bestimmte Systeme und Technologien werden sicher immer Spezialisten mit entsprechendem fachlichen Background notwendig sein. Doch sich allein auf ihre Kompetenz zu verlassen ist ein ebenso sicheres Rezept für Burnout und Fluktuation. Andere Team-Mitglieder sollten daher die Gelegenheit bekommen, zusätzliche Expertise aufzubauen, um so die Mehrzahl anfallender Fach- Incidents bewältigen zu können, während sich die Experten auf die komplexeren und dringenden Problemstellungen fokussieren. Umfangreiche Runbooks (siehe Best Practice #7) sind dabei eine ganz hervorragende Ressource, um technisches Fachwissen im Team zu erfassen und weiterzugeben.

Mit fachbereichsübergreifenden Schulungen und Wissenstransfers vermeiden Sie zudem eines der größten Risiken in der Incident Response – nämlich dass ein einzelner Mitarbeiter sämtliche intern verfügbare Fachkenntnis für ein bestimmtes System oder eine Technologie bündelt. Ist dieser Mitarbeiter nun erkrankt oder im Urlaub oder verlässt das Unternehmen abrupt, werden aus kritischen Systemen umgehend Mysterien, die kein anderer zu entschlüsseln weiß.

Prüfen Sie also Ihre Engineering-Teams auf eventuelle Abhängigkeit von Einzelnen. Nur dann können Sie auch Wissensredundanzen bilden, um solche Bottlenecks zu verhindern. Ganz genau so, wie Sie es auch sonst bei Systemressourcen tun.

Ist ein Problem nicht bekannt, kann man es auch nicht beheben. Eine Binsenweisheit und doch gewichtig zugleich, denn mit Transparenz für Anwendungen und Infrastruktur steht und fällt jeder Incident-Response- Prozess.

Man muss sich nur einmal eine Fehlerbehebung ohne Monitoring-Daten vorstellen: Ein Server mit einer kritischen Datenbank oder Anwendung fällt aus und der einzige „Datenpunkt“ zur Problemdiagnose findet sich in einer Power-LED an der Serverfront, die nun nicht mehr leuchtet. Das Response-Team wird sich nun in einem Troubleshooting-Ratespiel üben müssen und so wahrscheinlich ungewollt einen kostspieligen Reparaturvorgang mitsamt enorm hoher MTTR provozieren.

Ganz anders hingegen stellt sich ein Szenario dar, in dem Daten in Echtzeit über Anwendungen, Server und Infrastruktur abgerufen werden: Den Mitarbeitern liegen so belastbare Informationen zu Server-Load, Speicherauslastung, Reaktionszeiten sowie weitere Metrics vor, die sie zielführend nutzen können. Es wird also eine Faktengrundlage zur Evaluierung der Problemursache geschaffen, statt die Mitarbeiter in die Analyse-Dunkelkammer zu schicken.

Auch der praktische Nutzen einer Lösung kann mit Monitoring-Daten weiter quantifiziert, Diagnoseschritte rasch in Problemlösung konvertiert werden. Hieraus ergibt sich ein gehaltvoller Doppeleffekt, was Monitoring zum wohl schlagkräftigsten Mittel für effektive Fehlerbehebung und in der Folge bestmögliche MTTR macht.

In den vergangenen Jahren sind mehrere neue Technologien entstanden, dank derer sich Bereitschaftsteams künstliche Intelligenz (KI) und Algorithmen für maschinelles Lernen (ML) zunutze machen können. So sind sie in der Lage, mehr Incidents zu verhindern und entstehende schneller zu beheben.

Passend hierzu hat Gartner den Begriff „AIOps“ (kurz für „Artificial Intelligence for IT Operations“) geprägt. AIOps setzen auf ML-Algorithmen, um mit Software generierte Daten zu analysieren und potenzielle Probleme zu antizipieren, ihre Fehlerursachen zu identifizieren und sie dann mittels automatisierter Abläufe zu beseitigen.

AIOps übermitteln weitere wertvolle Incident- Informationen zusätzlich zu Ihren Telemetriedaten, bilden eine hervorragende Ergänzung für Ihr Monitoring und rüsten Sie so bestmöglich für Fehlerbehebung und Incident Resolution. Innovativen DevOps- und SRE-Teams gelingt es mit AIOps, rascher auf Incidents zu reagieren und ihre MTTR zu verringern.

AIOps machen sich primär auf vier Weisen bezahlt:

1. Pro-aktive Erkennung von Anomalien, noch bevor sich ein Problem in der Produktion bemerkbar machen, Kundenerlebnis oder Service-Level-Ziele beeinträchtigen kann
2. Bessere Alert-Relevanz dank Korrelation von Incidents und Anreicherung um Metadaten und Kontext für optimale Incident-Priorisierung
3. Intelligente Alert- und Eskalationsmechanismen für automatisches Routing von Incidents zu den qualifiziertesten Mitarbeitern bzw. Teams
4. Automatisierte Wiederherstellung anhand von Behebungs-Workflows zur Reduzierung der MTTR

Monitoring-Tools gibt es inzwischen zuhauf, Ähnliches gilt für die von ihnen ausgegebenen Alerts. Die schiere Schwemme an Informationen kann der Entwicklung eines zielführenden Plans nur allzu leicht im Wege stehen. Eine programmatisch orientierte Alert-Logik ist somit unabdingbar.

Ein praktischer erster Schritt bei ihrer Konzipierung besteht darin, Schwellenwerte für Service-Level- Indikatoren (SLIs) zu definieren. Dabei handelt es sich um einfache Metrics bzw. maximal zulässige Werte, die mit automatisierten Monitoring-Tools konstant überprüft werden können. Sind sie erreicht, ist dies gleichbedeutend mit gewichtigeren Problemen, die adressiert werden müssen. Ein Beispiel für die Formulierung eines solchen Schwellenwerts: „Wenn der Throughput unter Grenzwert X fällt, liegt irgendwo im System ein Fehler vor.“ Oder: „Ist die Latenz länger als Y Minuten erhöht, ist eine Prüfung notwendig.” Es soll also quantifiziert zum Ausdruck gebracht werden, wie es um den Health-Status des Systems bestellt ist.

Selbst wenn ein Team nicht mit allen technischen Einzelheiten einer Kundendatenbank vertraut ist, kann es so anhand der Schwellenwerte in der Entstehung begriffene Probleme identifizieren. Erreicht ein System seine SLI-Grenze, wird für das Engineering-Team ein Alert ausgegeben, wodurch dieses den potenziellen Incident angehen kann, bevor er sich seinen Weg in Kunden-Tweets und verärgerte Anrufe bahnt. Weiterhin wichtig bleibt es natürlich, die Grenzwerte sauber auszuloten, damit keine Alert-Fluten über Ihre Teams hereinbrechen und es zu keinen unnötigen Firedrills kommt.

Auch sollte ein Tool mit Funktionen zur Alert-Unterdrückung gewählt werden, um Benachrichtigungen bei geplanten Systemunterbrechungen wie Wartungen, Deployments und Testing Cycles gezielt zu deaktivieren.

Ihre Incident-Responses-Prozesse sowie Ihre Monitoringund Alert-Systematik wollen vollumfänglich dokumentiert werden. Erfassen Sie sie in sogenannten Runbooks: Dabei handelt es sich um Dokumentation, in der ein Engineer im Bereitschaftsdienst schnell nachschlagen kann, was bei Auftreten eines bestimmten Problems zu tun ist.

Das ansonsten nur in den Köpfen einzelner Mitarbeiter vorhandene Wissen zu ganz spezifischen Szenarien findet sich so kompakt konsolidiert in einem für alle nutzbaren Dokument wieder. Mit Runbooks reduzieren Sie nicht nur Ihre MTTR, sondern schulen auch neue Team-Mitglieder viel effizienter und sichern sich stärker ab gegen Brain Drain, wenn besonders arrivierte Kollegen oder solche mit Nischenexpertise das Unternehmen verlassen.

Ein Mittel für jedes potenzielle Szenario oder Allzweckwaffe für jedes Problem ist ein Runbook aber freilich nicht. Schließlich existieren dafür einfach zu viele Variablen und zu viele Konstellationen mit ganz individuellen Parametern. Einen hervorragenden Startpunkt bietet es aber allemal und spart Ihren Teams so Zeit bei der Bewältigung bekannter Probleme, die es dann auf die Lösung seiner größten und komplexesten Herausforderungen verwenden kann.

Ob Post Mortem, Incident-Review oder Day-After- Analyse – wer seine MTTR nachhaltig reduzieren möchte, für den ist auch eine disziplinierte Rundumbetrachtung aller Faktoren im Nachgang unumgänglich. Was genau ist geschehen? Welche Verkettung von Zusammenhängen hat das Problem ausgelöst und was war der Auslöser? Dies sind nur einige der wichtigsten Fragen, die bei der Entwicklung einer Präventivstrategie beantwortet werden wollen.

Und um die Konzipierung einer solchen, nicht um ein Konzert aus Schuldzuweisungen, geht es schließlich. Ebenfalls äußerst nützlich: Prozesse nach dem Schema „Don't Repeat Incidents“ (DRI). Vereinfacht ausgedrückt geht es bei einem DRI-Modell darum, jedweder Arbeit rund um einen Service temporär auszusetzen, bis bestehende Probleme ausgeräumt oder mitigiert worden sind. Dabei unterstreicht es nochmals die gemeinsame Verpflichtung, Probleme nicht mit Quick Fix, sondern nachhaltig zu lösen, und rundet die Fehlerbehebung ab. Ebenso manifestiert es das Credo, dass Qualität Gebot ist und nicht Option, weiter im Unternehmen.

Chaos Engineering beschreibt einen Vorgang, bei dem verschiedene Fehler in Ihre Systeme eingespeist werden – natürlich höchst kontrolliert – um zu testen, wie fehlerresistent sie wirklich sind. Mit Chaos Engineering können äußerst entscheidende Fragestellungen wie etwa die folgenden untersucht werden:

• Kam es zu den erwarteten Fehlerverkettungen?
• Konnten diese umgehend adressiert werden?
• Was konnten wir über die Monitoring-Daten ablesen?
• Wie lange hat es gedauert, bis der Service wieder verfügbar war?

Chaos Engineering hilft Ihrem Unternehmen in verschiedener Weise weiter. Zum einen lernen Ihre Teams, wo in Sachen Verfügbarkeit und Fehleranfälligkeit Verbesserungsmöglichkeiten bestehen. Es bietet aber hervorragende Gelegenheiten für handfeste Incident- Generalproben, bei denen Sie Ihre Prozesse, Eskalationsmechanismen, Richtlinien, Monitoring und Alert-Logik auf Herz und Nieren prüfen können. Reale Incident-Response-Szenarien können so viel abgeklärter bewältigt werden, was derartige Testläufe der MTTR ganz direkt zuträglich macht.

In der Hitze des Gefechts mag so mancher Schnellschuss durchaus attraktiv und effizient erscheinen. Im Nachhinein stellt sich dann nur leider allzu oft heraus, dass damit zwar das vorliegende Problem komplett isoliert behoben wurde, die MTTR schon bei leicht anderen Fällen aber immer noch unverändert ist. So hat sich an der Gesamt-MTTR als Mittelwert dann auch kaum etwas getan. Schlimmer noch: Einem Quick Fix entspringt womöglich auch ein signifikantes und vor allem ursprünglich noch vermeidbares Problem. Langfristig gesehen sollten die Ursachen eines Performance-Problems also stets direkt adressiert werden.

Im Verbund führen Sie diese 10 Best Practices schließlich hin zu einer auf Incident Response und Verfügbarkeit basierenden MTTR-Methodik. Technologischer Beschleuniger und Lösungsfundament für diese Strategie zugleich ist dabei die New Relic Observability-Plattform.

Sie bietet Ihnen unter anderem Features für Monitoring, AIOps, Alert-Definition und Incident-Diagnose, die Ihre Fehlerbehebung schneller, smarter und effizienter machen. In der Folge verzeichnen Sie signifikante Verbesserungen bei Ihrer Lösungszeit, die sich in kürzerer MTTR und Zugewinnen bei anderen Performance Metrics niederschlägt.

Unser umfassendes AIOps-Lösungsspektrum haben wir in New Relic AI gebündelt. Mit ihm erhalten Ihre Teams innovative ML- und Automatisierungstechnologien, die es ihnen ermöglichen, Probleme rascher zu diagnostizieren und zu beheben. New Relic AI sorgt zudem für eine direktere Identifikation von Fehlern: Anomalien in verschiedenen Tools Ihres Tech-Stacks werden automatisch erkannt und mitsamt Monitoring- Empfehlungen für ähnliche Zusammenhänge ausgegeben. All dies etwa via Slack, damit Sie Incidents direkt im Team angehen können.

Bei der reinen Erkennung von Problemen wollten wir es jedoch nicht belassen. New Relic AI nutzt einen umfangreichen Knowledge-Corpus. Dieser wird anhand Ihrer spezifischen Informationen sukzessive erweitert und verfeinert, damit für Sie nicht relevante Alerts nicht weiter ausgegeben werden. New Relic AI korreliert zudem ähnliche Incidents und reichert diese um wertvolle Metadaten und Kontext an, sodass Sie Fehler rascher diagnostizieren können. Weiter erhalten Sie hilfreiche Kontextdetails zu bestehenden Problemen, so unter anderem eine Einordnung im Rahmen der vier „goldenen Signale des Monitoring“ (Latenz, Traffic, Fehler und Sättigung) sowie aus Ihrer Umgebung korrelierte Indikatoren. Auch direkte Empfehlungen rund um adäquate interne Alert-Empfängergruppen für bestimmte Incidents sind möglich.

Wichtiger Kernaspekt Ihrer Strategie muss es sein, stets die richtigen Mitarbeiter zu informieren, dies rasch und effizient mit präzisen und konkret nutzbaren Informationen. Die programmatisch orientierte Alert-Logik von New Relic macht dies für den gesamten Stack und alle Mitarbeiter möglich.

So sind Alerts etwa direkt auf mit der New Relic Query Language (NRQL) ermittelte Anfrage-Ergebnisse abstimmbar. Anhand dieser können sie beispielsweise für spezifische Systemabrufe mit hohem Workload priorisiert werden. Performance-Schwächen an diesen Punkten dienen dann als Frühindikatoren für Probleme, bevor diese sich in Anwendungen in der Produktionsumgebung bemerkbar machen – und somit zu Downtime, Beschwerden und Umsatzeinbußen führen können.

New Relic Alerts beugt der gerade bei Incident- Response-Teams für Microservice-Umgebungen immer ausgeprägteren Alert-Schwemme vor. Flexible Alert- Richtlinien und Optionen für Benachrichtigungskanäle sorgen für bessere Kontrolle über Incident-Daten und minimieren das Aufkommen irrelevanter Alerts.

 Mit dem Monitoring des Systems in seiner Gesamtheit eröffnet New Relic Synthetics den Blick auf einen für viele DevOps-Teams ansonsten blinden Fleck. So erhalten sie verschiedenste Möglichkeiten zur Messung der Endpunkt-Performance: von einfachen Ping- Kommandos bis hin zu Monitoring-Features mit Detailtiefe und Simulation komplexer Szenarien via Skript. Synthetics unterstützt ebenso containerisierte Private Minions zum Monitoring von internen Seiten und zur Erweiterung der geografischen Abdeckung – ein Plus an Sicherheit, Cloud-Funktionalität und Flexibilität.

In vielen Fällen ist für eine rasche und erfolgreiche Fehlerbehebung eine genaue Kenntnis der Benutzerperspektive Gold wert. Es gilt, zu verstehen, welche Auswirkungen ein Incident auf Erlebnis und Interaktionsmöglichkeiten der Kunden hat. New Relic Browser unterstützt Sie dabei mittels detaillierten Einblicken in die Nutzungsmodelle Ihrer Anwendung oder Website, weit über das Themenspektrum der Seitenladezeit hinaus. Vielmehr erhalten Sie Einsicht in den gesamten Lebenszyklus einer Seite, von Daten zur Session Performance und AJAX-Anfragen bis hin zu JavaScript-Fehlern und Single-Page- Anwendungsstrukturen.

Bei Diagnose und Behebung von Incidents erhalten Ihre Engineers zudem dank Browser Klarheit in punkto geografischer Relevanz: Performance Metrics und Apdex-Scores etwa werden nach Region oder Staat gefiltert. Whitelists können auf URL- und Segmentebene, Block- und Monitoring-Listen domainspezifisch verwaltet werden.

Unsere modernen, verteilten Microservices-Umgebungen werden immer komplexer. Ein Preis, den die Vorteile von Microservices durchaus aufzuwiegen vermögen. Nichtsdestotrotz aber auch ein nicht zu unterschätzendes Hindernis, das bei der Implementierung von dynamischen, effizienten Incident-Resolution-Prozessen überwunden werden muss.

Gelingen kann dies mit dem New Relic Kubernetes Cluster Explorer, der Engineering-Teams auch für höchst komplexe, signifikant skalierte Systeme Transparenz verschafft. Als Teil einer mehrdimensionalen Darstellung eines Kubernetes-Clusters können Namespaces, Deployments, Nodes, Pods, Container und Anwendungen genau betrachtet werden. Daten und Metadaten zu diesen Elementen sind direkt abrufbar, eine Analyse ihrer Zusammenhänge über enorm intuitive Virtualisierungstools unmittelbar möglich.

Alle Stakeholder lesen den Health-Status eines Clusters über ein und denselben Referenzpunkt ab, nutzen diesen ebenso für die Fehlerbehebung. Dabei navigieren sie nahtlos zwischen allgemeinen Übersichten und Detailperspektiven. Dies beschleunigt die Fehlerbehebung, baut Informationsdivergenzen und Kommunikationsproblemen vor.

Mit den Features für Distributed Tracing in New Relic APM wird weitere Komplexität abgebaut. In diesem Fall rund um die Probleme, die beim Ursachen-Tracing von Latenz und anderen Problemen in verteilten Anwendungsarchitekturen auftreten. Über Distributed Tracing kann der Pfad einer Anfrage über komplexe Systeme hinweg nachverfolgt werden. Ebenso werden die Latenz der Komponenten entlang dieses Pfads dokumentiert und etwaige Bottlenecks ausgemacht.

Distributed Tracing setzt auf die intelligenten Features der New Relic Plattform: Tools wie Anomalous Span Detection, Trace Charts und individuell definierbare Abfragen von Distributed-Trace-Daten. Das Ergebnis: Sie isolieren, diagnostizieren und beheben Probleme rasch und mit Gewissheit.

Moderne Anwendungsarchitekturen machen es gar nicht so einfach, die richtige MTTR-Methodik zu finden. Hier setzt die New Relic Plattform an: Mit ihren innovativen Technologien kommen Sie bei der Gestaltung Ihrer Incident-Resolution-Prozesse nicht nur schneller ans Ziel, sondern auch mit einem robusteren, nachhaltigeren Ergebnis.

Bei aller Wichtigkeit darf nicht vergessen werden, dass die MTTR eine zur Quantifizierung der Incident Response wichtige Metric ist, jedoch nicht die einzige. Sie zu minimieren ist ein absolut erstrebenswertes Ziel, doch nicht um jeden Preis: Auch der dafür anfallende Aufwand will wohl geplant, die Ergebnisausrichtung stets langfristig orientiert sein.

Technologien wie New Relic liefern dabei einen wertvollen Echtzeit-Datenstrom. Ergänzt von präzise kalibrierten Alert-Richtlinien unterstützen sie Ihren Incident-Management-Prozess umfassend und vermitteln Ihnen einen Blueprint, mit dem Sie Incidents systematisch und effizient beheben. Sie ebnen Ihnen den Weg, um Ihre MTTR langfristig zu reduzieren und damit ebenso dauerhafte Verbesserungen Ihrer Anwendungsverfügbarkeit zu erlangen.

Testen Sie New Relic One und gestalten Sie bessere, stabilere Software-Erlebnisse. Informieren Sie sich hier.