Root-Cause-Analyse im Support: Warum die Ursache selten dort liegt, wo das Symptom auftritt

„Die Website ist seit heute Morgen extrem langsam.“ So beginnt ein typisches Ticket. Der erste Blick geht zum Webserver, zum PHP-Prozess, zum Cache. Die eigentliche Ursache liegt aber oft ganz woanders – zum Beispiel auf einem anderen Server, den der Kunde nie zu Gesicht bekommt.

Symptom und Ursache sind zwei verschiedene Orte

Ein Symptom ist der Punkt, an dem ein Mensch einen Fehler bemerkt. Die Ursache ist der Punkt, an dem er entsteht. Dazwischen liegen oft mehrere Systeme. Drei typische Muster aus dem Alltag:

• Die Website ist langsam – Ursache: ein voller Datenträger auf dem Datenbankserver. Die Datenbank kann nicht mehr sauber schreiben, Abfragen hängen, und der Webserver wartet.
• Mails kommen nicht an – Ursache: ein abgelaufenes Zertifikat beim Relay. Der Mailserver des Absenders arbeitet korrekt, nur die TLS-Verbindung zum nächsten Hop scheitert.
• Der Login schlägt fehl – Ursache: eine Uhr, die drei Minuten nachgeht. Zeitbasierte Verfahren wie TOTP-Codes oder SAML-Assertions mit Gültigkeitsfenster vertragen nur wenig Abweichung.

In allen drei Fällen wäre ein Neustart des betroffenen Dienstes nutzlos oder höchstens kurzfristig hilfreich. Das Ticket wäre vielleicht geschlossen, das Problem aber nicht gelöst.

Workaround oder Ursache?

Workarounds sind nicht schlecht. Wenn ein Kunde nicht arbeiten kann, hat die Wiederherstellung des Betriebs Vorrang. Ein Dienst-Neustart, ein manuell geleertes Verzeichnis, ein temporär angepasster Eintrag – alles legitim.

Wichtig ist nur, dass man es benennt: „Das ist ein Workaround.“ Danach kommt die zweite Frage: Warum ist es passiert, und was verhindert, dass es wieder passiert? Ein Workaround schließt das Ticket. Erst die Root-Cause-Analyse verhindert das nächste.

Ein einfaches Vorgehen

Für die Ursachensuche braucht es kein schweres Framework. Diese Schritte haben sich bewährt:

1. Zeitpunkt eingrenzen. Seit wann genau? Ein Zeitstempel macht aus einer vagen Beschreibung eine Spur in den Logs.
2. Fragen, was sich geändert hat. Update, Deployment, neue DNS-Einträge, abgelaufene Zertifikate, Wartung beim Anbieter. Systeme gehen selten ohne Grund kaputt.
3. Die Kette entlanggehen. Vom Nutzer über DNS, Netzwerk, Webserver, Anwendung und Datenbank bis zum Speicher. An jedem Glied prüfen: Funktioniert es isoliert?
4. Mehrmals „Warum?“ fragen. Die Website ist langsam – warum? Die Datenbank antwortet nicht – warum? Die Platte ist voll – warum? Ein Log wird nicht rotiert. Erst dort lässt sich dauerhaft ansetzen.
5. Die Ursache bestätigen. Eine Hypothese ist erst dann eine Ursache, wenn die Behebung das Symptom auch wirklich beseitigt.

Die ersten Minuten auf einem Linux-Server

Viele Ursachen lassen sich mit wenigen Standardbefehlen finden, bevor man in die Tiefe geht:

df -h                          # Speicherplatz
df -i                          # Inodes
timedatectl                    # Uhrzeit und NTP-Synchronisation
systemctl --failed             # fehlgeschlagene Dienste
journalctl -p err --since "1 hour ago"
uptime                         # Last und Laufzeit

Für Zertifikate auf einem entfernten Dienst hilft ein Blick auf das Ablaufdatum:

openssl s_client -connect mail.beispiel.de:465 -servername mail.beispiel.de </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate

Das ersetzt keine Analyse, aber es schließt in zwei Minuten die häufigsten Kandidaten aus: volle Datenträger, falsche Uhrzeit, gestoppte Dienste, abgelaufene Zertifikate.

Dokumentieren, damit es nicht wiederkommt

Eine gute Ursachenanalyse endet mit wenigen klaren Sätzen: Was war das Symptom, was die Ursache, was wurde kurzfristig getan und was ändert sich dauerhaft? Zum Beispiel Monitoring für den Datenträger, eine Erinnerung vor Ablauf des Zertifikats, eine korrekt laufende Zeitsynchronisation.

Diese Notiz hilft dem Kollegen, der denselben Fall in drei Monaten sieht – und oft auch einem selbst.

Checkliste

• Genauen Zeitpunkt des ersten Auftretens festgehalten?
• Änderungen im Zeitraum davor geprüft?
• Die ganze Kette geprüft, nicht nur den Ort des Symptoms?
• Speicherplatz, Uhrzeit, Dienste und Zertifikate ausgeschlossen?
• Workaround als solcher benannt?
• Ursache durch die Behebung bestätigt?
• Dauerhafte Maßnahme und kurze Dokumentation festgehalten?

Die zusätzliche halbe Stunde für die Ursache wirkt im Moment wie Luxus. Über Wochen gerechnet ist sie die günstigste Zeit, die man im Support investieren kann.