Troubleshooting

Troubleshooting - Systematische Fehlersuche und -behebung (Debugging)

Beschreibung

Troubleshooting ist eine Form der Problemlösung, die häufig zur Reparatur fehlerhafter Produkte oder Prozesse an einer Maschine oder einem System eingesetzt wird

• Es handelt sich um eine logische, systematische Suche nach der Ursache eines Problems, um es zu lösen und das Produkt oder den Prozess wieder funktionsfähig zu machen
• Die Fehlersuche ist erforderlich, um die Symptome zu identifizieren
• Die Ermittlung der wahrscheinlichsten Ursache ist ein Prozess der Eliminierung, bei dem potenzielle Ursachen eines Problems ausgeschlossen werden
• Schließlich muss bei der Fehlerbehebung bestätigt werden, dass die Lösung das Produkt oder den Prozess wieder in den funktionsfähigen Zustand versetzt

Diagnose

Im Allgemeinen ist die Fehlerbehebung die Identifizierung oder Diagnose von „Problemen“ im Managementfluss eines Systems, die durch einen Fehler verursacht werden

• Das Problem wird zunächst als Symptom einer Fehlfunktion beschrieben, und die Fehlerbehebung ist der Prozess der Ermittlung und Behebung der Ursachen dieser Symptome

Ein System kann anhand seines erwarteten, gewünschten oder beabsichtigten Verhaltens (bei künstlichen Systemen in der Regel anhand seines Zwecks) beschrieben werden

• Von Ereignissen oder Eingaben in das System wird erwartet, dass sie bestimmte Ergebnisse oder Ausgaben erzeugen. (Beispielsweise soll die Auswahl der Option „Drucken“ aus verschiedenen Computeranwendungen dazu führen, dass eine Hardcopy aus einem bestimmten Gerät ausgegeben wird)
• Jedes unerwartete oder unerwünschte Verhalten ist ein Symptom
• Bei der Fehlerbehebung werden die spezifische(n) Ursache(n) des Symptoms isoliert
• Häufig ist das Symptom ein Fehler des Produkts oder Prozesses, der dazu führt, dass keine Ergebnisse erzielt werden. (Es wurde beispielsweise nichts gedruckt)
• Es können dann Korrekturmaßnahmen ergriffen werden, um weitere Fehler ähnlicher Art zu verhindern

Die Methoden des forensischen Ingenieurwesens sind nützlich, um Probleme in Produkten oder Prozessen aufzuspüren, und es steht eine breite Palette von Analysetechniken zur Verfügung, um die Ursache oder die Ursachen bestimmter Fehler zu ermitteln

• Es können dann Korrekturmaßnahmen ergriffen werden, um weitere Fehler ähnlicher Art zu verhindern
• Vorbeugende Maßnahmen sind mithilfe der Fehlermöglichkeits- und Einflussanalyse (FMEA) und der Fehlerbaumanalyse (FTA) vor der Serienproduktion möglich, und diese Methoden können auch für die Fehleranalyse verwendet werden

Es gibt zwei wesentliche Elemente, die für eine Fehlerdiagnose erforderlich sind: a priori Fachwissen und Suchstrategien

• Es wird empfohlen, eine Strategie zu verwenden, die sich an den Merkmalen der korrekten Funktionsweise des Geräts orientiert (topografische Strategie), und eine Strategie, die sich an den Merkmalen der abnormalen Funktionsweise orientiert (symptomatische Strategie)
• Die zweite Strategie fragt wirklich: „Was ist falsch?“, die erste fragt: „Was passiert?“

Eine Strategie ist eine organisierte Reihe von Aktivitäten, die einen plausiblen Weg zur Erreichung eines Ziels darstellen

• Strategien sollten nicht als Algorithmen betrachtet werden, die unflexibel bis zur Lösung befolgt werden
• Problemlöser verhalten sich opportunistisch, passen Aktivitäten innerhalb einer Strategie an und ändern Strategien und Taktiken als Reaktion auf Informationen und Ideen

Eine symptomatische Strategie (auch als fallbasiertes Schließen oder oberflächliches Schließen bekannt) erfordert a priori vorhandenes Fachwissen, das aus früheren Erfahrungen gewonnen wurde, die Zusammenhänge zwischen Symptomen und Ursachen herstellten

• Dieses Wissen wird als oberflächliches, kompiliertes, evidenzbasiertes, geschichtsbasiertes sowie fallbasiertes Wissen bezeichnet
• Diese Strategie wird am häufigsten mit der Diagnose durch Experten in Verbindung gebracht
• Die Diagnose eines Problems erfolgt in einem schnellen Erkennungsprozess, bei dem Symptome entsprechende Situationskategorien hervorrufen
• Ein Experte kennt die Ursache, weil er bereits auf ähnliche Fälle gestoßen ist
• Fallbasiertes Denken ist die leistungsstärkste und am häufigsten verwendete Strategie
• Allerdings funktioniert diese Strategie nicht unabhängig bei wirklich neuartigen Problemen oder wenn ein tieferes Verständnis dessen, was vor sich geht, angestrebt wird

