# 1.9 Störung dokumentieren, abschließen und Wiederholung verhindern

Eine Störung ist nicht allein deshalb abgeschlossen, weil die betroffene Funktion wieder verfügbar ist.

Ein vollständiger Abschluss beantwortet zusätzlich:

- Was ist passiert?
- Welche Systeme und Benutzer waren betroffen?
- Wann begann und endete die Störung?
- Was war die bestätigte Ursache?
- Welche Maßnahme stellte die Funktion wieder her?
- Wurde nur ein Workaround oder eine dauerhafte Lösung umgesetzt?
- Welche Risiken und offenen Aufgaben bleiben bestehen?
- Wie wird eine Wiederholung verhindert oder schneller erkannt?

Dabei gilt:

> Eine gute Störungsdokumentation ermöglicht einer anderen Person, den Ablauf, die Ursache, die Prüfungen und die Lösung ohne mündliche Zusatzinformationen nachzuvollziehen.

---

**Ziel dieser Seite**

Nach diesem Arbeitsschritt sollten:

- Wiederherstellung und dauerhafte Lösung dokumentiert sein,
- eine nachvollziehbare Zeitachse vorliegen,
- Ursache, Auslöser und begünstigende Faktoren getrennt sein,
- technische Belege und Testergebnisse zugeordnet sein,
- Auswirkungen auf Benutzer und Betrieb dokumentiert sein,
- verbleibende Risiken bekannt sein,
- offene Maßnahmen eine verantwortliche Person besitzen,
- Monitoring, Dokumentation und Notfallabläufe aktualisiert sein,
- der Abschlussstatus eindeutig sein,
- Wissen für zukünftige Störungen erhalten bleiben.

---

**1. Kennzeichnung der Befehle**

| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | Read-only: liest Informationen aus |
| `[TEST]` | Führt eine aktive Prüfung aus |
| `[FILE]` | Erstellt oder überschreibt eine Datei |
| `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte |
| `[CHANGE]` | Verändert Konfiguration oder Betriebszustand |
| `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten |

---

**2. Wiederhergestellt, gelöst und abgeschlossen unterscheiden**

| Status | Bedeutung |
|---|---|
| Erkannt | Störung wurde registriert |
| In Analyse | Ursache wird untersucht |
| Workaround aktiv | Funktion ist über einen vorläufigen Umweg verfügbar |
| Wiederhergestellt | ursprüngliche Funktion ist wieder verfügbar |
| Unter Beobachtung | Funktion läuft, Stabilität wird überwacht |
| Technisch gelöst | bestätigte technische Ursache wurde beseitigt |
| Dauerhaft gelöst | zusätzlich wurden erforderliche Präventionsmaßnahmen umgesetzt |
| Abgeschlossen | Dokumentation, Übergabe und offene Maßnahmen sind vollständig |
| Wiedereröffnet | Fehler trat erneut auf oder Abschlusskriterien waren nicht erfüllt |

Ein Ticket sollte nicht als „dauerhaft gelöst“ bezeichnet werden, wenn lediglich ein Workaround aktiv ist.

---

**3. Incident, Problem und Änderung unterscheiden**

| Element | Hauptziel | Beispiel |
|---|---|---|
| Störung oder Incident | Betrieb schnell wiederherstellen | Webanwendung wieder erreichbar machen |
| Problem oder Ursachenanalyse | Grundursache und Wiederholungsrisiko untersuchen | Ursache des wiederkehrenden Ausfalls bestimmen |
| Änderung oder Change | kontrollierte technische Anpassung durchführen | Konfigurationsvalidierung einführen |
| Wissenseintrag | Wiederverwendbare Lösung dokumentieren | Fehlerbild und Diagnosebefehle dokumentieren |
| Präventionsaufgabe | Wiederholung oder Auswirkung verhindern | Monitoring um Ende-zu-Ende-Test ergänzen |

Ein einzelner Vorfall kann mehrere verknüpfte Einträge benötigen.

---

**4. Abschlusskriterien festlegen**

Eine Störung kann abgeschlossen werden, wenn mindestens folgende Punkte geklärt sind:

- ursprüngliche Benutzerfunktion funktioniert,
- technischer Funktionstest wurde bestanden,
- relevante Regressionstests wurden durchgeführt,
- Sicherheitskontrollen funktionieren weiterhin,
- Monitoring zeigt einen stabilen Zustand,
- keine neuen relevanten Fehler treten auf,
- betroffene Personen wurden informiert,
- Ursache oder Unsicherheit ist dokumentiert,
- Workaround oder Lösung ist eindeutig gekennzeichnet,
- Rückfallstatus ist dokumentiert,
- Belege und Ausgaben sind zugeordnet,
- offene Maßnahmen besitzen Verantwortliche und Termine,
- verbleibende Risiken wurden akzeptiert oder weitergegeben.

---

**5. Abschlussentscheidung**

| Frage | Ja | Nein |
|---|---:|---:|
| Funktioniert die ursprüngliche Benutzeraktion? |  |  |
| Ist der technische Systemzustand stabil? |  |  |
| Sind Abhängigkeiten geprüft? |  |  |
| Sind negative Sicherheitstests bestanden? |  |  |
| Sind relevante Regressionstests bestanden? |  |  |
| Ist das Monitoring unauffällig? |  |  |
| Sind Protokolle nach der Lösung geprüft? |  |  |
| Ist die Ursache ausreichend dokumentiert? |  |  |
| Ist klar, ob es sich um Workaround oder Lösung handelt? |  |  |
| Sind offene Aufgaben zugewiesen? |  |  |
| Sind verbleibende Risiken dokumentiert? |  |  |
| Sind betroffene Personen informiert? |  |  |

