Troubleshooting-Methodik für IT-Support

Warum Methodik statt Rumprobieren?

Jeder im IT-Support kennt die Situation: Ein User ruft an, “der Computer geht nicht”, und du sitzt da mit zehn möglichen Ursachen im Kopf. Wer jetzt blind drauflos probiert – Neustart, Kabel tauschen, Treiber neu installieren – verliert Zeit und übersieht womöglich die eigentliche Ursache.

Strukturiertes Troubleshooting hat drei grosse Vorteile:

1. Schnellere Lösung – Du schliesst systematisch Ursachen aus, statt zufällig zu raten.
2. Reproduzierbarkeit – Andere können dein Vorgehen nachvollziehen und weitermachen.
3. Dokumentierbarkeit – Du kannst jeden Schritt im Ticket festhalten, was beim nächsten ähnlichen Fall hilft.

Diese Seite zeigt dir die bewährte 7-Schritte-Methode, wie das OSI-Modell als Troubleshooting-Leitfaden funktioniert, wie du mit strukturierter Root-Cause-Analyse tiefer als das Symptom gehst, wie du intermittierende Fehler über Sysinternals-Tools einfängst, und gibt dir konkrete Beispiele aus dem KMU-Alltag – inklusive virtualisierter Umgebungen und Terminalservern.

Die 7 Schritte des strukturierten Troubleshootings

Diese Methodik ist an den CompTIA A+/Network+-Standard angelehnt und wird von IT-Pros weltweit eingesetzt.

Schritt 1: Problem genau verstehen

Bevor du irgendetwas anfasst, musst du wissen, was eigentlich los ist. Stelle dem User gezielt Fragen:

• Was passiert genau? Was wird angezeigt / was fehlt?
• Was wurde erwartet?
• Seit wann tritt das Problem auf?
• Was hat sich geändert – Update, neue Hardware, Umzug, Passwortänderung?
• Nur dieser User / nur dieser PC / alle im Büro / alle Standorte?
• Gibt es eine Fehlermeldung – Screenshot oder Foto nehmen lassen.

Beispiel: User sagt “Outlook geht nicht”. Nach Nachfragen: “Seit heute Morgen, nur bei mir, auf dem Laptop zuhause geht es.” Das grenzt das Problem massiv ein – vermutlich kein Exchange-Problem, sondern ein lokales Outlook- oder Netzwerkproblem.

Schritt 2: Problem reproduzieren

Geh selbst an den Rechner (oder per RDP) und stelle das Problem nach. Wenn es nicht reproduzierbar ist:

• Dokumentiere das Verhalten und beobachte weiter.
• Frage nach, wann es zuletzt passiert ist – vielleicht zeigt sich ein Muster (immer morgens, immer nach Login).
• Ein nicht reproduzierbares Problem ist schwer zu lösen – bleib skeptisch.

Wie du solche sporadischen Fälle systematisch über Zeit erfasst statt nur zu warten, zeigt der Abschnitt “Intermittierende Fehler aufspüren” weiter unten im Text.

Schritt 3: Eingrenzen (Divide & Conquer)

Das ist der Kern der Methodik. Statt alles auf einmal anzuschauen, teilst du das System in Abschnitte und testest gezielt:

Das Ziel: den Bereich, in dem der Fehler liegt, immer weiter einschränken.

Schritt 4: Hypothese aufstellen und testen

Jetzt hast du genug Infos für eine begründete Vermutung. Formuliere sie konkret:

“Ich vermute, das Outlook-Profil ist beschädigt, weil das Problem nur bei diesem User auf diesem Gerät auftritt und nach dem gestrigen Update erschienen ist.”

Dann teste eine Änderung auf einmal. Wer drei Dinge gleichzeitig ändert, weiss hinterher nicht, was geholfen hat – und kann das Problem beim nächsten User nicht schnell lösen.

Schritt 5: Lösung umsetzen oder eskalieren

Wenn deine Hypothese sich bestätigt hat, setzt du die Lösung um. Falls du nicht weiterkommst:

