Fehler-Ursachen-Analyse: 4 Tipps zur schnelleren Behebung von Fehlern

Stellen Sie sich Folgendes vor: Sie und Ihr Team arbeiten rund um die Uhr an der Fertigstellung der nächsten Hauptversion Ihres Softwareprodukts. Sie entwickeln neue Funktionen in einem guten Tempo. Das Team behebt Fehler, sobald die Qualitätssicherung sie meldet. Die Modultests sind alle im grünen Bereich. Nachdem die Anwendung durch eine umfassendere Reihe von Tests grünes Licht erhalten hat, ist es an der Zeit, sie zu veröffentlichen. Und dann – bumm! Sobald sie in die Produktionsumgebung gelangt, stürzt die App spektakulär ab. Was ist schief gelaufen?

Wie sich herausstellte, waren die Testumgebungen nicht annähernd so nah an der Produktionsumgebung, wie Sie ursprünglich dachten. Es wurden Änderungen an der Infrastruktur der Umgebung vorgenommen, ohne dass dies in irgendeiner Form dokumentiert wurde. Das Ergebnis war, dass die Umgebungen langsam auseinanderdrifteten.

Als Fachleute in der Technologiebranche verbringen wir einen beträchtlichen Teil unserer Zeit mit der Problembehandlung. Und ja, wir verbringen auch Zeit damit, Fehler zu beheben – aber man kann nicht etwas reparieren, wenn man nicht weiß, was damit nicht stimmt. Jeder Softwareentwickler, der schon einmal Stunden vor einem Debugger verbracht hat, wird Ihnen bestätigen, dass der wirklich schwierige Teil darin besteht, den Fehler zu finden. Sobald Sie wissen, was das Problem ist, kann die Behebung des Problems sogar ganz banal sein.

Wenn Sie also erfahren, wie Sie Fehler schneller beheben können, ist das eine der besten Investitionen, die Sie als Softwareentwickler oder IT-Mitarbeiter im Allgemeinen tätigen können.

Kommen wir nun zu der Frage, wie wir die Probleme schnell finden und schneller beheben können.

Fehler-Ursachen-Analyse: Was ist das und warum sollten Sie sich dafür interessieren?

Bei der Fehler-Ursachen-Analyse (englisch Root Cause Analysis, kurz RCA) handelt es sich um eine spezielle Technik, die Sie bei der Problembehandlung einsetzen können. Mit dieser Technik analysieren Sie das vorliegende Problem anhand einer bestimmten Reihe von Schritten, um die Hauptursache des Problems zu ermitteln. RCA basiert auf dem Grundsatz, dass es nicht sinnvoll ist, sich um die Symptome eines Problems zu kümmern, während die Ursachen ignoriert werden.

Durch die Anwendung von RCA können Sie verstehen, was passiert ist. Oft ist es nicht möglich, sich allein durch die Beobachtung der Symptome ein vollständiges Bild zu machen. Aber die Feststellung, was passiert ist, ist nur der erste Schritt – man muss dann weitergehen und den Grund für das Geschehen aufdecken. Mit diesem Wissen ausgestattet, ist es an der Zeit, es in die Praxis umzusetzen, indem man einen Plan oder eine Strategie formuliert, um die Wahrscheinlichkeit eines erneuten Auftretens des Problems zu verringern.

Nachdem das „Was“ und das „Warum“ geklärt sind, finden Sie hier vier Tipps, die Ihnen helfen, dank RCA weniger Probleme zu haben.

Verwenden Sie die Quietscheentchen-Methode
Ja, ich meine es ernst, die Quietscheentchen-Methode. Das habe ich mir nicht ausgedacht. Sie wird auch Quietscheentchen-Debugging genannt und hat wahrscheinlich noch mehr Namen. Sie besteht darin, einem Quietscheentchen Ihr Problem zu erklären. Sie haben kein Quietscheentchen? Kein Problem! Sie können jeden Gegenstand verwenden, den Sie gerade zur Hand haben. Oder Sie könnten sogar mit einem Menschen sprechen!

