Der beste Troubleshooter sucht nicht zuerst den Fehler

Wenn ein System anfängt sich merkwürdig zu verhalten, ist der erste Reflex oft: Logs öffnen.

Das verstehe ich. Logs fühlen sich konkret an. Da ist etwas. Eine Fehlermeldung. Ein Zeitstempel. Ein Stack Trace. Ein Code. Etwas, in das man sich verbeißen kann.

Aber gutes Troubleshooting beginnt selten damit, den Fehler zu suchen.

Gutes Troubleshooting beginnt damit, das Problem kleiner zu machen.

Denn in komplexen IT- und OT-Umgebungen ist fast alles mit allem verbunden. Eine Anwendung spricht mit einer Datenbank. Diese Datenbank läuft auf einem Server. Dieser Server ist mit einem Netzwerk verbunden. Dieses Netzwerk läuft durch Firewalls, Switches, VLANs, DNS, Zertifikate, Berechtigungen, Skripte, Schnittstellen, Benutzer, Maschinen, Prozesse — und manchmal eine Excel-Datei, von der niemand genau weiß, warum sie existiert.

Wenn man ohne Richtung zu suchen beginnt, kann man stundenlang suchen, ohne der Ursache näherzukommen.

Man liest Logs. Man sieht Warnungen. Man findet alte Fehler. Man entdeckt Abweichungen, die vielleicht schon immer da waren. Jemand ruft, es sei “definitiv die Firewall”. Ein anderer sagt “die Anwendung hat sich schon gestern komisch verhalten.” Währenddessen wächst der Druck, immer mehr Menschen werden hineingezogen, und technischer Nebel entsteht.

Alle schauen auf etwas.

Aber niemand weiß genau, welches Problem gerade gelöst wird.

Nicht: Wo ist der Fehler? Sondern: Wo hört das Problem auf?

Deshalb beginne ich lieber woanders.

Funktioniert es auf einer Workstation nicht, oder auf allen? Funktioniert es lokal, aber nicht von außen? Schlägt es bei einem Benutzer fehl, einer Rolle, einer Maschine, einem Netzwerksegment, einem Zeitpunkt, einem Dateityp, einer Produktionslinie, einem Batch, einem API-Aufruf?

Was hat vorher funktioniert? Was hat sich geändert? Was funktioniert noch?

Diese Fragen klingen einfach. Manchmal fast zu einfach. Aber sie sind oft wichtiger als die erste technische Analyse.

Ein Fehler ist Verhalten innerhalb eines Kontexts

Ein System tut etwas, das nicht erwartet wird. Aber das bedeutet nicht automatisch, dass das System selbst kaputt ist.

Ich war einmal an einer Anlage, wo eine Produktionslinie nach einem routinemäßigen Windows-Update ausfiel. Alle schauten auf die SPS-Software. Logisch, denn da war die Fehlermeldung. Aber der SPS-Code hatte sich nicht geändert. Die Umgebung hatte sich geändert.

Das Update hatte einen Treiber ersetzt, der die Kommunikation mit einem seriellen Port handhabte. Das System tat genau das, was es sollte — nur die Schicht darunter war herausgezogen worden.

Ich sehe dieses Muster immer wieder.

Die Fehlermeldung zeigt auf die Anwendung, aber die Ursache liegt in der Umgebung. Der Code hat sich nicht geändert, aber der Treiber hat. Oder das SSL-Zertifikat ist abgelaufen, während das gesamte Team in der Anwendungslogik sucht. Oder Daten werden nach einer Netzwerkänderung an das falsche Gateway weitergeleitet, und die Anwendung bekommt ein Timeout, das wie ein Bug aussieht.

Eine der schwierigsten Varianten: eine Firewall mit Deep Packet Inspection, die still einen HTTP-Header ergänzt. Die Anwendung schlägt fehl, die Anfrage sieht in den Logs normal aus, aber irgendwo auf dem Weg ist das Paket leicht anders als das, was der Server erwartet.

Man kann tagelang im Code suchen, ohne es zu finden, weil das Problem nicht im Code liegt.

Die Fehlermeldung ist nicht die Ursache. Sie ist nur die Stelle, wo das System begann, sich zu beschweren.

Ein Thermometer verursacht kein Fieber. Eine Log-Zeile verursacht keinen Ausfall. Ein Alarm auf einem HMI ist nicht automatisch das Problem in der Maschine. Es ist ein Signal. Und Signale müssen innerhalb des Ganzen gelesen werden.

Suche nach dem Kontrast

Deshalb suche ich zuerst nach Kontrast.

Das funktioniert. Das nicht. Gestern hat es funktioniert. Heute nicht. Diese Maschine reagiert normal. Jene nicht.

Dieser Kontrast ist der Einstiegspunkt.

Von dort aus kann man Hypothesen bilden. Nicht als wilde Vermutung, sondern als gangbaren Weg. Wenn das Problem nur in einem Netzwerksegment existiert, muss man nicht zuerst den gesamten Anwendungscode durchgehen. Wenn das Problem nur bei neuen Datensätzen auftritt, schaut man früher auf Daten, Validierung oder eine Prozessänderung. Wenn das Problem nur nach einer bestimmten Zeit auftritt, schaut man auf Batch-Prozesse, Zertifikate, geplante Tasks, Ressourcennutzung oder externe Schnittstellen.