• Eskaliere an den nächsten Level (L2, Hersteller, Fachabteilung).
• Gib dem Kollegen eine saubere Übergabe: Was du getestet hast, was du ausgeschlossen hast, wo du stehst.
• Kein Eskalieren ist keine Stärke – unnötig lange auf einem Problem sitzen kostet Zeit und Nerven.

Schritt 6: Vollständige Funktion prüfen

Nachdem du die Lösung umgesetzt hast: Testen, testen, testen.

• Funktioniert das, was vorher kaputt war?
• Hat deine Lösung nichts anderes kaputt gemacht (Seiteneffekte)?
• Ist das Problem nur bei diesem User / PC gelöst, oder muss die Lösung auf mehrere Systeme angewendet werden?

Den User einbeziehen: Lass den User selbst prüfen, ob alles wieder wie erwartet funktioniert. Du siehst vielleicht nicht alles.

Schritt 7: Dokumentieren

Das ist der Schritt, den alle überspringen wollen – und den man am meisten bereut, wenn man ihn weglässt.

Dokumentiere im Ticketsystem oder Wiki:

• Was war das Problem? (Symptom)
• Was war die Ursache? (Root Cause)
• Was war die Lösung? (Fix)
• Zeitaufwand und Datum

Beim nächsten ähnlichen Fall findest du die Lösung in einer Minute statt in einer Stunde.

Root-Cause-Analyse: Über den Symptom-Fix hinaus

Schritt 4 der 7-Schritte-Methode (“Hypothese aufstellen”) reicht bei einfachen Fällen völlig aus. Bei wiederkehrenden oder komplexen Problemen lohnt es sich aber, systematisch nach der eigentlichen Ursache statt nur nach dem nächsten Symptom zu suchen. Genau das ist der Kern der Root-Cause-Analyse (RCA) im ITIL-Problemmanagement.

5-Whys: Fünfmal “Warum?” fragen

Die einfachste RCA-Technik: Du fragst so lange “Warum?”, bis du bei einer Ursache ankommst, die du tatsächlich beheben kannst – nicht nur bei einem weiteren Symptom.

Beispiel aus dem Alltag – Server wird jede Nacht neu gestartet:

1. Warum startet der Server jede Nacht um 3 Uhr neu?
   → Weil Windows Update einen Neustart erzwingt.

2. Warum erzwingt Windows Update den Neustart?
   → Weil ein Update seit Tagen "pending restart" ist und die
     Wartungsfenster-Richtlinie automatische Neustarts erlaubt.

3. Warum wurde der Neustart nicht im geplanten Wartungsfenster ausgeführt?
   → Weil der Server während des Wartungsfensters (Sonntag 2 Uhr)
     im Dauerbetrieb war (Batch-Job lief noch).

4. Warum lief der Batch-Job länger als das Wartungsfenster?
   → Weil die Datenmenge seit dem letzten Kapazitäts-Review
     um 40% gewachsen ist, das Wartungsfenster aber nicht
     angepasst wurde.

5. Warum wurde das Wartungsfenster nicht an das Datenwachstum
   angepasst?
   → Weil es keinen periodischen Review-Prozess für
     Wartungsfenster gibt.

Root Cause: Fehlender periodischer Review-Prozess für
Wartungsfenster – nicht "Windows Update ist schuld".

Die eigentliche Massnahme ist also nicht “Update deaktivieren” (das wäre nur Symptombekämpfung und ein Sicherheitsrisiko), sondern einen Kalendereintrag für vierteljährliche Wartungsfenster-Reviews einzuführen.

Ishikawa-Diagramm (Fischgräten-Diagramm): Ursachen kategorisieren

Bei komplexeren Problemen mit mehreren möglichen Ursachenfeldern hilft das Ishikawa- oder Fischgräten-Diagramm. Es zwingt dich, systematisch über Kategorien nachzudenken, statt nur die naheliegendste Erklärung zu prüfen. Die klassischen sechs Kategorien (6M) für IT-Kontexte angepasst:

                    Mensch          Methode
                       \               /
                        \             /
    Hardware ----------->  PROBLEM  <----------- Software
                        /             \
                       /               \
                 Umgebung           Management/
                                     Prozess

