Major Incidents und Eskalation

OpsWeave unterstuetzt den vollstaendigen ITIL-konformen Incident-Management-Prozess einschliesslich Major Incidents, Eskalationsstufen, Problem Management und einer Known Error Database (KEDB).

Major Incidents

Ein Major Incident ist ein Incident mit erheblicher Auswirkung auf geschaeftskritische Services, der eine koordinierte Reaktion erfordert.

Erklaerung

Ein Incident kann als Major Incident deklariert werden durch:

• Manuelle Bezeichnung durch einen Manager oder Admin
• Automatische Erkennung basierend auf Auswirkung + betroffenen Assets

Bei der Erklaerung werden folgende Felder gesetzt:

• is_major: true
• incident_commander_id — Verantwortlicher Incident Commander
• bridge_call_url — URL fuer den Krisen-Call (z. B. Teams/Zoom-Link)

Incident Commander

Der Incident Commander koordiniert die Behebung des Major Incidents:

• Wird bei der Erklaerung zugewiesen
• Verantwortlich fuer Kommunikation und Koordination
• Kann Kind-Tickets an verschiedene Teams delegieren
• Dokumentiert den Fortschritt im Ticket

Benachrichtigungen

Bei Erklaerung eines Major Incidents werden automatisch benachrichtigt:

• Alle Benutzer mit der Admin-Rolle im Mandanten
• Alle Benutzer mit der Manager-Rolle im Mandanten
• Der zugewiesene Incident Commander
• Die zugewiesene Gruppe

Benachrichtigungen werden zugestellt ueber:

• In-App-Benachrichtigungen (Socket.IO Echtzeit)
• Optional: E-Mail-Benachrichtigung

Bridge-Call

Die Bridge-Call-URL wird prominent im Ticket-Detail angezeigt, sodass alle Beteiligten schnell dem Krisen-Call beitreten koennen.

Eskalation

OpsWeave unterstuetzt ein dreistufiges Eskalationsmodell:

Stufe	Bezeichnung	Beschreibung
L1	First Level	Erstaufnahme und Basisdiagnose
L2	Second Level	Spezialisierte technische Analyse
L3	Third Level	Experten, Entwickler, Hersteller-Support

Eskalationsprozess

1. Ticket wird erstellt und der L1-Gruppe zugewiesen
2. L1 kann nicht loesen — Eskalation an L2
3. L2 kann nicht loesen — Eskalation an L3

Fuer jede Eskalation wird erfasst:

• Zielgruppe — An welche Gruppe eskaliert wird
• Begruendung — Warum eskaliert wird
• Zeitstempel — Wann die Eskalation stattfand
• Eskaliert von — Wer eskaliert hat

Eskalationen werden in der Ticket-Historie dokumentiert und koennen auch rueckgaengig gemacht werden (De-Eskalation).

Problem Management

Problem-Tickets (PRB) dienen der Ursachenanalyse (RCA) wiederkehrender Incidents.

Ursachenanalyse (RCA)

Problem-Tickets haben zusaetzliche Felder:

• root_cause — Beschreibung der identifizierten Ursache
• workaround — Temporaerer Workaround
• permanent_fix — Beschreibung der dauerhaften Loesung
• rca_completed_at — Zeitpunkt der abgeschlossenen Analyse

Eltern-Kind-Beziehungen

Incidents und Problems koennen hierarchisch verknuepft werden:

Problem (PRB-2026-00005) — Ursache: Speicherueberlauf
  ├── Incident (INC-2026-00041) — Webportal nicht erreichbar
  ├── Incident (INC-2026-00042) — API-Timeouts
  └── Incident (INC-2026-00043) — Batch-Jobs fehlgeschlagen

• Ein Problem kann mehrere Kind-Incidents haben
• Ein Major Incident kann mehrere Kind-Aufgaben (Sub-Tickets) haben
• Kind-Tickets werden im Ticket-Detail unter „Kind-Tickets" angezeigt
• Wenn das Problem geloest ist, koennen alle Kind-Incidents geschlossen werden

Known Error Database (KEDB)

Die Known Error Database dokumentiert bekannte Fehler und ihre Workarounds.

KEDB-Eintraege

Jeder bekannte Fehler enthaelt:

Feld	Beschreibung
Titel	Kurzbeschreibung des bekannten Fehlers
Symptome	Wie aeussert sich der Fehler?
Ursache	Was verursacht den Fehler?
Workaround	Temporaerer Workaround
Dauerhafte Loesung	Geplante oder umgesetzte Behebung
Status	Aktueller Status des bekannten Fehlers
Betroffene Assets	Verknuepfte CIs aus der CMDB
Verknuepfte Tickets	Zugehoerige Incidents und Problems

KEDB-Status

Status	Beschreibung
Identifiziert	Fehler ist bekannt, noch keine Loesung
Workaround verfuegbar	Temporaerer Workaround dokumentiert
Behoben	Dauerhafte Loesung umgesetzt

KEDB verwalten

• Erstellen — Neuen bekannten Fehler anlegen (manuell oder aus Problem-Ticket)
• Bearbeiten — Status aktualisieren, Workaround/Fix hinzufuegen
• Suchen — Volltextsuche ueber Titel, Symptome, Ursache
• Filtern — Nach Status, betroffenen Assets, Erstellungsdatum
• Verknuepfen — Bekannten Fehler mit Incidents/Problems verbinden

Bei der Ticket-Bearbeitung werden passende KEDB-Eintraege vorgeschlagen, um wiederkehrende Probleme schneller zu loesen.

REST API

# Tickets (inkl. Major Incident + Eskalation)
GET    /api/v1/tickets                     # Liste (filtern: is_major, ticket_type)
POST   /api/v1/tickets                     # Erstellen (inkl. parent_ticket_id)
GET    /api/v1/tickets/:id                 # Detail (inkl. RCA-Felder, Kinder)
PUT    /api/v1/tickets/:id                 # Aktualisieren (Major-Erklaerung, RCA)
PATCH  /api/v1/tickets/:id/status          # Status aendern
PATCH  /api/v1/tickets/:id/assign          # Zuweisen / eskalieren
GET    /api/v1/tickets/:id/history         # Historie (inkl. Eskalationen)
GET    /api/v1/tickets/:id/comments        # Kommentare

# Known Error Database
GET    /api/v1/kedb                        # KEDB-Eintraege auflisten
POST   /api/v1/kedb                        # Bekannten Fehler erstellen
GET    /api/v1/kedb/:id                    # Detail bekannter Fehler
PUT    /api/v1/kedb/:id                    # Bekannten Fehler aktualisieren
GET    /api/v1/kedb/search?q=term          # KEDB durchsuchen
POST   /api/v1/kedb/:id/link/:ticketId     # Mit Ticket verknuepfen
DELETE /api/v1/kedb/:id/link/:ticketId     # Verknuepfung entfernen