Vorlage für einen Vorfallsbericht

Ein Vorfallsbericht ist ein strukturierter interner Nachweis über ein Ereignis, das den normalen Betrieb, die Sicherheit oder die Verfügbarkeit eines Dienstes gestört hat — oder hätte stören können. Eine Vorlage für den IT-Vorfallsbericht gibt diesem Nachweis eine feste Struktur, damit nichts übersehen wird, während der Vorfall noch läuft.

Für ein IT- oder SaaS-Team kann das zum Beispiel sein:

• Ein vollständiger oder teilweiser Dienstausfall
• Erhöhte Fehlerraten oder starke Leistungseinbußen
• Ein fehlgeschlagenes Deployment in der Produktion
• Ein Ausfall von Datenbank oder Infrastruktur
• Ein Ausfall oder Sicherheitsvorfall bei einem Drittanbieter
• Jedes Ereignis, das die Verfügbarkeit gefährdet hat, auch ohne vollständigen Ausfall

Der Bericht hält die bekannten Fakten, die betriebliche Reaktion, die Auswirkungen, die Zeitleiste, die Kommunikation und die Nachbereitung fest, die mit dem Vorfall verbunden sind.

Der Begriff kann sich auch auf Arbeitsunfälle oder Vorfälle im Bereich der physischen Sicherheit beziehen — diese Vorlage ist für Vorfälle im Technologie- und Service-Management gedacht, nicht für physische.

Nicht jede Warnung, jeder Bug oder jede kurze Unterbrechung braucht einen formalen Bericht — legen Sie Ihre eigene Schwelle anhand von Kundenauswirkung, Risiko und interner Richtlinie fest. Ein Bericht ist in der Regel angebracht, wenn ein Vorfall:

• einen erheblichen, für Kunden sichtbaren Ausfall verursacht
• ein SLA oder SLO verletzt oder gefährdet
• Koordination über mehrere Teams oder Kommunikation mit Kunden bzw. der Öffentlichkeit erfordert
• ein mögliches Sicherheits- oder Datenschutzproblem betrifft
• wesentliche finanzielle oder betriebliche Auswirkungen hat
• einen früheren Fehler wiederholt oder umfangreiche Korrekturarbeiten erfordert

Für Vorfälle mit geringerem Schweregrad reicht eine kürzere Version derselben Vorlage — nur Zusammenfassung, Auswirkungen, Zeitleiste und Folgemaßnahmen. Entscheidend ist, dass die Schwelle vorab festgelegt und nicht mitten im Vorfall diskutiert wird.

Identifikation des Vorfalls

Geben Sie dem Vorfall einen klaren, aussagekräftigen Titel, der den Dienst und das für Kunden sichtbare Symptom nennt — „Erhöhte API-Fehlerraten durch erschöpfte Datenbankverbindungen“, nicht „API-Problem“. Eine Vorfall-ID erleichtert später den Querverweis zwischen Ticket, Statusseite und Postmortem.

Schweregrad

Der Schweregrad vermittelt Dringlichkeit und Auswirkung. Ein einfaches Modell:

Die genauen Schwellen sind wichtiger als die Bezeichnungen — verknüpfen Sie jede Stufe mit klaren Auswirkungskriterien und Erwartungen an die Reaktion.

Wichtige Zeitpunkte

Halten Sie fest, wann der Vorfall begann, erkannt, eingedämmt und behoben wurde. Mit diesen Zeitstempeln lassen sich Time-to-Detect, Time-to-Acknowledge und Time-to-Resolve messen und das für Kunden sichtbare Auswirkungsfenster vom internen Reaktionsprozess trennen.

Zusammenfassung des Vorfalls

Ein paar sachliche Sätze: Was ist passiert, was war betroffen, was war die Ursache und wie wurde der Dienst wiederhergestellt? Zum Beispiel:

Zwischen 14:03 und 14:31 UTC kam es für Kunden zu erhöhten Fehlerraten in der öffentlichen API. Ursache war, dass die Datenbankverbindungen ihr konfiguriertes Limit erreichten. Das Team stellte den Dienst wieder her, indem es die betroffenen Abfragen beendete und die Verbindungskapazität erhöhte.

Die tiefere technische Erklärung gehört in den Abschnitt zur Ursache.

Auswirkungen auf Kunden und Geschäft

Beschreiben Sie Folgen, nicht nur Symptome — „Kunden konnten den Checkout nicht abschließen“, nicht „CPU-Auslastung bei 100 %“. Erfassen Sie, welche Dienste und Kunden betroffen waren, wie lange es dauerte, ob Daten verloren gingen oder verzögert wurden und ob ein SLA oder SLO verletzt wurde. Quantifizieren Sie, wo möglich, und schreiben Sie lieber „unbekannt“, als zu raten.

Erkennung

Wie hat das Team davon erfahren — durch einen Alarm, eine Kundenmeldung, ein Support-Ticket? Wenn Kunden es vor dem Monitoring bemerkt haben, ist das eine Erkennungslücke, die hier festgehalten werden sollte.

