Ein systematischer Troubleshooting-Workflow für Linux-Server

1. Warum planloses Troubleshooting scheitert

Im Ernstfall neigen selbst erfahrene Administratoren dazu, unter Zeitdruck wahllos Maßnahmen auszuprobieren: den Dienst neu starten, den ganzen Server rebooten, eine vermutete Konfigurationsänderung zurücknehmen, alles am besten gleichzeitig. Jede dieser Aktionen verändert den Systemzustand, bevor die eigentliche Ursache überhaupt bekannt ist. Verschwindet der Fehler danach, bleibt unklar, welche der Maßnahmen tatsächlich gewirkt hat, und das Problem kann jederzeit unbemerkt zurückkehren. Genau dieser Modus, oft als Shotgun-Debugging bezeichnet, verlängert Incidents im Schnitt deutlich, weil jede undokumentierte Änderung neue Variablen einführt, die die nächste Diagnose zusätzlich erschweren.

Ein systematischer Troubleshooting-Workflow löst dieses Problem, indem er eine feste Reihenfolge vorschreibt: erst verifizieren, dass wirklich ein Ausfall vorliegt, dann prüfen, was sich zuletzt geändert hat, danach Ressourcen in einer festen Abfolge von Load über Memory und Disk bis Netzwerk durchgehen, und erst danach gezielt in Logs suchen, beginnend beim aktuellsten Eintrag. Diese Reihenfolge ist kein Zufall: Jeder Schritt schließt eine ganze Fehlerklasse aus oder bestätigt sie, bevor der nächste beginnt. Das Ergebnis ist ein reproduzierbarer Ablauf, den jedes Teammitglied im Bereitschaftsdienst gleich anwenden kann, unabhängig von individueller Erfahrung mit dem betroffenen System.

2. Schritt 1: Ist der Dienst wirklich down?

Bevor überhaupt etwas verändert wird, steht die Verifikation: Liegt tatsächlich ein Ausfall vor, oder handelt es sich um einen Fehlalarm aus einem defekten Monitoring-Check, einer falsch konfigurierten Firewall-Regel, die nur den Monitor blockiert, oder einem einzelnen fehlerhaften Messpunkt? Ein Health-Check direkt auf dem Server mit curl gegen localhost, kombiniert mit einer Prüfung von außerhalb des Netzwerks, deckt genau diese Fälle zuverlässig auf. Wer diesen Schritt überspringt und sofort in die Tiefe geht, verschwendet regelmäßig Zeit mit der Diagnose eines Problems, das gar nicht existiert.

Wichtig ist außerdem die Unterscheidung zwischen drei völlig unterschiedlichen Zuständen: der Dienst ist komplett abgestürzt, der Dienst läuft, antwortet aber langsam oder mit Fehlern, oder es handelt sich um einen reinen Fehlalarm. Ein abgestürzter Prozess hinterlässt meist einen klaren Exit-Code und eine Stacktrace im Journal, während ein langsamer, aber laufender Dienst fast immer auf Ressourcenknappheit hindeutet, die erst die folgenden Schritte zu Load, Memory, Disk und Netzwerk aufdecken. Diese frühe Einordnung entscheidet, wie viel Zeit die weiteren Schritte in Anspruch nehmen werden.

#!/usr/bin/env bash
# Step 1: verify the outage is real before touching anything
systemctl status nginx --no-pager
# Active: active (running) since Fri 2026-07-12 08:14:02 UTC; 3h ago -> unit is up

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" http://localhost/health
# 200 0.041s -> local health check succeeds

# Check from an external vantage point too, monitoring can be blind locally
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://shop.example.com/health

# Confirm the process is actually running, not just the unit file loaded
pgrep -a nginx || echo "No nginx process found"

3. Schritt 2: Was hat sich geändert?

Die meisten Incidents werden nicht durch spontanen Hardware-Verschleiß ausgelöst, sondern durch eine konkrete Änderung: ein Deployment, ein Paket-Update, einen Cron-Job, einen Config-Management-Lauf oder ein abgelaufenes Zertifikat. Der Abgleich des Ausfallzeitpunkts mit dem Zeitpunkt der letzten Änderung ist deshalb oft der einzelne wertvollste Diagnoseschritt im gesamten Workflow, noch bevor eine einzige Logzeile im Detail gelesen wurde. Wer diesen Schritt vor der Ressourcenanalyse durchführt, findet die Ursache in vielen Fällen bereits in wenigen Minuten.