Worum geht es also bei der Quietscheentchen-Methode wirklich? Dieser Ansatz beruht auf dem beobachteten Effekt, dass man sich selbst dazu zwingt, seine Gedanken zu ordnen, wenn man jemandem etwas erklärt. Unsere Gedankengänge sind oft chaotisch oder ungeordnet. Wenn wir vor der Aufgabe stehen, sie jemandem erklären zu müssen, haben wir keine andere Wahl, als sie irgendwie zu ordnen. Jeff Atwood, der Mitbegründer der beliebten Frage-und-Antwort-Website Stack Overflow, berichtet, wie oft ihm ein Softwareentwickler erzählt hat, dass er auf der Website eine neue Frage verfasst hat, währenddessen selbst auf die Antwort gekommen ist und die Frage dann nie abgeschickt hat!

Reicht der Quietscheentchen-Ansatz aus, um jedes Problem zu beheben? Nein, natürlich nicht. Das kann der Fall sein, aber oft ist es nur der erste Schritt einer umfassenderen Strategie.

Haben Sie Sorge, dass die Leute Sie für etwas seltsam halten, weil Sie mit Gegenständen sprechen? Nun, die Sache ist die, dass die ganze Idee mit dem Quietscheentchen eher ein Witz ist. Es ist eine alberne und einprägsame Figur, die nicht allzu ernst genommen werden sollte. Wichtig ist, dass Sie sich zwingen, die Gedanken in Ihrem Kopf in geordneter Weise auszudrücken und das Problem so klar wie möglich zu erklären.

Sie können die folgenden Methoden anwenden:
1. Schreiben Sie eine Stack Overflow-Frage. Oder Sie können so tun, als ob Sie eine Stack Overflow-Frage schreiben würden, aber stattdessen in Notepad schreiben.
2. Reichen Sie einen detaillierten Fehlerbericht ein. Irgendjemand muss das wahrscheinlich sowieso tun, warum also nicht zwei Fliegen mit einer Klappe schlagen?
3. Gehen Sie zum Arbeitsplatz/Büro eines Kollegen und reden Sie ein paar Minuten mit ihm. Natürlich nur, wenn Ihr Kollege damit einverstanden ist, stören Sie Ihre Kollegen nicht unnötig.


Sammeln Sie viele Protokolldaten (und durchsuchen Sie sie effizient)

Wenn Sie das Problem erfolgreich auf eine einleuchtende Art und Weise erklärt haben, aber immer noch nicht zum Kern des Problems vordringen können, dann müssen Sie weiter gehen. Jetzt gilt es, Daten über das Problem zu sammeln und daraus Erkenntnisse zu gewinnen.

Protokollierung und Überwachung können hier sehr hilfreich sein – Absturzprotokolle, Anwendungs- und Serverprotokolle und so weiter. Sie müssen Beweise dafür sammeln, dass das Problem aufgetreten ist, aber nach Möglichkeit auch herausfinden, wie lange es schon besteht und wie häufig es auftritt.

Das ist aber noch nicht alles. Es ist wichtig, viele Daten zu sammeln, aber all diese Daten nützen nicht viel, wenn Sie die benötigten Informationen nicht schnell genug finden können. Die Suche nach der sprichwörtlichen Nadel im Heuhaufen macht weder Spaß noch ist sie besonders produktiv.

Deshalb müssen Sie Tools einsetzen, die es Ihnen ermöglichen, alle gesammelten Protokolldaten in Echtzeit zu durchsuchen und zu analysieren und sie in wertvolle Erkenntnisse umzuwandeln, die Sie zur schnelleren Diagnose und Lösung von Problemen nutzen können.


