# 1.7 Ursache bestätigen und alternative Erklärungen ausschließen Eine plausible Hypothese ist noch keine bestätigte Ursache. Auch wenn eine Maßnahme scheinbar erfolgreich war, kann ein anderer gleichzeitig veränderter Zustand für die Wiederherstellung verantwortlich gewesen sein. Deshalb gilt: > Eine Ursache muss das Fehlerbild technisch erklären, zu Umfang und Zeitpunkt passen und durch Belege oder Gegenproben gestützt werden. In komplexen IT-Systemen existiert häufig nicht nur eine einzelne Ursache. Meist wirken Auslöser, technische Fehler, Abhängigkeiten und begünstigende Bedingungen zusammen. --- **Ziel dieser Seite** Nach diesem Arbeitsschritt sollten: - Symptom und Ursache getrennt sein, - unmittelbare Ursache und Grundursache unterschieden sein, - Auslöser und begünstigende Faktoren identifiziert sein, - abhängige Systeme berücksichtigt sein, - widersprechende Beobachtungen geprüft sein, - alternative Erklärungen bewertet sein, - die Ursache mit mehreren Belegen bestätigt sein, - verbleibende Unsicherheiten dokumentiert sein. --- **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 | | `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen | | `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten | --- **2. Symptom, unmittelbare Ursache und Grundursache unterscheiden** | Ebene | Bedeutung | Beispiel | |---|---|---| | Symptom | Sichtbare Auswirkung | Webanwendung liefert HTTP 503 | | Unmittelbare technische Ursache | Zustand, der das Symptom direkt erzeugt | Backend kann keine Datenbankverbindung aufbauen | | Auslöser | Ereignis, das den Fehler aktiviert hat | Neue Konfiguration wurde bereitgestellt | | Grundursache | Systemischer Grund, warum der Fehler möglich war | Pipeline prüfte den Datenbank-Hostnamen nicht | | Begünstigender Faktor | Bedingung, die Entstehung oder Auswirkung verstärkte | Änderung wurde gleichzeitig auf allen Backends verteilt | | Erkennungslücke | Grund für eine verspätete Erkennung | Monitoring prüfte nur, ob TCP 443 erreichbar war | | Wiederherstellungsfaktor | Maßnahme, die den Betrieb wiederherstellte | Konfigurationsrollback | | Präventionsmaßnahme | Maßnahme gegen eine Wiederholung | Validierung und schrittweise Bereitstellung einführen | --- **3. Beispiel einer vollständigen Ursachenkette** | Ebene | Feststellung | |---|---| | Symptom | Benutzer erhalten HTTP 503 | | Direkte Ursache | Webanwendung erreicht die Datenbank nicht | | Technischer Mechanismus | Falscher Datenbank-Hostname in der Anwendungskonfiguration | | Auslöser | Deployment um 14:31 Uhr | | Grundursache | Deployment-Pipeline akzeptiert ungeprüfte Konfigurationswerte | | Begünstigender Faktor | Änderung wurde auf allen Instanzen gleichzeitig ausgerollt | | Erkennungslücke | Kein Ende-zu-Ende-Monitoring der Anmeldung | | Wiederherstellung | Vorherige Konfiguration wurde wiederhergestellt | | Prävention | Schema-Validierung, Staging-Test und schrittweiser Rollout | Die Aussage „Das Deployment war schuld“ wäre zu ungenau. Erst die vollständige Ursachenkette zeigt, was technisch fehlschlug und wodurch eine Wiederholung verhindert werden kann. --- **4. Nicht vorschnell nach einer einzigen Ursache suchen** Komplexe Störungen entstehen häufig durch eine Kombination mehrerer Bedingungen. **Beispiel** Ein einzelnes fehlerhaftes Backend führt nicht zwangsläufig zu einem Gesamtausfall. Der Ausfall entsteht möglicherweise erst, weil zusätzlich: - der Load Balancer fehlerhafte Health Checks verwendet, - alle Anfragen zum fehlerhaften Backend geleitet werden, - die verbleibenden Backends überlastet werden, - kein automatisches Failover erfolgt, - Monitoring die wachsende Fehlerquote nicht erkennt. In diesem Fall gibt es mehrere relevante Ursachen und beitragende Faktoren. **Zu dokumentierende Ursachenarten** - technische Ursache, - Konfigurationsursache, - Prozessursache, - organisatorische Ursache, - fehlende Schutzmaßnahme, - fehlende Erkennung, - fehlende oder unwirksame Wiederherstellung. --- **5. Eine Ursache gilt nicht allein durch zeitliche Nähe als bestätigt** **Unzureichende Aussage** `Der Fehler begann nach dem Update, also war das Update die Ursache.` **Erforderliche Zusatzfragen** - Welche konkrete Komponente wurde verändert? - Passt diese Komponente technisch zum Fehlerbild? - Sind nur aktualisierte Systeme betroffen? - Funktionieren identisch aktualisierte Vergleichssysteme? - Gibt es passende Protokolleinträge? - Verändert ein Rollback das Ergebnis? - Könnte der Neustart während des Updates entscheidend gewesen sein? - Wurden gleichzeitig weitere Änderungen ausgeführt? - Trat der Fehler möglicherweise bereits vor dem Update auf? --- **6. Stärke von Belegen bewerten** | Beleg | Aussagekraft | |---|---| | Vermutung ohne Messwert | Sehr gering | | Einzelne Benutzerangabe | Gering | | Zeitliche Nähe | Gering bis mittel | | Passende Fehlermeldung | Mittel | | Reproduzierbares Muster | Mittel bis hoch | | Konfigurationsunterschied zum funktionierenden System | Hoch | | Protokoll zeigt direkten technischen Fehler | Hoch | | Paketaufzeichnung bestätigt Kommunikationsfehler | Hoch | | Fehler verschwindet nach kontrollierter Entfernung der Ursache | Sehr hoch | | Fehler erscheint in Testumgebung nach kontrollierter Wiederherstellung der Ursache erneut | Sehr hoch | | Mehrere voneinander unabhängige Belege stimmen überein | Sehr hoch | Eine zuverlässige Bestätigung verwendet möglichst mehrere voneinander unabhängige Belege. --- **7. Kriterien für eine bestätigte Ursache** Eine Ursache sollte möglichst folgende Fragen beantworten: | Kriterium | Frage | |---|---| | Technischer Mechanismus | Wie erzeugt die Ursache das beobachtete Symptom? | | Fehlerumfang | Warum sind genau diese Systeme oder Benutzer betroffen? | | Zeitlicher Zusammenhang | Warum begann der Fehler zu diesem Zeitpunkt? | | Reproduzierbarkeit | Lässt sich das Verhalten kontrolliert wiederholen? | | Vergleich | Warum funktionieren nicht betroffene Systeme? | | Gegenprobe | Verschwindet das Symptom ohne die vermutete Ursache? | | Alternativen | Welche anderen Erklärungen wurden geprüft? | | Widersprüche | Gibt es Fakten, die nicht zur Ursache passen? | | Beweislage | Welche Logs, Messwerte oder Vergleiche bestätigen sie? | | Wiederholungsschutz | Welche Maßnahme verhindert ein erneutes Auftreten? | Wenn eine vermutete Ursache den Umfang oder den technischen Mechanismus nicht erklären kann, ist sie wahrscheinlich unvollständig. --- **8. Die Gegenfrage stellen** Eine besonders wichtige Frage lautet: > Was müsste beobachtet werden, wenn die vermutete Ursache nicht stimmt? **Beispiel** Hypothese: `Eine Firewall-Regel blockiert TCP 443 aus VLAN 30.` Mögliche Gegenbelege: - Pakete aus VLAN 30 erreichen den Server nachweislich. - Der Server sendet eine Antwort zurück. - Der Fehler tritt auch innerhalb des Servernetzes auf. - Ein lokaler Test auf dem Server schlägt ebenfalls fehl. - Die Firewall protokolliert eine erlaubte Verbindung. - Andere Dienste über denselben Netzwerkpfad sind ebenfalls betroffen. - Der Fehler besteht nach Rücknahme der Firewall-Regel weiter. Gegenbelege müssen genauso sorgfältig dokumentiert werden wie unterstützende Belege. --- **9. Kontrafaktische Prüfung** Eine kontrafaktische Prüfung untersucht, was ohne die vermutete Ursache geschehen würde. | Frage | Bedeutung | |---|---| | Wäre die Störung ohne diese Bedingung aufgetreten? | Prüft die Notwendigkeit der Ursache | | Existiert dieselbe Bedingung auf funktionierenden Systemen? | Prüft, ob sie allein ausreichend ist | | Verschwindet der Fehler, wenn die Bedingung entfernt wird? | Prüft den direkten Zusammenhang | | Erscheint der Fehler in einer Testumgebung erneut? | Prüft Reproduzierbarkeit | | Erklärt die Ursache auch die nicht betroffenen Systeme? | Prüft den Fehlerumfang | | Gibt es einen anderen Faktor mit derselben Wirkung? | Prüft alternative Erklärungen | Eine Bedingung kann notwendig, aber allein nicht ausreichend sein. Beispielsweise kann ein fehlerhaftes Backend erst zusammen mit einer fehlerhaften Load-Balancer-Konfiguration einen vollständigen Ausfall verursachen. --- **10. Ursachenbestätigung mit A/B-Vergleich** | Zustand A | Zustand B | Mögliche Interpretation | |---|---|---| | Betroffenes System | Funktionierendes System | Unterschiede priorisieren | | Fehlerhafte Konfiguration | Bekannte funktionierende Konfiguration | Konfigurationsunterschied prüfen | | Benutzer A gestört | Benutzer B funktioniert | Konto oder Berechtigung prüfen | | VLAN 30 gestört | VLAN 40 funktioniert | Netzwerkpfad oder ACL prüfen | | Backend 1 funktioniert | Backend 2 gestört | Backend-spezifische Ursache | | Anwendungsversion alt funktioniert | neue Version gestört | Versionsänderung priorisieren | | Proxy verwendet | direkter Test funktioniert | Proxy oder Proxyrichtlinie prüfen | | DNS-Auflösung verwendet | festes Ziel funktioniert | DNS oder Zielauswahl prüfen | Der Vergleich ist nur aussagekräftig, wenn alle nicht untersuchten Bedingungen möglichst gleich bleiben. --- **11. Betroffenes und funktionierendes System vergleichen** **Zu vergleichende Eigenschaften** | Bereich | Beispiele | |---|---| | Betriebssystem | Version, Build, Kernel | | Updates | Patchstand und Installationszeit | | Anwendung | Version, Module, Erweiterungen | | Konfiguration | Inhalt, Prüfsumme, Änderungszeit | | Dienste | Status, Starttyp, Dienstkonto | | Netzwerk | IP, VLAN, Gateway, DNS, Proxy | | Sicherheit | Firewallprofil, EDR, Zertifikate | | Benutzer | Gruppen, Rollen, Richtlinien | | Dateien | Version, Besitzer, Rechte, ACL | | Abhängigkeiten | Datenbank, API, Storage, DNS | | Umgebung | Variablen, Pfade, Laufzeitversion | | Ressourcen | CPU, RAM, Datenträger, Quota | --- **12. Dateien und Konfigurationen unter Windows vergleichen** **Dateiinhalte vergleichen** `[RO] Compare-Object (Get-Content "") (Get-Content "")` **SHA-256-Prüfsumme bilden** `[RO] Get-FileHash "" -Algorithm SHA256` **Dateiinformationen anzeigen** `[RO] Get-Item "" | Select-Object FullName, Length, CreationTime, LastWriteTime` **Versionsinformationen einer ausführbaren Datei** `[RO] (Get-Item "").VersionInfo` **Berechtigungen anzeigen** `[RO][SENSITIV] Get-Acl "" | Format-List` **Installierte Hotfixes vergleichen** `[RO] Get-HotFix | Sort-Object InstalledOn -Descending` --- **13. Dateien und Konfigurationen unter Linux vergleichen** **Dateien zeilenweise vergleichen** `[RO] diff -u "" ""` **SHA-256-Prüfsumme bilden** `[RO] sha256sum ""` **Dateiinformationen anzeigen** `[RO] stat ""` **Dateityp bestimmen** `[RO] file ""` **Berechtigungen und ACL anzeigen** `[RO][SENSITIV] getfacl ""` **Debian- oder Ubuntu-Paketversion** `[RO] dpkg-query -W ""` **RHEL-, Rocky-, AlmaLinux- oder Fedora-Paketversion** `[RO] rpm -q ""` --- **14. Dateien und Konfigurationen unter macOS vergleichen** **Dateien zeilenweise vergleichen** `[RO] diff -u "" ""` **SHA-256-Prüfsumme bilden** `[RO] shasum -a 256 ""` **Dateiinformationen anzeigen** `[RO] stat -x ""` **Dateityp bestimmen** `[RO] file ""` **Berechtigungen und ACL anzeigen** `[RO][SENSITIV] ls -lde ""` **Anwendungsversion über Systeminformationen suchen** `[RO] system_profiler SPApplicationsDataType` Bei umfangreichen Installationen kann `system_profiler SPApplicationsDataType` längere Zeit benötigen und eine große Ausgabe erzeugen. --- **15. Prüfsummen richtig interpretieren** | Ergebnis | Bedeutung | |---|---| | Prüfsummen identisch | Dateien sind zum Prüfzeitpunkt binär identisch | | Prüfsummen unterschiedlich | Mindestens ein Byte unterscheidet sich | | Dateiinhalt gleich, Metadaten anders | Besitzer, Rechte oder Zeitstempel können abweichen | | Anwendungsversion gleich, Prüfsumme anders | anderer Build, beschädigte Datei oder Modifikation möglich | | Prüfsumme gleich, Verhalten anders | Ursache liegt wahrscheinlich außerhalb der Datei | Eine identische Prüfsumme beweist nicht, dass die gesamte Umgebung identisch ist. --- **16. Dienstabhängigkeiten unter Windows prüfen** **Benötigte Dienste anzeigen** `[RO] Get-Service -Name -RequiredServices` **Abhängige Dienste anzeigen** `[RO] Get-Service -Name -DependentServices` **Dienstkonfiguration anzeigen** `[RO] sc.exe qc ` **Erweiterte Dienstinformationen** `[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name=''" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId` **Dienstereignisse anzeigen** `[RO] Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"; StartTime=(Get-Date).AddHours(-1)} | Select-Object TimeCreated, Id, Message` **Listener eines Dienstes prüfen** `[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort ` **Prozess zum Listener bestimmen** `[RO] Get-Process -Id ` --- **17. Dienstabhängigkeiten unter Linux prüfen** **Abhängigkeiten eines Dienstes anzeigen** `[RO] systemctl list-dependencies .service --all` **Dienste anzeigen, die vom untersuchten Dienst abhängen** `[RO] systemctl list-dependencies .service --reverse --all` **Deklarierte Abhängigkeiten und Reihenfolge** `[RO] systemctl show .service -p Requires -p Wants -p After -p Before` **Effektive Unit-Konfiguration anzeigen** `[RO] systemctl cat .service` **Dienstzustand anzeigen** `[RO] systemctl status .service --no-pager` **Dienstprotokoll anzeigen** `[RO] journalctl -u .service --since "1 hour ago" --no-pager` **Listener prüfen** `[RO][PRIV] ss -lntp | grep ":"` **Prozess untersuchen** `[RO] ps -p -o pid,ppid,user,lstart,stat,%cpu,%mem,command` --- **18. Dienstzustand unter macOS prüfen** macOS verwendet `launchd`. Die richtige Dienst-Domain hängt davon ab, ob es sich um einen System-, Benutzer- oder GUI-Dienst handelt. **Geladene Dienste anzeigen** `[RO] launchctl list` **Systemdienst untersuchen** `[RO][PRIV] launchctl print system/` **Benutzerdienst untersuchen** `[RO] launchctl print gui//` Die Benutzer-ID kann mit folgendem Befehl ermittelt werden: `[RO] id -u` **Property-List anzeigen** `[RO] plutil -p ""` **Listener prüfen** `[RO][PRIV] lsof -nP -iTCP: -sTCP:LISTEN` **Prozess untersuchen** `[RO] ps -p -o pid,ppid,user,lstart,state,%cpu,%mem,command` `launchd` bildet Abhängigkeiten nicht in derselben Weise wie systemd ab. Deshalb müssen zusätzlich verwendete Sockets, Dateien, Netzwerkziele und Anwendungsprotokolle geprüft werden. --- **19. Technische Abhängigkeiten vollständig betrachten** Ein sichtbarer Dienst kann von vielen weiteren Komponenten abhängen. | Komponente | Mögliche Abhängigkeit | |---|---| | Client | DNS, Proxy, Zertifikat, Richtlinie | | DNS | Zone, Forwarder, Netzwerk, Root-Server | | Webserver | Zertifikat, Dateisystem, Backend | | Reverse Proxy | Upstream, Health Check, DNS | | Anwendung | Datenbank, Cache, Queue, API | | Datenbank | Storage, Speicher, Replikation | | Authentifizierung | Active Directory, LDAP, RADIUS, MFA | | Zertifikat | CA, Zwischenzertifikat, Uhrzeit, Sperrprüfung | | Dateifreigabe | DNS, Kerberos, Berechtigung, Storage | | Container | Netzwerk, Volume, Secret, Image | | Virtuelle Maschine | Hypervisor, Datastore, virtuelles Netzwerk | | Cloud-Dienst | IAM, Sicherheitsgruppe, Region, Provider | | Backup | Agent, Repository, Netzwerk, Dienstkonto | | Monitoring | Agent, Collector, Zeit, Datenbank | --- **20. Abhängigkeitskette dokumentieren** **Beispiel: Anmeldung an einer Webanwendung** | Reihenfolge | Komponente | Erforderliche Funktion | |---:|---|---| | 1 | Client | Netzwerkverbindung vorhanden | | 2 | DNS | Hostname wird korrekt aufgelöst | | 3 | Firewall | TCP 443 wird erlaubt | | 4 | Load Balancer | funktionsfähiges Backend wird gewählt | | 5 | Webserver | TLS und HTTP funktionieren | | 6 | Anwendung | Anmeldeanfrage wird verarbeitet | | 7 | Identitätsdienst | Benutzer wird authentifiziert | | 8 | Datenbank | Benutzer- und Sitzungsdaten sind verfügbar | | 9 | Anwendung | Rolle wird geprüft | | 10 | Browser | Sitzungscookie wird gespeichert | Ein Fehler in einer späteren Abhängigkeit kann nach außen wie ein allgemeiner „Webserverfehler“ wirken. --- **21. Abhängigkeit gezielt umgehen oder isolieren** Eine Komponente kann für einen Test kontrolliert aus dem Pfad genommen werden. Dies darf keine dauerhafte oder unautorisierte Umgehung von Sicherheitskontrollen werden. **DNS für einen einzelnen curl-Test umgehen** `[TEST] curl --resolve "server.example:443:" -v https://server.example/` Dadurch bleiben Hostname, HTTP-Host-Header, SNI und Zertifikatsprüfung erhalten. **Proxy für einen einzelnen curl-Test umgehen** `[TEST] curl --noproxy "*" -v https://server.example/` > Das Umgehen eines Unternehmensproxys kann gegen Sicherheitsrichtlinien verstoßen. Der Test darf nur durchgeführt werden, wenn direkte Verbindungen erlaubt und ausdrücklich autorisiert sind. **Anwendungsebene gegen Transportebene** Windows: `[TEST] Test-NetConnection server.example -Port 443` Linux und macOS: `[TEST] nc -vz -w 3 server.example 443` Anschließend: `[TEST] curl -v https://server.example/` | TCP-Test | HTTP-Test | Wahrscheinlicher Bereich | |---|---|---| | erfolgreich | erfolgreich | grundlegender Dienstpfad funktioniert | | erfolgreich | fehlgeschlagen | TLS, HTTP, Anwendung oder Authentifizierung | | fehlgeschlagen | nicht möglich | Netzwerk, Firewall oder Listener | | wechselnd | wechselnd | Load Balancer, Backend oder instabiler Pfad | --- **22. Alternative Erklärungen bei typischen Beobachtungen** | Beobachtung | Mögliche alternative Erklärungen | |---|---| | Neustart löst Fehler | Cache, Speicherleck, Prozesszustand, Verbindung, Timing | | Dienstneustart löst Fehler | Abhängigkeit wurde neu verbunden, Port freigegeben, Konfiguration neu geladen | | DNS-Cache-Leerung löst Fehler | TTL wäre gleichzeitig abgelaufen, DNS-Eintrag wurde parallel geändert | | Firewall-Änderung löst Fehler | Stateful Session wurde erneuert, NAT oder Route änderte sich | | Update-Rollback löst Fehler | Rollback enthielt ebenfalls Neustart oder Konfigurationsrücksetzung | | Kabelwechsel löst Fehler | Port wurde neu ausgehandelt, Switchport oder DHCP-Lease änderte sich | | Anmeldung mit Testkonto funktioniert | Konto, Rolle, Profil, MFA oder Lizenz unterscheiden sich | | Zugriff über IP funktioniert | DNS möglich, aber HTTPS über IP wurde nicht vollständig geprüft | | Port ist offen | Anwendung kann intern trotzdem fehlerhaft sein | | Dienststatus ist „Running“ | Prozess kann hängen oder Abhängigkeit nicht erreichen | | Ein Test ist erfolgreich | sporadischer Fehler kann weiterhin bestehen | | Fehler verschwindet von selbst | Last, Lease, TTL, Token oder Providerzustand änderte sich | --- **23. Warum „Nach Maßnahme funktioniert es“ nicht immer genügt** Zwischen Maßnahme und erfolgreichem Test können weitere Veränderungen stattgefunden haben: - Cacheeintrag ist abgelaufen, - DHCP-Lease wurde erneuert, - DNS-Eintrag wurde repliziert, - Benutzerkonto wurde entsperrt, - Token wurde erneuert, - Providerstörung wurde behoben, - Failover ist erfolgt, - geplante Aufgabe wurde beendet, - Last ist zurückgegangen, - anderer Backend-Server wurde ausgewählt. Deshalb müssen Zeitpunkt, technische Wirkung und Kontrolltest zusammen betrachtet werden. --- **24. Gegenprobe durchführen** Eine Gegenprobe testet, ob das Ergebnis wirklich von der vermuteten Ursache abhängt. **Geeignete Gegenproben** - gleicher Test vor und nach der Korrektur, - betroffenes und funktionierendes System vergleichen, - Ursache in Testumgebung entfernen, - vorherige Konfiguration kontrolliert wiederherstellen, - bestimmtes Backend direkt testen, - Funktion mit und ohne Proxy vergleichen, - Funktion aus unterschiedlichen VLANs vergleichen, - Benutzer und Client getrennt wechseln. **Nicht geeignete Gegenprobe** Eine produktive Fehlkonfiguration wird absichtlich erneut aktiviert, obwohl dadurch ein weiterer Ausfall entstehen könnte. Eine erneute Fehlererzeugung gehört normalerweise in: - Testumgebung, - Staging, - Labor, - isolierte Kopie, - geplantes Wartungsfenster mit Freigabe. --- **25. Die Fünf-Warum-Methode vorsichtig einsetzen** Die Fünf-Warum-Methode fragt wiederholt nach dem technischen oder organisatorischen Grund eines Fehlers. **Beispiel** | Frage | Antwort | |---|---| | Warum war die Anwendung nicht erreichbar? | Der Dienst konnte nicht starten | | Warum konnte der Dienst nicht starten? | Die Konfigurationsdatei war ungültig | | Warum war die Konfigurationsdatei ungültig? | Ein Deployment setzte einen falschen Portwert | | Warum wurde der falsche Wert akzeptiert? | Es gab keine Schema-Validierung | | Warum fehlte die Validierung? | Sie war im Deploymentprozess nicht vorgesehen | **Mögliche Grundursache** `Der Deploymentprozess validiert Konfigurationswerte nicht vor der produktiven Bereitstellung.` **Mögliche Prävention** - Schema-Validierung, - automatisierter Konfigurationstest, - Staging, - schrittweiser Rollout, - automatische Rücknahme bei fehlgeschlagenem Health Check. --- **26. Grenzen der Fünf-Warum-Methode** Die Methode darf nicht dazu führen, dass eine komplexe Störung künstlich auf eine einzelne lineare Ursache reduziert wird. **Mögliche Probleme** - mehrere unabhängige Ursachen werden übersehen, - gewünschte Antwort wird durch die Fragestellung vorgegeben, - Untersuchung endet bei „menschlichem Fehler“, - technische und organisatorische Faktoren werden vermischt, - fehlende Belege werden durch Vermutungen ersetzt. Für komplexe Störungen ist eine Ursachenmatrix häufig besser. --- **27. Ursachenmatrix** | Faktor | Vorhanden | Notwendig | Allein ausreichend | Belegt | Bewertung | |---|---|---|---|---|---| | Falscher Datenbank-Hostname | Ja | Ja | Nein | Konfigurationsvergleich | Direkte Ursache | | Keine Konfigurationsvalidierung | Ja | Nein | Nein | Pipeline geprüft | Grundursache | | Gleichzeitiger Rollout | Ja | Nein | Nein | Deploymentprotokoll | Verstärkte Auswirkung | | Kein Ende-zu-Ende-Monitoring | Ja | Nein | Nein | Monitoringkonfiguration | Erkennungslücke | | Hohe Benutzerlast | Nein | Nein | Nein | Monitoring | Widerlegt | | Datenbankausfall | Nein | Nein | Nein | Datenbankmonitoring | Widerlegt | --- **28. Menschliche Handlung nicht automatisch als Grundursache verwenden** **Ungeeignet** `Der Administrator hat die falsche Adresse eingetragen.` Diese Aussage beendet die Untersuchung zu früh. **Weiterführende Fragen** - Warum konnte ein ungültiger Wert gespeichert werden? - Gab es eine technische Validierung? - War die Benutzeroberfläche eindeutig? - Wurde die Änderung automatisch geprüft? - Existierte ein Vier-Augen-Prinzip? - War die Dokumentation aktuell? - War ausreichend Zeit für die Änderung vorgesehen? - Konnte der Rollout schrittweise erfolgen? - Gab es eine automatische Rückfallmöglichkeit? - Warum erkannte das Monitoring den Fehler nicht? Eine sachliche Ursachenanalyse untersucht, wie Systeme und Prozesse verbessert werden können, statt einzelne Personen zu beschuldigen. --- **29. Bestätigungsgrade verwenden** | Grad | Bedeutung | |---|---| | Bestätigt | Direkter Mechanismus, mehrere Belege und Gegenprobe vorhanden | | Sehr wahrscheinlich | Mechanismus und mehrere Belege vorhanden, Gegenprobe nicht möglich | | Wahrscheinlich | Plausibel und teilweise belegt | | Möglich | Technisch denkbar, aber kaum belegt | | Unklar | Belege reichen nicht für eine Bewertung | | Unwahrscheinlich | Mehrere Fakten widersprechen | | Widerlegt | Definierte Vorhersage wurde durch Gegenbeleg widerlegt | Wenn eine Gegenprobe aus Sicherheits- oder Produktionsgründen nicht möglich ist, sollte die Ursache als „sehr wahrscheinlich“ und nicht automatisch als vollständig bestätigt dokumentiert werden. --- **30. Wann die Ursachensuche beendet werden kann** Die Untersuchung kann beendet oder in eine spätere Nachanalyse überführt werden, wenn: - der Dienst stabil wiederhergestellt ist, - der technische Mechanismus nachvollzogen wurde, - Umfang und Zeitpunkt erklärt sind, - alternative wahrscheinliche Ursachen geprüft wurden, - ausreichend starke Belege vorhanden sind, - verbleibende Unsicherheiten dokumentiert sind, - Präventionsmaßnahmen abgeleitet werden können, - weiteres Testen ein unverhältnismäßiges Risiko erzeugen würde. Eine Untersuchung sollte nicht endlos fortgeführt werden. Der notwendige Beweisgrad hängt von Auswirkung und Risiko der Störung ab. | Störung | Erforderlicher Beweisgrad | |---|---| | Einzelner unkritischer Arbeitsplatz | technische Plausibilität und dokumentierter Funktionstest | | Wiederkehrende Unternehmensstörung | mehrere Belege und Gegenprobe | | Kritischer Produktionsausfall | ausführliche Ursachenanalyse | | Datenverlust | hohe Beweissicherheit und Managementbeteiligung | | Sicherheitsvorfall | Incident Response und möglicherweise Forensik | | Rechtlich relevanter Vorfall | dokumentierte Beweismittelkette und Fachstellen | --- **31. Vollständiges Praxisbeispiel** **Störung** Seit 14:31 Uhr liefert `https://server.example` abwechselnd HTTP `200` und HTTP `503`. **Fehlerumfang** - alle Benutzer betroffen, - ungefähr jede zweite Anfrage schlägt fehl, - DNS liefert zwei Zieladressen, - TCP und TLS funktionieren zu beiden Adressen. **Hypothesen** | Nr. | Hypothese | |---:|---| | H1 | DNS liefert eine nicht vorgesehene IP-Adresse | | H2 | Eines der Backends ist fehlerhaft | | H3 | Load Balancer verteilt Anfragen falsch | | H4 | Datenbank ist vollständig ausgefallen | | H5 | Clientnetzwerk ist instabil | **Prüfungen** - Beide DNS-Adressen gehören zur vorgesehenen Umgebung. - Backend 1 liefert reproduzierbar HTTP `200`. - Backend 2 liefert reproduzierbar HTTP `503`. - Datenbankmonitoring zeigt keinen allgemeinen Ausfall. - Backend 2 protokolliert einen nicht auflösbaren Datenbank-Hostnamen. - Konfigurationsvergleich zeigt einen Tippfehler. - Der Tippfehler wurde mit dem Deployment um 14:31 Uhr eingeführt. - Die Pipeline akzeptierte den Wert ohne Prüfung. - Der Load Balancer markierte Backend 2 weiterhin als gesund, weil der Health Check nur eine statische Seite prüfte. **Bewertung der Hypothesen** | Hypothese | Bewertung | Begründung | |---|---|---| | H1 | Widerlegt | Beide DNS-Adressen sind vorgesehen | | H2 | Bestätigt | Fehler ist reproduzierbar an Backend 2 gebunden | | H3 | Teilweise bestätigt | Health Check erkennt den Backendfehler nicht | | H4 | Widerlegt | Datenbank und Backend 1 funktionieren | | H5 | Widerlegt | TCP- und TLS-Verbindungen sind stabil | **Ursachenkette** | Ebene | Feststellung | |---|---| | Symptom | ungefähr jede zweite Anfrage liefert HTTP 503 | | Direkte Ursache | Backend 2 erreicht die Datenbank nicht | | Technischer Fehler | falscher Datenbank-Hostname | | Auslöser | Deployment um 14:31 Uhr | | Grundursache | fehlende Validierung der Konfiguration | | Begünstigender Faktor | fehlerhafter Health Check | | Erkennungslücke | Monitoring prüft keine Datenbankfunktion | | Sofortmaßnahme | Backend 2 aus Rotation nehmen oder Konfiguration zurücksetzen | | Prävention | Validierung und anwendungsnahen Health Check einführen | --- **32. Dokumentationsvorlage für die Ursachenkette** | Feld | Eintrag | |---|---| | Ticketnummer | | | Symptom | | | Fehlerumfang | | | Beginn der Störung | | | Direkte technische Ursache | | | Technischer Mechanismus | | | Auslöser | | | Grundursache | | | Begünstigende Faktoren | | | Erkennungslücken | | | Wiederherstellungsfaktoren | | | Unterstützende Belege | | | Widersprechende Belege | | | Geprüfte Alternativen | | | Durchgeführte Gegenprobe | | | Bestätigungsgrad | | | Verbleibende Unsicherheiten | | | Sofortmaßnahme | | | Präventionsmaßnahme | | --- **33. Vorlage für alternative Erklärungen** | Nr. | Alternative Erklärung | Erwartete Beobachtung | Tatsächliche Beobachtung | Beleg | Status | |---:|---|---|---|---|---| | A1 | | | | | Offen | | A2 | | | | | Offen | | A3 | | | | | Offen | | A4 | | | | | Offen | --- **34. Prüffragen zur Grundursache** - Erklärt die Ursache alle beobachteten Symptome? - Erklärt sie, warum bestimmte Systeme nicht betroffen waren? - Erklärt sie den Beginn der Störung? - Ist der technische Mechanismus nachvollziehbar? - Gibt es direkte technische Belege? - Wurde die Ursache mit einem Vergleichssystem geprüft? - Wurde eine Gegenprobe durchgeführt? - Welche alternativen Erklärungen wurden ausgeschlossen? - Welche Beobachtungen widersprechen der Ursache? - Existiert dieselbe Bedingung auf funktionierenden Systemen? - Kann die Ursache in einer Testumgebung reproduziert werden? - Ist die genannte Ursache nur ein menschlicher Fehler? - Welche technische Schutzmaßnahme hätte den Fehler verhindert? - Welche Monitoringfunktion hätte den Fehler früher erkannt? - Sind mehrere Ursachen oder begünstigende Faktoren vorhanden? --- **Kurzcheckliste** - [ ] Symptom und Ursache getrennt - [ ] Direkte technische Ursache bestimmt - [ ] Technischen Mechanismus beschrieben - [ ] Auslöser bestimmt - [ ] Grundursache untersucht - [ ] Begünstigende Faktoren berücksichtigt - [ ] Erkennungslücken berücksichtigt - [ ] Abhängigkeiten geprüft - [ ] Betroffenes und funktionierendes System verglichen - [ ] Konfigurationsunterschiede geprüft - [ ] Datei- und Versionsunterschiede geprüft - [ ] Dienstabhängigkeiten geprüft - [ ] Unterstützende Belege dokumentiert - [ ] Widersprechende Belege dokumentiert - [ ] Alternative Erklärungen aufgestellt - [ ] Alternative Erklärungen geprüft - [ ] Gegenprobe durchgeführt oder begründet ausgelassen - [ ] Zeitliche Korrelation nicht mit Ursache verwechselt - [ ] Wiederherstellungsmaßnahme nicht automatisch als Ursache interpretiert - [ ] Mehrere mögliche Ursachen berücksichtigt - [ ] Menschliche Handlung nicht vorschnell als Grundursache verwendet - [ ] Bestätigungsgrad dokumentiert - [ ] Verbleibende Unsicherheiten dokumentiert - [ ] Präventionsmaßnahmen ableitbar --- **Ergebnis dieses Arbeitsschrittes** Am Ende dieses Schrittes liegt eine nachvollziehbare Ursachenkette vor. Sie unterscheidet: - sichtbares Symptom, - unmittelbare technische Ursache, - technischen Mechanismus, - auslösendes Ereignis, - Grundursache, - begünstigende Faktoren, - Erkennungslücken, - Wiederherstellungsmaßnahmen, - mögliche Präventionsmaßnahmen. Eine Ursache gilt nicht allein deshalb als bestätigt, weil der Fehler nach einer Änderung verschwunden ist. Sie muss zum Fehlerbild passen, durch technische Belege gestützt und gegen alternative Erklärungen geprüft worden sein. **Nächste Seite:** **1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren** --- **Offizielle Hersteller-, Standard- und Projektdokumentation** - [NIST – SP 800-61 Revision 3: Incident Response Recommendations and Considerations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [Google SRE – Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) - [Google SRE Workbook – Postmortem Practices](https://sre.google/workbook/postmortem-culture/) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Compare-Object](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/compare-object) - [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [freedesktop.org – systemd-Unit-Abhängigkeiten](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [Apple Support – Protokollmeldungen in der Konsole anzeigen](https://support.apple.com/guide/console/log-messages-cnsl1012/mac)