Krisenmanagement — Betrieb & Wartung

Deployment

Erstinstallation

# 1. Backend: Migration ausfuehren
cd /var/www/backend-api
cat prisma/migrations/11_crisis_management_v1/migration.sql | npx prisma db execute --stdin
cat prisma/migrations/12_school_trip_child_protection/migration.sql | npx prisma db execute --stdin

# 2. Prisma Client neu generieren
npx prisma generate

# 3. Modul in Registry registrieren
npx tsx prisma/seed-module-registry.ts

# 4. Standard-Szenarien seeden
npx tsx prisma/seed-crisis-scenarios.ts

# 5. Backend bauen und neustarten
npm run build
pm2 restart backend-api

Updates

# Backend
cd /var/www/backend-api
git pull
npm run build
pm2 restart backend-api

# Portal
cd /var/www/prilog-portal
git pull
npm run build
pm2 restart portal

Neue Tenants

Wenn ein neuer Tenant provisioniert wird, muessen die Standard-Szenarien erneut geseeded werden:

cd /var/www/backend-api
npx tsx prisma/seed-crisis-scenarios.ts

Das Seed-Script ist idempotent — bereits existierende Szenarien werden uebersprungen.

n8n Deployment

n8n laeuft als Docker-Container auf dem Kunden-Server:

# n8n starten (im Kunden-Server Docker-Compose)
docker compose up -d n8n

# n8n Status pruefen
docker compose ps n8n

# n8n Logs anzeigen
docker compose logs -f n8n --tail 50

Die n8n-Workflows werden beim Deployment automatisch importiert. Die n8n-UI ist unter http://localhost:5678 erreichbar (nur intern, nicht oeffentlich exponiert).

Monitoring

n8n Workflow-Ausfuehrungen

Eskalation und Workflow-Steuerung laufen in n8n. Monitoring erfolgt ueber:

1. n8n UI — Unter Executions alle Ausfuehrungen einsehen (Erfolg, Fehler, laufend)
2. Docker Logs — docker compose logs n8n --tail 100
3. Backend-Logs — Callback-Aufrufe werden im Backend geloggt

Log-Muster fuer Fehlersuche

Log-Nachricht	Bedeutung
Krise aktiviert { eventId, scenario }	Erfolgreiche Aktivierung
n8n workflow triggered { workflowId, eventId }	n8n-Workflow erfolgreich gestartet
n8n callback: tasks created { eventId, count }	Aufgaben via n8n-Callback erstellt
MatrixCrisis: Raumerstellung fehlgeschlagen	Synapse nicht erreichbar
MatrixCrisis: kein aktiver ServerOrder	Tenant hat keinen aktiven Server
n8n callback error	Fehler bei n8n-Callback-Verarbeitung
Crisis Management data cleaned up	Modul-Daten nach 30-Tage-Retention geloescht

Gesundheitspruefung

# Pruefen ob der Backend-Server laeuft
pm2 status backend-api

# Pruefen ob n8n laeuft
docker compose ps n8n

# n8n Workflow-Ausfuehrungen pruefen
docker compose logs n8n --tail 20 | grep -i execution

# Pruefen ob aktive Krisen existieren
curl -s -H "Authorization: Bearer $TOKEN" \
  https://api.prilog.chat/api/platform/v1/crisis/active | jq '.total'

Datenbank

Tabellen

Tabelle	Beschreibung	Groesse (geschaetzt)
crisis_scenarios	Szenario-Konfigurationen	Hunderte Zeilen pro Tenant
crisis_events	Aktive + archivierte Krisen	Dutzende pro Jahr
crisis_tasks	Checklisten-Aufgaben	5-10 pro Event
crisis_reports	Nachberichte (JSON)	1 pro Event
crisis_audit_entries	Audit-Log	Hunderte pro Event
school_trip_events	Schulreisen	Dutzende pro Jahr
child_protection_cases	Kinderschutzfaelle	Einzelne pro Jahr