Reaktion und Gegenmaßnahmen

Fassen Sie die Maßnahmen zusammen, die den Verlauf des Vorfalls verändert haben — Rollbacks, Failover, Kapazitätsänderungen, Workarounds — und die Überlegungen hinter den wichtigsten Entscheidungen, besonders dort, wo die Beteiligten zwischen Optionen mit unterschiedlichen Risiken wählen mussten.

Zeitleiste des Vorfalls

Eine chronologische, sachliche Darstellung der Ereignisse in einer klar benannten Zeitzone. Schreiben Sie sie später nicht um, damit sie geordneter wirkt, als sie war, und kopieren Sie kein komplettes Chat-Protokoll hinein — fassen Sie zusammen, was Untersuchung, Reaktion oder Kommunikation wesentlich beeinflusst hat.

Kommunikation

Verlinken Sie, was wo gesagt wurde — interne Updates, Statusseite, Kunden-E-Mails, Hinweise für den Support — statt es zu duplizieren. Interne Berichte dürfen Details enthalten (Infrastruktur, Namen von Mitarbeitern, vorläufige Theorien), die in einem öffentlichen Update nichts zu suchen haben.

Ursache und begünstigende Faktoren

Trennen Sie klar zwischen Symptomen, vermuteten Ursachen, bestätigten Ursachen und begünstigenden Faktoren — erzwingen Sie keine einzelne „Grundursache“, bevor die Untersuchung abgeschlossen ist. Ein fehlgeschlagenes Deployment kann der Auslöser sein, während unzureichende Tests und fehlende Alarme es erst zum Ausfall werden ließen.

Folgemaßnahmen

Jede Maßnahme braucht eine verantwortliche Person und, bei hoher Priorität, ein Fälligkeitsdatum. „Monitoring verbessern“ ist eine Absicht; „Alarm für Connection-Pool-Auslastung über 80 % einrichten, verantwortlich: Platform Engineering, fällig am 15. September“ ist eine Maßnahme.

Das folgende vereinfachte Beispiel zeigt, wie die Vorlage für einen SaaS-Ausfall ausgefüllt werden könnte.

Angaben zum Vorfall

Titel des Vorfalls: Erhöhte API-Fehler durch erschöpfte Datenbankverbindungen Vorfall-ID: INC-2026-017 Schweregrad: SEV-2 Status: Behoben Verantwortlich für den Vorfall: Platform Engineering Incident Commander: On-Call Engineering Lead

Wichtige Zeitpunkte

Vorfall begonnen: 14:03 UTC Vorfall erkannt: 14:07 UTC Vorfall bestätigt: 14:09 UTC Gegenmaßnahmen begonnen: 14:18 UTC Dienst wiederhergestellt: 14:31 UTC Vorfall behoben: 14:45 UTC

Zusammenfassung

Zwischen 14:03 und 14:31 UTC kam es für Kunden bei der Nutzung der öffentlichen API zu erhöhten Fehlerraten. Eine Gruppe lang laufender Datenbankabfragen erschöpfte den verfügbaren Connection-Pool. Die Beteiligten beendeten die betroffenen Abfragen und erhöhten vorübergehend die Verbindungskapazität, wodurch die normale API-Leistung wiederhergestellt wurde.

Auswirkungen

Etwa 18 % der API-Anfragen lieferten während des Vorfalls Fehler zurück. Der Zugriff auf das Dashboard und die Verfügbarkeit der Statusseite waren nicht beeinträchtigt. Es wurde kein Datenverlust und keine Datenbeschädigung festgestellt.

Erkennung

Der Vorfall wurde durch einen Alarm für erhöhte API-Fehlerraten erkannt. Für den Datenbank-Connection-Pool gab es keinen eigenen Sättigungsalarm.

Zeitleiste

Ursache

Eine Reihe lang laufender analytischer Abfragen belegte einen großen Teil der Verbindungen zur Produktionsdatenbank. Die verbleibende Kapazität reichte nicht aus, um den normalen API-Verkehr zu bedienen.

Begünstigende Faktoren

• Es gab keinen Alarm für die Sättigung des Datenbank-Connection-Pools.
• Analytische Workloads teilten sich die Datenbankkapazität mit kundenseitigen Anfragen.
• Die Timeout-Limits für Abfragen waren höher als nötig.
• Das zuständige Runbook enthielt keine Diagnoseschritte für erschöpfte Verbindungen.

Folgemaßnahmen

Ein Vorfallsbericht ist nicht der einzige Nachweis, den ein Vorfall hervorbringt — meist ist er nur der erste.

Ein Postmortem baut auf dem Vorfallsbericht auf, statt das Ereignis von Grund auf zu rekonstruieren, und eine Ursachenanalyse ist in der Regel eine Grundlage für das Postmortem, kein Ersatz dafür. Ein öffentliches Update auf der Statusseite ist eine vierte, völlig eigene Sache — geschrieben für Kunden, nicht für das interne Team, und niemals der unbearbeitete interne Bericht.