Konkret lohnt sich der Blick auf mehrere Quellen gleichzeitig: journalctl zeigt Neustarts und Fehler betroffener Dienste im relevanten Zeitfenster, /var/log/apt/history.log beziehungsweise /var/log/dpkg.log dokumentieren Paket-Updates, crontab -l und /etc/cron.d zeigen geplante Jobs, und git log im Deployment-Repository liefert die exakte Uhrzeit des letzten Rollouts. Bei Einsatz von Ansible oder Puppet gehört auch die Run-History dieser Tools zur Prüfliste. Fällt der Ausfallbeginn mit einem dieser Ereignisse zusammen, ist die Ursache mit hoher Wahrscheinlichkeit bereits gefunden.

#!/usr/bin/env bash
# Step 2: correlate incident start time with recent changes
uptime -s                                   # last reboot time
journalctl --since "2 hours ago" -u nginx.service --no-pager | tail -30

# Package changes in the relevant time window
grep "2026-07-12" /var/log/apt/history.log
zgrep "2026-07-12" /var/log/dpkg.log* 2>/dev/null

# Cron jobs that ran around the incident
grep CRON /var/log/syslog | grep "12:1[0-5]"

# Deployment history in the application repository
cd /var/www/shop && git log --oneline --since="3 hours ago"

# Configuration management run history (if Ansible/Puppet is used)
ls -la /var/log/ansible/ | tail -5

4. Schritt 3: Load und CPU prüfen

Erst nach der Verifikation und dem Änderungsabgleich beginnt die eigentliche Ressourcenanalyse, und sie startet bewusst mit Load und CPU, weil diese Kennzahl mit einem einzigen uptime-Befehl abrufbar ist und den Incident sofort grob einordnet: rechenlastig oder wartend. Eine Load Average deutlich über der Anzahl verfügbarer Kerne, kombiniert mit hoher CPU-Auslastung in top, deutet auf einen rechenintensiven Prozess hin, während eine hohe Load bei niedriger CPU-Auslastung fast immer I/O-Wartezeit bedeutet, was den nächsten Verdacht bereits in Richtung Disk oder Netzwerk lenkt.

top beziehungsweise htop, sortiert nach CPU-Spalte, zeigt in Sekunden, ob ein einzelner Prozess außer Kontrolle geraten ist, etwa nach einem fehlerhaften Deployment mit einer Endlosschleife. mpstat -P ALL 1 deckt zusätzlich auf, ob die Last gleichmäßig über alle Kerne verteilt ist oder ob ein Single-Thread-Prozess einen einzelnen Kern vollständig auslastet, während andere Kerne im Leerlauf bleiben und die gemittelte Load Average das verschleiert. Diese Feinheit entscheidet oft, ob ein Neustart des Prozesses ausreicht oder ob eine strukturelle Anpassung nötig ist.

; /etc/troubleshooting/thresholds.ini
; Load and CPU thresholds used during triage, step 3 of the workflow
[load]
warning_per_core = 1.0
critical_per_core = 2.0
sustain_minutes = 10

[cpu]
warning_iowait_percent = 20
warning_steal_percent = 5

; Rule of thumb: escalate on the sustained 15-minute value, not on a 1-minute spike

5. Schritt 4: Speicher und Swap prüfen

Speicher wird direkt nach Load und CPU geprüft, weil Speicherdruck sich häufig wie ein Disk- oder Performance-Problem tarnt: Ein System, das aktiv swappt, wirkt langsam, obwohl die eigentliche Ursache im RAM liegt. free -h liefert einen schnellen Überblick über belegten, freien und für Puffer und Cache genutzten Speicher, während vmstat 1 in den Spalten si und so zeigt, ob gerade aktiv in den Swap geschrieben oder aus ihm gelesen wird. Kontinuierliches Swapping unter Last ist ein zuverlässiges Zeichen für echten Speichermangel, kein normaler Betriebszustand.

Ein zweiter, oft übersehener Check ist die Suche nach dem OOM-Killer: dmesg -T | grep -i "killed process" zeigt, ob der Kernel einen Prozess wegen Speichermangels gewaltsam beendet hat, häufig ohne dass der Prozess selbst eine aussagekräftige Fehlermeldung hinterlässt. Bei Magento- und PHP-Umgebungen sind typische Ursachen eine zu groß konfigurierte PHP-FPM-Pool-Größe im Verhältnis zum verfügbaren RAM, ein wachsender OPcache ohne Limit, oder ein Speicherleck in einem Hintergrundprozess, das erst nach Stunden im Betrieb sichtbar wird.

