IncidentOps

Rolle: alleiniger Entwickler · Uniprojekt · IT355 · Jahr: 2026 · Status: technische Umsetzung abgeschlossen

kurz: Ein rollenbasiertes Incident-Response-System aus React-Client und Spring-Boot-API. Responder arbeiten die Queue ab, aktualisieren Incidents, schreiben Notizen und eskalieren. Admins verwalten Teams, Services und SLA-Richtlinien.

Problem

Während eines Incidents landet die Historie überall: Chat, Tickets, persönliche Notizen. IncidentOps hält sie in einem Datensatz. Jeder Incident hat eine verantwortliche Person, einen verwalteten Service, eine Priorität, einen kontrollierten Status, einen SLA-Zustand, Notizen und manuelle Eskalationen, und die Timeline hält fest, wer was wann geändert hat.

Rahmenbedingungen

• Ein Lebenszyklus über drei Schichten. UI, API und Datenbank müssen sich einig sein, welche Statusübergänge erlaubt sind. Ein Client darf keinen Schritt überspringen.
• Berechtigungen gehören dem Server. Responder und Admins sehen unterschiedliche Ansichten, aber ein versteckter Admin-Link in React ist nie die Sicherheitsgrenze.
• Der SLA-Zustand wird berechnet, nicht eingetippt. Fristen kommen aus Richtlinien, die einen verwalteten Service mit einer Priorität verknüpfen.

Entscheidungen

• Ein nach Features organisiertes Spring-Boot-Backend mit frameworkfreier Domäne. Die Domänenschicht kennt keine Spring-, JPA- oder HTTP-Typen. Application Services führen die Use Cases aus, PostgreSQL-Adapter speichern Nutzer, Services, Incidents, Events, Richtlinien und Eskalationen.
• Übergänge werden auf dem Server geprüft. Notizen, Eskalationen und Statuswechsel landen in der Timeline mit dem angemeldeten Nutzer als Akteur.
• Spring Security mit JWT erzwingt RESPONDER und ADMIN an jedem Endpoint. Sitzungsdaten bleiben im Client im aktiven Browser-Tab.
• Der SLA-Zustand kommt von der API. Der Server meldet, ob Bestätigung und Lösung im Plan, überschritten oder erfüllt sind. Der Client zeigt das mit Text und Zeitstempel, nicht nur mit Farbe.
• app -> features -> shared im Frontend, Abhängigkeiten zeigen also nur in eine Richtung.

Ergebnis

Die Full-Stack-Verifikation nutzte signierte Login-Anfragen, Spring Security, MockMvc, PostgreSQL-Testcontainers und dieselben REST-Verträge, die das Frontend verwendet. Abgedeckt waren Anlegen von Incidents, Statuswechsel, Notizen, Eskalation, rollenbasierte 403-Antworten, Admin-Katalogoperationen und transaktionales Löschen. Browserchecks in Desktop-, Tablet- und Mobilbreite prüften Tastaturfokus, scrollbare Dialoge, API-Wiederherstellung, abgelaufene Sitzungen und die Vorgabe, dass nichts horizontal überläuft.