Störungsanalyse bei Legacy-Software: Wie man Fehlerursachen systematisch findet

Freitagnachmittag. Die Bestellungen kommen nicht mehr im Warenwirtschaftssystem an. Niemand hat etwas geändert. Gestern lief alles.

Jetzt beginnt die Störungsanalyse. Und sie beginnt fast immer unter den gleichen Bedingungen: Es gibt keine Logs. Es gibt keine Dokumentation. Der Entwickler, der das System gebaut hat, arbeitet seit sechs Jahren woanders.

Diese Situation ist normal. Sie ist kein Zeichen von Nachlässigkeit. Gewachsene Software sammelt über Jahre einiges an, und die Fehlersuche gehört dazu.

Dieser Artikel zeigt, wie Sie trotzdem strukturiert vorgehen. Vom Symptom zur Ursache, in nachvollziehbaren Schritten.

Warum Raten die teuerste Methode ist

Unter Druck passiert meistens das Gleiche. Jemand vermutet etwas, ändert eine Einstellung, startet den Server neu. Manchmal hilft das. Oft macht es die Lage schlechter.

Das Problem dabei ist nicht der Neustart. Das Problem ist, dass danach niemand weiß, was eigentlich los war.

Ein Neustart löscht oft genau die Spuren, die zur Ursache führen. Temporäre Dateien verschwinden. Prozesse werden beendet. Der Speicherzustand ist weg. Der Fehler kommt drei Wochen später wieder, und die Suche beginnt bei null.

Deshalb gilt: Erst dokumentieren, dann eingreifen. Auch wenn es sich falsch anfühlt, wenn das Telefon klingelt.

Was Sie in den ersten zehn Minuten festhalten sollten

Notieren Sie das, bevor Sie irgendetwas ändern:

• Wann genau wurde die Störung bemerkt?
• Was genau funktioniert nicht, und was funktioniert noch?
• Welche Fehlermeldung erscheint, im Wortlaut?
• Wer war zuletzt am System, und was wurde gemacht?
• Gab es kürzlich ein Update, einen Serverumzug, eine Zertifikatserneuerung?

Ein Screenshot der Fehlermeldung ist mehr wert als eine Beschreibung aus der Erinnerung. Machen Sie ihn.

Schritt 1: Das Symptom sauber beschreiben

"Die Software geht nicht" ist kein Symptom. Das ist ein Gefühl.

Ein brauchbares Symptom ist konkret. "Beim Speichern eines Auftrags erscheint nach etwa 30 Sekunden eine weiße Seite. Bei Aufträgen mit weniger als zehn Positionen passiert das nicht."

Der Unterschied ist enorm. Die zweite Beschreibung enthält bereits zwei Hinweise. Die 30 Sekunden deuten auf ein Zeitlimit hin. Die Abhängigkeit von der Auftragsgröße deutet auf Speicher oder Laufzeit hin.

Gute Störungsanalyse ist zu großen Teilen gute Beobachtung.

Die drei Fragen, die den Suchraum halbieren

Tritt der Fehler immer auf oder nur manchmal? Sporadische Fehler haben andere Ursachen als dauerhafte. Sie hängen oft an Last, Uhrzeit oder bestimmten Datensätzen.

Betrifft es alle Nutzer oder nur einzelne? Wenn nur ein Nutzer betroffen ist, liegt es selten am Server. Dann geht es um Berechtigungen, Browser oder Daten.

Seit wann tritt es auf? Der Zeitpunkt ist der wichtigste Hinweis überhaupt. Alles, was in diesem Zeitfenster passiert ist, kommt als Ursache in Frage.

Schritt 2: Die Zeitachse rekonstruieren

Software ändert ihr Verhalten nicht von selbst. Wenn gestern alles lief und heute nicht mehr, hat sich etwas geändert. Auch wenn es niemand war.

Typische Änderungen, an die niemand denkt:

Zertifikate laufen ab. SSL-Zertifikate haben eine Laufzeit. Läuft eines ab, brechen Schnittstellen zu anderen Systemen weg. Die Anwendung selbst zeigt oft keine klare Fehlermeldung.

Festplatten laufen voll. Ein volles Dateisystem ist eine der häufigsten Ursachen für scheinbar unerklärliche Fehler. Datenbanken können nicht mehr schreiben, Sessions gehen verloren, Uploads scheitern.

Automatische Updates des Betriebssystems. Der Server aktualisiert im Hintergrund eine Bibliothek. Die alte Anwendung erwartet die alte Version.

Zeitumstellung und Jahreswechsel. Klingt banal, ist es nicht. Ältere Systeme rechnen an Datumsgrenzen gerne falsch.

Ein externer Dienst hat sich geändert. Ein Zahlungsanbieter schaltet ein altes Protokoll ab. Eine Versand-API ändert ihr Datenformat. Ihre Software erfährt davon nichts.

Prüfen Sie diese Punkte, bevor Sie in den Code schauen. Sie sind schnell auszuschließen und erklären erstaunlich viele Störungen.

Schritt 3: Von außen nach innen arbeiten

Eine Webanwendung besteht aus mehreren Schichten. Netzwerk, Webserver, Anwendungsserver, Anwendung, Datenbank. Der Fehler steckt in genau einer davon.

Arbeiten Sie sich von außen nach innen vor und prüfen Sie jede Schicht einzeln.

Erreicht die Anfrage überhaupt den Server? Wenn nicht, liegt es an DNS, Firewall oder Netzwerk.