6. Schritt 5: Disk und Dateisystem prüfen

Nach Speicher folgt Disk, denn volle Dateisysteme oder erschöpfte Inodes erzeugen Fehlerbilder, die auf den ersten Blick wie Anwendungsfehler aussehen: fehlgeschlagene Schreibvorgänge, abgebrochene Log-Rotationen, verweigerte Datenbank-Commits. df -h zeigt den belegten Speicherplatz je Partition, doch das reicht nicht aus: df -i zeigt die Anzahl freier Inodes, und ein Dateisystem mit reichlich freiem Speicherplatz kann trotzdem vollständig unbrauchbar sein, wenn Millionen kleiner Dateien, etwa Sessions oder Cache-Einträge, alle verfügbaren Inodes verbraucht haben.

Ist ausreichend Platz und genug Inodes vorhanden, aber die Symptome bleiben, lohnt sich der Blick auf die I/O-Ebene mit iostat -xz 1, das Wartezeiten und Auslastung je Blockgerät zeigt. Ein weiterer wichtiger Check nach Disk-Fehlern im Kernel-Log ist eine unbeabsichtigte Read-Only-Remountierung des Dateisystems, sichtbar in dmesg nach einem Hardwarefehler. Gelöschte, aber noch geöffnete Dateien, die weiterhin Speicherplatz belegen, lassen sich mit lsof +L1 aufspüren, ein häufiger, aber selten vermuteter Grund für unerklärlich vollen Speicherplatz.

7. Schritt 6: Netzwerk prüfen

Netzwerkprobleme kommen im Workflow zuletzt vor den Logs, weil sie meist erst relevant werden, wenn Load, Memory und Disk bereits ausgeschlossen wurden. ss -tulnp zeigt, ob der betroffene Dienst tatsächlich auf dem erwarteten Port lauscht, ein überraschend häufiger Fehler nach einem fehlgeschlagenen Neustart, bei dem der Prozess zwar läuft, aber an einen falschen Port oder ein falsches Interface gebunden ist. ss -tan state established zeigt zusätzlich, ob eine ungewöhnlich hohe Anzahl offener Verbindungen die verfügbaren File-Descriptors erschöpft.

Bei Verbindungsproblemen zu abhängigen Systemen wie Datenbank, Redis oder externen APIs helfen einfache Basischecks: DNS-Auflösung mit dig oder getent hosts, ein direkter Verbindungstest mit nc -zv host port, und die aktuellen Firewall-Regeln mit nft list ruleset beziehungsweise iptables -L -n. Paketverlust oder erhöhte Latenz auf dem Pfad zeigt mtr deutlich zuverlässiger als ein einfacher ping, weil es die Route hop-für-hop mit Verlustraten darstellt und so einen einzelnen defekten Netzwerksegment lokalisieren kann.

8. Schritt 7: Logs richtig lesen, neueste zuerst

Logs stehen bewusst am Ende des Workflows, nicht am Anfang, weil sie die zeitaufwändigste und am wenigsten strukturierte Informationsquelle sind. Wer direkt mit den Logs beginnt, durchsucht oft riesige Datenmengen ohne Hypothese, während nach den vorherigen Schritten bereits ein enger Verdacht vorliegt, der die Suche gezielt eingrenzt. Entscheidend ist außerdem die Leserichtung: journalctl -r oder tail -f zeigen die neuesten Einträge zuerst, weil der aktuellste Eintrag am wahrscheinlichsten mit dem gerade beobachteten Symptom zusammenhängt, statt sich von oben durch Megabyte alter, irrelevanter Zeilen zu scrollen.

Der zweite entscheidende Kniff ist die Korrelation über mehrere Logquellen hinweg: Anwendungs-Log, Webserver-Log, systemd-Journal und Kernel-Meldungen aus dmesg müssen im exakt selben Zeitfenster betrachtet werden, das bereits im Schritt "Was hat sich geändert" identifiziert wurde. journalctl --since "12:10" --until "12:20" grenzt die Suche präzise ein und verhindert, dass irrelevante Einträge aus einer ganz anderen Zeitperiode die Diagnose verwässern. Strukturierte Ausgabe mit journalctl -o json und jq-Filterung erleichtert die maschinelle Weiterverarbeitung bei größeren Logmengen zusätzlich.