Wenn wesentliche Punkte mit „Nein“ beantwortet werden, sollte das Ticket nicht ohne Begründung endgültig geschlossen werden.

---

**6. Inhalt einer vollständigen Störungsdokumentation**

| Abschnitt | Inhalt |
|---|---|
| Kurzbeschreibung | Was war sichtbar gestört? |
| Auswirkung | Wer oder was war betroffen? |
| Beginn | Erster bekannter Fehlerzeitpunkt |
| Erkennung | Wie und wann wurde die Störung erkannt? |
| Wiederherstellung | Wann funktionierte der Dienst wieder? |
| Abschluss | Wann wurde die dauerhafte Lösung bestätigt? |
| Systeme | betroffene Clients, Server, Netze und Dienste |
| Symptom | Fehlermeldung und beobachtetes Verhalten |
| Fehlerumfang | betroffene und nicht betroffene Bereiche |
| Zeitachse | wichtige Ereignisse und Maßnahmen |
| Ursache | bestätigte technische Ursache |
| Auslöser | Ereignis, das den Fehler aktivierte |
| Begünstigende Faktoren | Bedingungen, die Auswirkung oder Dauer verstärkten |
| Erkennungslücken | Warum wurde der Fehler nicht früher erkannt? |
| Diagnose | wichtige Befehle, Ausgaben und Tests |
| Wiederherstellung | Sofortmaßnahme oder Workaround |
| Dauerhafte Lösung | Beseitigung der Grundursache |
| Verifikation | technische und fachliche Funktionstests |
| Rollback | vorbereitet, durchgeführt oder nicht erforderlich |
| Offene Risiken | verbleibende technische oder organisatorische Risiken |
| Folgeaufgaben | Präventions-, Monitoring- und Dokumentationsaufgaben |
| Verantwortliche | Zuständigkeit für jede offene Aufgabe |

---

**7. Kurzbeschreibung richtig formulieren**

**Ungeeignet**

`Server war kaputt und wurde repariert.`

**Besser**

`Am 30.07.2026 konnten Clients aus VLAN 30 zwischen 14:35 und 15:42 Uhr keine HTTPS-Verbindung zu server.example aufbauen. Ursache war eine fehlerhafte Firewall-ACL, die TCP 443 aus VLAN 30 blockierte. Nach Korrektur der ACL waren Porttest, Anmeldung und Monitoring erfolgreich.`

Eine gute Kurzbeschreibung enthält:

- Zeitraum,
- betroffene Funktion,
- betroffenen Umfang,
- bestätigte Ursache,
- Wiederherstellungsmaßnahme,
- abschließendes Testergebnis.

---

**8. Auswirkung dokumentieren**

Die Auswirkung sollte möglichst konkret beschrieben werden.

| Bereich | Zu dokumentierende Angaben |
|---|---|
| Benutzer | Anzahl oder betroffene Gruppen |
| Standorte | Gebäude, Niederlassungen oder Netze |
| Systeme | Clients, Server, Anwendungen |
| Funktionen | Anmeldung, Dateiablage, E-Mail, Produktion |
| Dauer | Beginn bis Wiederherstellung |
| Daten | Verlust, Verzögerung oder Inkonsistenz |
| Sicherheit | mögliche unautorisierte Zugriffe oder Kontrollverlust |
| Geschäft | ausgefallene Prozesse oder Verzögerungen |
| Externe Parteien | Kunden, Lieferanten oder Provider |
| Workaround | verfügbar, eingeschränkt oder nicht vorhanden |

Wenn keine genaue Anzahl verfügbar ist, sollte dies ausdrücklich vermerkt und nicht frei geschätzt werden.

---

**9. Wichtige Zeitpunkte dokumentieren**

| Zeitpunkt | Bedeutung |
|---|---|
| Letzter funktionierender Zustand | Funktion wurde zuletzt erfolgreich verwendet |
| Tatsächlicher Fehlerbeginn | soweit technisch bestimmbar |
| Erste Beobachtung | Fehler wurde erstmals bemerkt |
| Erkennung | Monitoring oder Support erkannte die Störung |
| Meldung | Ticket wurde erstellt |
| Bestätigung | Störung wurde technisch nachvollzogen |
| Eskalation | weitere Stelle wurde beteiligt |
| Eindämmung | Auswirkung wurde begrenzt |
| Wiederherstellung | Benutzerfunktion war wieder verfügbar |
| Dauerhafte Lösung | Grundursache wurde behandelt |
| Ende der Beobachtung | Stabilität wurde ausreichend bestätigt |
| Abschluss | Ticket wurde geschlossen |

Alle Uhrzeiten sollten dieselbe Zeitzone verwenden oder eindeutig als lokale Zeit beziehungsweise UTC gekennzeichnet sein.

---

**10. Zeitkennzahlen berechnen**

| Kennzahl | Berechnung | Bedeutung |
|---|---|---|
| Erkennungszeit | Erkennung minus Fehlerbeginn | Wie lange blieb der Fehler unentdeckt? |
| Reaktionszeit | Beginn der Bearbeitung minus Erkennung | Wie schnell begann die Reaktion? |
| Eindämmungszeit | Eindämmung minus Erkennung | Wie schnell wurde die Auswirkung begrenzt? |
| Wiederherstellungszeit | Wiederherstellung minus Fehlerbeginn | Wie lange war die Funktion beeinträchtigt? |
| Lösungszeit | dauerhafte Lösung minus Fehlerbeginn | Wie lange bis zur vollständigen Korrektur? |

