Zusammenspiel der Teams im Betrieb

1) Warum

Die iGaming-Plattform besteht aus Dutzenden von Domains (Payments, Games/Core, Risk/KYC, Data, Infra/SRE, Support, Compliance). Ohne formalisierte Interaktion wachsen MTTR, CFR und operationelle Risiken. Ziel ist es, disparate Funktionen in ein einziges Betriebssystem zu verwandeln: vorhersehbare Kontakte, transparente Warteschlangen, gemeinsame Signale und vereinbarte Priorität.

2) Grundsätze

1. SLO-first: Gemeinsame Entscheidungen sind an SLO/Fehlerbudgets gebunden.
2. Eine einzige Quelle der Wahrheit: gemeinsame Dashboards, einheitliche Status und Artefakte.
3. Klare Grenzen und Schnittstellen: Jedes Befehlspaar hat den beschriebenen Vertrag (OLA/Runbook/API).
4. Kleine Batchi und Reversibilität: Änderungen durch Ficheflage/Kanarei, schnelles Rollback.
5. No blame - yes data: Analyse nach Fakten, Verbesserungen sind ein obligatorischer Teil des Zyklus.
6. Minimal notwendige Privilegien und SoD: Rollenteilung für sensible Operationen.
7. Automatisieren Sie die Routine, standardisieren Sie den Rest.

3) Rollen und RACI (Ende-zu-Ende)

Head of Ops/SRE Lead ist der Eigentümer des Operating Frameworks, KPI/KRI. A

Service Owners (Zahlungen/Spiele/KYC/Daten) - Domain-Ziele, Änderungen, Risiko. A/R

Plattform/Infra - Barrierefreiheit, Performance, Releases/Kanarien. R

Risiko/Compliance/Sicherheit - SoD, RG/KYC/PII, Audits. C/A

Support/CRM - die Front der Beschwerden, Kommunikation mit den Spielern. R/C

On-Call IC/CL - Incident Management und externe Updates. R

Release Manager - Kalender, CAB, Änderungsstatus. R

Data/Analytics - Produkt- und Betriebsmetriken, RCA-Unterstützung. R/C

4) Interoperabilitätsverträge (OLA/SLx)

• Verantwortungsbereiche: wessen Bereich (z. B. PSP-Routing - Zahlungen; Cache/DB - Infra).
• Ziele/Schwellenmetriken: MTTA des Vorfalls, Reaktionszeit auf Eskalation, Nachbeobachtungsfenster.
• Warteschlangen und Prioritäten: P1-P4, Geschäftskritik, Freeze-Fenster.
• Schnittstellen: Kanäle, Bot-Befehle, API/Runbook, Eigentümerverzeichnisse.
• Artefakte: Welche Dokumente/Protokolle/Dashboards sind verpflichtet, die Veranstaltung zu begleiten.

5) Kommunikationskanäle und Protokolle

Operations-Chat (austauschbar): tägliche Updates, Mini-Rituale, Handover.
Var-Räume nach Zwischenfällen: werden vom Bot erstellt; IC/CL-Rollen werden vom Befehl zugewiesen.
CAB/Change-Channel: Diskussion über Veränderungen, Risiken, Release-Kalender.
Status-Kanal (nur lesen): SLO/Incident/Planned Work Zusammenfassungen.
Eskalationen: Befehlsvorlagen '/page', '/escalate', SLA Reporting.

Das einheitliche Protokoll der Mitteilungen: "die Tatsache → der Einfluss → ETA/ETR → das folgende Fenster apdejta → der Eigentümer".

6) Handover zwischen Schichten und Regionen

1. SLO/SLI: Wo das Risiko eines Budget-Burnouts liegt.

2. Offene Vorfälle/Eskalationen und deren ETA.

3. Geplante Arbeiten/Freigaben in den nächsten 24-48 Stunden

4. Anbieter (PSP/KYC/Studios): aktive Tickets, Erwartungen.

5. On-Call-Zusammensetzung und Kontakte (IC/CL/Domains).

6. „Watchlist“ - Bereiche mit erhöhter Aufmerksamkeit (Warteschlangen/Replikation/Cache).

Handover wird in einem Ersatzmagazin erfasst, Links zu Var-Räumen und Dashboards.

7) Zusammenarbeit bei Vorfällen

Start: alert → bot erstellt eine Karte'# inc-YYYY-MM-DD-XXX', weist IC/CL und Domain-Leads zu.
Eine-Stimme-Regel: IC - die endgültige Entscheidung; CL - Kommunikation.
Fakten und Hypothesen: Wir trennen; „Rote“ Signale haben Priorität.
Guardrails: Ficheflags/PSP-Routing ändern sich nur über ein Runbook mit SoD/Dual-Control.
Kommunikation: Entwürfe öffentlicher Updates über CL, Partner gezielt.
Closing: Post-Monitoring, Post-Mortem-Generierung und Verbesserungsaufgaben mit Eigentümern/Deadlines.

8) Zusammenarbeit bei Veränderungen

Veröffentlichungskalender: öffentlich, mit Freeze-Perioden und On-Call-Slots.
Qualität Tore: Einheit/Vertrag/e2e, Sicherheit, SLO-Tore Staging.
Kanarische Rollen: Schritt für Schritt 5%→25%→100% auf GEO/Tenanten/Banken.
Auto-Rollback: Richtlinien für wichtige SLI/KRI, WORM-Magazin.
Komma-Pakete: Update-Entwürfe im Vorfeld mit CL/Legal abgestimmt.
RACI-Änderungen: RM (A/R), SO (A/R), SRE (R), Sec/Compliance (C/A), CAB (A), IC/CL (R/C).

