Worauf kommt es an bei der Fehlersuche?
Es gibt verschiedene Punkte, die eine erfolgreiche und effiziente Fehlersuche bei einem komplexen Problem ausmachen. Drei davon sind:
- das Beherrschen der Grundlagen,
- die Kenntnis der Materie und
- eine strukturierte Vorgehensweise.
Die ersten beiden benötige ich, um überhaupt zu einem Ergebnis zu kommen. Der dritte Punkt hilft mir den Fehler schneller zu finden, indem ich unnötige Schritte auslasse und die erfolgversprechenden Wege zuerst gehe.
Erkenne ich ein Problem oder bekomme eines gemeldet, dann arbeite ich bis zu seiner Lösung in der folgenden Schleife:
- Ich beobachte das Problem,
- beurteile, was ich gesehen habe,
- ändere etwas am Gesamtsystem und
- teste, um erneut zu beobachten.
Dieser Ablauf entspricht im wesentlichen den vier Phasen, die George Pólya für die Lösung mathematischer Probleme vorschlägt.
Ich beobachte das Problem, um es - die Aufgabe bei Pólya - zu verstehen. Wenn ich beurteile, was ich gesehen habe, denke ich dabei darüber nach, was geändert werden müsste, das heißt, ich mache einen Plan. Indem ich das Gesamtsystem, das heißt die Konfiguration oder die Topologie des Systems, ändere, führe ich den zuvor gefassten Plan aus. Mit dem Test kontrolliere ich das Ergebnis meiner Änderung, so wie Pólya in der Rückschau.
Das Buch von Polya [1] bezieht sich zwar in erster Linie auf mathematische Probleme. Es ist aber auf jeden Fall eine gute Inspiration für jegliche Problemlösung, mithin auch für die Fehlersuche.
Die oben angeführte strukturierte Vorgehensweise bestimmt, worauf ich mich in einer Iteration der Schleife beim Beobachten konzentriere. Dabei arbeite ich vorzugsweise die folgenden Fragen ab, die ich für jede Anwendungsdomäne konkretisieren muss.
- Funktioniert überhaupt etwas?
- Funktioniert alles?
- Ist es schnell genug?
Konkretisierungen für die Fehlersuche bei IPsec finden sich in einem älteren Artikel, für Linux-Server und IP-Netzwerke im grünen Buch.
Um das Problem zu beobachten sowie das Gesamtsystem ändern und testen zu können, muss ich die Grundlagen beherrschen. Zum einen die allgemeine Grundlagen, die ich auch in anderen Anwendungsdomänen verwenden kann und zum anderen spezifische Grundlagen, abhängig von der eingesetzten Technologie.
Das Grundlagenwissen, das ich zum Beobachten und Ändern des Systems brauche, ist zum Teil systemübergreifend, wie das Auswerten von Paketmitschnitten oder Textdateien, und zum Teil systemspezifisch, wie das Anfertigen von Paketmitschnitten, das Auswerten und Ändern einer Konfiguration oder das Herausziehen der Systemprotokolle für die spätere Auswertung.
Damit ich das Beobachtete richtig beurteilen und geeignete Änderungen finden kann, benötige ich Fachwissen über die betroffene Materie.
Auch beim Fachwissen habe ich, neben dem konkreten Inhalt, meist mit zwei Aspekten zu tun. Zum einen mit dem in Standards und anderen Dokumenten beschriebenen idealen Verhalten und den dort verwendeten Begriffen. Zum anderen mit dem konkreten Verhalten und Begriffen der mir vorliegenden Software. Beide muss ich aufeinander abbilden, um das konkrete System zu verstehen. Diese Abbildung zwischen idealem Modell und konkretem System ist insbesondere dann wichtig, wenn zwei unterschiedliche Systeme dasselbe Protokoll verwenden, wie zum Beispiel IPsec. Dann sind Probleme vorprogrammiert, wenn beide Administratoren zwar ihre Software kennen, aber das Protokoll nur unzureichend.
Updates
- 2019-10-05: Verweis auf Buch von Pólya.