Fehlersuche
Ich habe in meinem Beruf schon sehr viele Fehler gesucht und die meisten davon beseitigt. Oft, habe ich sie selbst hervorgerufen, noch viel häufiger, war es einfach meine Aufgabe, sie zu beseitigen.
Viele Fehler waren und sind sehr knifflig, ich scheine solche Probleme anzuziehen. Das kommt manchmal davon, dass viele sich zurückziehen, wenn es schwierig wird, während ich das interessant finde. Mit der Zeit landen dann immer die schwierigsten Probleme bei mir und irgendwann will ich auch mal meine Ruhe haben.
Darum erzähle ich vielen Leuten, wie ich ein Problem gelöst habe, auch wenn Sie es nicht wissen wollen. Die meisten sind nur interessiert an kleinen Tricks, die in einer bestimmten Situation weiterhelfen. Aber das ist nur eine Seite der Medaille.
All die kleinen nützlichen Tricks und Helferlein sind nutzloser Ballast, wenn ich nicht weiß, wann und wie ich sie einsetzen kann. Natürlich kann ich diese sammeln und zu einer Art Kochbuch zusammenstellen, das für jedes Problem auf die entsprechende Abhilfe verweist. So etwas gibt es schon für viele Gebiete, wie zum Beispiel das Perl-Kochbuch, dito für DNS und Bind oder die Pattern-Bücher für Softwareentwickler.
Aber auch das hilft mir bei einer Fehlersuche nicht weiter, wenn ich nicht weiß, welches Problem ich da mit dem entsprechenden Rezept lösen will. Hier brauche ich zuallererst ein strukturiertes Vorgehen, das mir hilft, das Problem überhaupt zu identifizieren. Wohlgemerkt bei schwierigen Problemen. Bei einfachen Problemen ist es meist offensichtlich, was zu tun ist und wenn ein Problem wiederholt auftritt, wird es oft wiedererkannt. Wobei ich mich dann fragen sollte, warum das Problem immer wiederkommt.
Hier geht es mir um das strukturierte Vorgehen bei einem unbekannten Problem. Ich verwende da fünf Fragen, die ich für mich beantworte und die mich oft zur Lösung des Problems führen. Manchmal bleibt jedoch nicht viel Zeit, so dass ich hin und wieder die letzten beiden Fragen auslasse. Die fünf Fragen sind:
Was ist das Problem und ist es reproduzierbar?
Funktioniert irgendetwas?
Funktioniert alles?
Ist es schnell genug?
Was kann ich daraus lernen?
Was ist das Problem und ist es reproduzierbar?
Das ist das kleine Einmaleins, wenn man im Support arbeitet und nicht nach Problemen suchen muss, weil sie an einen herangetragen werden. Als erstes versuche ich soviel wie möglich von dem zu erfahren, der das Problem entdeckt hat.
Dabei muss ich mich zurücknehmen, um nicht gleich die erste Lösung zu präsentieren, die mir in den Sinn kommt. Schließlich arbeite ich nicht in der Hotline, die nur ein begrenztes Zeitbudget zur Verfügung hat. Ich muss versuchen, das Problem so genau wie möglich zu verstehen. Habe ich bereits eine Idee, kann ich durch Nachfragen versuchen, diese Idee zu bekräftigen oder zu widerlegen.
Ich muss herausfinden, was passiert und was passieren sollte. Idealerweise weiß ich schon, was passieren sollte, aber das kommt eher selten vor.
Auch ist interessant zu erfahren, was derjenige getan hat, der den Fehler entdeckt hat, um ihn hervorzurufen. Und genau so wichtig ist, zu wissen, ob der Fehler jetzt auftritt, in einem definierten Zeitraum auftrat oder gar nur ab und zu. Gerade im letzten Fall, bei intermittierenden Fehlern, ist es kaum möglich, genau zu sagen, ob das Problem jetzt gelöst ist oder einfach nur nicht auftritt. Darum versuche ich den Fehler gezielt selbst hervorzurufen, damit ich am Ende meine Lösung bewerten kann.
Funktioniert irgendetwas?
Diese Frage sollte eigentlich schon von der Hotline beantwortet sein. Dennoch habe ich es schon erlebt, dass mir ein "Internet-Ausfall" gemeldet wurde, bei dem sich nach meiner ersten Rückfrage herausstellte, dass lediglich der Server, der als Startseite im Browser eingestellt war, nicht erreicht werden konnte. Das ist ein Grund, warum ich immer frage, ob überhaupt etwas funktioniert.
Der andere ist, dass ich im Falle eines tatsächlichen Totalausfalls mich nicht mit Details verzetteln will, die mich völlig aus der Spur bringen. Bei einem Totalausfall muss ich vielleicht auf einen Notfallplan zurückgreifen. Ob das notwendig ist, will ich sehr früh klären.
Funktioniert alles?
Okay, ich weiß nun, das es kein Totalausfall ist, aber das Problem ist nun mal da.
Also muss ich als nächstes die beteiligten Komponenten identifizieren, die zusammen funktionieren müssen, damit das Problem nicht auftritt. Das heisst, damit das funktioniert, was jetzt nicht funktioniert. Was das genau ist, habe ich hoffentlich mit dem ersten Fragenkomplex herausbekommen. Die Komponenten muss ich anhand der Systemdokumentation - da existiert doch eine Dokumentation? - herausbekommen.
Ich kann die einzelnen Komponenten Stück für Stück überprüfen, schneller geht es wahrscheinlich, wenn ich das Gesamtsystem prüfe, indem ich es benutze. Dabei beobachte ich, ob alle beteiligten Komponenten in der richtigen Reihenfolge mitspielen. Fehlen einige Komponenten, kann ich mich über deren Abhängigkeiten an die Ursache herantasten.
Das erfordert eine genaue Kenntnis der beteiligten Systeme und die nötigen Informationen sollten in der Dokumentation stehen.
Ist es schnell genug?
Die Schnelligkeit eines Systems wird immer subjektiv bewertet, sie ist eine sogenannte nichtfachliche Anforderung. War ein System ausgefallen, ist der Anwender vielleicht zunächst erstmal froh, dass er überhaupt wieder arbeiten kann und meldet sich dann später, dass es zu langsam ist.
SLA (Service Level Agreements) können helfen, sich über eine eindeutige Definition von "schnell genug" zu verständigen. Eine Baseline, die bei der Inbetriebnahme oder nach Aktualisierungen aufgenommen wurde, hilft später bei der schnellen Überprüfung.
Habe ich Probleme mit der Geschwindigkeit, muss ich genau hinschauen. Dabei kann ich mich der USE-Methode von Brendan Gregg bedienen. Durch die Beantwortung der vorigen Frage (funktioniert alles?) sollte ich alle beteiligten Systeme kennen. Für jedes einzelne davon kontrolliere ich die Auslastung (Utilization), Sättigung (Saturation) und Fehlerereignisse (Error).
Dabei meint Auslastung bei einigen Komponenten, wie CPU oder Netzverbindungen, die Prozentzahl der Zeit, die die Ressource in einem gegebenen Intervall verwendet wird. Bei anderen Komponenten, wie RAM oder Plattenplatz meint es den Anteil der verwendeten Kapazität an der Gesamtkapazität.
Sättigung meint die Arbeit, die in Warteschlangen wartet, während die Ressource zu 100 Prozent ausgelastet ist. Bei der CPU eines Rechners meint das die Anzahl der Prozesse, die nicht blockiert sind und auf Rechenzeit warten. Bei RAM meint es den ausgelagerten Hauptspeicher und bei Routern, Switches und Gateways die Datagramme, die in Queues auf das Versenden warten.
Fehler meint die Anzahl der Fehlerereignisse, auch wenn die Operation wiederholt wird. Bei RAM sind das zum Beispiel Pagefaults, nach denen eine Seite von der Platte geladen wird. Im Netz zählen dazu verworfene und fehlerhafte Datagramme, auch wenn das Protokoll, wie zum Beispiel TCP, diese selbstständig wiederholt.
Wichtig ist, ein geeignetes Zeitintervall zu wählen, da kurze Lastspitzen (Bursts) zu einer Sättigung und damit zu Performance-Problemen führen können, die in einem zu großen Intervall durch die Mittelung verschwinden.
Was kann ich daraus lernen?
Das ist der schönste Teil der Fehlersuche, der Druck ist abgebaut, jemand ist glücklich und ich habe vielleicht ein wenig dazugelernt. Wenn ich es dabei belasse, verschenke ich aber einiges.
Zum einen ist es schön einen Fehler behoben zu haben, noch schöner wäre, wenn er gar nicht erst aufgetreten wäre. Da das zumindest beim ersten Mal nur mit sehr hohem Aufwand und selbst dann nur teilweise zu erreichen ist, sollte ich mich darum kümmern, dass er sich möglichst nicht wiederholt.
Dabei kann ich mich der 5-W-Methode bedienen, das heißt ich frage fünfmal Warum: warum ist der Fehler aufgetreten, warum ist das, was ihn verursacht hat aufgetreten, und so weiter. Allerdings darf ich das nicht vorschnell auf eine Ursache einengen, die ich für diesen Fehler verantwortlich mache, wenn erst das Zusammenspiel mehrerer Umstände zum Fehler führte. In diesem Fall muss ich allen potentiellen Ursachen, deren Zusammenspiel den Fehler ermöglicht hat, nachspüren. Und natürlich muss ich mich fragen, ob das Abstellen dieser Ursachen nicht vielleicht andere Probleme aufwirft. Kurz gesagt, ich nutze den Fehler, um das System und seine Ausnahmezustände besser zu verstehen.
Und um ähnliche Probleme in Zukunft zu verhindern kann ich mein Monitoring anpassen, die Best Practices überarbeiten und meine Kollegen schulen.
Vielleicht habe ich bei der Suche nach diesem Fehler aber auch eine neue Technik gelernt. Für diese kann ich dann überlegen, wo ich sie noch einsetzen könnte und welchen Nutzen sie mir da bringen würde.
Dieser Text ist ein überarbeiteter Auszug aus dem Buch Fehlersuche bei Linux-Servern und in IP-Netzwerken.
Posted 2017-07-31