Beispiel: "ERP-System bricht bei Monatsabschluss ab"

Mensch:      Mitarbeiter starten Abschluss parallel auf
             mehreren Terminals
Methode:     Kein dokumentierter Ablauf, in welcher
             Reihenfolge Module laufen müssen
Hardware:    DB-Server-RAM seit 2 Jahren nicht erweitert
Software:    ERP-Patch von letzter Woche ändert Sperr-
             verhalten bei Transaktionen
Umgebung:    Netzwerk-Backup läuft zeitgleich, sättigt I/O
Prozess:     Kein Change-Freeze vor Monatsabschluss

Aus so einer Übersicht wird oft klar: Es ist selten eine einzelne Ursache, sondern eine Kombination (hier z.B. Backup-I/O-Last plus fehlender Change-Freeze plus paralleler Zugriff). Das Diagramm lässt sich gut in einem Whiteboard-Tool oder auf Papier mit dem Team erarbeiten – gerade bei Vorfällen mit mehreren Beteiligten bringt das mehr Perspektiven zusammen als eine Einzelanalyse.

Timeline-Korrelation: Was ist wann passiert?

Bei Problemen, die “plötzlich” auftraten, ist der wichtigste Schritt, alle bekannten Zeitpunkte in einer gemeinsamen Timeline zusammenzuführen – Änderungen, Symptome und Beobachtungen:

Ohne die Timeline würde man vielleicht zuerst am Netzwerk suchen. Mit der Timeline ist der zeitliche Zusammenhang zum Update um 22:14 auffällig – die Hypothese “Update hat SMB-Konfiguration verändert” liegt nahe und lässt sich gezielt prüfen (z.B. per Get-SmbServerConfiguration vergleichen mit dem letzten bekannten guten Stand aus der Dokumentation).

Das OSI-Modell als Troubleshooting-Leitfaden

Das OSI-Modell ist nicht nur Theorie für Prüfungen – es ist ein hervorragender strukturierter Rahmen für Netzwerk-Troubleshooting. Geh immer von unten nach oben:

Layer 7 – Application   → App-Fehler, Konfiguration, Berechtigungen
Layer 6 – Presentation  → Codecs, Verschlüsselung, Zertifikate
Layer 5 – Session       → Authentifizierung, Sitzungen, Timeouts
Layer 4 – Transport     → TCP/UDP, Ports, Firewall-Regeln
Layer 3 – Network       → IP-Adresse, Routing, Gateway, DNS
Layer 2 – Data Link     → MAC-Adresse, Switch, VLAN, Switchport
Layer 1 – Physical      → Kabel, NIC, WLAN-Signal, Patchfeld

Warum von unten nach oben? Weil Layer-1-Probleme (Kabel nicht drin) alle höheren Layer komplett blockieren. Es bringt nichts, den Proxy zu konfigurieren, wenn das Netzwerkkabel locker ist.

Praxisbeispiel: “Kein Internetzugang”

# Schnellcheck: Netzwerk von unten nach oben
Get-NetAdapter                                    # L1/L2: Adapter-Status
ipconfig /all                                     # L3: IP-Konfiguration
ping 192.168.1.1                                  # L3: Gateway erreichbar?
ping 8.8.8.8                                      # L3: Internet erreichbar (ohne DNS)?
Resolve-DnsName google.com                        # L7: DNS funktioniert?
Test-NetConnection google.com -Port 443           # L4: HTTPS erreichbar?

Häufige Troubleshooting-Szenarien im KMU-Alltag

Szenario 1: User kann sich nicht anmelden

Symptom: "Falsche Anmeldeinformationen" bei Windows-Login

1. Konto gesperrt? → ADUC oder PowerShell prüfen:

   Search-ADAccount -LockedOut | Select Name, SamAccountName
   Get-ADUser mmuster -Properties LockedOut, BadLogonCount