9) Einheitliche Telemetrie und Artefakte

Allgemeiner Metrikkatalog: SLI/SLO, Geschäftsmetriken, KRI (Warteschlangen, PSP, Replikation).
Dashboard „Operations Map“: Übersicht über Domänen, Regionen, Status von Vorfällen/Arbeiten.
Zeitlinien: einheitliches Format (Zeit, Autor, Aktion, Ergebnis, Links).
Post-Mortems: Vorlage ohne Gebühren, Präventionsmaßnahmen, Revisionsdatum.
Runbooks/Checklists: versioned; Link aus Alert und Incident Cards.

10) Priorisierung und Planung

Wöchentlicher Ops-Plan (30-45 Min.): Aushandlung von Top-Risiken, Releases, Limits, Verbesserungen aus Post-Mortems.
Kanban-Operationen: Spalten 'Backlog → Ready → In Progress → Validate → Done', WIP-Limits.
Prioritätskriterien: Auswirkungen auf SLO/Umsatz/Compliance, Größe/Reversibilität, Abhängigkeit von Anbietern.

11) Eskalationsmatrix (Squeeze-out)

12) Politik und SoD

SoD/4-eyes: die Schlussfolgerungen/Bonusse/routing der PSP/Export PII - nur bei der doppelten Billigung.
JIT-Rechte: Vorübergehende Eskalation von Privilegien für Runbook-Aktionen.
Datenrichtlinien: Verbot von PII in offenen Kanälen/Dashboards; Geo-Grenzen.
Audit: Unveränderliche Aktivitätsprotokolle (WORM), Richtlinienrevisionen.

13) Interaktionswerkzeuge

Incident-Bot: '/incident new', Rollen, Update-Timer, Kommentwürfe, '/runbook', '/flag', '/config'.
Metrics API: generische SLO-Views und KRIs, Beispiele (trace_id) für RCA.
Release-Portal: Manifeste, Gates, Rollover/Rollback-Status.
Verzeichnis der Eigentümer/CMDB: Domains, Kontakte, Backup-Kanäle.

14) Kollaborationsmetriken (KPI/KRI)

MTTA/MTTR nach Domains und Slots (Tag/Nacht), Anteil der Vorfälle, die vor Beschwerden erfasst wurden.
Handover Qualität: Übertragungsfehler (Checklistenpunkte nicht rechtzeitig geschlossen).
Change Collaboration:% Releases mit fertigen Com-Paketen und ohne Pullbacks.
Guardrail Discipline: Häufigkeit von Verstößen gegen SoD/Richtlinien (Ziel ist 0).
Comms Cadence: Einhaltung der öffentlichen Update-Intervalle beim P1/P2.
Post-mortem SLA: Anteil der Post-Mortems ≤ D + 5, Ausführung von Aktionen.
Fair-Share Load: Verteilung der Nächte/Spitzen auf Personen/Teams.
Customer Signal Lead: Verzögerung zwischen objektiver Verschlechterung und ersten Beschwerden.

15) Roadmap für die Umsetzung (6-10 Wochen)

Ned. 1-2: Bestandsaufnahme der Domains/Eigentümer; OLA-Vorlagen; Start des Ersatzkanals und der Handover-Checkliste; Basis-Eskalationsmatrix.
Ned. 3-4: Incident-Bot (MVP), gemeinsamer Status-Kanal, SLO/SLI/KRI-Einzelkarte; Verzeichnis runbooks.
Ned. 5-6: CAV/Release-Kalender, Komma-Pakete und Freeze-Fenster; SoD/4-eyes für sensible Operationen.
Ned. 7-8: Kanarienrollen und Auto-Rollback als Standard; Post-Mortem-Vorlage, Exec/Ops-Dashboards der Zusammenarbeit.
Ned. 9-10: P1-Übungen, regionalübergreifende Handler, WORM-Audit, KPI/KRI-Berichte, OLA-Anpassung.

16) Muster (Fragmente)

16. 1 OLA (Payments ↔ Infra/SRE)

yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"

16. 2 Hendover Checkliste (10 Punkte)

1. SLO-Status von Domains

2. Offene Vorfälle (ETA/Eigentümer)

3. Geplante Arbeiten/Freigaben + Beobachtungsfenster

4. Anbieter (PSP/KYC/Studios) - Risiken/Erwartungen

5. Warteschlangen/Replikation/Cache - Fehler/Anomalien

6. Grenzwert-/Ficheflag-Änderungen

7. Reklamationen/Tickets und Belastungsschwellen

8. Komma-Pläne und Status-Entwürfe

9. On-Call-Kader und Reserve

10. „Watchlist“ pro Slot

17) Antipatterns

„Wird sich jemand darum kümmern?“ ohne RACI und Besitzer.
Vorfälle ohne IC/CL und Updating-Timer.
Versteckte Änderungen (manuelle Klicks), kein Git/Audit.
Unnatürliche Telemetrie: Unterschiedliche Zahlen in verschiedenen Teams.
Releases ohne Kommpakete und Kanaren.
SoD-Verstöße „um der Geschwindigkeit willen“.
Handover mündlich, ohne Aufzeichnungen und Checklisten.
Post-Mortems ohne Aktionen und Fristen.

Summe

Das Zusammenspiel der Teams im Betrieb ist eine vertragliche Zusammenarbeit: OLA/SLx, klare Kanäle und Rollen, Händlerdisziplin, allgemeine Telemetrie, vereinbarte Freigaben und Incident-Prozesse. Ein solcher Rahmen reduziert MTTR und CFR, richtet Prioritäten aus, schützt SLO, Umsatz und Compliance - und macht die tägliche Arbeit berechenbar und nachhaltig.