Skip to main content

Ursachenanalyse (Root Cause Analysis)

1. Ziel dieser Seite

Diese Seite beschreibt die professionelle Ursachenanalyse (Root Cause Analysis, RCA) nach Störungen, Sicherheitsvorfällen oder Performance-Problemen. Ziel ist nicht Schuldzuweisung, sondern die nachhaltige Vermeidung zukünftiger Vorfälle.

Ohne fundierte Ursachenanalyse entstehen:

  • wiederkehrende Störungen
  • technische Schulden
  • Vertrauensverlust bei Kunden

2. Grundlagen der Ursachenanalyse

2.1 Ursache vs. Auslöser vs. Symptom

  • Symptom: Sichtbares Problem
  • Auslöser: Ereignis, das den Fehler sichtbar macht
  • Ursache: Struktureller Ursprung

Professionelle RCA fokussiert sich ausschließlich auf die Ursache.

2.2 Prinzipien einer guten RCA

  • Faktenbasiert
  • Nachvollziehbar
  • Reproduzierbar
  • Dokumentiert

3. Typische Fehler ohne Ursachenanalyse

  • Neustarts statt Problemlösung
  • Skalierung ohne Analyse
  • Workarounds als Dauerlösung

4. Methodische Vorgehensmodelle

4.1 5-Why-Methode

Durch wiederholtes Hinterfragen wird schrittweise die eigentliche Ursache ermittelt.

  • Einfach
  • Schnell
  • Für operative Vorfälle geeignet

4.2 Ishikawa-Diagramm

  • Mensch
  • Prozess
  • Technik
  • Umgebung

Besonders geeignet für komplexe Systeme und Team-Analysen.

4.3 Timeline-Analyse

  • Chronologische Ereigniskette
  • Erkennt Wechselwirkungen

5. Praktisches Vorgehen bei Incidents

5.1 Datensammlung

  • Logs
  • Monitoring-Daten
  • Change-Historie

5.2 Ereignisrekonstruktion

  • Was ist wann passiert?
  • Welche Systeme waren beteiligt?

5.3 Ursachenvalidierung

  • Ist die Ursache reproduzierbar?
  • Erklärt sie alle Symptome?

6. Dokumentation der Ursachenanalyse

  • Klare Beschreibung der Ursache
  • Betroffene Systeme
  • Auswirkungen
  • Behebungsmaßnahmen

Diese Dokumentation bildet die Grundlage für:

  • Knowledge Base
  • Audits
  • Verbesserungsmaßnahmen

7. Vor- und Nachteile strukturierter RCA

Vorteile

  • Langfristige Stabilität
  • Weniger Incidents
  • Höhere Systemqualität

Nachteile

  • Zeitaufwand
  • Disziplin erforderlich

8. Prävention durch Ursachenanalyse

  • Verbesserte Architekturentscheidungen
  • Bessere Change-Prozesse
  • Gezieltes Monitoring

9. Fazit

Ursachenanalyse ist kein optionaler Schritt, sondern Pflichtbestandteil professionellen IT-Betriebs. Nur wer Ursachen versteht, kann Systeme dauerhaft stabil, sicher und skalierbar betreiben.