Vorlage für eine Ursachenanalyse

Eine Ursachenanalyse identifiziert die konkrete Bedingung oder den konkreten Fehler, deren Beseitigung den Vorfall verhindert hätte — im Unterschied zu den Symptomen, die Sie bemerkt haben, und den begünstigenden Faktoren, die ihn schlimmer oder wahrscheinlicher gemacht haben. Eine Vorlage für die Ursachenanalyse bei IT-Vorfällen hält diese drei Dinge auf der Seite getrennt — genau dort, wo die meisten hastigen Analysen scheitern.

Ein Beispiel: Einer Datenbank gingen die Verbindungen aus (Symptom), weil eine Reihe analytischer Abfragen Verbindungen zu lange offen hielt (begünstigender Faktor), weil kein Abfrage-Timeout erzwungen wurde (Grundursache).

Nicht jeder Vorfall braucht eine formale Ursachenanalyse. Führen Sie eine durch, wenn ein Vorfall einen hohen Schweregrad hat, einen früheren Fehler wiederholt, ein SLA verletzt oder ohne eine gezielte Korrektur wahrscheinlich erneut auftritt. Kleinere, einmalige Probleme mit einer offensichtlichen, bereits behobenen Ursache brauchen die vollständige Übung in der Regel nicht — es reicht, die Ursache im Vorfallsbericht zu vermerken.

Es gibt keine einzig richtige Methode — wählen Sie die, die zur Komplexität des Vorfalls passt.

• Fünf Warum (5 Whys) — fragen Sie wiederholt „warum“, jedes Mal zur vorherigen Antwort, bis Sie eine Ursache erreichen, an der Sie ansetzen können. Schnell und einfach; funktioniert am besten bei klaren Vorfällen mit einer einzelnen Ursache.
• Fishbone-Diagramm (Ishikawa) — gruppieren Sie mögliche Ursachen in Kategorien wie Menschen, Prozesse, Technologie und Umfeld. Nützlich, wenn wahrscheinlich mehrere Faktoren zusammen den Vorfall verursacht haben.
• Fehlerbaumanalyse — bilden Sie die logische Kombination von Fehlern ab, die zusammen auftreten mussten, damit es zum Vorfall kam. Geeignet für komplexe Systeme mit mehreren Fehlerpfaden.
• Änderungsanalyse — vergleichen Sie den Zustand des Systems vor und nach dem Vorfall, um einzugrenzen, was sich geändert hat. Wirksam, wenn der Vorfall kurz nach einem Deployment, einer Konfigurationsänderung oder einer Migration auftrat.

Die Vorlage unten verwendet standardmäßig die Fünf-Warum-Methode, ergänzt um eine Aufschlüsselung im Fishbone-Stil — wechseln oder kombinieren Sie Methoden, wie es der Vorfall erfordert.

Problembeschreibung

Eine kurze, sachliche Zusammenfassung dessen, was ausgefallen ist — nicht der gesamte Vorfallsbericht. Verlinken Sie ihn, statt ihn zu wiederholen.

Verwendete Methode

Benennen Sie die Methode (Fünf Warum, Fishbone, Fehlerbaum, Änderungsanalyse), damit jeder, der die Analyse später liest, versteht, wie die Schlussfolgerung zustande kam.

Die Analyse

Die eigentliche Argumentation — die Warum-Kette, die kategorisierten Faktoren, der Fehlerbaum oder der Vorher-nachher-Vergleich. Dieser Teil verdient die meiste Sorgfalt; eine hastige Analyse bleibt meist bei der ersten plausiblen Antwort stehen statt bei der tatsächlichen.

Auslöser, Grundursache und begünstigende Faktoren

Trennen Sie drei Dinge: den Auslöser (das unmittelbare Ereignis, das den Vorfall ausgelöst hat — ein Deployment, eine Abfrage, eine Konfigurationsänderung), die Grundursache (die tiefere Bedingung, die daraus einen Vorfall werden ließ, beschrieben als System oder Prozess — niemals als Person oder Team) und die begünstigenden Faktoren (Bedingungen, die ihn wahrscheinlicher, länger oder schlimmer gemacht haben, ohne Auslöser oder Ursache zu sein). Kennzeichnen Sie die Grundursache anhand der Belege als vermutet oder bestätigt.

Korrektur- und Präventivmaßnahmen

Korrekturmaßnahmen beheben, was bereits defekt ist; Präventivmaßnahmen verringern die Wahrscheinlichkeit einer Wiederholung oder eines ähnlichen Vorfalls an anderer Stelle. Jede Maßnahme braucht eine verantwortliche Person und, bei hoher Priorität, ein Fälligkeitsdatum.

Verifizierung