Eine topografische Strategie fällt in die Kategorie des tiefen Denkens

• Beim tiefen Denken wird fundiertes Wissen über ein System genutzt
• Topographie bedeutet in diesem Zusammenhang eine Beschreibung oder Analyse einer strukturierten Einheit, die die Beziehungen zwischen ihren Elementen aufzeigt

Tiefes Denken, auch als Argumentation aus ersten Prinzipien bekannt, wird bei neuartigen Fehlern angewendet, wenn erfahrungsbasierte Ansätze nicht praktikabel sind

• Die topographische Strategie ist daher mit einem a priori-Domänenwissen verbunden, das aus einem grundlegenderen Verständnis eines Systems entwickelt wird, möglicherweise unter Verwendung von Wissen aus ersten Prinzipien
• Dieses Wissen wird als tiefes, kausales oder modellbasiertes Wissen bezeichnet

Hoc merkte an, dass symptomatische Ansätze möglicherweise durch topografische Ansätze unterstützt werden müssen, da Symptome unterschiedlich definiert werden können

• Das Gegenteil ist auch der Fall – oberflächliche Überlegungen können abduktiv verwendet werden, um kausale Hypothesen zu generieren, und deduktiv, um diese Hypothesen in einer topografischen Suche zu bewerten

Aspekte

Normalerweise wird die Fehlerbehebung auf etwas angewendet, das plötzlich nicht mehr funktioniert, da der zuvor funktionierende Zustand die Erwartungen an das weitere Verhalten bildet

• Daher liegt der anfängliche Fokus oft auf den jüngsten Änderungen am System oder an der Umgebung, in der es sich befindet. (Zum Beispiel ein Drucker, der „funktionierte, als er dort drüben eingesteckt war“)
• Es gibt jedoch ein bekanntes Prinzip, dass eine Korrelation nicht unbedingt eine Kausalität impliziert. (Zum Beispiel bedeutet der Ausfall eines Geräts kurz nachdem es an eine andere Steckdose angeschlossen wurde nicht unbedingt, dass die Ereignisse miteinander zusammenhängen
• Der Ausfall könnte auch auf einen Zufall zurückzuführen sein.) Daher erfordert die Fehlerbehebung eher kritisches Denken als magisches Denken

Es ist nützlich, die Erfahrungen zu berücksichtigen, die wir mit Glühbirnen gemacht haben

• Glühbirnen „brennen“ mehr oder weniger zufällig aus; schließlich führen das wiederholte Erhitzen und Abkühlen des Glühfadens und Schwankungen in der Stromversorgung dazu, dass der Glühfaden reißt oder verdampft
• Das gleiche Prinzip gilt für die meisten anderen elektronischen Geräte und ähnliche Prinzipien gelten für mechanische Geräte
• Einige Ausfälle sind Teil der normalen Abnutzung von Komponenten in einem System

Das erste Grundprinzip bei der Fehlersuche besteht darin, das Problem nach Wunsch reproduzieren zu können Das zweite Grundprinzip bei der Fehlersuche besteht darin, das „System“ auf seine einfachste Form zu reduzieren, die das Problem noch zeigt Das dritte Grundprinzip bei der Fehlersuche besteht darin, „zu wissen, wonach man sucht“

• Mit anderen Worten, man muss die Funktionsweise des Systems vollständig verstehen, damit man den Fehler „erkennen“ kann, wenn er auftritt

Ein Fehlerdiagnostiker könnte jede Komponente in einem System einzeln überprüfen und dabei jede potenziell verdächtige Komponente durch eine bekanntermaßen gute Komponente ersetzen

• Dieser Prozess der „seriellen Substitution“ kann jedoch als degeneriert angesehen werden, wenn Komponenten ohne Berücksichtigung einer Hypothese darüber, wie ihr Ausfall zu den diagnostizierten Symptomen führen könnte, ersetzt werden

Einfache und mittelschwere Systeme sind durch Listen oder Bäume von Abhängigkeiten zwischen ihren Komponenten oder Subsystemen gekennzeichnet

• Komplexere Systeme enthalten zyklische Abhängigkeiten oder Wechselwirkungen (Rückkopplungsschleifen)
• Solche Systeme sind für „Bisektions“-Fehlerbehebungstechniken weniger geeignet

Es ist auch hilfreich, von einem bekannten guten Zustand auszugehen, das beste Beispiel ist ein Neustart eines Computers