Abkürzungen wie MTTR werden in verschiedenen Organisationen unterschiedlich verwendet, beispielsweise für „Mean Time to Repair“, „Restore“, „Resolve“ oder „Recovery“. Deshalb sollte die konkret gemeinte Kennzahl ausgeschrieben und definiert werden.

---

**11. Zeitachse erstellen**

| Zeit | Quelle | Ereignis | Auswirkung oder Erkenntnis |
|---|---|---|---|
| 14:31 | Deployment | neue Konfiguration verteilt | möglicher Auslöser |
| 14:35 | Monitoring | HTTP-Fehlerrate steigt | erster technischer Hinweis |
| 14:38 | Benutzer | Anmeldung schlägt fehl | Benutzerwirkung bestätigt |
| 14:42 | Support | Ticket erstellt | Bearbeitung beginnt |
| 14:48 | Diagnose | Backend 2 liefert HTTP 503 | Fehler eingegrenzt |
| 14:55 | Anwendung | falscher Datenbank-Hostname gefunden | unmittelbare Ursache |
| 15:05 | Change | Backend 2 aus Rotation genommen | Auswirkung eingedämmt |
| 15:17 | Change | Konfiguration korrigiert | technische Lösung |
| 15:22 | Test | Anmeldung erfolgreich | Funktion wiederhergestellt |
| 15:52 | Monitoring | keine neuen Fehler | Stabilität bestätigt |
| 16:00 | Abschluss | Folgeaufgaben erstellt | Incident beendet |

**Wichtig**

Die Zeitachse sollte Fakten enthalten. Vermutungen werden als solche gekennzeichnet.

---

**12. Fakten und Bewertungen trennen**

**Fakt**

`Um 14:31 Uhr wurde Deployment 2026.07.30-3 ausgeführt.`

**Bewertung**

`Das Deployment war der Auslöser der Störung.`

**Fakt**

`Backend 2 protokollierte um 14:35 Uhr einen Fehler bei der Namensauflösung des Datenbankservers.`

**Bewertung**

`Der falsche Datenbank-Hostname verursachte die HTTP-503-Antworten.`

Beide Arten von Informationen sind wichtig, müssen aber voneinander unterscheidbar bleiben.

---

**13. Technische Diagnose dokumentieren**

Nicht jede vollständige Konsolenausgabe muss direkt in den Tickettext kopiert werden. Das Ticket sollte jedoch die relevanten Befehle, Ergebnisse und Verweise enthalten.

| Feld | Beispiel |
|---|---|
| Prüfzeitpunkt | 2026-07-30 14:48 CEST |
| Quellsystem | PC-030 |
| Zielsystem | server.example |
| Befehl | `Test-NetConnection server.example -Port 443` |
| Ergebnis | `TcpTestSucceeded: False` |
| Vergleich | Test aus VLAN 40 erfolgreich |
| Interpretation | Fehler ist vom Quellnetz abhängig |
| Ausgabedatei | `INC-2026-0042-TCP-Test-PC030.txt` |
| Hypothese | H1 – ACL blockiert VLAN 30 |
| Bewertung | stark gestützt |

---

**14. Befehle und Ausgaben nachvollziehbar zuordnen**

**Geeignete Dateinamen**

`INC-2026-0042-PC030-TCP-Test-20260730-144800.txt`

`INC-2026-0042-FW01-Auditlog-20260730-145000.txt`

`INC-2026-0042-SRVAPP02-Application.evtx`

Ein sinnvoller Dateiname enthält:

- Ticketnummer,
- System,
- Inhalt,
- Datum,
- Uhrzeit.

---

**15. Abschlusszustand unter Windows dokumentieren**

**Zeitpunkt**

`[RO] Get-Date -Format o`

**Dienststatus**

`[RO] Get-Service -Name <Dienstname>`

**Prozess-ID**

`[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId`

**Listener**

`[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>`

**Funktionstest**

`[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed`

**Neue Systemfehler**

`[RO] Get-WinEvent -FilterHashtable @{LogName="System"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message`

**Neue Anwendungsfehler**

`[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; Level=1,2; StartTime=(Get-Date).AddMinutes(-30)} | Select-Object TimeCreated, Id, ProviderName, Message`

---

**16. Abschlusszustand unter Linux dokumentieren**

**Zeitpunkt**

`[RO] date --iso-8601=seconds`

**Dienststatus**

`[RO] systemctl status <Dienstname>.service --no-pager`

**Fehlgeschlagene Dienste**

`[RO] systemctl --failed`

**Listener**

`[RO][PRIV] ss -lntp | grep ":<Port>"`

**Funktionstest**

`[TEST] nc -vz -w 3 <Servername> <Port>`

**Neue Dienstprotokolle**

`[RO] journalctl -u <Dienstname>.service --since "30 minutes ago" --no-pager`

**Neue Systemfehler**

`[RO] journalctl --since "30 minutes ago" -p err --no-pager`

---

**17. Abschlusszustand unter macOS dokumentieren**

**Zeitpunkt**

`[RO] date "+%Y-%m-%dT%H:%M:%S%z"`

**Systemdienst**

`[RO][PRIV] launchctl print system/<Dienstlabel>`

**Benutzerdienst**