2. Falsches Passwort → Passwort zurücksetzen:

   Set-ADAccountPassword -Identity "mmuster" -Reset -NewPassword (ConvertTo-SecureString "NeuesPasswort123!" -AsPlainText -Force)
   Unlock-ADAccount -Identity "mmuster"

3. Domäne nicht erreichbar → Kann der PC den DC pingen? DNS-Auflösung des DC-Namens testen.
4. Kerberos-Problem → Zeit auf PC und DC abweichend? Maximal 5 Minuten Abweichung erlaubt.

Mehr dazu: Active Directory – User & Gruppen

Szenario 2: Drucker druckt nicht

Symptom: Druckjob hängt in der Warteschlange

1. Spooler-Dienst neu starten:

   Stop-Service -Name Spooler -Force
   Remove-Item -Path "$env:SystemRoot\System32\spool\PRINTERS\*" -Force -Recurse
   Start-Service -Name Spooler

2. Drucker offline? → IP geändert? Drucker neu starten, Port-IP im Druckertreiber prüfen.
3. Treiber-Problem? → Treiber deinstallieren und neu installieren.
4. Netzwerkpfad bei Druckserver? → \\druckserver\druckername erreichbar?

Mehr dazu: Drucker & Netzwerkdrucker

Szenario 3: VPN verbindet, aber interne Ressourcen nicht erreichbar

Symptom: VPN zeigt "verbunden", aber \\server\freigabe ist nicht erreichbar

1. Split Tunneling aktiv? → Nur Firmentraffic durch VPN, oder alles?
2. DNS korrekt? → Bekommt der VPN-Client intern den internen DNS-Server?

   ipconfig /all          # DNS-Server im VPN-Tunnel prüfen
   Resolve-DnsName server.firma.local   # Interner Hostname auflösbar?

3. Routing stimmt? → Interner Adressbereich (z.B. 10.0.0.0/8) über VPN geroutet?
4. Firewall auf dem Zielserver? → Erlaubt Windows Firewall Zugriff aus dem VPN-Subnetz?

Szenario 4: Windows-PC extrem langsam

Symptom: Alles dauert Minuten, CPU oder RAM am Anschlag

1. Task-Manager öffnen (Strg+Shift+Esc): Was frisst CPU/RAM/Disk?
2. Disk-Auslastung 100%? Oft Windows Search oder Antivirus beim Erstscan:

   # Top-Prozesse nach CPU
   Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet

3. Malware? → Defender-Scan ausführen, ggf. Malwarebytes zusätzlich.
4. RAM zu wenig? → systeminfo zeigt Gesamt-RAM. Unter 8 GB ist heute oft zu wenig.
5. HDD statt SSD? → Get-PhysicalDisk – HDDs sind 2026 ein häufiger Bremsklotz.
6. Startprogramme reduzieren: Win+R → msconfig → Autostart-Tab.

Intermittierende Fehler aufspüren: Logging über Zeit

Das Tückische an sporadischen Fehlern – “manchmal friert der PC morgens ein”, “der Server crasht ein- bis zweimal pro Woche nachts” – ist, dass du beim Draufschauen selten etwas siehst. Live-Debugging bringt hier nichts. Die Lösung: kontinuierlich mitschneiden, bevor der Fehler auftritt, statt danach zu suchen.

Reliability Monitor: Der schnellste Ausgangspunkt

Der Zuverlässigkeitsverlauf (Reliability Monitor) ist eine unterschätzte Bordmittel-Funktion von Windows. Er zeigt eine chronologische Übersicht über Abstürze, Installationen und Warnungen – genau das, was du für eine Timeline-Korrelation brauchst.

Aufruf: Win+R → perfmon /rel

Der Verlauf zeigt pro Tag einen Stabilitätsindex (1–10) sowie Symbole für Anwendungsfehler, Windows-Fehler, sonstige Fehler und Informationsereignisse (z.B. Update-Installationen). Damit siehst du auf einen Blick, ob die Abstürze zeitlich mit einer Software-Installation oder einem Update zusammenfallen – ein direkter Input für die Timeline-Korrelation aus dem RCA-Abschnitt oben.