• Ein cognitive walkthrough ist auch eine gute Sache, die man ausprobieren sollte
• Eine umfassende Dokumentation, die von kompetenten technischen Redakteuren erstellt wurde, ist sehr hilfreich, insbesondere wenn sie eine Theorie der Funktionsweise für das betreffende Gerät oder System enthält

Eine häufige Ursache für Probleme ist ein schlechtes Design, z. B. ein schlechtes Human Factors-Design, bei dem ein Gerät aufgrund des Fehlens einer geeigneten Zwangsfunktion (Verhaltensformungsbeschränkung) verkehrt herum oder auf dem Kopf stehend eingesetzt werden könnte, oder ein fehlendes fehlertolerantes Design

• Dies ist besonders schlimm, wenn es mit Gewöhnung einhergeht, bei der der Benutzer die falsche Verwendung einfach nicht bemerkt, z. B. wenn zwei Teile unterschiedliche Funktionen haben, aber ein gemeinsames Gehäuse, sodass bei einer flüchtigen Betrachtung nicht ersichtlich ist, welches Teil verwendet wird

Die Fehlerbehebung kann auch in Form einer systematischen Checkliste, eines Fehlerbehebungsverfahrens, eines Flussdiagramms oder einer Tabelle erfolgen, die erstellt wird, bevor ein Problem auftritt

• Die Entwicklung von Fehlerbehebungsverfahren im Voraus ermöglicht es, ausreichend über die Schritte zur Fehlerbehebung nachzudenken und die Fehlerbehebung in den effizientesten Fehlerbehebungsprozess zu organisieren
• Fehlerbehebungstabellen können computerisiert werden, um sie für die Benutzer effizienter zu gestalten

Einige computergestützte Fehlerbehebungsdienste (wie Primefax, später in MaxServ umbenannt) zeigen sofort die 10 besten Lösungen mit der höchsten Wahrscheinlichkeit an, das zugrunde liegende Problem zu beheben

• Der Techniker kann entweder zusätzliche Fragen beantworten, um das Fehlerbehebungsverfahren fortzusetzen, wobei jeder Schritt die Liste der Lösungen eingrenzt, oder sofort die Lösung implementieren, die seiner Meinung nach das Problem behebt
• Diese Dienste bieten einen Rabatt, wenn der Techniker nach der Lösung des Problems einen zusätzlichen Schritt unternimmt: die Rückmeldung der Lösung, die das Problem tatsächlich behoben hat
• Der Computer verwendet diese Berichte, um seine Schätzungen darüber zu aktualisieren, welche Lösungen die höchste Wahrscheinlichkeit haben, diese bestimmte Reihe von Symptomen zu beheben

Halbierung

Eine effiziente, methodische Fehlerbehebung beginnt mit einem klaren Verständnis des erwarteten Verhaltens des Systems und der beobachteten Symptome

• Auf dieser Grundlage erstellt der Problemlöser Hypothesen zu möglichen Ursachen und entwickelt Tests (oder greift auf eine standardisierte Checkliste zurück), um diese potenziellen Ursachen zu beseitigen
• Dieser Ansatz wird oft als „divide and conquer“ bezeichnet

Zwei gängige Strategien, die von Problemlösern angewendet werden, sind die Überprüfung auf häufig auftretende oder leicht zu testende Bedingungen (z. B. die Überprüfung, ob die Anzeige eines Druckers leuchtet und ob das Kabel an beiden Enden fest sitzt)

• Dies wird oft als „Melken der Frontplatte“ bezeichnet

Dann wird das System „halbiert“ (z. B. wird bei einem Netzwerk-Drucksystem überprüft, ob der Auftrag den Server erreicht hat, um festzustellen, ob ein Problem in den Subsystemen „in Richtung“ des Benutzers oder „in Richtung“ des Geräts vorliegt)

Diese letztere Technik kann besonders effizient in Systemen mit langen Ketten von seriellen Abhängigkeiten oder Interaktionen zwischen ihren Komponenten sein

• Es handelt sich einfach um die Anwendung einer binären Suche über den gesamten Bereich der Abhängigkeiten, was oft als „Halbteilung“ bezeichnet wird
• Es ähnelt dem Spiel „20 Fragen“: Jeder kann eine Option aus einer Million herausfiltern, indem er die Menge der Alternativen 20 Mal in zwei Hälften teilt (da 2^10 = 1024 und 2^20 = 1.048.576)

Reproduzierbare Symptome

Eines der Grundprinzipien der Fehlersuche ist, dass reproduzierbare Probleme zuverlässig isoliert und gelöst werden können

• Oft wird bei der Fehlersuche ein erheblicher Aufwand und Schwerpunkt auf die Reproduzierbarkeit gelegt [...]
• auf die Suche nach einem Verfahren, mit dem das Symptom zuverlässig hervorgerufen werden kann

