Troubleshooting Linux und IP-Netzwerke

2. Herangehen

Neben dem geistigen Rüstzeug, das ich im vorigen Kapitel besprochen habe, bestimmt die Art und Weise, wie ich an ein Problem herangehe, den Erfolg.

Natürlich gibt es kein Patentrezept, das ich unverändert auf alle Probleme anwenden kann. Je nach Wichtigkeit und Dringlichkeit werde ich vielleicht in einem Fall auf eine schnelle, dafür nicht sehr gründliche Lösung hinarbeiten und mir in einem anderen Fall die Zeit nehmen, ein Problem ein für alle Mal aus der Welt zu schaffen.

Problemaufnahme

Bei der Aufnahme eines Problems entscheide ich oft schon, wie ich damit umgehen werde. Um ein Problem zu lösen, muss ich es zuallererst verstehen. Dabei hilft mir der Entscheidungsbaum, an der richtigen Stelle die richtigen Fragen zu stellen:

Diese und ähnliche Fragen stelle ich, wenn mir ein Kunde einen Ausfall meldet.

Performanceprobleme werden subjektiv oft verschieden wahrgenommen, bei diesen frage ich leicht modifiziert:

Die nachfolgenden Fragen muss ich meist allein beantworten.

Manche Probleme lassen sich bereits bei der Problemaufnahme lösen, weil das Stellen der richtigen Fragen mitunter direkt zur passenden Antwort und damit zur Lösung des Problems führt. In allen anderen Fällen hilft eine umfangreiche Problemaufnahme, dass wichtige Details bei der Lösungssuche nicht übersehen werden.

Wenn ich ein Problem selbst feststelle, kann ich die Fragen in meinem Rhythmus beantworten, mit der nötigen Sorgfalt.

Problematisch kann es werden, wenn andere ihr Problem an mich herantragen. Sei es ein Kunde, der mich anruft, weil ich gerade Telefondienst habe. Sei es ein Kollege, der mal eben sein Problem herüber trägt, oder der Chef, der irgendetwas schnell erledigt haben will. Diese Arten von Problemaufnahmen haben eins gemeinsam: da ist jemand, der seine ganz eigene Vorstellung von der Wichtigkeit, Dringlichkeit und mitunter auch von der Lösung des Problems hat. Die kann richtig sein oder falsch.

Schwierig wird es, wenn ich mich auf eine falsche Fährte schicken lasse oder wenn ich nicht mehr klar denken kann, durch den im Gespräch aufgebauten Druck.

Hier helfen mir vier Kraftprinzipien, die ich aus der Kampfkunst kenne und für Problemlösungen einsetze, um den Kopf frei zu bekommen. Diese lauten:

Nun ist das hier kein Buch über Kampfkunst, und ich bin auch nicht berufen über dieses Thema zu schreiben. Was mache ich also mit diesen Prinzipien? Wie setze ich sie ein?

Der Schlüssel liegt darin, das Wort Kraft durch Gedanken, Ideen oder Vorurteile zu ersetzen.

Wie mache ich mich frei von meinen eigenen Vorurteilen? Dazu ein Beispiel. Ich bin auf Arbeit oft einer der letzten, der geht, weil ich dann noch die eine oder andere Änderung vornehmen kann, ohne damit rechnen zu müssen, unterbrochen zu werden oder jemand zu beeinträchtigen. Am Ende kontrolliere ich, ob alles funktioniert, und mache Feierabend. An einem Morgen komme ich zur Arbeit und werde vom Kollegen am Telefondienst, einem Administrator wie ich, mit leicht hektischer und etwas vorwurfsvoller Stimme empfangen:

“Im Rathaus geht das INTERNET nicht!”

Mehr sagt er dazu nicht, allein Stimme und Tonfall sollen mir klar machen, dass es wichtig und dringend ist.

