Rollen und Verantwortlichkeiten im Betrieb

1) Warum Rollen formalisieren

Eine klare Rollenverteilung reduziert MTTA/MTTR, eliminiert „Grauzonen“, beschleunigt Releases und macht SLO/Compliance-Compliance reproduzierbar. Rollen = Verantwortung + Befugnisse + Schnittstellen (an wen wir schreiben, wen wir eskalieren, welche Entscheidungen autorisiert sind).

2) RACI-Basismodell

R (Responsible) - Führt die Arbeit aus.
A (Accountable) - trägt die endgültige Verantwortung und trifft Entscheidungen.
C (Consulted) ist ein Experte, der vor/während der Zeit konsultiert wird.
I (Informiert) - Informiert durch SLA.

3) Rollenkatalog (Beschreibungen und Verantwortlichkeiten)

3. 1 Incident Commander (IC)

Ziel: Leitet die Reaktion auf den Vorfall SEV-1/0.
Autorität: SEVs ankündigen, Releases einfrieren, Traffic wechseln, eskalieren.
Hauptaufgaben: Zeitlinie, Entscheidungsfindung, Fokus halten, Aufgabenverteilung, Go/No-Go.
Artefakte: Incident Card, SLA-Upgrades, endgültige AAR.

3. 2 P1/P2 On-Call (Primary/Secondary)

Ziel: primäre Reaktion und technische Maßnahmen.
P1: Triage, Playbook-Start, Kommunikation mit IC.
P2: Backup, komplexe Änderungen, Kontext halten, bei Stürmen - nimmt die Subströme.

3. 3 SRE / Platform Engineer

Das Ziel: Plattform- und Geländerzuverlässigkeit (SLO, Alerts, GitOps, Autoscale, DR).
Aufgaben: SLI/SLO, Alert-Hygiene, Progressive Releases, Infrastruktur als Code, Capacity, Observability.
Während des Vorfalls: Wurzeldiagnose, Rollbacks/Folbacks, Aktivierung von degrade-UX.

3. 4 Service Owner / Product Owner

Das Ziel: Servicequalität im geschäftlichen Sinne.
Aufgaben: SLO/Prioritäten definieren, Releases/Fenster abstimmen, Go/No-Go mitmachen.
Comms: Entscheidung, wann und was Kunden gemeinsam mit Comms sagen.

3. 5 Release Manager

Das Ziel: Veränderungen sicher herbeiführen.
Aufgaben: Orchestrierung von Releases, Checkup Gates, Canary/Blue-Green, Annotationen von Releases, Freeze bei Zwischenfällen.

3. 6 CAB Chair / Change Manager

Das Ziel: Veränderungsrisiko managen.
Aufgaben: RFC-Prozess, Plan/Backout, Konfliktkalender, High-Risk-Genehmigungen.

3. 7 RCA Lead / Problem Manager

Ziel: Post-Incident-Analyse, CAPA.
Aufgaben: Zeitlinie, evidenzbasierte Kausalität, Korrektur-/Präventionsmaßnahmen, Kontrolle D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

Das Ziel: Sicherheit und Reaktion auf Sicherheitsvorfälle.
Aufgaben: Triage von Security-Events, Schlüsselrotation, Isolation, Forensik, regulatorische Hinweise, WORM-Audit.

3. 9 DataOps / Analytics

Das Ziel: Daten- und Pipelinesicherheit.
Aufgaben: Frische/Qualität (DQ), Datenverträge, Lineage, Backfills, SLA BI/Reports.

3. 10 FinOps

Das Ziel: überschaubare Kosten.
Aufgaben: Kontingente/Limits, $/unit Reports, Budget Gates, Optimierungen (Log Volumes, Egress, Redundanz).

3. 11 Compliance / Legal

Ziel: Einhaltung von Vorschriften und Verträgen.
Aufgaben: Kündigungsfristen, Retentionen/Unveränderlichkeit evidence, Abstimmung öffentlicher Texte.

3. 12 Support / Comms

Ziel: Kommunikation mit Kunden/internen Stakeholdern.
Aufgaben: Status-Seite, Update-Layouts, Häufigkeit und Klarheit der Nachrichten, Feedback sammeln.

3. 13 Vendor Manager / Provider Owner

Zweck: Beziehungen zu externen Anbietern (PSP/KYC/CDN usw.).
Aufgaben: Eskalationen, SLA/OLA, redundante Routen, Fensterkoordination.

4) Rollen bei Veränderung und Eskalation