`[RO] launchctl print gui/$(id -u)/<Dienstlabel>`

**Listener**

`[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN`

**Funktionstest**

`[TEST] nc -vz -w 3 <Servername> <Port>`

**Neue Prozessfehler**

`[RO] log show --last 30m --predicate 'process == "<Prozessname>" AND (messageType == error OR messageType == fault)' --style compact`

---

**18. Plattformübergreifenden HTTP-Abschlusstest durchführen**

**Windows**

`[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/`

**Linux und macOS**

`[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/`

Der Test dokumentiert unter anderem:

- HTTP-Status,
- tatsächlich verwendete Ziel-IP,
- DNS-Zeit,
- TCP-Verbindungszeit,
- TLS-Zeit,
- Gesamtzeit.

Die Werte müssen mit bekannten Normalwerten, Monitoring-Baselines oder vereinbarten Anforderungen verglichen werden.

---

**19. Prüfsummen für Abschlussunterlagen erstellen**

Die Prüfsummen sollten erst erstellt werden, nachdem keine weiteren Dateien mehr zur Sammlung hinzugefügt werden.

**Windows**

`[FILE] Get-ChildItem "<Diagnoseordner>" -File -Recurse | Get-FileHash -Algorithm SHA256 | Export-Csv "<Diagnoseordner>-SHA256.csv" -NoTypeInformation -Encoding UTF8`

**Linux**

`[FILE] (cd "<Diagnoseordner>" && find . -type f -print0 | sort -z | xargs -0 -r sha256sum) > "<Diagnoseordner>-SHA256SUMS.txt"`

**macOS**

`[FILE] find "<Diagnoseordner>" -type f -exec shasum -a 256 {} \; > "<Diagnoseordner>-SHA256SUMS.txt"`

Eine Prüfsumme dokumentiert die Integrität der Datei ab dem Zeitpunkt ihrer Berechnung. Sie beweist nicht automatisch Herkunft oder Authentizität.

---

**20. Abschlussunterlagen schützen**

Diagnose- und Abschlussunterlagen können enthalten:

- Benutzernamen,
- interne IP-Adressen,
- Hostnamen,
- Gruppenmitgliedschaften,
- Dateipfade,
- Zertifikate,
- Prozessbefehle,
- Sicherheitsprotokolle,
- Netzwerkverkehr,
- technische Schwachstellen,
- Hinweise auf Zugangsdaten.

Deshalb muss geklärt sein:

- Wer darf die Unterlagen lesen?
- Wo dürfen sie gespeichert werden?
- Welche Aufbewahrungsfrist gilt?
- Müssen personenbezogene Daten minimiert werden?
- Muss eine unveränderte Originalkopie erhalten bleiben?
- Darf eine geschwärzte Arbeitskopie erstellt werden?
- Wann müssen die Daten gelöscht werden?
- Gelten rechtliche oder vertragliche Anforderungen?

---

**21. Wann eine ausführliche Nachanalyse sinnvoll ist**

Eine ausführliche Nachanalyse oder ein Postmortem ist besonders sinnvoll bei:

- längerem produktivem Ausfall,
- großer Benutzerwirkung,
- Datenverlust,
- Sicherheitsvorfall,
- wiederkehrender Störung,
- mehreren beteiligten Teams,
- fehlgeschlagener Änderung,
- unerwartetem Failover,
- hohem manuellem Wiederherstellungsaufwand,
- fehlender oder verspäteter Erkennung,
- unklarer Ursache,
- kritischem Single Point of Failure,
- nicht funktionierendem Rückfallplan,
- erheblicher SLA- oder SLO-Verletzung.

Die Kriterien sollten möglichst bereits vor einer Störung organisatorisch festgelegt werden.

---

**22. Sachliche und schuldfreie Nachanalyse**

Eine Nachanalyse soll Systeme und Prozesse verbessern, nicht einzelne Personen beschuldigen.

**Ungeeignet**

`Der Administrator war unvorsichtig und hat den falschen Wert eingetragen.`

**Besser**

`Die Verwaltungsoberfläche akzeptierte den ungültigen Wert ohne technische Validierung. Die Änderung wurde anschließend ohne Staging- oder Canary-Prüfung auf alle Instanzen verteilt.`

**Weiterführende Fragen**

- Warum konnte ein ungültiger Wert gespeichert werden?
- Warum erkannte kein automatischer Test den Fehler?
- Warum wurde die Änderung gleichzeitig überall verteilt?
- Warum erkannte das Monitoring die Benutzerwirkung nicht?
- Warum war der Rückfallplan nicht verfügbar?
- Welche Informationen standen der ausführenden Person zur Verfügung?
- Welche technische Schutzmaßnahme hätte den Fehler verhindert?

---

**23. Regeln für eine sachliche Formulierung**

| Vermeiden | Besser |
|---|---|
| Schuldzuweisung | technischen Ablauf beschreiben |
| persönliche Bewertung | beobachtbare Fakten verwenden |
| „offensichtlich“ | konkrete Belege nennen |
| „immer“ oder „nie“ | Zeitraum und Umfang nennen |
| „Server war kaputt“ | betroffene Funktion beschreiben |
| „Netzwerkproblem“ | Protokoll, Quelle und Ziel nennen |
| „Benutzerfehler“ | konkrete Eingabe oder Prozesslücke nennen |
| „Problem gelöst“ | getestete Funktion und Ergebnis nennen |
| „Monitoring versagte“ | fehlende Prüfung oder Alarmbedingung nennen |

---

