Troubleshooting-Grundlagen ohne Fachchinesisch

Heute gibt es mal, passend für einen Geschäftsführer, abstrakte Kost: Ein Troubleshooting Tutorial, wo kein einziges Wort über spezielle Technologien verloren wird, sondern vielmehr ein allgemeiner Lösungsansatz und Vorgehensplan skizziert wird. Es geht um Entspannungstechniken, geistige Grundeinstellung gegenüber dem Problem und zu guter Letzt auch um systematische Lösunsgansätze.

01: Keine Panik!

Ein allseits bekanntes Buch bringt es auf den Punkt, was der Mediziner in der Theorie und fast jeder in der Praxis kennt. Das Ausschütten von Stresshormonen (Adrenalin) ist nicht sonderlich hilfreich, wenn man klar denken muss. Als wir vor 50.000 Jahren noch in Afrika auf den Bäumen hockten, war es sehr hilfreich beim Anblick eines Problems (i.d.R. ein Löwe oder ähnliches Getier) Adrenalin auszuschütten. Bei Problemen des 21. Jahrhunderts hilft es jedoch eher selten mit einem 190er Puls und weit aufgerissenen Augen vor der Konsole zu sitzen. Daher bieten sich Entspannungstechniken sowohl für Profis als auch für Anfänger an.

Eine Frageliste kann helfen:

1. Ist Leib und Leben in Gefahr? (z.B. hungriger Löwe auf Tastatur)
2. Ist die Firma in Gefahr? (z.B. unternehmensweiter Datenverlust )
3. Ist (D)ein Arbeitsplatz in Gefahr? (z.B. Produktionsausfall mit hohen Kosten?)
4. Was passiert, wenn nix passiert?
   • Diese Frage zielt nicht darauf ab stoisch in der Ecke zu sitzen und abzuwarten, sondern beantwortet sie vielmehr auf indirekte Weise die Zeitdauer, bis ein Problem „gefährlicher“ wird.
     Beispiel: Wenn der Backupserver 3h nicht geht, ist das i.d.R. nicht so schlimm. Wenn er aber 3 Monate nicht geht, kann das sehr schnell die ganze Firma in Gefahr bringen, wenn ein kritischer Datenverlust auftritt.

Oftmals sind nach Beantwortung dieser Fragenkette Puls und Blutdruck auch ohne medikamentöse Unterstützung wieder in dem Bereich, wo man halbwegs klar denken kann. Danach kann man sich der wichtigsten Frage überhaupt widmen:

02: Was ist denn überhaupt das Problem?

Oftmals wird während der operativen Hektik vergessen, das Problem zu beschreiben oder besser zu verstehen. Dazu müssen folgende Grundregeln beachtet werden:

1. KEINE ANNAHMEN!!!
   • Für alle Aussagen müssen Belege gesammelt bzw. genannt werden. Alles ohne Beleg ist bei der Problemerfassung erst mal wertlos, da es nur eine Hypothese ist. Diese kann man sich für später aufheben, denn da braucht man solche Hypothesen, sofern diese bis dahin noch „leben“.
   • Wichtig ist aber auch, dass sich die Datensammlerei nicht zu einem Exzess ausbildet und man nie über Schritt 02 hinauskommt.
     Profitipp: Wenn man feststellt, dass man nicht genug Belege hat, um bei Schritt 04 (Hypothesen prüfen) weiterzumachen, kann man ohne Scham zurück zum Datensammeln gehen. Das ist nix Schlimmes, man muss sich nur der Tatsache bewusst sein, dass man das tut. 🙂
2. Versuche das Gesamtkonstrukt und den Kontext zu verstehen.
   • Oftmals sind IT-Infrastrukturen ziemlich komplex und man bekommt mindestens genauso oft nur einen kleinen Teil „vorgesetzt“, weil der „Melder des Problems“ schon vermeintlich das Problem eingegrenzt hat.
   • Wenn es Komponenten im Gesamtkonstrukt gibt, die Ihr nicht versteht, dann schaut zu, dass Ihr es tut.
     • Variante 1: Fragt jemanden, der sich (wirklich) auskennt. Auch hier: Keine Annahmen!
     • Variante 2: Lest das Handbuch (ja solche Dinge sind zum Lesen da).
     • Variante 3: Versucht zu abstrahieren (Beispiel: Ich kenne keinen Mercedes-Antrieb, ich weiss aber wie ein Verbrennungsmotor funktioniert!). Gefahr ist, dass man hier falsche Abstraktionen betreibt. (Elektoauto kann sicherlich nicht mit Diesel/Benziner Kenntnissen repariert werden.) Seid euch dieser Gefahr bewusst und bevorzugt dann lieber Variante 1 oder 2.