Backup-Hinweise

• Kinderschutzfaelle enthalten sensible Daten — Backups verschluesseln
• retainUntil beachten: Daten duerfen nicht vor Ablauf geloescht werden
• Audit-Logs sind beweissichernd — Integritaet gewaehrleisten

Index-Uebersicht

-- Haeufigste Queries
crisis_scenarios(tenant_id)
crisis_scenarios(tenant_id, is_active)
crisis_events(tenant_id, status)
crisis_events(scenario_id)
crisis_tasks(event_id)
crisis_tasks(event_id, status)
crisis_audit_entries(tenant_id, created_at)
crisis_audit_entries(event_id)
school_trip_events(tenant_id, status)
child_protection_cases(tenant_id, status)
child_protection_cases(retain_until)

Aufbewahrungsfristen

Datentyp	Frist	Rechtsgrundlage
Krisenberichte	5 Jahre	Organisatorische Dokumentationspflicht
Audit-Logs	5 Jahre	Nachweispflicht
Kinderschutzfaelle	10 Jahre nach Schliessung	§8a SGB VIII, Jugendamt-Empfehlung
Schulreise-Daten	Bis manueller Loeschung	Keine gesetzliche Vorgabe

Automatische Loeschung

• Modul-Deaktivierung: 30 Tage Karenzzeit, dann cleanup() loescht Szenarien, Events, Tasks, Reports, Audit
• Kinderschutzfaelle: Werden bei Modul-Deaktivierung NICHT geloescht — retainUntil muss beachtet werden
• Cron-Job Empfehlung: Regelmaessig retainUntil < NOW() pruefen und abgelaufene Faelle archivieren

Troubleshooting

Krise kann nicht aktiviert werden

Symptom	Ursache	Loesung
Kein Szenario sichtbar	Nicht freigegeben	Im Szenario-Manager freigeben
"CRISIS_ALREADY_ACTIVE"	Laufende Krise	Bestehende Krise zuerst beenden
Kein Matrix-Raum erstellt	Synapse nicht erreichbar	Synapse-Status pruefen, Token-Refresh
403 Forbidden	Fehlende Rolle	Benutzer-Rolle im Portal pruefen

Eskalation funktioniert nicht

Symptom	Ursache	Loesung
Tasks werden nicht eskaliert	n8n-Container gestoppt	docker compose up -d n8n
Tasks werden nicht eskaliert	n8n-Workflow deaktiviert	In n8n-UI Workflow aktivieren
Eskalation verzoegert	n8n-Workflow-Intervall	Workflow-Timer in n8n pruefen
Keine Matrix-Nachrichten	Synapse-Token abgelaufen	Wird automatisch erneuert
n8n-Callback schlaegt fehl	Backend nicht erreichbar	pm2 status backend-api pruefen

PDF-Export schlaegt fehl

Symptom	Ursache	Loesung
500 PDF_GENERATION_FAILED	pdfkit nicht installiert	npm install pdfkit auf dem Server
Leeres PDF	Report-Content fehlt	Krise muss zuerst beendet werden

Kinderschutz: Vier-Augen blockiert

Symptom	Ursache	Loesung
"FOUR_EYES_SAME_PERSON"	Gleicher User zweimal	Zweiter User muss bestaetigen
"Erste Zustimmung erhalten"	Normal — wartet auf zweite Person	Zweite Person einloggen

Kapazitaetsplanung

Das Krisenmanagement-Modul hat minimale Ressourcenanforderungen:

• CPU: Vernachlaessigbar (n8n uebernimmt Workflow-Ausfuehrung)
• RAM: ~256 MB fuer n8n Docker-Container
• Datenbank: <1 MB pro Tenant pro Jahr
• Netzwerk: Minimaler Matrix-Traffic (Textnachrichten)

Der einzige ressourcenintensive Vorgang ist die PDF-Generierung (pdfkit), die aber nur bei Nachberichten/Exporten aufgerufen wird.