**24. Aufbau einer Nachanalyse**

| Abschnitt | Inhalt |
|---|---|
| Titel | eindeutiger Name und Ticketnummer |
| Datum | Datum der Störung und Nachanalyse |
| Status | Entwurf, geprüft oder abgeschlossen |
| Beteiligte Systeme | technische Komponenten |
| Zusammenfassung | kurze sachliche Beschreibung |
| Auswirkung | Benutzer, Dienste, Dauer und Daten |
| Erkennung | wie und wann die Störung erkannt wurde |
| Zeitachse | wichtige Ereignisse |
| Ursache | technische Ursache und Mechanismus |
| Auslöser | aktivierendes Ereignis |
| Begünstigende Faktoren | Bedingungen, die Wirkung verstärkten |
| Wiederherstellung | Maßnahmen zur Betriebswiederherstellung |
| Lösung | dauerhafte Korrektur |
| Was funktionierte gut? | hilfreiche Abläufe und Werkzeuge |
| Was funktionierte nicht? | technische oder organisatorische Lücken |
| Wo bestand Glück? | Faktoren, die größeren Schaden zufällig verhinderten |
| Folgeaufgaben | konkrete Verbesserungsmaßnahmen |
| Belege | Protokolle, Tickets, Ausgaben und Changes |

---

**25. „Was funktionierte gut?“ dokumentieren**

Beispiele:

- Monitoring erkannte den Fehler schnell.
- Eskalationsweg war bekannt.
- Zuständigkeiten waren eindeutig.
- Vergleichssystem war verfügbar.
- Konfiguration war versioniert.
- Rollback war dokumentiert und getestet.
- Kommunikation erfolgte regelmäßig.
- Protokolle enthielten ausreichende Informationen.
- Canary begrenzte die Auswirkung.
- Ersatzsystem war verfügbar.

Diese Punkte zeigen, welche bestehenden Prozesse beibehalten oder ausgebaut werden sollten.

---

**26. „Was funktionierte nicht?“ dokumentieren**

Beispiele:

- Monitoring prüfte nur Hostverfügbarkeit.
- Benutzerfunktion wurde nicht überwacht.
- Konfigurationsänderung wurde nicht validiert.
- Rückfallplan war unvollständig.
- Zuständigkeit war unklar.
- wichtige Protokolle fehlten.
- Zeitstempel der Systeme wichen voneinander ab.
- Dokumentation war veraltet.
- Vergleichssystem fehlte.
- Änderung wurde gleichzeitig auf allen Systemen ausgeführt.
- Workaround war nicht bekannt.
- externe Abhängigkeit war nicht dokumentiert.

Die Beschreibung sollte konkret genug sein, um daraus eine überprüfbare Aufgabe abzuleiten.

---

**27. „Wo bestand Glück?“ dokumentieren**

Dieser Abschnitt beschreibt Faktoren, die einen größeren Schaden verhindert haben, obwohl dafür keine verlässliche Schutzmaßnahme existierte.

Beispiele:

- Störung trat außerhalb der Hauptnutzungszeit auf.
- Ein Administrator kannte einen nicht dokumentierten Workaround.
- Ein nicht betroffenes Ersatzsystem war zufällig verfügbar.
- fehlerhafte Änderung erreichte nicht alle Systeme.
- Datenbankverbindung wurde rechtzeitig manuell getrennt.
- Benutzer meldete den Fehler frühzeitig.
- Backup war verwendbar, obwohl Restore nie getestet wurde.

Glück ist keine dauerhafte Schutzmaßnahme. Daraus sollten Verbesserungsaufgaben entstehen.

---

**28. Konkrete Folgeaufgaben erstellen**

Eine Nachanalyse ohne konkrete und nachverfolgte Maßnahmen verbessert das System nicht.

Jede Folgeaufgabe benötigt:

- eindeutige Beschreibung,
- Verantwortliche,
- Ticket- oder Aufgaben-ID,
- Priorität,
- Zieltermin,
- messbaren Endzustand,
- Prüfmethode,
- Status.

**Ungeeignet**

`Monitoring verbessern.`

**Besser**

`Bis zum 14.08.2026 wird für die Webanwendung ein Ende-zu-Ende-Check eingerichtet, der alle fünf Minuten eine Testanmeldung ausführt und bei drei aufeinanderfolgenden Fehlern alarmiert. Verantwortlich: Betriebsteam. Nachweis: erfolgreich ausgelöster Testalarm.`

Die konkreten Zeitintervalle und Grenzwerte müssen aus den Anforderungen der jeweiligen Umgebung abgeleitet werden.

---

**29. Folgeaufgaben kategorisieren**

| Kategorie | Ziel | Beispiel |
|---|---|---|
| Verhindern | Fehlerentstehung verhindern | Konfigurationsvalidierung |
| Begrenzen | Auswirkung reduzieren | Canary oder Rate Limit |
| Erkennen | Fehler früher feststellen | Ende-zu-Ende-Monitoring |
| Diagnostizieren | Ursache schneller finden | strukturierte Protokolle |
| Wiederherstellen | Reparatur beschleunigen | getesteter Rückfallplan |
| Dokumentieren | Wissen verfügbar machen | Runbook aktualisieren |
| Automatisieren | manuelle Fehler reduzieren | geprüfte Deployment-Pipeline |
| Schulen | Verfahren bekannt machen | Übung des Notfallablaufs |
| Entfernen | unnötige Abhängigkeit beseitigen | Single Point of Failure abbauen |

---

