Root Cause Analysis (RCA): Ursachenanalyse einfach erklärt

Was ist eine Root Cause Analysis?

„Root Cause“ heißt Grundursache. Eine Root Cause Analysis, auf Deutsch Ursachenanalyse, sucht genau diese Ursache. Sie fragt nicht nur, was passiert ist, sondern warum es passieren konnte.

Die Methode stammt aus dem Qualitätsmanagement und der Industrie. Heute wird sie überall eingesetzt, wo Fehler teuer sind: in der Produktion, im Gesundheitswesen, in der IT und in der IT-Sicherheit.

Symptom, Ursache und Grundursache

• Symptom: Das, was man sieht. Beispiel: Der Online-Shop ist nicht erreichbar.
• Direkte Ursache: Der unmittelbare Auslöser. Beispiel: Der Server ist abgestürzt, weil die Festplatte voll war.
• Grundursache (Root Cause): Der Grund, warum es so weit kommen konnte. Beispiel: Niemand überwacht den Speicherplatz, und alte Protokolldateien werden nie gelöscht.

Wer nur das Symptom behandelt, startet den Server neu. Wer die direkte Ursache behebt, räumt die Festplatte auf. Erst wer die Grundursache beseitigt, verhindert den nächsten Ausfall: mit einer Überwachung und einer automatischen Löschregel.

Die Schritte einer Root Cause Analysis

1. Problem beschreiben: Was ist genau passiert, wann, wo und mit welchen Folgen? Eine klare Beschreibung verhindert, dass man das falsche Problem löst.
2. Daten sammeln: Protokolle, Messwerte, Zeugenaussagen und Dokumente zusammentragen.
3. Ablauf rekonstruieren: Eine Zeitleiste zeigt, welche Ereignisse in welcher Reihenfolge stattfanden.
4. Ursachen finden: Mit Methoden wie 5 Why oder dem Ishikawa-Diagramm von den Symptomen zur Grundursache vordringen.
5. Maßnahmen festlegen: Lösungen entwickeln, die die Grundursache beseitigen, mit Verantwortlichen und Fristen.
6. Wirkung prüfen: Nach einer Weile kontrollieren, ob das Problem wirklich nicht wieder auftritt.

Methoden der Ursachenanalyse

5-Why-Methode

Man fragt mehrmals hintereinander „Warum?“. Ein Beispiel:

1. Warum war der Shop nicht erreichbar? Weil der Server abgestürzt ist.
2. Warum ist er abgestürzt? Weil die Festplatte voll war.
3. Warum war sie voll? Weil sich alte Protokolldateien angesammelt haben.
4. Warum wurden sie nicht gelöscht? Weil es keine Löschregel gibt.
5. Warum ist das niemandem aufgefallen? Weil der Speicherplatz nicht überwacht wird.

Die Methode ist einfach und schnell. Bei komplexen Problemen mit mehreren Ursachen stößt sie aber an Grenzen.

Ishikawa-Diagramm (Fischgräten-Diagramm)

Das Problem steht am „Kopf“ des Fisches. Die „Gräten“ sind Kategorien möglicher Ursachen. Verbreitet sind die 6M: Mensch, Maschine, Methode, Material, Milieu (Umfeld) und Messung. So denkt das Team in alle Richtungen und übersieht weniger.

Weitere Methoden

• Fehlerbaumanalyse: Ausgehend vom Fehler werden alle möglichen Ursachen und ihre Kombinationen in einem Baum dargestellt.
• Pareto-Analyse: Sie zeigt, welche wenigen Ursachen für die meisten Probleme verantwortlich sind.
• Änderungsanalyse: Was hat sich vor dem Problem geändert? Viele Störungen folgen auf ein Update oder eine neue Einstellung.

Root Cause Analysis im IT-Betrieb

Im IT-Betrieb unterscheidet man zwei Aufgaben. Das Incident Management stellt den Betrieb so schnell wie möglich wieder her. Das Problem Management sucht danach die Grundursache, damit der Fehler nicht wiederkommt. Das Rahmenwerk ITIL trennt diese beiden Aufgaben ausdrücklich.

Viele Teams schreiben nach größeren Störungen einen Bericht, oft „Post-Mortem“ genannt. Er beschreibt Ablauf, Ursache und Maßnahmen, ohne einzelne Personen zu beschuldigen.

Root Cause Analysis in der IT-Sicherheit

In der Cybersicherheit ist die Root Cause Analysis ein fester Bestandteil der Nachbereitung von Sicherheitsvorfällen. Sie klärt, wie ein Angreifer eindringen konnte und warum bestehende Schutzmaßnahmen nicht gegriffen haben. Bewährt haben sich folgende Grundsätze:

• Beweise sichern: Protokolle, Systemabbilder und weitere forensische Spuren früh sichern, bevor sie überschrieben werden. Siehe Security Logging und Monitoring.
• Zeitleiste erstellen: Den Ablauf vom ersten Zugriff bis zur Entdeckung rekonstruieren.
• Technische und organisatorische Ursachen betrachten: Neben Schwachstellen und Fehlkonfigurationen auch Prozesse, Zuständigkeiten und fehlende Erkennung untersuchen.
• Ohne Schuldzuweisung arbeiten: Eine sachliche Nachbesprechung sorgt dafür, dass alle Informationen offen geteilt werden.
• Maßnahmen nachverfolgen: Korrekturen mit Verantwortlichen und Fristen festlegen und ihre Wirkung prüfen.

Die Ursachenanalyse gehört zur Nachbereitung, der letzten Phase des Incident-Response-Managements. Sie liefert die Lehren, mit denen der Incident-Response-Plan verbessert wird.

Vorteile und Herausforderungen

Vorteile:

• Dauerhafte Lösungen: Wer die Grundursache beseitigt, verhindert Wiederholungen.
• Geringere Kosten: Weniger wiederkehrende Fehler sparen Zeit und Geld.
• Bessere Prozesse: Die Analyse zeigt oft Schwächen in Abläufen und Zuständigkeiten.
• Höhere Qualität: Produkte und Dienste werden zuverlässiger.

Herausforderungen:

• Fehlende Daten: Ohne Protokolle und Messwerte bleibt die Analyse Spekulation.
• Angst vor Schuldzuweisung: Wer Nachteile befürchtet, verschweigt wichtige Details.
• Zu früh aufhören: Oft gibt man sich mit der ersten plausiblen Antwort zufrieden.
• Keine Umsetzung: Erkenntnisse ohne Maßnahmen und Kontrolle ändern nichts.

Fazit

Eine Root Cause Analysis fragt so lange „Warum?“, bis die eigentliche Ursache eines Problems gefunden ist. Das kostet etwas Zeit, verhindert aber, dass derselbe Fehler wieder auftritt. Ob im Qualitätsmanagement, im IT-Betrieb oder nach einem Sicherheitsvorfall: Entscheidend sind gute Daten, eine offene Fehlerkultur und Maßnahmen, die wirklich umgesetzt werden.