Auf diese Weise ist Troubleshooting keine Suche im Heuhaufen, sondern eine kontrollierte Eingrenzung.

Erfahrung kann auch in die Irre führen

Das erfordert Disziplin. Denn es ist verlockend, direkt in die Technologie einzutauchen. Besonders wenn man technisch stark ist.

Man sieht eine Fehlermeldung und denkt: Da ist es.

Man erkennt ein Muster. Man hat so etwas schon einmal gesehen. Man möchte es lösen.

Aber manchmal sieht ein Fehler wie etwas aus, das man kennt, während die Ursache woanders liegt. Ein Datenbankfehler durch Berechtigungen. Ein Netzwerkfehler durch DNS. Ein Anwendungsfehler durch abgelaufene Zertifikate. Ein Performance-Problem durch Logging, Storage, Locking oder einen Prozess, der leicht anders läuft als zuvor.

In Software sieht man dasselbe. Ein Service schlägt fehl, weil eine nachgelagerte Abhängigkeit nach einem Update ein anderes Antwortformat zurückgibt. Alle debuggen den Service. Niemand schaut auf die Abhängigkeit.

Oder eine API funktioniert in Staging perfekt, aber bricht in Produktion zusammen. Nicht wegen des Codes, sondern wegen einer anders gesetzten Umgebungsvariable, einem anderen Zertifikat oder einer strengeren Netzwerkpolitik.

Das System beschwert sich an der falschen Stelle.

Und wenn man nur dort schaut, wo es sich beschwert, gräbt man an der falschen Stelle.

In OT ist Verhalten manchmal wichtiger als Dokumentation

In OT-Umgebungen wird das noch schärfer.

Dort ist Verhalten manchmal wichtiger als das, was auf dem Papier steht. Eine Anlage läuft seit Jahren. Die Menschen kennen aus Erfahrung, was normal ist. Eine kleine Verzögerung kann Bedeutung haben. Eine ungewöhnliche Geräusch, eine Timing-Differenz, eine manuelle Aktion oder ein alter Bypass kann Teil des echten Systems geworden sein.

In Software kennt man das auch.

Diese gespeicherte Prozedur von 2011, die niemand anzufassen wagt. Dieser try-catch-Block, der “vorübergehend” eingebaut wurde und jetzt seit drei Jahren in Produktion läuft. Dieser Legacy-Service, der eigentlich ersetzt werden sollte, von dem aber zwanzig andere Systeme abhängen.

Auf dem Papier soll es vielleicht nicht so funktionieren.

In der Praxis funktioniert es so.

Deshalb frage ich bei Ausfällen gerne die Menschen vor Ort — ob es Operatoren oder Entwickler sind:

Was ist normales Verhalten?

Nicht weil sie immer die technische Ursache kennen. Sondern weil sie oft schneller sehen, was abweicht. Sie kennen den Rhythmus des Prozesses. Sie wissen, was gestern anders war. Sie wissen, welcher Workaround seit Monaten verwendet wird. Sie wissen, welche Benachrichtigung ignoriert wird, weil sie “immer da ist.”

Diese Art von Information steht selten ordentlich in der Dokumentation. Aber sie ist oft entscheidend.

Diagnose, kein Meeting

Troubleshooting ist also nicht nur Technologie. Es ist auch das Zuhören auf Verhalten. Von Systemen, Prozessen und Menschen.

Bestimme zuerst die Grenze. Dann finde die Änderung. Dann verfolge die Abhängigkeiten. Und erst dann gehe gezielt tief.

Das verhindert auch, dass Teams sich gegenseitig unnötig beschuldigen.

In komplexen Umgebungen zeigt jeder schnell auf die Domäne jemand anderen. Development schaut auf Infrastruktur. Infrastruktur schaut auf Anwendungsmanagement. Management schaut auf Security. Security schaut auf Policy. Operations schaut auf “dieses neue Update.”

Aber eine gute Diagnose nimmt die Emotion heraus.

Nicht: Wer hat das verursacht? Sondern: Unter welchen Umständen tritt dieses Verhalten auf?

Das macht es sachlicher. Ruhiger. Und oft auch schneller.

Kontext macht den Unterschied

Beim Troubleshooting verlasse ich mich weniger auf heroisches Suchen und mehr auf systematische Eingrenzung.

Nicht weil Logs unwichtig sind. Logs sind wichtig. Monitoring ist wichtig. Metriken, Paketmitschnitte, Traces, Event Viewer, Audit-Logs und Dashboards können enorm wertvoll sein. Aber nur, wenn man weiß, wonach man sucht.

Ohne Kontext ist eine Log-Datei hauptsächlich eine Sammlung technischen Rauschens.

Mit Kontext wird sie Beweise.

Man beginnt nicht mit Graben. Man beginnt damit, zu bestimmen, wo man graben soll. Und manchmal ist der beste erste Schritt kein Befehl, keine Query, kein Dashboard.

Sondern ein paar einfache Fragen:

Was hat vorher funktioniert? Was hat sich geändert? Wo hört das Problem auf? Was ist noch stabil?