**30. Wirksamkeit von Maßnahmen priorisieren**

| Stärke | Maßnahmenart | Beispiel |
|---:|---|---|
| 1 | Fehler technisch unmöglich machen | ungültige Konfiguration wird abgelehnt |
| 2 | Änderung automatisch prüfen | automatischer Syntax- und Funktionstest |
| 3 | Auswirkung begrenzen | Canary, Redundanz, automatische Rücknahme |
| 4 | Fehler schnell erkennen | Ende-zu-Ende-Monitoring |
| 5 | Wiederherstellung beschleunigen | getestetes Runbook |
| 6 | Warnhinweis oder Checkliste | manueller Prüfschritt |
| 7 | Erinnerung an mehr Aufmerksamkeit | „Beim nächsten Mal besser aufpassen“ |

Technische Schutzmaßnahmen und automatisierte Prüfungen sind normalerweise zuverlässiger als eine reine Aufforderung zu größerer Aufmerksamkeit.

---

**31. Folgeaufgaben richtig formulieren**

| Feld | Beispiel |
|---|---|
| Aufgabe | JSON-Konfiguration vor Deployment validieren |
| Begründung | ungültiger Hostname verursachte Ausfall |
| Verantwortlich | Plattformteam |
| Priorität | Hoch |
| Zieltermin | 14.08.2026 |
| messbarer Endzustand | Pipeline lehnt ungültiges Schema ab |
| Prüfmethode | Testdeployment mit absichtlich ungültigem Wert |
| Ticket-ID | TASK-2026-0182 |
| Status | Offen |

---

**32. Maßnahmenstatus verwenden**

| Status | Bedeutung |
|---|---|
| Offen | Aufgabe wurde erstellt |
| Geplant | Umsetzung ist terminiert |
| In Bearbeitung | Umsetzung läuft |
| Blockiert | Abhängigkeit verhindert Umsetzung |
| Umgesetzt | technische Änderung ist erfolgt |
| In Prüfung | Wirksamkeit wird verifiziert |
| Abgeschlossen | messbarer Endzustand ist bestätigt |
| Verworfen | Aufgabe wurde begründet abgelehnt |
| Risiko akzeptiert | Risiko wurde durch zuständige Stelle akzeptiert |

„Umgesetzt“ und „wirksam bestätigt“ sollten unterschieden werden.

---

**33. Monitoring aus der Störung verbessern**

Nach einer Störung sollte geprüft werden:

- Wurde der Fehler automatisch erkannt?
- Wurde die Benutzerwirkung erkannt?
- War der Alarm rechtzeitig?
- War der Alarm verständlich?
- War der Alarm einer zuständigen Person zugeordnet?
- Enthielt der Alarm ausreichend Kontext?
- Gab es zu viele irrelevante Alarme?
- Fehlte eine wichtige Messgröße?
- Funktionierte der Alarm während der Störung?
- Wurde die Wiederherstellung korrekt erkannt?

**Guter Alarm**

Ein guter Alarm ist:

- symptomorientiert,
- handlungsrelevant,
- eindeutig zugeordnet,
- mit Zeit und betroffenem System versehen,
- mit Runbook oder Diagnosehinweis verknüpft,
- anhand eines realistischen Grenzwerts ausgelöst.

---

**34. Benutzerwirkung statt nur Komponentenstatus überwachen**

| Komponentenprüfung | Zusätzliche Ende-zu-Ende-Prüfung |
|---|---|
| Server antwortet auf Ping | Benutzer kann Anwendung öffnen |
| TCP 443 ist erreichbar | HTTPS-Anmeldung funktioniert |
| Dienststatus ist „Running“ | konkrete API-Anfrage funktioniert |
| Datenbankprozess läuft | Anwendung kann Daten lesen |
| Dateiserver ist erreichbar | Testdatei kann gelesen werden |
| Drucker antwortet im Netz | Testseite wird tatsächlich gedruckt |
| Backupjob startet | Sicherung wird erfolgreich abgeschlossen und geprüft |
| DNS-Dienst läuft | vorgesehener Name wird korrekt aufgelöst |

---

**35. Dokumentation und Runbooks aktualisieren**

Nach der Störung sollten geprüft werden:

- Systemdokumentation,
- Netzplan,
- Port- und Firewallübersicht,
- Dienstabhängigkeiten,
- Backup- und Restoreanleitung,
- Eskalationskontakte,
- Monitoringbeschreibung,
- bekannte Fehler,
- Installationsanleitung,
- Rollbackverfahren,
- Notfallzugänge,
- Konfigurationsvorlagen,
- Befehlsübersichten.

**Ein guter Wissenseintrag enthält**

- eindeutiges Fehlerbild,
- typische Fehlermeldung,
- betroffene Systeme,
- mögliche Ursachen,
- Diagnosebefehle,
- Interpretation der Ausgaben,
- bestätigte Lösung,
- Rückfallmöglichkeit,
- Risiken,
- Quellen,
- Datum der letzten Prüfung.

---

**36. Wiederkehrende Störungen erkennen**

Einzelne Tickets sollten nach gemeinsamen Merkmalen ausgewertet werden.

**Mögliche Suchmerkmale**

- gleiche Fehlermeldung,
- gleicher Dienst,
- gleicher Standort,
- gleiches Gerät,
- gleiche Anwendungsversion,
- gleicher Zeitpunkt,
- gleicher Hersteller,
- gleicher Auslöser,
- gleicher Workaround,
- gleiche Grundursache.