Nachdem man sich diese Grundregeln verinnerlicht hat, kann man dann folgende recht triviale Frageliste abarbeiten, die uns recht schnell zu einer qualifizierten Problembeschreibung führt:

1. Wer/Was genau hat das Problem?
   • Welche Person oder Personengruppe?
   • Welche Systeme?
   • Welche Seite?
   • Welche Teilkomponente?
   • Gegenfrage: Wer hat das Problem nicht? Dies hilft oftmals, das Problem besser zu begreifen.
2. Wann trat/tritt das Problem bzw. Symptom auf?
   • Zeitpunkt?
   • Nachdem XYZ gemacht wurde?
     Profitipp: Wenn man „Wir haben nix gemacht“ hört, kann man davon ausgehen, dass was gemacht wurde – In Härtefällen kann man „Ich habe gefragt was geändert wurde und nicht was nicht geändert wurde.“ entgegensetzen 😉
   • Nach Ereignis XYZ?
3. Wie stellt sich das Problem dar?
   • Hier braucht es eine genaue und detaillierte Fehlerbeschreibung.
     Profitipp: „Es geht nicht“, ist nicht genau und nicht detailliert! Hier weitere Fragetechniken anwenden 😉
4. Bis wann muss das Problem behoben sein, bis es schlimmere Konsequenzen hat? (Vgl. dazu auch „Was passiert, wenn nix passiert?“ aus 01: Keine Panik)

03: Provisorium installieren

Oftmals kann die Situation entspannt werden (und damit auch die eigene Einstellung zum Problem), indem ein temporäres Provisorium installiert wird. Das einzige, was man hierbei beachten sollte, ist, dass es wirklich temporär bleibt und man sich weiterhin an die Ursachenforschung macht und nicht Fünfe gerade sein lässt.

04: Hypothesen aufstellen und prüfen

Nachdem das Problem eindeutig beschrieben wurde, kann man sich an den kreativen Teil der Arbeit wagen und Hypothesen aufstellen, was die Ursache des Problems ist und sich dann daran machen diese zu verifizieren.

Hilfreich an der Stelle ist folgendes Vorgehen:

1. Bewerte die Hypothesen nach Wahrscheinlichkeit und Einfachheit der Verifizierung und sortiere danach.
   Hier kann gerne das Bauchgefühl helfen, ist ja schließlich Kreativarbeit.
2. Gehe zuerst die „Quick Wins“ (Hohe Wahrscheinlichkeit und Einfachheit der Verifizierung) an.
3. Sobald es einen Gegenbeweis für die Richtigkeit einer Hypothese gibt, diese zu den Akten legen und nicht mehr weiterverfolgen!
4. Beim Prüfen der Hypothesen wie folgt vorgehen:
   1. Fang in der Mitte an!
      Wenn das Problem an mehreren Stellen liegen könnte, an einer Stelle mit der Suche einsteigen, die genau in der „Mitte“ liegt um auszuschließen, ob es in den oberen oder unteren 50% liegt.
   2. Kreuzproben!
      Hast Du ein defektes Teil/Dings/Bums im Verdacht, dann kannst Du es entweder tauschen oder noch besser versuchen den Fehler an einer anderen Stelle wieder auftauchen zu lassen, indem Du es dorthin installierst. Das hilft Defekte in anderen Teilen auszuschließen.
   3. Und natürlich: Keine Annahmen!
      Prüfen bedeutet nicht vermuten, aber das steht ja schon oben geschrieben.

Wie schon gesagt ist dieser Teil der Arbeit eine Kreativleistung. Sollte man sich nicht in der Verfassung befinden diese zu erbringen, gibt es folgende Möglichkeiten:

1. Bitte einen Kollegen um Hilfe, der vielleicht mehr Abstand zur Sache hat.
2. Gehe zurück zu Schritt 01 (Keine Panik) , Schritt 02 (Informationen sammeln) oder 03 (Provisorium installieren) um Deine geistige Grundhaltung gegenüber dem Problem zu verbessern.

05: Fehler und(!) Ursache beseitigen

Hat man den Fehler gefunden, kann man sich Gedanken machen, wie man ihn beseitigt. Mindestens genauso wichtig ist es aber bei wiederkehrenden Fehlern die Ursache zu beseitigen.Es kommt ja niemand auf die Idee dauernd brennende Tankstellen zu löschen, anstatt dort Brandschutzmaßnahmen umzusetzen.

Sonstige nützliche Informationen

Gerade bei größeren Eskalationen haben sich folgende Praktiken bewährt:

