LF 6 · Serviceanfragen · 20/50 · 65 Min. angesetzt – Langform, jedes Wort zählt
Diagnose: Hypothese, Eskalation
Diagnose ist eine Kette aus Vermutung und kleinem Test. Wer fünf Dinge gleichzeitig ändert, weiß nie, was geholfen hat, und kann nichts zurückdrehen. Dieses Kapitel bleibt bei der Methode. Der Change mit Fenster und Rollback ist das nächste. Wenn du hier schon „schnell die Firewall aufmachen“ sagst, hast du die Diagnose durch Hoffnung ersetzt.
Ein Symptom ist, was der Anwender sieht. Eine Ursache ist, was du nach Messung behauptest. Dazwischen liegen Hypothesen, die scheitern dürfen. „Netz kaputt“ ist keine Hypothese. „DHCP-Relais fehlt in VLAN 20, deshalb APIPA am Platz 3.12“ ist eine: du kannst sie mit einem Blick auf den Relais-Eintrag und einem Discover am Span-Port töten oder halten. Die IHK will diese Trennung in Teil 2 genauso wie der Betrieb um 2 Uhr.
Eine Vermutung, ein Test
Du formulierst einen Satz, der falsch sein kann. Dann eine Messung oder eine kleine Änderung, die genau diesen Satz trifft – nicht die ganze Welt. Ping auf die IP des Nachbarn trifft das Segment. Ping auf den Namen trifft DNS zusätzlich. Ein tcpdump auf 67/68 trifft DHCP, nicht „das Internet“. Nach dem Test schreibst du das Ergebnis ins Ticket, auch wenn es negativ war. Negativ ist Fortschritt. Ungeschriebenes ist verloren.
Hypothese
Ein Satz, der scheitern kann. Sie nennt Ort und Mechanismus, nicht nur das Gefühl. Ohne Ort (welches VLAN, welcher Host, welcher Dienst) ist sie ein Slogan.
Test
Kleine Änderung oder Messung gegen genau diese Hypothese. Eine Variable, ein Zeitpunkt, ein erwartetes Bild. Wer DHCP, DNS und die NIC-Treiber in einem Rutsch anfasst, hat getestet, dass er beschäftigt war.
Known Error
Bekannter Fehler mit dokumentiertem Workaround oder Ursache. Pflegen, sonst zahlt jede Schicht dieselbe Stunde. Ein Known Error ohne Ticketbezug ist ein Gerücht in der Kaffeeküche.
Workaround
Weg, die Arbeit wieder möglich zu machen, ohne die Ursache tot zu haben. Darf nicht still zur Dauerlösung werden. Datum, Risiko, wer ihn kennt – sonst erbt ihn der nächste als „so haben wir das immer gemacht“.
- Symptom in einem Satz, mit Uhr und Umgebung.
- Eine Hypothese, nicht drei.
- Ein Test, der sie treffen kann.
- Ergebnis schreiben, auch das Nein.
- Nächste Hypothese oder übergeben.
Eskalation ist Übergabe, kein Abwurf
1st Level sammelt, filtert, löst den Katalog und die bekannten Handgriffe. 2nd ändert am System, liest Logs in der Tiefe, kennt die Architektur. 3rd ist Hersteller, Fachverfahren, Architekturentscheid. Funktionale Eskalation geht an die Rolle, die das System kann. Hierarchische Eskalation geht an die Leitung, weil Zeit, Vertrag oder Schaden das verlangen – nicht weil du keine Lust hast. Beides braucht denselben Stand: was gesehen, was versucht, was bewusst nicht versucht, Zeitstempel, nächster sinnvoller Schritt. Ohne das zwingst du Level 2, deine Arbeit zu wiederholen, und die SLA-Uhr läuft weiter.
1st / 2nd / 3rd
Sichtbarkeit und Tiefe, keine Rangordnung der Menschen. 1st, der den Discover nicht prüft und „Netzwerk“ nach oben schiebt, hat nicht eskaliert. Er hat den Beutel weitergereicht.
Eskalation
Übergabe mit Kontext. Zeit, Symptom, Hypothesen, Tests, Artefakte (Logzeile, Screenshot, Ticketnummer beim Lieferanten). „Bitte einmal anschauen“ ist kein Kontext.
Diagnose-Reihenfolge, die in LF 9 wiederkommt und hier schon gelten muss: leuchtet der Link. Bekommt der Client eine Adresse. Ping auf IP des Nachbarn. Ping auf Gateway. Ping auf eine äußere IP. Name auflösen. Dienstport. Wer oben bei „Outlook hängt“ beginnt, würfelt durch sieben Schichten. Schreib, auf welcher Schicht du gerade bist. Die Kammer nennt das strukturierte Fehlersuche. Der Betrieb nennt es, nicht drei Stunden im falschen Keller zu stehen.
# Klein messen, groß schreiben ping -n 4 10.20.30.1 ipconfig /all nslookup intranet.firma.example Get-WinEvent -LogName System -MaxEvents 30
Prüfung