Wenden Sie die 5-W-Methode an
Nachdem Sie Informationen gesammelt haben, ist es an der Zeit, diese zu nutzen, indem Sie die Kausalfaktoren ermitteln. Mit „Kausalfaktor“ ist hier die unmittelbare Ursache des vorliegenden Problems gemeint. Sie sollten nicht einfach einen Kausalfaktor identifizieren und dann aufhören. Sie müssen weiter gehen. Eine der bekanntesten Techniken dafür ist die 5-W-Methode.

Sie besteht darin, die Frage „Warum?“ iterativ zu stellen, bis man zum Kern des Problems vorstößt. Lassen Sie uns ein kurzes Beispiel betrachten:

Problem: Auf der Website wird Fehler 500 angezeigt.
1. Warum? Weil die Weiterleitungskomponente des Web-Frameworks eine Fehlfunktion aufweist.
2. Warum? Weil sie eine andere Komponente benötigt, die ihrerseits eine Fehlfunktion aufweist.
3. Warum? Weil diese Komponente des Web-Frameworks die intl-Erweiterung benötigt, die nicht funktioniert.
4. Warum? Weil sie versehentlich deaktiviert wurde, nachdem die Serversoftware aktualisiert wurde.

Wie Sie sehen können, ist die Zahl fünf nur ein Beispiel. Es ist möglich, mit weniger Schritten zum eigentlichen Problem zu gelangen, vielleicht brauchen Sie aber auch noch mehr.

Die 5-W-Methode ist alles andere als perfekt. Sie hat ihren Anteil an Kritik erhalten, und sie hat sicherlich ihre Grenzen. Aber sie kann nützlich sein, wenn es darum geht, Entwickler zu ermutigen, weiter nach der Ursache des Problems zu suchen, anstatt beim ersten Anzeichen einer Lösung aufzuhören.


Holen Sie sich ein zweites Paar Augen
Ein Verfahren, das ich in meiner Karriere als Softwareentwickler zu schätzen gelernt habe, sind Code-Reviews. Es ist schon erstaunlich, wie die einfache Tatsache, dass eine andere, unvoreingenommene Person einen Blick auf Ihren Code wirft, so viele Probleme aufdecken kann, die Sie vorher nicht erkennen konnten. Mit der Zeit wird man sich durch die bloße Erwartung, dass eine andere Person einen Blick auf den Code wirft, bewusster. Man beginnt, ihm mehr Aufmerksamkeit zu widmen, als man es sonst tun würde.

Empfehle ich also Code-Reviews? Grundsätzlich ja, aber das ist nicht die einzige Möglichkeit, ein zweites Paar Augen zu nutzen. Ich schlage vor, bei so ziemlich jeder Aufgabe, die ein Entwickler ausführt, Review-ähnliche Prozesse einzusetzen. Oder noch besser: Paare. Programmieren Sie zu zweit, konfigurieren Sie den Server zu zweit, beheben Sie Fehler zu zweit und unterstützen Sie den Kunden zu zweit. Kurz gesagt: Führen Sie die Problembehandlung zu zweit durch.

Kunst oder Wissenschaft?

Die Fehlerbehebung befindet sich in einem Stadium, in dem sie immer noch mehr Kunst als Wissenschaft ist. Das sollte Sie aber nicht davon abhalten, Techniken und Tools einzusetzen, um sie effizienter zu gestalten.

Wenden Sie also diese Techniken für die Durchführung einer RCA an:
1. Verwenden Sie die Quietscheentchen-Methode
2. Sammeln Sie viele Protokolldaten und verwenden Sie geeignete Tools, um sie zu durchsuchen und zu analysieren.
3. Wenden Sie die 5-W-Methode an
4. Holen Sie sich ein zweites Paar Augen

Es ist Zeit, sich Ihr Quietscheentchen zu schnappen und mit der Analyse der Ursachen Ihrer Fehler zu beginnen.

Weitere Informationen zu den Preisen von Amazon OpenSearch Service

Zur Seite mit den Preisen
Bereit zum Entwickeln?
Erste Schritte mit Amazon OpenSearch Service
Haben Sie noch Fragen?
Kontakt