Natürlich weiß ich noch, was ich am Vorabend gemacht habe, aber das tut nichts zur Sache, ich will erst herauskriegen, was nicht funktioniert. Ich mache mich frei von meinen Gedanken an den vorigen Tag, konzentriere mich auf das Problem von heute und antworte in neutralem Ton:

“Das ist aber schade.”

Je nach dem, wer gerade da ist, höre ich dann oft:

“Das wusste ich, dass er das jetzt sagt.”

Ich habe mich von den Gedanken meines Kollegen und von dem Druck, den er bewusst oder unbewusst aufbauen wollte, befreit und ihm den Wind aus den Segeln genommen.

Es gibt auch andere Wege, den aufgebauten Druck abzuleiten. Zum Beispiel, in dem ich sage, dass ich mich gleich darum kümmere, wenn ich an meinem Platz bin. Das ist in vielen Fällen auch der beste Weg, wenn derjenige nicht in der Lage ist, sich selbst zu helfen. Aber in diesem Fall handelte es sich um einen Administrator, der nicht einmal die einfachsten Fragen gestellt hatte, um das Problem einzugrenzen. Dann einfach zu sagen, ich kümmere mich drum, hätte solches Verhalten nur zementiert, mit dem Effekt, dass selbst simpelste Sachen unreflektiert an Level 2 Support weitergereicht werden.

Bei uns ist es üblich, dass reihum alle Mitarbeiter ein paar Stunden Telefonsupport machen und damit die Probleme der Kunden direkt mitbekommen. Das halte ich für eine gute Idee, weil es den Horizont erweitert für die Probleme der Kollegen. Außerdem ist es ein Qualitätstest für die Dokumentation der “Routineaufgaben”, die für den nächsten Kollegen ganz und gar keine Routine sind.

Beim Telefondienst sind alle gehalten, möglichst nicht mehr als 5 Minuten mit einem Anruf zu verbringen und dann das Problem zu eskalieren, wenn es noch nicht gelöst ist. In 5 Minuten kann man nicht sehr viel herausbekommen, wenn man nicht mit dem Problemkreis vertraut ist, aber etwas schon.

Wenn an einer Hotline nur Kundenmeldungen unreflektiert weiter gereicht werden, dann verzögert sie nur die Hilfe für die Kunden und stapelt die Arbeit für die, die sie erledigen. Das mag kurzzeitig angehen, wenn der aufnehmende Kollege überhaupt keine Ahnung von der Materie hat. Langfristig ist es sinnvoll, den Mitarbeiter für die Hotline zu schulen und gegebenenfalls die Dokumentation der Routineaufgaben zu überarbeiten.

Nachdem ich den Druck abgebaut hatte, konnte ich mich daran machen, die Gedanken meines Kollegen, also das, was er über das Problem wusste, zu nutzen. Anhand des Entscheidungsbaumes fragte ich als nächstes, ob alle Webserver nicht erreichbar sind oder nur externe oder gar nur bestimmte, und was sie alles ausprobiert hätten.

An diesem Tag musste ich keine eigenen Gedanken mehr hinzufügen, weil noch während der ersten Fragen klar wurde, dass nur einzelne Webserver im Internet betroffen waren und das Problem nicht durch uns gelöst werden konnte. Der Kollege am Telefondienst wäre in diesem Fall gut beraten gewesen, selbst fundiert zurückzufragen.

Selber denken

Wenn ich auf ein komplexes Problem treffe, dass mir in dieser Form noch nicht untergekommen ist, könnte ich versucht sein, mir als erstes Hilfe bei anderen zu holen. Sei es durch eine Suche im Internet, indem ich einen Kollegen befrage oder eine Anfrage in einem Forum oder auf einer Mailingliste stelle. Mit etwas Glück brauche ich mich nicht weiter anstrengen und bekomme die Lösung frei Haus geliefert. Leider ist dieses Vorgehen, das durchaus funktionieren kann, auf lange Sicht eher kontraproduktiv.