Intermittierende Symptome

Einige der schwierigsten Probleme bei der Fehlersuche hängen mit Symptomen zusammen, die intermittierend auftreten

• In der Elektronik ist dies oft das Ergebnis von thermisch empfindlichen Komponenten (da der Widerstand eines Schaltkreises mit der Temperatur der darin enthaltenen Leiter variiert)
• Druckluft kann verwendet werden, um bestimmte Stellen auf einer Leiterplatte zu kühlen, und eine Heißluftpistole kann verwendet werden, um die Temperaturen zu erhöhen; daher erfordert die Fehlersuche bei elektronischen Systemen häufig die Anwendung dieser Werkzeuge, um ein Problem zu reproduzieren

In der Computerprogrammierung führen Race Conditions oft zu intermittierenden Symptomen, die extrem schwer zu reproduzieren sind; verschiedene Techniken können eingesetzt werden, um die bestimmte Funktion oder das Modul schneller aufzurufen, als es im Normalbetrieb der Fall wäre (analog zum „Aufheizen“ einer Komponente in einer Hardware-Schaltung), während andere Techniken eingesetzt werden können, um größere Verzögerungen in anderen Modulen oder interagierenden Prozessen einzuführen oder eine Synchronisierung zwischen ihnen zu erzwingen

Intermittierende Probleme können wie folgt definiert werden

Ein intermittierendes Problem ist ein Problem, für das es kein bekanntes Verfahren zur konsistenten Reproduktion seiner Symptome gibt.|Steven Litt

Insbesondere behauptet er, dass es einen Unterschied zwischen der Häufigkeit des Auftretens und einem „bekannten Verfahren zur konsistenten Reproduktion“ eines Problems gibt

• Wenn man beispielsweise weiß, dass ein intermittierendes Problem „innerhalb“ einer Stunde nach einem bestimmten Reiz oder Ereignis auftritt, dies aber manchmal in fünf Minuten und manchmal erst nach fast einer Stunde geschieht, stellt dies kein „bekanntes Verfahren“ dar, selbst wenn der Reiz die Häufigkeit der beobachtbaren Symptome erhöht

Dennoch müssen Fehlerbeheurer manchmal auf statistische Methoden zurückgreifen ..

• und können nur Verfahren finden, um das Auftreten des Symptoms so weit zu erhöhen, dass eine serielle Substitution oder eine andere Technik möglich ist
• In solchen Fällen besteht selbst dann, wenn das Symptom für deutlich längere Zeiträume zu verschwinden scheint, nur eine geringe Sicherheit, dass die Ursache gefunden wurde und das Problem wirklich gelöst ist

Außerdem können Tests durchgeführt werden, um bestimmte Komponenten zu belasten und festzustellen, ob diese Komponenten ausgefallen sind

Mehrere Probleme

Das Isolieren einzelner Komponentenfehler, die reproduzierbare Symptome verursachen, ist relativ einfach

Viele Probleme treten jedoch nur als Folge mehrerer Fehler oder Störungen auf

• Dies gilt insbesondere für fehlertolerante Systeme oder solche mit integrierter Redundanz
• Funktionen, die einem System Redundanz, Fehlererkennung und Failover hinzufügen, können ebenfalls fehleranfällig sein, und genügend verschiedene Komponentenfehler in jedem System können es „zum Absturz bringen“

Selbst bei einfachen Systemen muss der Problemlöser immer die Möglichkeit in Betracht ziehen, dass es mehr als einen Fehler gibt. (Das Ersetzen jeder einzelnen Komponente, die Verwendung der Seriensubstitution und das anschließende Austauschen jeder neuen Komponente gegen die alte, wenn das Symptom weiterhin besteht, kann in solchen Fällen zu keiner Lösung führen

• Noch wichtiger ist, dass der Austausch einer Komponente durch eine defekte Komponente die Anzahl der Probleme sogar erhöhen kann, anstatt sie zu beseitigen)

Beachten Sie, dass, obwohl wir von „Komponenten ersetzen“ sprechen, die Lösung vieler Probleme eher Anpassungen oder Feinabstimmungen als „Ersetzen“ umfasst

• Beispielsweise müssen unterbrochene Leitungen – oder „verschmutzte oder lose Kontakte“ – möglicherweise einfach nur gereinigt und/oder festgezogen werden
• Bei allen Diskussionen über „Ersetzen“ sollte davon ausgegangen werden, dass es sich um „Ersetzen oder Anpassen oder andere Modifikationen“ handelt

Anhang

Siehe auch

• Troubleshooting

Links

Weblinks

1. https://en.wikipedia.org/wiki/Troubleshooting