Wechsel: P1/P2 + IC-of-the-day (nicht mit P1 kombinierbar).
Eskalationen nach Zeit: P1→P2 (5 min ohne ack) → IC (10 min) → Duty Manager (15 min).
Quiet Hours: P2/P3-Signale werden nicht geweckt; Sicherheitssignale - immer.

5) Schnittstellen der Interaktionen (wer mit wem und wie)

IC ↔ Release Manager: Freeze/Rollback-Lösung.
IC ↔ Comms: Update-Texte und Frequenz.
SRE ↔ DataOps: Business-SLI (Zahlungserfolg, Datenfrische) in SLO-Gardrails.
Security ↔ Legal: Meldungen über Sicherheitsvorfälle, Benachrichtigungsfristen.
Vendor Owner ↔ IC: Anbieterstatus, Switchover/Folback.

6) KPIs nach Rolle (Benchmarks)

IC: Time-to-Declare, Einhaltung von Comms SLA, MTTR durch SEV-1/0.
P1/P2: MTTA, Time-to-First-Action,% Follow-Playbooks.
SRE/Plattform: SLO-Abdeckung, Alert Hygiene,% der Auto-Pullbacks sind erfolgreich.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Erfolgsrate von Backfills.
Comms: Status Genauigkeit, Complaint Rate/Vorfall.
FinOps: $/Einheit,% QoQ-Einsparungen, Quoteneinhaltung.

7) Vorlagen für Rollenkarten

7. 1 IC-Karte

Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)

7. 2 Karte der P1/P2

Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries

7. 3 Release Manager-Karte

Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after

8) Prozesse und Rollenbeteiligung (Zusammenfassung)

A — Accountable, R — Responsible, C — Consulted, I — Informed.

9) Checklisten

9. 1 Rollenzuweisung

• Jede Rolle hat einen Eigentümer, einen Stellvertreter und einen Abdeckungsbereich.
• Befugnisse werden beschrieben (welche Entscheidungen getroffen werden können).
• Verknüpfte Playbooks und Kommunikationskanäle.
• SLA zu Reaktion/Comms veröffentlicht.
• Die Rolle ist in jedem Dienst im Verzeichnis (CMDB) verfügbar.

9. 2 Schaltung und Handhabung

• Schichtkarte aktualisiert (aktive Vorfälle, Risiken, Fenster).
• Die JIT/JEA-Zugänge wurden überprüft.
• Echobotschaft an den Kanal: „Schicht angenommen/übergeben“.

9. 3 Post-Vorfall

• AAR durchgeführt, RCA ernannt.
• CAPA mit Eigentümern/Fristen, D + 14/D + 30 Kontrolle.
• Playbooks/Alerts/Policies aktualisiert.

10) Anti-Muster

Unklares „wer entscheidet“ → Verzögerungen und doppelte Anstrengungen.
IC kombiniert mit P1 - Verlust der Führung.
Öffentliche Komms ohne Zustimmung von Legal/Comms.
Release ohne Release Manager und Gates → CFR-Wachstum.
Fehlende Rollenreservierung (Krankheit/Urlaub).
„Heldentum“ statt Prozess: Wir retten per Hand, aber wir fixieren das Geländer nicht.
Rollen werden nicht im CMDB/Service-Verzeichnis → verlorene Eskalationen angezeigt.

11) Einbettung in Werkzeuge

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Verzeichnis/CMDB: Der Service hat den Besitzer, On-Call, SLO, Dashboards, Playbooks, Fenster.
Alert-as-Code: Jede Seite hat einen Besitzer und ein Standard-Playbook.
GitOps: IC/Release-Lösungen spiegeln sich in Release Annotationen und Tickets wider.

12) Reifegradmetriken der Rollenverteilung

Coverage Rollen in Verzeichnissen: ≥ 100% der kritischen Dienste.
On-Call SLA: Ack p95 ≤ 5 Minuten Page Storm p95 unter Kontrolle.
Postmortem SLA: Entwurf ≤ 72h; CAPA completion ≥ 85%.
Change Governance:% High-Risk-Änderungen mit RFC/CAB ≥ 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) Mini-Vorlagen

13. 1 RACI für Service (Datei im Repo)

yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident:  {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases:  {A: release-manager, R: dev,platform, C: security, I: support}
changes:  {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}

13. 2 Rollenprofil (Markdown)

Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations

14) Das Ergebnis

Operationen sind nachhaltig, wenn Rollen transparent, mit Autorität versehen und in Tools eingebettet sind. Rollenkatalog, RACI, klare Schnittstellen und Metriken für jede Rolle verwandeln Incidents, Releases und Änderungen in überschaubare Prozesse: Entscheidungen werden schnell getroffen, Risiken kontrolliert und die Nutzer sehen einen stabilen Service.