Um bei einer Internetsuche erfolgreich zu sein, muss ich das Problem so in wenigen Suchworten beschreiben können, dass relevante Seiten möglichst weit vorn in den Suchergebnissen dabei sind und das Irrelevantes ausgefiltert wird. Das heißt, ich muss mein Problem unterscheidbar machen von anderen Problemen. In vielen Fällen hilft mir dabei das Systemlog, da Auszüge aus diesem mit relevanten Logzeilen oft sehr gut im Internet gefunden werden können.

Wenn ich meine Kollegen befragen will, muss ich daran denken, dass diese ihre eigenen Probleme haben und in den meisten Fällen nicht dafür bezahlt werden, meine Probleme zu lösen. Das mindeste, was ich tun kann, ist, das Problem so genau wie möglich zu spezifizieren und genau den Kollegen zu befragen, von dem ich glaube, dass er signifikant zur Lösung beitragen kann. Natürlich spricht nichts gegen ein zwangloses Gespräch bei Kaffee, Tee oder abends beim Bier. Aber wenn ein Kollege gerade selbst mit eigenen Problemen beschäftigt ist, muss ich damit rechnen, dass er mich nicht zur Kenntnis nimmt beziehungsweise mehr oder weniger höflich wegschickt.

Ähnlich ist es mit Foren und Mailinglisten. Hier muss ich mir Gedanken machen, ob mein Problem überhaupt in das Forum passt oder anders herum, welches Forum für mein Problem geeignet ist. Natürlich sollte ich vor einer Frage an einen Kollegen oder in einem Forum im Internet recherchiert haben, um nicht die gleiche Frage zum hundertsten Mal zu stellen.

Wenn ich jemand anderen zu meinem Problem befrage, muss ich diesen in den richtigen Kontext setzen. Das heißt, ich muss ihm mitteilen, was ich erreichen will oder wie das System vorher funktioniert hat, was funktioniert, was nicht und was ich bereits ausprobiert habe.

Andererseits aktiviert genau diese intensive Beschäftigung mit dem Problem mein Unterbewusstsein, so dass mir oft beim Formulieren der Frage ein Lösungsweg einfällt.

Visuelles Denken

Ich arbeite beim Nachdenken gern visuell, weil ich damit meine Gedanken besser ordnen kann. Bei einfachen Problemen kann ich mir das entsprechende Bild im Kopf vorstellen und weiß, welcher Aspekt zu welchem Teil gehört. Bei schwierigeren Problemen oder um ein Problem zu kommunizieren, greife ich gern zu Stift und Papier. Dazu brauche ich weder eine künstlerische Ausbildung noch zeichnerisches Talent.

Dan Roam gibt in [Roam2009] eine sehr gute Anleitung, wie man Probleme visuell präsentieren und dabei gleichzeitig seine eigenen Gedanken ordnen kann.

Ein wesentlicher Punkt bei ihm ist die Einteilung der Probleme in sechs Kategorien:

Neben diesen sechs Kategorien arbeitet er mit den folgenden fünf Dichotomien um Gedanken klarer darzustellen:

simpel ausführlich
Qualität Quantität
Vision Durchführung
individuelle Merkmale Vergleich
Wandel Status Quo

Obwohl er sich vorrangig auf die Visualisierung von Geschäftsideen bezieht, sind die Techniken sehr gut für die Kommunikation von Problemen der Fehlersuche geeignet.

Logs auswerten

Die Systemprotokolle sind bei nicht trivialen Problemen das erste, was ich mir ansehe. Einerseits geben diese oft schon über eine zeitliche Korrelation einen Hinweis auf die Art des Problems. Andererseits finde ich darin die besten Suchworte für eine Internetsuche.

Dafür müssen die Programme so eingestellt sein, dass ich eine Balance finde, bei der notwendige Nachrichten angezeigt und unnötige weggelassen werden. Ein Programm, welches eine bequeme Filterung und Abfrage der Logs ermöglicht, ist von Vorteil. In vielen Fällen habe ich aber nur das lokale Systemlog und die Bordmittel wie grep, less oder more.

