fotospiel-app/docs/ops/oncall-roles.md

title, sidebar_label

title	sidebar_label
Rollen & On-Call-Handbuch	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 (bd-Issues als Roadmap/Backlog).
• 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.