Bestätigen Sie, dass die Korrektur tatsächlich die Grundursache behebt und nicht nur das Symptom — und halten Sie fest, wie und wann das geprüft wurde. Eine Ursachenanalyse, die nie verifiziert wird, kann die eigentliche Ursache unbemerkt ungelöst lassen.

Das folgende Beispiel führt den Vorfall INC-2026-017 aus der Vorlage für den Vorfallsbericht fort.

Titel der Analyse: Warum wurde der Datenbank-Connection-Pool erschöpft? Zugehöriger Vorfall: INC-2026-017 Verwendete Methode: Fünf Warum Auslöser: Ein Stapel lang laufender analytischer Abfragen begann, Verbindungen jeweils mehrere Minuten lang offen zu halten.

Fünf Warum

Grundursache

Auf dem gemeinsam genutzten Connection-Pool wurde kein Abfrage-Timeout erzwungen, sodass lang laufende analytische Abfragen Verbindungen unbegrenzt belegen konnten. Status: Bestätigt.

Begünstigende Faktoren

• Analytische und kundenseitige Workloads teilten sich denselben Connection-Pool.
• Es gab keinen Alarm für die Sättigung des Connection-Pools.

Korrektur- und Präventivmaßnahmen

Verifizierung

Bestätigt durch einen Lasttest des Analytics-Workloads mit dem neuen Timeout und der Pool-Isolation; nach zwei Wochen Beobachtung keine erschöpften Verbindungen.

Eine Ursachenanalyse ist in der Regel eine Grundlage für ein Postmortem, kein Ersatz dafür — und sie folgt auf den Vorfallsbericht, statt ihn zu ersetzen.

Sehen Sie sich unsere Vorlage für den IT-Vorfallsbericht für den Nachweis an, der in die Ursachenanalyse einfließt; die Postmortem-Vorlage folgt in Kürze.

• Bleiben Sie nicht bei der ersten plausiblen Ursache stehen. Fragen Sie weiter „warum“, bis Sie etwas erreichen, an dem Sie ansetzen können — nicht nur etwas, das ausreichend klingt.
• Unterscheiden Sie bestätigt von vermutet. Stellen Sie eine Arbeitshypothese nicht als verifizierte Schlussfolgerung dar.
• Beziehen Sie Personen ein, die nah an der Arbeit sind, nicht nur den Incident Commander — sie kennen oft das „Warum“, das in Logs nicht sichtbar ist.
• Trennen Sie die Grundursache von den begünstigenden Faktoren. Einen begünstigenden Faktor zu beheben, ohne die Grundursache anzugehen, verhindert keine Wiederholung.
• Vermeiden Sie Schuldzuweisungen. Fragen Sie, was das System versagen ließ, nicht, wer die Änderung vorgenommen hat.
• Verifizieren Sie die Korrektur. Bestätigen Sie, dass sie die Grundursache behebt und nicht nur das unmittelbare Symptom.

Was ist der Unterschied zwischen einer Grundursache und einer Ursache?

Eine Ursache ist alles, was zum Vorfall beigetragen hat. Die Grundursache ist die konkrete Ursache, deren Beseitigung ihn verhindert hätte — alles andere ist ein begünstigender Faktor.

Wie viele „Warum“ braucht man?

So viele, wie nötig sind, um etwas Umsetzbares zu erreichen — oft etwa fünf, manchmal weniger oder mehr. Hören Sie auf, wenn die nächste Antwort etwas ist, das Ihr Team tatsächlich beheben kann.

Ersetzt eine Ursachenanalyse ein Postmortem?

Nein. Die Ursachenanalyse erklärt die Ursache; das Postmortem nutzt diese Analyse zusammen mit dem Vorfallsbericht, um Erkenntnisse zu dokumentieren und umfassendere Veränderungen anzustoßen.

Wer sollte die Ursachenanalyse durchführen?

In der Regel die für den Vorfall verantwortliche Person oder eine benannte Moderation, mit Input von den Personen, die während des Vorfalls den betroffenen Systemen am nächsten waren.

Legen Sie fest, welche Schweregrade eine Ursachenanalyse erfordern, wer verantwortlich ist und wie die Ergebnisse in Ihr Postmortem und Ihre Korrekturmaßnahmen einfließen — genau wie bei einem Vorfallsbericht. Konsequent durchgeführt, macht eine Ursachenanalyse aus jedem Vorfall eine konkrete, überprüfbare Verbesserung — nicht nur eine Geschichte darüber, was schiefgelaufen ist.

Die Vorlage orientiert sich daran, wie Teams mit öffentlichen Engineering-Handbüchern ihre Auswertungen nach Vorfällen durchführen. Bemerkenswert ist, dass keines von ihnen eine Analysemethode vorschreibt. Standardisiert werden die Schwelle, die Frist, die Verantwortung und der Ort, an dem Korrekturmaßnahmen nachgehalten werden — und dem folgt die Vorlage.