Ein Beispiel für diese Balance sind die Lognachrichten des SNMP-Dämons. In bestimmten Situationen will ich, neben den eigentlichen SNMP-Informationen wissen, welcher Rechner wann SNMP-Anfragen gestellt hat. Auf einem kleinen System mit begrenztem Platz für Lognachrichten würde das andere wichtige Nachrichten aus dem Puffer drängen, so dass ich dafür sorge, dass nur berechtigte Systeme SNMP-Anfragen stellen können, und nicht jede Anfrage protokolliert wird.

Noch komplexer wird es, wenn erst mehrere Lognachrichten zusammen eine Aussage zu einem Problem machen können, wie zum Beispiel beim Durchlaufen einer E-Mail durch den Server oder beim Anmelden eines VPN-Clients. Für solche komplexen Auswertungen nutze ich ein Grundgerüst eines Perl-Skripts zur Logauswertung, in das ich die spezifischen Auswertungen im konkreten Fall einfüge.

Andere fragen

Suchmaschinen

In den meisten Fällen verwende ich Auszüge aus den Systemlogs, um eine Internetsuche zu beginnen. Dabei entferne ich zu spezifische Details wie Datum, Uhrzeit, Rechnername, PID und IP-Adressen.

Wenn die ersten Ergebnisse noch keinen Hinweis auf die Lösung liefern, schaue ich in den Seiten, die meinem Problem am nächsten kommen, nach weiteren Suchworten.

Eventuell lasse ich einige Suchworte weg, falls zu wenige Ergebnisse kommen.

Manchmal kommt es vor, dass ein von der Suchmaschine gelieferter Link nicht erreichbar ist. Dann kann ich versuchen, die Version aus dem Cache der Suchmaschine anzuschauen. Wenn der Link zu einer Mailingliste ging, kann ich versuchen, ein anderes Archiv dieser Mailingliste ausfindig zu machen. Oder ich schaue nach, ob ich die Website im Internetarchiv, der Wayback Machine finde.

tip

Beinahe das Wichtigste an einer Internetsuche ist ein Zeitlimit, nach dem ich die Suche abbreche. Eventuell kann ich später, wenn ich mehr Erkenntnisse gewonnen habe, eine neue Suche starten.

Kollegen

Kollegen sind oft gute Ansprechpartner bei schwierigen Problemen. Zum einen sind sie durch die gemeinsame Arbeit mit dem konkreten Rechner oder Netzwerk vertraut, haben das gleiche Problem vielleicht schon gehabt und können sofort weiterhelfen. Zum anderen kennt man sich durch die gemeinsame Arbeit und weiß, welche Fragen man wem stellen kann.

Die andere Seite der Medaille ist, dass die Kollegen nicht dafür angestellt sind, meine Probleme zu lösen, sondern eigene haben.

Will ich also ein Problem mit einem Kollegen besprechen, sollte ich meine Hausaufgaben gemacht, selbst über das Problem nachgedacht und selbst dazu im Internet gesucht haben. Dann bin ich vorbereitet, kann dem Kollegen konkrete Fragen stellen und auf sein Nachfragen fundiert antworten.

Bevor ich meinen Kollegen befrage, schaue ich genau hin, ob er beschäftigt ist und sende gegebenenfalls die Frage als E-Mail, um seinen Arbeitsfluss nicht unnötig zu unterbrechen.

Abgesehen davon ist ein Gespräch an der Kaffeemaschine, im Gang oder in der Pause schon allein dadurch hilfreich, dass bereits das Ausformulieren des Problems Denkprozesse in Gang setzt, die zur Lösung führen können. Dann ist es sogar hilfreich, wenn der Kollege nicht zu stark mit der Materie vertraut ist, weil ich noch genauer und vor allem verständlicher formulieren muss. Auch hier gilt: halt die Kollegen nicht von der Arbeit ab.

Foren / Mailinglisten