ProcMon Boot Logging: Fehler beim Systemstart einfangen

Manche Probleme treten nur beim Hochfahren auf – ein Dienst startet nicht zuverlässig, ein Treiber lädt manchmal nicht, der Login dauert nach jedem zweiten Neustart ewig. Da du in diesem Fenster nicht manuell mitschneiden kannst, bietet Process Monitor eine spezielle Funktion dafür:

1. Process Monitor starten, Options → Enable Boot Logging wählen.
2. PC neu starten. ProcMon installiert dazu temporär einen Treiber (procmon24.sys) und protokolliert ab dem Bootvorgang jede Datei-, Registry- und Prozessaktivität.
3. Nach dem Neustart Windows 5–15 Minuten laufen lassen, bis alle Autostart-Programme geladen sind.
4. Process Monitor erneut öffnen – es erscheint automatisch die Frage, ob der aufgezeichnete Bootlog gespeichert werden soll. Mit “Yes” bestätigen und als Bootlog.pml sichern.
5. Die Datei lässt sich wie ein normaler ProcMon-Trace mit Filtern durchsuchen (siehe nächster Abschnitt).

perfmon Data Collector Sets: Performance-Daten über Stunden/Tage sammeln

Für Probleme wie “die Datenbank wird nachts langsam” oder “der RAM läuft über Tage hinweg voll” brauchst du keinen Einzelschnappschuss, sondern kontinuierliche Performance-Counter über einen längeren Zeitraum. Dafür sind Data Collector Sets im Performance Monitor (perfmon.msc) gemacht:

Über die GUI:

1. perfmon.msc öffnen → Datensammlungssätze → Benutzerdefiniert → Rechtsklick → Neu → Datensammlungssatz.
2. “Manuell erstellen (erweitert)” wählen, dann Leistungsindikatordaten als Datentyp.
3. Relevante Counter hinzufügen (z.B. \Processor(_Total)\% Processor Time, \Memory\Available MBytes, \PhysicalDisk(_Total)\Avg. Disk sec/Transfer).
4. Abtastintervall setzen (z.B. alle 15 Sekunden) und eine Stoppbedingung (z.B. “Gesamtdauer: 24 Stunden”).

Per Kommandozeile mit logman (schneller reproduzierbar, gut fürs Ticket dokumentierbar):

# Data Collector Set anlegen: CPU, RAM, Disk-Latenz alle 15s, zirkuläre Datei max. 250 MB
logman create counter DiagLog `
  -c "\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" "\PhysicalDisk(_Total)\Avg. Disk sec/Transfer" `
  -si 00:00:15 -f bincirc -max 250 -o C:\PerfLogs\diaglog.blg

logman start DiagLog      # Aufzeichnung starten
logman query DiagLog      # Status prüfen
logman stop DiagLog       # Aufzeichnung beenden

# Aufzeichnung in ein CSV umwandeln, um sie z.B. in Excel weiterzuverarbeiten
relog C:\PerfLogs\diaglog.blg -f CSV -o C:\PerfLogs\diaglog.csv

Diese Methode eignet sich hervorragend, um mit dem Team oder Vorgesetzten zu vereinbaren: “Wir lassen das über Nacht mitloggen, morgen schauen wir uns die Kurve an” – ganz ohne dass jemand am Rechner sitzen bleiben muss.

Differenzdiagnose: Hardware, Treiber oder Software?

Eine der häufigsten Fragen beim Troubleshooting ist: Liegt es an der Hardware, am Treiber oder an der Applikation selbst? Die Sysinternals-Tools Process Monitor und Process Explorer helfen, diese drei Ebenen sauber zu trennen.

ProcMon-Filter gezielt einsetzen

Ungefiltert erzeugt Process Monitor tausende Events pro Sekunde – ohne Filter ist er unbenutzbar. Der Filter-Dialog (Strg+L) ist deshalb der wichtigste Handgriff:

