4 Root-Cause-Analysis-Tipps: Wie Ursachenanalyse besser geht

Kommt es zu einem größeren Systemausfall oder umfassenderen Performance-Problemen, kümmert sich die IT-Abteilung darum, dass alle Services so schnell wie möglich wieder laufen und die Ursache für das zugrundeliegende Problem gefunden wird. Dazu dient im Regelfall eine Root Cause Analysis (RCA, auch Ursachenanalyse). Eine echte Herausforderung sind dabei allerdings weniger die großangelegten Ausfälle, sondern vielmehr sporadisch auftretende Probleme. Diese betreffen oft nur eine kleine Benutzergruppe und sind selten sowie von kurzer Dauer. Dennoch können sie extrem schädliche Auswirkungen haben, wenn dabei kritische Prozesse wichtiger Endbenutzer beeinträchtigt werden. Das könnte sich etwa in folgenden Szenarien manifestieren:

• Ein Benutzer erstellt eine komplexe Webseiten- oder Datenbankabfrage, die Systemressourcen bindet und daraufhin alle anderen Suchaktivitäten behindert.
• Eine Transaktion blockiert Systemressourcen und verursacht immer dann Performance-Probleme, wenn sie von mehreren Benutzern gleichzeitig durchgeführt wird.
• Ein nicht mehr ganz frisches Kabel, eine defekte Netzwerkkarte oder ein anderes Device führt zu Paketverlusten – die Auswirkungen sind für die Endbenutzer allerdings nur in Spitzenlastzeiten spürbar.
• Datenbank-Backup-Prozeduren nehmen mit wachsenden Datenmengen mehr Zeit in Anspruch, was bei einer Teilmenge der Endbenutzer zu Performance-Einbußen führt.
• Der Service eines Drittanbieters weist längere Antwortzeiten als üblich aus und mindert so die Performance von Applikationen, die von ihm abhängig sind.

Was in diesen Situationen hilft: Ein Prozess für Site Reliability Engineers (SREs), Softwareentwickler und IT-Betriebsspezialisten, um auch Probleme, die besonders diffizil zu identifizieren sind, mit Hilfe einer Root-Cause-Analyse möglichst schnell zu Tage zu fördern.

Um das umzusetzen und Ihre Root-Cause-Analysen zielführender zu gestalten, sollten Sie sich die folgenden vier Schritte verinnerlichen.

1. Observability als Produkt managen

Die Observability von Microservices, Daten-Pipelines, Applikationen und intern entwickelter Software zu optimieren, ist ein Best Practice aus dem DevOps-Bereich. Dabei bestehte eine wesentliche Herausforderung für Unternehmen darin, Datenstandards so zu etablieren und zu verbessern, dass die resultierende Konsistenz die Benutzerfreundlichkeit erhöht, wenn eine Root-Cause-Analyse erforderlich ist.

Nick Heudecker, Senior Director of Market Strategy and Competitive Intelligence beim Datenspezialisten Cribl, empfiehlt bei der Standardisierung noch einen Schritt weiter zu gehen – und Applikations-Logs als Datenprodukt zu behandeln, das vom IT-Betrieb konsumiert wird: “Sicherzustellen, dass die Telemetriedaten der Anwendungen von nachgelagerten Systemen verarbeitet werden können, ist der entscheidende Faktor, um App-Performance-Probleme zu identifizieren. Das erfordert strukturierte Protokolle, die mit dem richtigen Kontext angereichert sind und den jeweils relevanten Plattformen zur Verfügung stehen. Das klingt zunächst simpel, allerdings besteht die Herausforderung dabei darin, dass die Entwickler, die die Logs erstellen, oft nicht diejenigen sind, die diese auf operativer Seite nutzen.”

Standardisierung ist eine Möglichkeit, um Observability zum Produkt zu machen und für betriebliche Anforderungen zu vereinfachen. Eine andere bewährte DevOps-Methode ist es, sich mit dem Risikomanagement-Team über sensible Daten und die Richtlinien zu deren Aufbewahrung zu beraten. Dabei sollten DevOps-Teams auch Schulungsmaßnahmen für SREs sowie SOC- und NOC-Mitarbeiter ergreifen, um ihnen den Zusammenhang zwischen der Software und den Observability-Daten in Log-Files und anderen Repositories zu verdeutlichen.

Insbesondere große Unternehmen, die eine Vielzahl von Applikationen und Microservices entwickeln, sollten nach Meinung von Asaf Yigal, Mitbegründer und CTO beim Softwareunternehmen Logz.io, mehr tun als nur Observability-Standards einzuziehen: “Eine gezielte Echtzeit-Datenanalyse in der Observability-Praxis ermöglicht es den Engineers, Daten proaktiv abzufragen und die Erkenntnisse zu gewinnen, die zur Lösung der maßgeblichen Probleme erforderlich sind. Um zielführende Root-Cause-Analysen zu fahren und Leistungsdefizite in modernen, Microservice-lastigen Systemen zu beheben, braucht es eine effiziente Lösung, die Daten automatisiert durchforstet und proaktive statt reaktive Maßnahmen ermöglicht.”

2. Top-Down- und Bottom-Up-Analysen planen