Für Foren und Mailinglisten gilt im wesentlichen das gleiche wie für Kollegen.

Ich muss aber beachten, dass die Motivation hier zu antworten auf Freiwilligkeit beruht.

Ein sehr wichtiger Punkt ist, dass Foren und Mailinglisten öffentlich sind. Bei Fragen, die ich hier stelle, muss ich genau überlegen, inwieweit ich betriebliche Interna preisgebe.

Laborbuch

Schon seit Jahrzehnten habe ich die Angewohnheit, alle Dinge, mit denen ich mich im Laufe des Tages beschäftige, in einer DIN-A5-Kladde festzuhalten. Zwar habe ich hin und wieder auch elektronische Lösungen versucht, aber keine war für mich so praktisch wie handgeschriebene Aufzeichnungen. Da ich als Systemadministrator an verschiedenen Plätzen arbeite, brauche ich eine mobile Lösung. Und wenn ich wirklich alles notieren will, muss es schnell los gehen können. Für mich gibt es nichts schnelleres, als mein Notizbuch aufzuschlagen und drauflos zu schreiben.

Aber warum überhaupt alles aufschreiben?

Zum einen entlaste ich damit mein Gehirn. Als Systemadministrator werde ich mitunter als immer verfügbar für alles und jeden angesehen und ohne Rücksicht darauf, was ich gerade mache, mit neuen Aufträgen oder Anfragen überhäuft. Während ich E-Mails und Tickets zu einer mir genehmen Zeit bearbeiten kann, geht das bei telefonischen oder persönlichen Anfragen nicht. Selbst, wenn ich die Anforderung für den Moment abweise, ist der Arbeitsfluss zunächst einmal unterbrochen und dann kann ich das Problem auch gleich notieren um den Kopf wieder frei zu bekommen für das, was ich gerade machen wollte.

Das Laborbuch hilft mir auch, später nachzuverfolgen, was wann gemacht wurde und vielleicht auch, warum. Das sind Informationen, die sich selten in der offiziellen Dokumentation finden. Einmal spielten Teile meiner Aufzeichnungen eine nicht unerhebliche Rolle in einem Gerichtsverfahren, an dem meine Firma beteiligt war.

Schließlich habe ich einige der in diesem Buch beschriebenen Dinge alten Laborbüchern entnommen.

Was und wieviel man in ein Laborbuch schreibt, ist jedem selbst überlassen. Ich notiere meist alle notwendigen Informationen mit Ausnahme von Kennworten und Zugangsinformationen. Dadurch kann ich jederzeit Seiten aus dem Laborbuch kopieren und weitergeben.

Im Laufe der Jahre hatte ich mir bereits einen bestimmten Stil erarbeitet, als ich im WWW auf [Bullet Journal] als Methode für handgeschriebene Aufzeichnungen stieß, die sich ideal damit ergänzt. Im Laufe der Zeit wird sich dieser Stil sicher noch etliche Male ändern.

Hilfsaufgaben

Eine “Hilfsaufgabe ist eine Aufgabe, die wir nicht um ihrer selbst willen betrachten, sondern weil wir hoffen, daß ihre Betrachtung uns helfen kann, eine andere Aufgabe, unsere ursprüngliche Aufgabe zu lösen”, schreibt George Pólya in [Polya2010]. Natürlich sollte die Hilfsaufgabe einfacher zu lösen sein, als die ursprüngliche Aufgabe.

Das Ziel ist das ursprüngliche Problem, die Hilfsaufgabe ist ein Mittel zum Zweck. Das ist wichtig, wenn man mich fragt, warum ich etwas anderes mache, als ein momentan wichtiges oder dringendes Problem zu bearbeiten. Die Hilfsaufgabe, auch wenn sie nichts mit dem eigentlichen Problem zu tun hat, ist ein Baustein zur Lösung. Zumindest sollte das so sein. Ist das nicht so, muss ich mich fragen, ob ich das Problem wirklich verstanden habe.