{
  "_comment": "journalctl -o json --since 12:10 --until 12:20 -u php8.3-fpm | jq",
  "unit": "php8.3-fpm.service",
  "timestamp": "2026-07-12T12:14:02Z",
  "priority": "err",
  "message": "WARNING: [pool www] seems busy (you may need to increase pm.max_children)",
  "pid": 28471
}

9. Dokumentation, Eskalation und der Workflow im Vergleich

Dokumentation gehört nicht erst nach dem Incident dazu, sondern beginnt mit der Verifikation des Ausfalls. Ein gemeinsam sichtbares Dokument oder ein dedizierter Chat-Kanal, in dem Zeitstempel, geprüfte Hypothesen, Befunde und angewendete Maßnahmen laufend notiert werden, verhindert doppelte Prüfungen bei einer Übergabe zwischen Bereitschaftspersonen und wird später fast unverändert zur Grundlage des Postmortems. Wer erst nach Abschluss des Incidents aus dem Gedächtnis rekonstruiert, was wann geprüft wurde, verliert regelmäßig wichtige Details und Zeitangaben.

Ebenso wichtig wie die Dokumentation ist ein klares Eskalationskriterium, festgelegt bevor der nächste Incident beginnt, nicht währenddessen. Ein festes Zeitfenster ohne messbaren Fortschritt, etwa dreißig Minuten, oder das Überschreiten einer definierten Auswirkungsschwelle, etwa Umsatzausfall oder betroffene Kernfunktionen, sind objektive Auslöser, die eine Eskalation ohne Diskussion unter Zeitdruck ermöglichen. Frühes Eskalieren mit einer zweiten, frischen Perspektive ist fast immer wirkungsvoller als stundenlanges einsames Weitergraben, selbst wenn die eigene Erfahrung im System hoch ist.

Die folgende Übersicht stellt die verbreiteten Anti-Pattern den empfohlenen Schritten dieses Workflows direkt gegenüber.

Die Tabelle zeigt ein durchgängiges Muster: Jedes unsichere Vorgehen ersetzt einen strukturierten Schritt durch Zufall oder Einzelkämpfertum. Wer die rechte Spalte konsequent als festen Ablauf etabliert, verkürzt nicht nur die Downtime des einzelnen Incidents, sondern baut über die Zeit ein Runbook auf, das neue Teammitglieder direkt einsatzfähig macht.

# incident-log-2026-07-12-1214.yaml
incident:
  started_at: "2026-07-12T12:10:00Z"
  detected_by: "external uptime monitor, 5xx on /checkout"
  severity: "sev2"
timeline:
  - time: "12:11"
    action: "Verified outage: curl to /health returns 502 from outside and inside"
  - time: "12:14"
    action: "Checked changes: deploy at 12:05 added new PHP-FPM pool config"
  - time: "12:17"
    action: "Load average 1m 9.8 on 4 cores, mpstat shows single core at 100% sys"
  - time: "12:22"
    action: "Rolled back PHP-FPM pool config from the 12:05 deploy"
    result: "5xx rate dropped to zero within 90 seconds"
escalated: false
next_steps:
  - "Postmortem draft from this file, scheduled for 2026-07-13"

10. Zusammenfassung

Ein systematischer Troubleshooting-Workflow für Linux-Server löst immer dasselbe Grundproblem: Unter Zeitdruck neigen selbst erfahrene Administratoren zu wahllosem Ausprobieren, das Incidents verlängert statt sie zu verkürzen. Die feste Reihenfolge aus Verifikation, Änderungsabgleich, Load, Memory, Disk, Netzwerk und Logs schließt bei jedem Schritt eine ganze Fehlerklasse aus, bevor der nächste beginnt, und liefert am Ende eine nachvollziehbare Kette von Beobachtungen statt eines zufälligen Treffers.

Der größte Hebel liegt in der konsequenten Anwendung über jeden Incident hinweg, unabhängig davon, wer gerade Bereitschaftsdienst hat. Live-Dokumentation während des Vorfalls macht das spätere Postmortem zur reinen Formsache, und klare Eskalationskriterien verhindern, dass eine einzelne Person stundenlang allein feststeckt. Wer diesen Workflow als festen Bestandteil der Incident-Response etabliert, reduziert Downtime messbar und baut gleichzeitig Wissen auf, das über den einzelnen Vorfall hinaus im gesamten Team bleibt.

11. FAQ: Troubleshooting-Workflow für Linux-Server