Eine langsame Query mit simplen Datenbank-Protokolldateien aufzutun, ist relativ einfach. Die Ursache für den Slowdown zu identifizieren ist schon komplexer, wenn die Leistung nur dann sinkt, wenn die Datenbank unter Last steht und mehrere Abfragen um die selben Systemressourcen konkurrieren. Grant Fritchey, DevOps Advocate bei Redgate Software, hat ein Beispiel für eine solche Query auf Lager, die mit durchschnittlich 6ms noch relativ flott lief: “Aus Performance-Sicht handelte es sich eigentlich um eine unbedeutende Query – bis klar wurde, das sie mehrere Tausend mal pro Minute gestellt wurde. Damit war sie selbst mit 6 ms noch nicht schnell genug. Das verdeutlicht, wie wichtig es ist, Observability- und Datenbank-Monitoring-Tools zu integrieren, um ein ganzheitliches und differenziertes Verständnis von der Systemleistung zu erhalten.”

Für eine effektive Root Cause Analysis sind Monitoring Tools unerlässlich, die mehr können als nur einfache Warnungen bei Ausfällen oder größeren Performance-Problemen zu liefern. Operations-Spezialisten und SREs brauchen Indikatoren, die darüber Auskunft geben, wenn sich die Performance außerhalb der Norm bewegt – und Top-Down-Analyse-Tools, um verdächtige Aktivitäten untersuchen zu können. Die Werkzeuge sollten darüber hinaus dazu beitragen, Leistungsausreißer zu identifizieren, insbesondere, wenn es um hochvolumige oder leistungsschwache Aktivitäten handelt. Das trägt auch dazu bei, End-User-Experiences zu isolieren, um Root-Cause-Analysen auf Benutzerebene zu realisieren.

3. Netzwerkprobleme identifizieren/ausschließen

Performance-Probleme lassen sich leicht auf Netzwerk und Infrastruktur schieben, insbesondere, wenn diese in den Verantwortungsbereich von Anbietern oder anderen Abteilungen fallen. Diese Art von Ausreden war vor dem DevOps-Zeitalter an der Tagesordnung – bis sich im Unternehmensumfeld schließlich die Erkenntnis durchsetzen konnte, dass Agilität und betriebliche Resilienz Themen für die gesamte Belegschaft sind. Ganz ausgestorben ist der Verweis auf einen Sündenbock allerdings dennoch nicht, wie Nicolas Vibert, Netzwerkspezialist beim Cloud-Unternehmen Isovalent, weiß: “Bei Problemen mit der Anwendungs-Performance ist fast immer das Netzwerk schuld. Was auch daran liegt, dass das am schwersten zu beweisen ist.”

Komplexe Netzwerkprobleme zu identifizieren und zu beheben, ist eine noch größere Challenge, wenn es darum geht, Microservices oder Applikationen aufzubauen, die mit Drittanbieter-Systemen, IoT-Datenströmen und anderen verteilten Echtzeitsystemen integrieren. Für den IT-Betrieb bedeutet das, Netzwerke zu überwachen, die Ergebnisse mit Performance-Problemen auf Anwendungsebene in Beziehung zu setzen und effizientere Netzwerk-Ursachenanalysen zu fahren.

Eileen Haggerty, AVP of Product and Solutions Marketing beim Softwareanbieter Netscout, spezifiziert: “Die integrierte Paketüberwachung in virtualisierten Umgebungen bietet konsistente Echtzeiteinblicke in den Datenverkehr und die Anwendungsleistung. Aber jede Domäne und jeder Standort muss gleichermaßen intelligent, transparent und analysierbar sein – unabhängig davon, wo Workloads, Applikationen und Services ausgeführt werden. Ein konsistenter Messansatz in jeder Hosting-Umgebung ermöglicht eine einfachere und schnellere Root Cause Analysis.”

4. Kollaborieren über Root Causes

Wenn sporadische Performance-Probleme gelöst werden sollen, müssen Informationen aus verschiedenen Observability-Tools und -Quellen korreliert werden. Das erfordert wiederum ein interdisziplinär aufgestelltes Team, das sein Wissen intern austauscht und effizient zusammenarbeitet, wenn eine Root-Cause-Analyse erforderlich ist. Das weiß Chris Hendrich, stellvertretender CTO beim Cloud-Serviceanbieter Sada, aus eigener Erfahrung: “Ich konnte in vielen größeren, gut etablierten Unternehmen einen bemerkenswerten Mangel an Anwendungsdokumentation und eine stark eingeschränkte Kommunikation zwischen den Teams feststellen. Silos aufzubrechen, kann Unternehmen dabei unterstützen, ihre Fähigkeit in Sachen Ursachenanalyse zu optimieren.”

Es kommt jedoch auch darauf an, wie die Teams nach der Root Cause suchen, wie Liz Fiong-Jones, Field CTO beim Observability-Anbieter Honeycomb, unterstreicht: “Direkt die Nadel aus dem Heuhaufen zu picken, ist gar nicht notwendig. Es kommt darauf an, die verschiedenen Teile des Haufens, in denen sich die Nadel befinden könnte, eingrenzen zu können. Bei dieser ‘Filterarbeit' können die richtigen Tools unterstützen.” (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.