Praxisbeispiel: Anwendung stürzt beim Start ab, unklar ob
fehlende DLL (Software) oder Treiberproblem (Hardware).

1. Filter setzen: Process Name → is → anwendung.exe → Include
2. Filter setzen: Result → is not → SUCCESS → Include
3. Aufzeichnung starten, Anwendung starten bis zum Absturz, stoppen
4. In der Ergebnisliste nach dem letzten Eintrag vor dem Absturz suchen

So unterscheidest du typische Befunde:

Process Explorer: Handles und gesperrte Dateien finden

Wenn eine Datei sich nicht löschen oder verschieben lässt (“Die Datei ist bereits geöffnet in…”), oder wenn ein Prozess partout nicht beendet werden will, hilft Process Explorer:

1. Process Explorer starten (als Administrator, für vollständige Sicht auf alle Prozesse).
2. Find → Find Handle or DLL oder Strg+F.
3. Namen der gesperrten Datei oder DLL eingeben (Teilstring genügt, Gross-/Kleinschreibung wird ignoriert).
4. Der Treffer zeigt Prozessname und PID – darüber lässt sich der Handle gezielt schliessen oder der Prozess beenden.

Das Kommandozeilen-Pendant handle.exe (ebenfalls aus der Sysinternals Suite) eignet sich für Skripte und Remote-Sitzungen ohne GUI:

# Alle Prozesse anzeigen, die eine bestimmte Datei offen halten
.\handle.exe "C:\Freigaben\Projekt\bericht.docx"

Damit lässt sich auch die Grenze zwischen “Software hält Handle offen” (z.B. ein hängender Word-Prozess) und “Treiber/Filter-Treiber blockiert” (z.B. ein Antivirus-Minifilter) klären – Letzteres zeigt sich oft durch Systemprozesse wie System oder AV-Dienste als Besitzer des Handles.

Troubleshooting in virtualisierten und Remote-Umgebungen

Terminalserver (RDS) und VDI (Virtual Desktop Infrastructure) bringen eine zusätzliche Dimension ins Troubleshooting: Ein Symptom kann am Endgerät, an der Netzwerkverbindung, an der virtuellen Maschine, am Hypervisor-Host oder am Profil-Backend liegen. Die Grundmethodik bleibt gleich – Divide & Conquer –, aber die Trennlinien verschieben sich.

Erste Eingrenzung: Ein User oder viele?

Für den letzten Fall lohnt sich ein Blick auf Host-Ebene, siehe Hyper-V-Grundlagen bzw. VMware ESXi-Grundlagen und generell Virtualisierung-Grundlagen.

Terminalserver-Sitzungen gezielt diagnostizieren

# Alle aktiven Sitzungen auf einem RDS-Host auflisten
query session /server:RDS01
quser /server:RDS01

# Eine hängende Sitzung zurücksetzen (Vorsicht: Datenverlust bei
# ungespeicherter Arbeit in dieser Sitzung möglich)
rwinsta <SessionID> /server:RDS01

# User sauber abmelden statt hart zurückzusetzen
logoff <SessionID> /server:RDS01

Wichtige Ereignisprotokolle für RDS-spezifische Fehler liegen unter Anwendungs- und Dienstprotokolle → Microsoft → Windows → TerminalServices-*, insbesondere TerminalServices-RemoteConnectionManager (Verbindungsaufbau) und TerminalServices-LocalSessionManager (Sitzungsstatus). Details zu Terminalserver/RDS-Administration findest du auf der Seite Terminalserver & RDS Support.

Profilprobleme von Infrastrukturproblemen trennen

Ein sehr häufiges VDI/RDS-Muster: “Anmeldung dauert ewig” oder “Einstellungen sind nach Neuanmeldung weg”. Bevor du das RDS-Backend verdächtigst, prüfe zuerst das Profil-Handling:

