Die Rollen der Infrastrukturteams

1) Das ganze Bild: warum Spezialisierung

Planbarkeit und Schnelligkeit: Klare Eigentümer reduzieren „Grauzonen“.
Zuverlässigkeit und Sicherheit: Verteilung der Verantwortung auf Domänen (K8s, Netzwerke, DB, Sicherheit).
Wirtschaft: FinOps trennt den Wert vom Verbrauch und verwaltet den „Preis der Neunen“.
Developer Experience: Plattform als Produkt - Self-Service, Vorlagen, Kataloge.

2) Hauptrollen und Verantwortungsbereiche

3) Haftungsgrenzen (Eigentumsgrenzen)

Die Plattform besitzt Ebenen L3-L7 Plattformdienste (K8s, Grid, Observability), aber keine Geschäftslogik.
SRE besitzt den Zuverlässigkeitsprozess (SLO/Incidents/Postmortems) und nicht jede spezifische Metrik des Produktteams.
Release/Delivery besitzt die Mechanik des Layouts, aber die Verantwortung für das „Was“ wird gegeben - die Teams haben ein Gefühl.
DBRE besitzt Datencluster/Richtlinien und das Produktteam (gemäß DBRE-Standards) besitzt das Schema/die Migrationen.
SecOps besitzt Richtlinien und Kontrollen und die Implementierung erfolgt gemeinsam mit den Domain-Inhabern.

4) Betriebsmodelle

1. Zentrale Plattform - schneller Start, Engpassrisiko.
2. Plattform als Produkt (PaaP) - Self-Service-Vorlagen, Kataloge, „interner Marktplatz“ von Dienstleistungen.
3. Verband/Gilden - Experten sind in Produktdomänen eingebettet (Kapitel/embedded SRE/DBRE).
4. Matrix - Strategische Standards des Zentrums + Ausführung in Domänen.

Empfehlung: PaaP für Grundbedürfnisse und embedded für kritische Domains kombinieren.

5) Schnittstellen und OLAs (interne Vereinbarungen)

Service-Verzeichnis: was „als Service“ verfügbar ist (K8s Namespace, DB-Cluster, Warteschlange, SLO-Dashboard, Alert-Profil).
OLA (Operational Level Agreement): Reaktionszeiten, Verantwortungsbereiche, Eskalationspunkte.
Plattform-Service-SLO-Karten: Verfügbarkeit, API-Latenz, Bereitstellungszeit aus der Vorlage.

yaml service: "Kubernetes Namespace Provisioning"
owner: "Platform"
request_channel: "Service Catalog"
targets:
response_time: "≤ 15 min"
delivery_time: "≤ 1 hour (without manual approvals)"
scope:
includes: "quota, RBAC, secrets integration"
excludes: "business configs, database migrations"
escalation: "#plat-ops-oncall"

6) RACI: Wer macht was

Legende: R - erfüllt, A - antwortet, C - Beratung, I - informiert.

7) KPIs und Leistungskennzahlen nach Rolle

Plattform: Lead-Zeit für die Bereitstellung von Service,% Self-Service, DevEx NPS.
SRE: MTTR/MTTD, SLO-Ausführung, Playbook-Abdeckung, Auto-Mitigate-Anteil.
CloudOps/NetOps: Perimeter-Aptime, Chenji-Ausführungszeit, Konfigurationsvorfälle.
DBRE: RPO/RTO, Recovery-Erfolg, Replikations-Lag p95.
Release: Prozentsatz der kanarischen Releases, Rate der Pullbacks, Zeit der Umgebung.
Observability: Vollständigkeit der Signale, Antwortzeit der Anfragen/Dashboards, Anti-Noise-Ratio.
SecOps: Schließzeiten für kritische CVEs, MTTD/MTTR von Sicherheitsvorfällen, Secret-Manager-Abdeckung.
FinOps: Kosten pro Service/RPS, Rightsizing-Einsparungen, Genauigkeitsprognose.

8) Onboarding und DevEx

Startpaket: Terraform/Helm-Vorlagen, CI/CD-Pipelines, Checklisten „Hallo, Service“.
Dock-Portal: Standards, Beispiele, Live-Dashboards, Self-Service-Buttons.
Workshops/Bürostunden: nach Rollen (SRE 101, SecOps 101, DBRE 101).
Politik der Eskalationen: Wen man nachts ruft und wann ein Ticket reicht.

9) Grenzen des Datenbesitzes und der Zugriffe