Sehen Sie sich unsere Vorlage für die Ursachenanalyse für den nächsten Schritt an; die Postmortem-Vorlage folgt in Kürze.

• Halten Sie Fakten fest, während sie passieren, in einer durchgehenden Zeitzone. Eine Zeitleiste Tage später zu rekonstruieren oder Zeitzonen zu mischen führt zu einem unzuverlässigen Nachweis.
• Trennen Sie Fakten von Annahmen. Kennzeichnen Sie vermutete Ursachen als vermutet, bis Belege sie bestätigen.
• Beschreiben Sie Auswirkungen aus Kundensicht, nicht nur als technische Symptome. „Kunden konnten nicht bezahlen“, nicht „CPU bei 100 %“.
• Bewahren Sie die Überlegungen hinter wichtigen Entscheidungen. Warum ein Rollback, Failover oder Workaround gewählt wurde, nicht nur, dass es geschah.
• Vermeiden Sie Schuldzuweisungen. Konzentrieren Sie sich darauf, was den Vorfall ermöglicht oder verschlimmert hat, nicht darauf, wer die Änderung vorgenommen hat.
• Geben Sie jeder Folgemaßnahme eine verantwortliche Person und bei hoher Priorität ein Zieldatum.
• Verlinken Sie Belege, statt sie hineinzukopieren — Dashboards, Logs, Kommunikation, Deployments, Tickets.
• Prüfen Sie den Bericht vor dem Abschluss. Bestätigen Sie, dass Auswirkungen, Zeitleiste und Maßnahmen korrekt sind; holen Sie bei erheblichen Vorfällen eine Freigabe ein.
• Betrachten Sie einen konsequent ausgefüllten Bericht als Ihren Audit-Trail. Er ist ein nützlicher Nachweis für SOC-2-Prüfungen, ISO-27001-Audits und Sicherheitsfragebögen von Kunden, ohne dass ein eigener Compliance-Prozess nötig ist.

Wie schreibt man einen Vorfallsbericht?

Beginnen Sie mit einer Vorlage, damit unter Druck nichts vergessen wird. Erfassen Sie Titel, Schweregrad und wichtige Zeitpunkte, sobald sie bekannt sind; füllen Sie Zusammenfassung, Auswirkungen und Zeitleiste aus, wenn sich die Fakten festigen; und lassen Sie Ursache, begünstigende Faktoren und Folgemaßnahmen offen, bis die Untersuchung aufgeholt hat.

Welches Format ist für einen Vorfallsbericht richtig?

Es gibt kein einziges verbindliches Format, aber ein bewährtes umfasst: Identifikation (Titel, ID, Schweregrad), wichtige Zeitstempel, eine sachliche Zusammenfassung, Auswirkungen auf Kunden und Geschäft, Erkennung, Reaktion, eine Zeitleiste, Kommunikation, Ursache und Folgemaßnahmen. Die Vorlage oben verwendet diese Struktur.

Was sind die Kernelemente eines Vorfallsberichts?

Mindestens: Was ist passiert, wann, wie wurde es erkannt, wer und was war betroffen, wie hat das Team reagiert, wie wurde der Dienst wiederhergestellt, was wurde kommuniziert und welche Arbeit steht noch aus. Alles andere dient dazu, diese Fragen zu beantworten.

Ist für jeden Ausfall ein Vorfallsbericht erforderlich?

Nein. Legen Sie Schwellen vorab anhand von Kundenauswirkung, Schweregrad und Risiko fest — ein kurzer Aussetzer braucht vielleicht nur ein Ticket, während ein größerer Ausfall oder ein Sicherheitsereignis in der Regel einen vollständigen Bericht rechtfertigt.

Ersetzt ein Vorfallsbericht ein Postmortem?

Nein. Der Bericht ist der Nachweis der Fakten; das Postmortem ist die tiefere Analyse, warum es passiert ist und was geändert werden soll. Vorfälle mit geringem Schweregrad brauchen vielleicht nur den Bericht — größere oder wiederkehrende bekommen in der Regel beides.

Der beste Zeitpunkt, um zu entscheiden, wie Vorfälle dokumentiert werden, ist vor dem ersten Vorfall. Legen Sie fest, was als Vorfall zählt, welche Schweregrade einen Bericht erfordern, wer ihn verantwortet, wo er gespeichert wird und wann ein Postmortem erforderlich ist — damit die Beteiligten nicht mitten im Vorfall über Dokumentation diskutieren.

Ein gut gestalteter Vorfallsbericht sollte während eines Ausfalls keinen zusätzlichen Verwaltungsaufwand erzeugen. Konsequent eingesetzt, wird er mehr als der Nachweis eines einzelnen Fehlers — er hilft Teams, sich zu koordinieren, zu kommunizieren und die Zuverlässigkeit langfristig zu verbessern.

Die Struktur dieser Vorlage folgt dem, was Teams mit öffentlichen Engineering-Handbüchern in ihren Vorfallsaufzeichnungen verlangen. Sie unterscheiden sich vor allem darin, wer den Nachweis führt und welche Vorfälle anschließend schriftlich ausgewertet werden.