1. Läuft ein Profil-Container-System wie FSLogix? Ist der Container-Speicherort (meist ein SMB-Fileshare) erreichbar und performant?
2. Ist der Container evtl. noch von einer vorherigen, hängenden Sitzung gesperrt (siehe Process-Explorer-Handle-Suche weiter oben)?
3. Ist es wirklich derselbe Fehler bei mehreren Usern, oder nur bei einem – dann eher ein individuell beschädigtes Profil.

Eine ausführliche Anleitung zu Profil-Containern liefert die Seite FSLogix-Profilverwaltung.

Besonderheit nicht-persistenter VDI-Desktops

Bei nicht-persistenten VDI-Pools wird die virtuelle Maschine nach jedem Logoff auf den Ausgangszustand zurückgesetzt (“Reset to Golden Image”). Das hat für dein Troubleshooting zwei praktische Konsequenzen:

• ProcMon Boot Logging und lokale Logs überleben den Reset nicht. Konfiguriere ProcMon so, dass die Log-Datei direkt auf einen Netzwerkpfad geschrieben wird (File → Backing Files), statt lokal – sonst ist der Trace nach dem nächsten Reset weg.
• Ein Fehler, der “nach dem letzten Golden-Image-Update” bei allen Usern auftritt, deutet stark auf eine Änderung im Image selbst hin – prüfe zuerst das Änderungsprotokoll des Images, bevor du Einzelfälle untersuchst (Timeline-Korrelation, siehe oben).

Eskalation: Wann und wie?

Eskalation ist kein Versagen – sie ist professionell. Eskaliere, wenn:

• Du das Problem nach 30–60 Minuten nicht eingrenzen konntest.
• Du spezifisches Fachwissen brauchst (Netzwerk, Datenbank, ERP).
• Die Auswirkung kritisch ist (ganzer Standort ausgefallen, Produktion steht).
• Du zum Test produktive Systeme ändern müsstest.

Übergabe sauber machen:

• Was ist das Symptom?
• Was hast du bereits getestet?
• Was hast du ausgeschlossen?
• Was ist deine aktuelle Hypothese?

Ein L2-Kollege, der eine saubere Übergabe bekommt, braucht keine 30 Minuten, um denselben Stand zu erreichen.

Blameless-Postmortems nach grösseren Vorfällen

Wenn ein Vorfall gravierend war – Produktionsausfall, Datenverlust, längerer Totalausfall eines Standorts – reicht “Ticket gelöst, Haken dran” nicht. Hier kommt der Blameless-Postmortem-Prozess ins Spiel, wie ihn Google SRE seit Jahren praktiziert und viele Unternehmen übernommen haben.

Warum “blameless”?

Der Grundgedanke: Ein Postmortem geht davon aus, dass alle Beteiligten mit den Informationen, die ihnen zum jeweiligen Zeitpunkt vorlagen, vernünftig gehandelt haben. Statt zu fragen “Wer hat den Fehler gemacht?”, fragt man “Warum war es zum jeweiligen Zeitpunkt naheliegend, so zu handeln – und wie verhindern wir das System-seitig beim nächsten Mal?”

Das ist kein weicher Kulturbegriff, sondern hat einen harten praktischen Grund: Sobald Postmortems dazu benutzt werden, Schuldige zu finden, hören Mitarbeitende auf, Fehler oder Beinahe-Unfälle offen zu melden – und genau die Information geht verloren, die künftige Vorfälle verhindern könnte.

Wann ist ein Postmortem Pflicht?

Struktur eines guten Postmortem-Dokuments

Ein Postmortem-Template, das sich in der Praxis bewährt hat, orientiert sich an dieser Struktur:

1. Zusammenfassung
   Ein bis zwei Sätze: Was ist passiert, wie lange, wie kritisch?

2. Impact
   Wie viele User/Kunden betroffen? Welcher finanzielle/
   reputative Schaden? Wurden SLAs verletzt?

3. Timeline
   Chronologische Abfolge mit Zeitstempeln: Wann wurde was
   bemerkt, wer hat wann was getan, wann war es behoben?