IAM-Versicherung: Rollenbesitzer, Lebensdauer der Zugriffe, JIT (Just-in-Time) Zugriffe.
Geheimnisse: Zentralisierte Secret Manager, Rotation, Verbot von Geheimnissen in ENV/Repo.
Dateneigentum: Das Produkt besitzt das Schema/die Daten der Domäne; DBRE besitzt ein „Gefäß“ (Cluster und Politiker).

10) Prozesse: Vorfälle, Änderungen, Freigaben

Vorfälle: IC/Kriegsraum/Postmortem (siehe „Vorfälle und SRE-Playbooks“).
Änderungen (Change Management): risikobasiert, fast lane für low risk, CAB nur für high risk.
Releases: progressive Lieferung, Freeze-Regeln bei der Verbrennung des Fehlerbudgets.

11) Checklisten nach Rolle (Quetschen)

Platform

• Servicekatalog und SLAs für jeden Plattformdienst
• IaC + Policy Templates (OPA/Conftest)

SRE

• Top-Pfad-SLO-Karten, Burn-Rate-Alerts, Playbooks
• Monatlicher Bericht über fehlerhafte Budgets

DBRE

• DR-Drill, Wiederherstellungstest, RPO/RTO signiert
• Migrations- und Indexierungsrichtlinien

SecOps

• Triage von Schwachstellen und Patch-Fenstern
• DLP/PII-Kontrollen, Audit-Zugänge

Release

• Kanarische Standardschritte, Auto-Rollback
• Ficha-Flaggen und Kill-Schalter

Observability

• Metrik-/Label-Standards, Budget-Dashboards
• Anti-Noise (Quorum, Multi-Window), SLO-Widgets

FinOps

• Chargeback/Showback, Rightsizing-Empfehlungen
• „Cost per 9“, Prognose

12) Anti-Muster der Organisation

„DevOps ist ein Mensch“: die Überlastung der „Generalisten“, das Fehlen von Domain-Besitzern.
„Plattform = Ticketkasse“: Alles über Handzettel, kein Selbstservice.
„SRE = Feuerwehrleute im Einsatz“: keine SLOs und Befugnisse.
„Sicherheit als Stopphahn“: Spätes Einschalten, statt „guardrails by design“.
„Observability = schöne Grafiken“: ohne actionable alert und SLO.
„Bei FinOps geht es nur um den Bericht“: ohne Empfehlung und Auto-Rightsizing.

13) Artefaktmuster

Vorlage für Plattformdienstkarte

yaml service: "Managed PostgreSQL"
owner: "DBRE"
plan: "S, M, L"
slo:
availability: "99. 95 %/quarter"
rpo: "≤ 5 min"
rto: "≤ 15 min"
interfaces:
request: "Service Catalog → Postgres"
incidents: "#dbre-oncall"
changes: "Change Policy L2"
security:
secrets: "Vault"
access: "JIT/RBAC"
finops:
pricing: "по vCPU/GB/IOPS"
limits: "quota per tenant"

Mini-RACI für Releases

yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform

14) Implementierungsplan (4 Iterationen)

1. Standardisierung (2-3 Wochen): Rollenübersicht, Servicekatalog, RACI, OLAs, Eskalationskanäle.
2. DevEx (3-4 Wochen): Service-Katalog, CI/CD-Vorlagen, Terraform-Module, Basis-SLOs/Dashboards.
3. Zuverlässigkeit und Sicherheit (4-6 Wochen): Incident Playbooks, DR-Drill, WAF/DLP, Secret Manager.
4. FinOps und Optimierung (kontinuierlich): Chargeback, Rightsizing, „Cost per 9“, Auto-Policies.

15) Mini-FAQ

Wo kann ich SRE aufbewahren - in der Plattform oder in den Produkten?
Hybrid: Strategisches SRE in der Plattform, embedded-SRE in kritischen Domänen.

Wer besitzt SLO-Dienste?
Produktteams. SRE bietet Methodik, Tooling und Prozesskontrolle.

Wie kann man „Schatten-IT“ vermeiden?
Servicekatalog, explizite OLAs, schneller Self-Service und transparente Preise (Showback/Chargeback).

Summe

Eine starke Infrastrukturfunktion sind klare Rollen + Produktansatz für die Plattform + Vereinbarungen über Schnittstellen und Metriken. Erfassen Sie RACI und OLAs, geben Sie Self-Service und Standards, messen Sie die Leistung anhand der KPIs jeder Rolle und verbessern Sie regelmäßig DevEx, SLO und Kosten. Dadurch werden Betriebsrisiken reduziert, Releases beschleunigt und die Infrastruktur berechenbar gemacht.