Antwortet der Webserver? Eine 502- oder 504-Meldung bedeutet: Der Webserver läuft, aber die dahinterliegende Anwendung antwortet nicht.

Startet die Anwendung? Viele Legacy-Anwendungen zeigen bei einem Fehler eine leere Seite, weil die Fehlerausgabe aus Sicherheitsgründen abgeschaltet ist. Das ist richtig so, macht die Suche aber schwerer.

Antwortet die Datenbank? Testen Sie die Verbindung getrennt von der Anwendung. Eine überlastete oder gesperrte Datenbank sieht von außen aus wie ein Anwendungsfehler.

Diese Reihenfolge spart Zeit. Sie schließen mit jedem Schritt einen ganzen Bereich aus, statt überall gleichzeitig zu suchen.

Schritt 4: Logs finden, auch wenn es keine gibt

"Wir haben keine Logs" stimmt fast nie. Meistens weiß nur niemand, wo sie liegen.

Fast jeder Webserver schreibt ein Fehlerprotokoll. Bei Apache liegt es üblicherweise unter /var/log/apache2/error.log, bei Nginx unter /var/log/nginx/error.log. PHP schreibt oft ein eigenes Protokoll. Datenbanken protokollieren langsame Abfragen, wenn die Funktion aktiviert ist.

Diese Dateien sind der wichtigste Ausgangspunkt jeder Störungsanalyse. Sie enthalten Zeitstempel. Und Zeitstempel lassen sich mit dem Zeitpunkt der Störung abgleichen.

Falls wirklich nichts protokolliert wird: Schalten Sie die Protokollierung jetzt ein, nicht erst beim nächsten Vorfall. Wie ein sinnvolles Grundgerüst aussieht, beschreiben wir im Artikel zum Monitoring für Legacy-Software.

Was ist eigentlich jusched?

Bei der Suche in Prozesslisten stolpern viele über Namen, die niemand kennt. Ein Klassiker auf Windows-Servern ist jusched.exe. Dahinter steckt der Java Update Scheduler, ein Hintergrunddienst von Oracle, der nach Java-Updates sucht.

Er ist in der Regel harmlos. Aber er zeigt ein typisches Muster: Auf gewachsenen Systemen laufen Dienste, deren Zweck niemand mehr kennt. Genau diese Unklarheit macht die Fehlersuche langsam.

Wer nicht sicher ist, ob ein unbekannter Prozess legitim ist, sollte ihn prüfen statt ihn zu beenden. Bei einem konkreten Verdacht auf einen Angriff gelten andere Regeln, die wir unter Erste Schritte nach einem Angriff beschrieben haben.

Schritt 5: Die Ursache bestätigen, nicht nur vermuten

Eine Vermutung ist erst dann eine Ursache, wenn Sie den Fehler gezielt auslösen und wieder abstellen können.

Das klingt aufwändig. Es ist aber der einzige Weg, der verhindert, dass Sie dasselbe Problem in vier Wochen erneut lösen.

Praktisch bedeutet das: Bauen Sie die Bedingung nach, unter der der Fehler auftritt. Ändern Sie eine einzige Sache. Prüfen Sie, ob der Fehler verschwindet. Machen Sie die Änderung rückgängig und prüfen Sie, ob er zurückkommt.

Eine Sache pro Durchgang. Wer drei Dinge gleichzeitig ändert, weiß hinterher nicht, welche geholfen hat.

Schritt 6: Dokumentieren, damit es beim nächsten Mal schneller geht

Nach der Behebung ist vor der nächsten Störung. Fünf Zeilen reichen:

Was war das Symptom? Was war die Ursache? Was wurde geändert? Wann? Wie lässt sich das künftig verhindern?

Diese Notizen sind über die Jahre wertvoller als jedes Handbuch. Sie entstehen nebenbei und sammeln sich zu echtem Systemwissen an.

Häufen sich die Störungen, ist die einzelne Ursache selten das eigentliche Thema. Dann sind es die technischen Schulden, die sich über Jahre angesammelt haben. Welche Warnzeichen darauf hindeuten, lesen Sie in unserem Artikel zu den Warnsignalen technischer Schulden.

Was Sie vorbereiten können, bevor es brennt

Die beste Störungsanalyse ist die, für die schon alles bereitliegt. Drei Dinge machen den größten Unterschied:

Protokollierung aktiviert und aufbewahrt. Ohne Logs suchen Sie im Dunkeln. Mit Logs suchen Sie gezielt.

Eine einfache Übersicht der Systemlandschaft. Welche Server, welche Dienste, welche Schnittstellen nach außen? Eine Seite reicht.

Ein Notfallplan mit Zuständigkeiten. Wer entscheidet? Wer hat Zugänge? Wen ruft man an? Mehr dazu im Artikel zum Notfallplan für kritische Altsoftware.

Diese Vorbereitung kostet wenige Stunden. Im Ernstfall spart sie Tage.

Fazit: Struktur schlägt Erfahrung

Gute Störungsanalyse ist keine Frage von Genie. Sie ist eine Frage von Methode.

Symptom sauber beschreiben. Zeitachse rekonstruieren. Von außen nach innen prüfen. Logs lesen. Ursache bestätigen. Ergebnis festhalten.

Wer so vorgeht, findet die Ursache auch in einem System, das niemand mehr vollständig kennt. Und wer es einmal dokumentiert hat, findet sie beim nächsten Mal in Minuten statt in Tagen.

Sie stecken gerade in einer Störung fest und kommen nicht weiter? Wir übernehmen die Systemanalyse im Notfall auch für Systeme, die wir nicht gebaut haben. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.