4. Root Cause
   Ergebnis der 5-Whys- bzw. Ishikawa-Analyse (siehe oben) –
   die tatsächliche Ursache, nicht nur das Symptom.

5. Was ging gut?
   Was hat die Erkennung/Behebung beschleunigt?

6. Was ging schlecht?
   Was hat die Erkennung/Behebung verzögert?

7. Wo hatten wir Glück?
   Ehrliche Einschätzung: Was hätte schlimmer kommen können,
   wenn nicht zufällig X der Fall gewesen wäre?

8. Massnahmen (Action Items)
   Konkrete Aufgabe, Verantwortlicher, Frist – keine vagen
   "wir sollten mal..."-Einträge.

Führe das Postmortem-Meeting zeitnah durch (innerhalb weniger Tage, solange Details noch frisch sind), lade alle relevanten Beteiligten ein – auch bereichsübergreifend – und stelle sicher, dass die Massnahmen tatsächlich als Tickets landen und nachverfolgt werden. Ein Postmortem ohne umgesetzte Massnahmen ist reine Dokumentation ohne Wirkung.

Dokumentation und Wissensmanagement

Gute Dokumentation multipliziert dein Wissen. Jede gelöste Ursache, die im Wiki oder Ticketsystem steht, spart beim nächsten ähnlichen Fall Zeit.

Minimalstruktur für ein Ticket:

Problem:    Outlook-Profil beschädigt nach Update KB5034439
Symptom:    Outlook startet nicht, Fehlermeldung "Profil kann nicht geöffnet werden"
Ursache:    Korruptes OST-Profil durch abgebrochenes Update
Lösung:     OST-Datei gelöscht (%localappdata%\Microsoft\Outlook\),
            Outlook neu geöffnet, Profil neu synchronisiert
Dauer:      ca. 20 Min

Nützliche Diagnose-Tools auf einen Blick

Troubleshooting im PowerShell-Alltag

Einige Befehle, die du beim Troubleshooting immer wieder brauchst:

# === SYSTEMINFO ===
Get-ComputerInfo | Select-Object WindowsProductName, TotalPhysicalMemory, OsLastBootUpTime
systeminfo | findstr /C:"Boot Time" /C:"Total Physical Memory"

# === EVENTS / FEHLERLOG ===
# Letzte 20 Fehler im Systemprotokoll
Get-EventLog -LogName System -EntryType Error -Newest 20 | Select TimeGenerated, Source, Message

# Kritische Events der letzten 24h
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddHours(-24)}

# === NETZWERK DIAGNOSE ===
ipconfig /all                                          # IP-Konfiguration
ipconfig /flushdns                                     # DNS-Cache leeren
Test-NetConnection 8.8.8.8 -Port 53                   # DNS-Port testen
Test-NetConnection fileserver.firma.local -Port 445   # SMB-Freigabe testen

# === DIENSTE ===
Get-Service | Where-Object { $_.Status -eq 'Stopped' -and $_.StartType -eq 'Automatic' }
# Zeigt: Dienste, die automatisch starten sollten, aber gestoppt sind

# === DISK-HEALTH ===
Get-PhysicalDisk | Select FriendlyName, MediaType, HealthStatus, Size

Weiterlernen

• CompTIA: Use a Troubleshooting Methodology for More Efficient IT Support – Fundierter Artikel zur 7-Schritte-Methode
• Microsoft Learn: Fehlerbehebung bei Netzwerkproblemen – Offizielle Doku
• Petri IT Knowledgebase: How to use the OSI Model for Network Troubleshooting – Praxisnahe OSI-Troubleshooting-Anleitung
• Atlassian: Problemmanagement in ITIL – ITIL-Grundlagen für strukturiertes Problem-Management
• Google SRE Book: Postmortem Culture – Das Original zum Blameless-Postmortem-Prozess
• Microsoft Sysinternals – Offizielle Docs zur Sysinternals Suite
• PowerShell für IT-Alltag – Wichtige Befehle für die tägliche Arbeit als IT-Allrounder