|
|
| (6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 17: |
Zeile 17: |
| * 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 | | * 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 |
|
| |
|
| == 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 algorithm|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)
| | <noinclude> |
| * 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 [[Intermittierenden Störungen|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
| |
| <blockquote>Ein intermittierendes Problem ist ein Problem, für das es kein bekanntes Verfahren zur konsistenten Reproduktion seiner Symptome gibt.|Steven Litt</blockquote> | |
|
| |
|
| 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 [[Ursachenanalyse|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
| |
|
| |
| <noinclude>
| |
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| {{Special:PrefixIndex/{{BASEPAGENAME}}}} | | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| ==== Links ====
| | === Links === |
| ===== Weblinks =====
| | ==== Weblinks ==== |
| # https://en.wikipedia.org/wiki/Troubleshooting | | # https://en.wikipedia.org/wiki/Troubleshooting |
|
| |
|
| [[Kategorie:Troubleshooting]] | | [[Kategorie:Troubleshooting]] |
| </noinclude> | | </noinclude> |