---
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 (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.