Bei wiederkehrenden Störungen sollte ein übergeordneter Problem- oder Ursachenanalyse-Eintrag erstellt und mit den einzelnen Tickets verknüpft werden.

---

**37. Verbleibende Risiken dokumentieren**

Nicht jede Verbesserung kann sofort umgesetzt werden.

| Risiko | Wahrscheinlichkeit | Auswirkung | Zwischenmaßnahme | Verantwortlich | Termin |
|---|---|---|---|---|---|
| Fehler kann bis zur Pipeline-Anpassung erneut auftreten | Mittel | Hoch | Änderungen manuell prüfen | Plattformteam | 14.08.2026 |
| Monitoring erkennt Teilfehler nicht | Mittel | Mittel | manuelle Kontrolle | Betriebsteam | 07.08.2026 |
| Rollback noch nicht automatisiert | Niedrig | Hoch | dokumentiertes manuelles Verfahren | Entwicklung | 21.08.2026 |

Ein Risiko darf nur durch die dafür zuständige Stelle akzeptiert werden.

---

**38. Sicherheitsvorfälle gesondert behandeln**

Bei einem möglichen oder bestätigten Sicherheitsvorfall darf der normale technische Ticketabschluss nicht allein entscheiden.

Zusätzlich können erforderlich sein:

- Freigabe durch Incident Response oder SecOps,
- Beweismittelerhaltung,
- Datenschutzprüfung,
- rechtliche Bewertung,
- Meldepflichten,
- Benachrichtigung betroffener Stellen,
- längere Aufbewahrungsfristen,
- zusätzliche Kontrollen,
- Zugangsdatenwechsel,
- Bedrohungssuche,
- Überwachung möglicher Folgeaktivitäten.

Der technische Dienst kann bereits wiederhergestellt sein, während der Sicherheitsvorfall noch offen bleibt.

---

**39. Abschlusskommunikation erstellen**

Eine Abschlussmeldung sollte enthalten:

- betroffene Funktion,
- Zeitraum,
- Auswirkung,
- Wiederherstellungszeitpunkt,
- bestätigte Ursache oder aktueller Kenntnisstand,
- umgesetzte Lösung,
- verbleibende Einschränkungen,
- offene Folgemaßnahmen,
- Ansprechpartner oder Ticketnummer.

**Beispiel**

`Die Störung beim Zugriff auf die Webanwendung ist seit 15:42 Uhr behoben. Betroffen waren Clients aus VLAN 30. Ursache war eine fehlerhafte Firewall-ACL für TCP 443. Die Regel wurde korrigiert und durch Port-, Anmelde- und Monitoringtests bestätigt. Weitere Einschränkungen sind derzeit nicht bekannt. Als Folgemaßnahme wird ein automatischer Verbindungstest aus jedem Client-VLAN eingerichtet. Referenz: INC-2026-0042.`

---

**40. Vollständiges Abschlussbeispiel**

**Zusammenfassung**

Am 30.07.2026 konnten Clients aus VLAN 30 die Anwendung `server.example` über HTTPS nicht erreichen.

**Auswirkung**

- ein Standort betroffen,
- ungefähr 45 Arbeitsplätze,
- Anmeldung an der Anwendung nicht möglich,
- keine Hinweise auf Datenverlust,
- Clients aus VLAN 40 nicht betroffen.

**Zeitraum**

- letzter erfolgreicher Zugriff: 13:50 Uhr,
- erste bekannte Störung: 14:35 Uhr,
- Erkennung: 14:42 Uhr,
- Wiederherstellung: 15:42 Uhr,
- Beobachtung beendet: 16:42 Uhr.

**Ursache**

Eine Firewall-ACL blockierte TCP 443 aus VLAN 30.

**Auslöser**

Die ACL wurde bei einer Netzwerkänderung um 14:31 Uhr unvollständig übernommen.

**Begünstigender Faktor**

Es existierte kein automatischer Verbindungstest aus jedem Client-VLAN.

**Diagnose**

- DNS-Auflösung korrekt,
- Ziel-IP korrekt,
- Porttest aus VLAN 30 fehlgeschlagen,
- Porttest aus VLAN 40 erfolgreich,
- Firewall-Log zeigte verworfene Pakete,
- Serverdienst und Listener waren aktiv.

**Lösung**

Die freigegebene ACL wurde korrigiert.

**Verifikation**

- TCP 443 aus VLAN 30 erreichbar,
- HTTPS-Anmeldung erfolgreich,
- andere VLANs weiterhin funktionsfähig,
- gesperrte Ports weiterhin gesperrt,
- keine neuen relevanten Firewallfehler,
- Monitoring über eine Stunde unauffällig.

**Folgeaufgaben**

| Aufgabe | Verantwortlich | Priorität | Termin |
|---|---|---|---|
| Verbindungstest aus jedem Client-VLAN einrichten | Monitoringteam | Hoch | 14.08.2026 |
| ACL-Änderungsvorlage ergänzen | Netzwerkteam | Mittel | 07.08.2026 |
| Rückfallverfahren dokumentieren | Netzwerkteam | Mittel | 07.08.2026 |
| Netzplandokumentation aktualisieren | Systemintegration | Mittel | 05.08.2026 |

---

**41. Vorlage für eine vollständige Störungsdokumentation**

**Ticketnummer:**  
`<Ticketnummer>`

**Titel:**  
`<Kurze eindeutige Störungsbeschreibung>`

**Status:**  
`Erkannt / In Analyse / Workaround / Wiederhergestellt / Beobachtung / Gelöst / Abgeschlossen`