1. Teamwork
   Zusammen ist man besser, das weiss man spätestens, wenn man mal in einer gut aufeinander abgestimmten Fußballmanschaft gespielt hat. Ideal ist es, wenn man in einem Team die Leute nach ihren Stärken einsetzt und ihnen Rollen (Schriftführer, Systematiker, Kreativling, Redner, Führer, Gute Fee, …)  zuweist, die sie gut erfüllen können.
2. Proaktiv und reaktiv Informieren
   Es gibt für Anwender und Kunden nichts Schlimmeres als nichts zu wissen, daher sollte man auf jeden Fall immer über das Problem und den Fortschritt informieren. Wenn man sich nicht sicher ist, ob eine Information richtig ist, sollte diese als ebensolche Information markiert werden. (Beispiel: Wir schätzen, dass in 2h alles normal ist, wir können es aber nicht garantieren).
   Hier bietet sich an, auf das oben genannte Teamwork zurückzugreifen und fest jemandem aus dem Team abzustellen, der die Informationen routet, während die anderen ungestört arbeiten können.
   Profitipp: Ein hysterischer Chef, der ständig beim Debuggen durch Fragen nervt, ist eine ideale Besetzung für diese Aufgabe (Er hilft, ist informiert und er kann das tun, was er (hoffentlich) am Besten kann: Informieren und zu der Sache stehen.)
3. Die Zeit im Auge behalten
   Zum einen sollte man bei den Informationen an den Kunden bzw. Anwender immer sinnvoll geschätzte Entstörzeiten angeben, zum anderen sollte man rechtzeitig erkennen, dass man ein Problem eventuell nicht lösen kann.
   Die Erkenntnis, dass man ein Problem nicht lösen kann und der angemessene Umgang damit, ist sehr wichtig. Für diesen Fall müssen andere Maßnahmen bereit stehen (Notbetrieb, RollBack, …) und man darf sich nicht scheuen diese rechtzeitig zu ergreifen.
4. Schadensbegrenzung auch mit unüblichen Methoden
   Wenn man mit normalen Methoden nicht mehr zum Ziel kommt, bitte auch (ungefährliche) unübliche Methoden verwenden.
   Beispiel: Wenn ein System zwar offiziell 100% Verfügbarkeit abbilden muss, aber ein Reboot das Problem beseitigen würde, dann ist es manchmal sinnvoller den Reboot unter Schmerzen durchzuboxen anstatt an dem Paradigma der 100% Verfügbarkeit festzuhalten.

Danke und Nachwort

Mein Dank geht hier an der Stelle an Oli und Benny. Oli, weil er mich auf die Idee gebracht hat, mal was „Nichttechnisches“ zu schreiben und Benny, weil er gleich darauf angesprungen ist und mich mit einer 3 Meter eMail überschüttet hat, die man nur etwas umformulieren und etwas sortieren musste um diesen Artikel zu schreiben. Daher ist Benny (Benjamin Ulsamer) auch explizit als Co-Autor genannt.

Wie immer sind positive und kritische Kommentare erwünscht, schließlich ist Feedback jedweder Art ein Ausdruck von Anerkennung für einen Autor.

Links und Ressourcen

Gute Slides zu Problemlösungsmethoden: http://www.emagister.de/uploads_courses_de/Folienauszuege_Problemloesungsmethoden.pdf

UPDATE 1 (2014-07-09 04:11):

Wenn Du denkst dass ein Herstellersupport Dir das Denken abnehemen wird, bist Du falsch gewickelt. Da arbeiten bestenfalls Expertensysteme, die die eigene Infrastruktur nicht kennen. Das Denken wird einem definitv nicht abgenommen…

UPDATE 2 (2018-07-05 10:30):

Artikel durch Zufall (aka Ronnys Kommentar) wiedergefunden, durchgelesen und nach wie vor für gut befunden. Eine wichtige Sache habe ich euch damals unterschlagen und zwar, dass man das „Teamwork“ Thema noch besser skalieren kann indem man sich „extern“ Hilfe/Wissen sucht. Das können Usergruppen, Kollegen in anderen Ländern, Bekannte bei befreundeten Unternehmen, Kunden (Ja, man kann auch mal einen Kunden fragen wie er was gelöst hat), u.v.m. sein. Ich nenne es mal „echtes soziales Netzwerk“. Seid vorsichtig mit Forenbeiträgen, weil sich da oft sehr viele Idioten und Trolle tummeln, daher die Infos immer verifizieren(Ist es das was ich will?) und validieren(Geht es technisch?).

Richard Müller

Richard Müller ist Geschäftsführer der Proact Deutschland GmbH. Den "kreativen" Umgang mit Computern und Datennetzen lernte er schon im Schulalter. Bis heute hat Richard eine Begeisterung für technisch brilliante Konzepte und Lösungsansätze in den Bereichen IT-Infrastruktur - hier vor allem alles rund ums Netzwerk.