Es kann passieren, dass ich mit einer Hilfsaufgabe lediglich nachweise, dass eine bestimmte Ursache nicht in Frage kommt. Das hilft mir insofern weiter, als ich mich nun guten Gewissens mit ganzer Kraft auf die Suche nach anderen Ursachen machen kann.

Nicht zuletzt füge ich mit einer gelösten Hilfsaufgabe meinem Werkzeugkasten neue Mittel hinzu, die mir bei zukünftigen Problemen helfen können.

Die Hilfsaufgabe kann mir auf verschiedene Weise helfen. Ich kann das Resultat für die Lösung des ursprünglichen Problems einsetzen, zum Beispiel indem ich ein Skript oder Programm schreibe, dessen Ausgabe ich weiterverwende. Oder ich nutze die Methode, mit der ich die Hilfsaufgabe gelöst habe, für mein ursprüngliches Problem. Zum Beispiel, wenn ich das Migrieren eines Dienstes oder eine spezielle Router-Konfiguration in einem Testnetz ausprobiere und dokumentiere, bevor ich meine dabei gewonnenen Kenntnisse in das Produktivsystem übertrage.

Das Lösen der Hilfsaufgabe hat den Nachteil, das ich damit Zeit und Kraft von der Lösung meines ursprünglichen Problems abziehe. Trägt die Hilfsaufgabe am Ende nicht zur Lösung des Problems bei, so ist diese Zeit und Energie verloren. Darum ist es wichtig, Hilfsaufgaben sorgfältig auszuwählen. Leider gibt es dafür keine unfehlbare Methode, so wie es keine unfehlbare Methode gibt, jedes Problem zu lösen.

Wenn ich feststecke

So etwas hat vermutlich fast jeder schon mal erlebt. Man steckt fest in einem Problem, hat alles ausprobiert, aber nichts funktioniert, das Problem ist nicht zu fassen. Entnervt lässt man es liegen, geht Essen, Schlafen oder Spazieren. Dann kommt man zurück und löst es.

Wie geht das denn?

Die beste Erklärung, die ich kenne, liegt in den zwei Modi, in denen unser Gehirn arbeitet. Es gibt verschiedene Modelle dafür, die unterschiedliche Aspekte beschreiben.

Nennen wir die beiden Modi Bewusstsein und Unterbewusstsein, dann habe ich am Anfang bewusst an dem Problem gearbeitet. In dem ich eine Pause machte, gab ich dem Unterbewusstsein Gelegenheit, sich des Problemes anzunehmen und es auf seine Art zu bearbeiten. Als ich mich wieder bewusst dem Problem zu wandte, konnte ich auf die Ergebnisse aus dem Unterbewusstsein zurückgreifen.

Das Bewusstsein nutzt einen Bereich des Gehirns, der entwicklungsgeschichtlich jung ist. Dieser Modus arbeitet langsam, dafür ist er methodisch und in der Lage, logische Schlussfolgerungen herzuleiten. Dieser Modus benötigt sehr viel Energie.

Der andere Modus nutzt entwicklungsgeschichtlich ältere Areale des Gehirns, die sich auch schon bei Reptilien nachweisen lassen. Dieser Modus arbeitet schnell, intuitiv und effizient.

Ist der bewusste Modus aktiv, schweigt der unbewusste. Durch die Pause für den bewussten Modus bekam der unbewusste Modus Gelegenheit, das Problem auf seine Art zu bearbeiten. Die Ergebnisse des Unterbewusstseins treten dann als eine Art Geistesblitz in das Bewusstsein. Natürlich müssen diese Ergebnisse noch evaluiert werden und es gibt keine Garantie, dass man immer eine Lösung für das konkrete Problem bekommt. Aber vielleicht zeigen sich Wege, wie das Problem notfalls umgangen werden kann.

Für weitere Informationen zu den Denkprozessen im Gehirn empfehle ich [Kahneman2011] und zum Thema Kreativität [Csikszentmihalyi2014].