**Zusammenfassung:**  
`<Was ist passiert?>`

**Auswirkung:**  
`<Benutzer, Systeme, Standorte, Funktionen und Daten>`

**Beginn der Störung:**  
`<Datum, Uhrzeit und Zeitzone>`

**Erkennung:**  
`<Datum, Uhrzeit, Quelle und Zeitzone>`

**Wiederherstellung:**  
`<Datum, Uhrzeit und Zeitzone>`

**Ende der Beobachtung:**  
`<Datum, Uhrzeit und Zeitzone>`

**Betroffene Systeme:**  
`<Liste>`

**Nicht betroffene Vergleichssysteme:**  
`<Liste>`

**Fehlermeldung:**  
`<vollständiger Fehlertext>`

**Direkte technische Ursache:**  
`<Ursache>`

**Technischer Mechanismus:**  
`<Wie erzeugte die Ursache das Symptom?>`

**Auslöser:**  
`<Ereignis oder Änderung>`

**Grundursache:**  
`<systemischer Grund>`

**Begünstigende Faktoren:**  
`<Liste>`

**Erkennungslücken:**  
`<Liste>`

**Zeitachse:**  
`<chronologische Ereignisse>`

**Diagnosebefehle und Ergebnisse:**  
`<Befehle, Ausgaben und Verweise>`

**Sofortmaßnahme:**  
`<Workaround oder Eindämmung>`

**Dauerhafte Lösung:**  
`<umgesetzte Korrektur>`

**Rollback:**  
`<vorbereitet, durchgeführt oder nicht erforderlich>`

**Verifikation:**  
`<technische, fachliche, negative und Regressionstests>`

**Monitoring nach der Lösung:**  
`<Messwerte und Beobachtungsdauer>`

**Verbleibende Risiken:**  
`<Liste>`

**Folgeaufgaben:**  
`<Ticket-ID, Verantwortliche, Priorität, Termin und Prüfmethode>`

**Abschlussfreigabe:**  
`<zuständige Person oder Rolle>`

---

**42. Abschlusscheckliste**

- [ ] Ursprüngliche Benutzerfunktion wiederhergestellt
- [ ] Technische Funktion geprüft
- [ ] Abhängigkeiten geprüft
- [ ] Regressionstests durchgeführt
- [ ] Negative Sicherheitstests durchgeführt
- [ ] Monitoring beobachtet
- [ ] Protokolle nach der Lösung geprüft
- [ ] Wiederherstellungszeit dokumentiert
- [ ] Abschlusszeit dokumentiert
- [ ] Zeitzone angegeben
- [ ] Fehlerumfang dokumentiert
- [ ] Auswirkung dokumentiert
- [ ] Zeitachse erstellt
- [ ] Direkte Ursache dokumentiert
- [ ] Auslöser dokumentiert
- [ ] Grundursache dokumentiert
- [ ] Begünstigende Faktoren dokumentiert
- [ ] Erkennungslücken dokumentiert
- [ ] Workaround und dauerhafte Lösung unterschieden
- [ ] Diagnosebefehle und Ergebnisse zugeordnet
- [ ] Belege geschützt gespeichert
- [ ] Prüfsummen erstellt
- [ ] verbleibende Risiken dokumentiert
- [ ] Folgeaufgaben erstellt
- [ ] jede Folgeaufgabe besitzt eine verantwortliche Person
- [ ] jede Folgeaufgabe besitzt einen messbaren Endzustand
- [ ] Monitoringverbesserungen geprüft
- [ ] Runbooks und Dokumentation geprüft
- [ ] betroffene Personen informiert
- [ ] Sicherheits- oder Datenschutzprüfung berücksichtigt
- [ ] Abschlussstatus eindeutig gesetzt

---

**Ergebnis dieses Arbeitsschrittes**

Am Ende dieses Schrittes ist nicht nur die technische Funktion wiederhergestellt. Der gesamte Vorfall ist nachvollziehbar dokumentiert, offene Risiken sind bekannt und konkrete Verbesserungsmaßnahmen wurden zugewiesen.

Eine Störung sollte erst abgeschlossen werden, wenn:

- Wiederherstellung bestätigt ist,
- Ursache oder verbleibende Unsicherheit dokumentiert ist,
- Auswirkungen und Zeitachse nachvollziehbar sind,
- offene Maßnahmen nachverfolgt werden,
- Erkenntnisse in Monitoring, Dokumentation und Betriebsprozesse zurückfließen.

**Nächste Seite und Abschluss von Kapitel 1:**  
**1.10 Schnellreferenz – Diagnosebefehle für Windows, Linux und macOS**

---

**Offizielle Hersteller-, Behörden- und Projektdokumentation**

- [NIST – SP 800-61 Revision 3: Incident Response Recommendations and Considerations](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- [NIST – Incident-Response-Projekt](https://csrc.nist.gov/projects/incident-response)
- [Google SRE – Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
- [Google SRE Workbook – Postmortem Practices](https://sre.google/workbook/postmortem-culture/)
- [Google SRE – Incident Management Guide](https://sre.google/resources/practices-and-processes/incident-management-guide/)
- [Microsoft Learn – Post-incident Activity](https://learn.microsoft.com/en-us/compliance/assurance/assurance-sim-post-incident-activity)
- [Microsoft Learn – Incident Management](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management)
- [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash)
- [CISA – Cybersecurity Incident and Vulnerability Response Playbooks](https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks)
- [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html)