further rework to the documentation

docs/ops/oncall-roles.md

@@ -0,0 +1,126 @@
+---
+title: Rollen & On-Call-Handbuch
+sidebar_label: Rollen & On-Call
+---
+
+Dieses Dokument beschreibt, **wer** im Betrieb wofür zuständig ist und **wie** On‑Call‑Bereitschaft organisiert wird. Es ergänzt die technischen Runbooks um eine klare Verantwortungsebene.
+
+> Hinweis: Konkrete Namen/Kontaktdaten sollten nicht in Git stehen, sondern getrennt (z.B. in einem internen Adressbuch oder Passwort‑Safe). Dieses Dokument definiert Rollen und Prozesse.
+
+## 1. Rollenübersicht
+
+### 1.1 Platform Ops
+
+- Verantwortlich für:
+  - Infrastruktur (Docker/Dokploy‑Stacks, Netzwerke, TLS, Backups).
+  - Technische Verfügbarkeit der Services (App, Queues, DB, Redis, Storage).
+  - Umsetzung und Pflege der Runbooks unter `docs/ops/`.
+- Typische Aufgaben:
+  - Deployments koordinieren (`docker-compose`, Dokploy, Migrations).
+  - Monitoring/Alerting pflegen (`ops/monitoring-observability.md`).
+  - Incident‑Response bei SEV‑1/SEV‑2 (`ops/incidents-major.md`).
+
+### 1.2 On-Call Engineer
+
+- Rolle, die im wechselnden Turnus (z.B. wöchentlich) On‑Call ist.
+- Verantwortlich für:
+  - Reaktion auf laufende Alerts (Monitoring, Pager, Chat‑Bots).
+  - Erstes Triage nach `ops/incidents-major.md`.
+  - Eskalation an weitere Rollen (z.B. Platform Ops, Produkt, Security).
+- Voraussetzungen:
+  - Zugriff auf Produktions‑Logs, Monitoring‑Dashboards, Dokploy/Horizon.
+  - Vertraut mit den wichtigsten Runbooks (Public‑API, Storage, Photobooth, Billing).
+
+### 1.3 Support / Customer Success
+
+- Verantwortlich für:
+  - Kontakt mit Tenants (E‑Mail/Telefon/Chat).
+  - Übersetzung technischer Probleme in Kundensprache.
+  - Sammeln aller relevanten Informationen, bevor an On‑Call/Platform Ops eskaliert wird.
+- Typische Aufgaben:
+  - Tickets aus dem Help‑System triagieren.
+  - Proaktive Kommunikation bei Events („Wir haben ein Upload‑Problem identifiziert, wir arbeiten daran“).
+
+### 1.4 Produkt / Engineering Leads
+
+- Verantwortlich für:
+  - Entscheidungen bei Feature‑Flags, Rollbacks, Hotfix‑Releases.
+  - Priorisierung langfristiger Maßnahmen nach Incidents (`docs/process/roadmap.md`, `docs/process/todo/*`).
+- Typische Aufgaben:
+  - Teilnahme an Postmortems.
+  - Freigabe von riskanteren Änderungen (z.B. große Migrations).
+
+## 2. On-Call-Modell
+
+### 2.1 Bereitschaftszeiten
+
+Empfohlene Einteilung (anpassbar an dein Team):
+
+- **Bürozeiten (z.B. 09:00–17:00)**  
+  - On‑Call ist die jeweils zuständige Platform‑Ops‑Person des Tages.
+  - Reaktionsziel: 15 Minuten bei SEV‑1/2, 60 Minuten bei SEV‑3.
+- **Außerhalb der Bürozeiten / Event-Spitzen**  
+  - Optional: Rotierender On‑Call‑Dienst mit Rufbereitschaft.  
+  - Reaktionsziel: nach individueller Vereinbarung (z.B. 30–60 Minuten bei SEV‑1).
+
+> Wenn ihr keinen formalen 24/7‑Dienst habt, sollte klar dokumentiert sein, **wann** keine garantierte Reaktionszeit besteht (z.B. nachts/wochenends) und wie das Kunden gegenüber kommuniziert wird.
+
+### 2.2 Rotation & Übergabe
+
+- On‑Call‑Rotation (z.B. wöchentlich) im Teamtool (Kalender/Issue‑Tracker) pflegen.
+- Vor Start einer Schicht:
+  - Offene Incidents und bekannte Problemzonen durchgehen.
+  - Sicherstellen, dass Aufrufwege funktionieren (Chat, Telefon, Pager).
+- Nach Schicht:
+  - Kurze Übergabe an nächste On‑Call‑Person (offene Themen, laufende Beobachtungen).
+
+## 3. Eskalationspfad bei Incidents
+
+### 3.1 Standard-Eskalation (SEV-2/3)
+
+1. On‑Call nimmt Alert entgegen, prüft grob die Lage (`ops/incidents-major.md` → Triage).
+2. Wenn Problem lösbar erscheint:
+   - Runbooks anwenden (z.B. Public‑API‑Playbook, Medien‑Runbook, Photobooth‑Ops).
+   - Kundenkommunikation via Support abstimmen.
+3. Wenn unklar oder größer:
+   - Platform‑Ops bzw. Engineering Lead im Chat markieren.
+   - Incident‑Thread mit Statusupdates führen.
+
+### 3.2 SEV-1 (kritisch)
+
+1. On‑Call ruft sofort **Platform‑Ops** und ggf. **Produkt‑Lead** in den Incident‑Thread.
+2. Falls nötig, mit Produkt die Entscheidung für:
+   - Rollback auf letztes Release,
+   - temporäre Abschaltung einzelner Features (Feature‑Flags),
+   - Aktivierung einer Maintenance‑Seite
+   treffen.
+3. Support/Success informieren betroffene Tenants mit kurzem Status und ETA (auch wenn ETA noch grob ist).
+
+## 4. Tools & Zugänge
+
+Für On‑Call/Platform‑Ops sollten mindestens folgende Zugänge eingerichtet und getestet sein:
+
+- **Dokploy / Docker-Orchestrierung**
+  - Zugriff auf Compose‑Stacks, Logs, Health‑Checks.
+- **Horizon / Queue-Monitoring**
+  - Zugriff auf `/horizon` (nur für SuperAdmins).
+- **Logs**
+  - Zentralisierte Logs (Loki/ELK) oder SSH‑Zugriff zur Maschine mit `storage/logs`.
+- **Monitoring/Alerts**
+  - Zugang zu Uptime‑/Monitoring‑Service (Status‑Dashboard, Alert‑Konfiguration).
+
+> Stelle sicher, dass On‑Call‑Personen ausprobiert haben, ob sie diese Tools tatsächlich erreichen können (VPN, 2FA, etc.), bevor eine Schicht beginnt.
+
+## 5. Verbindung zu den Runbooks
+
+Bei einem Incident sollte die On‑Call‑Person immer vom **Betriebshandbuch** aus denken:
+
+- Einstieg über `docs/ops/operations-manual.md` (Docusaurus‑Startseite).
+- Je nach Symptome:
+  - **API-/Frontend-Probleme** → Public‑API‑Playbook (`ops/deployment/public-api-incident-playbook.md`), ggf. Marketing/Guest‑PWA‑Spezifikationen in `docs/prp/` (in PRP, nicht im Ops‑Bereich).
+  - **Upload/Storage-Probleme** → `ops/media-storage-spec.md`, `ops/guest-notification-ops.md`.
+  - **Photobooth** → `ops/photobooth/ops_playbook.md`.
+  - **Abrechnung** → `ops/billing-ops.md`.
+  - **DSGVO-Fälle** → `ops/compliance-dsgvo-ops.md`.
+
+Dieses Dokument soll nicht alle technischen Details wiederholen, sondern sicherstellen, dass immer klar ist, **wer** reagiert und **welches** Runbook als nächstes geöffnet werden sollte.