Shared Responsibility auf Plattform-Ebene

Lernziele

Nach dieser Lektion kannst du ein Shared-Responsibility-Modell für eine interne Plattform aufstellen: Welche Ebene verantwortet das Platform-Team, welche die Stream-Teams, welche Rolle spielt das Security-Team. Du verstehst, warum die Verantwortungsgrenze mit dem Abstraktionsgrad der Plattform wandert, was Escape Hatches damit zu tun haben und wie du das Modell so dokumentierst, dass es im Incident und im Audit trägt.

Das Problem: „Wer patcht eigentlich das Base-Image?”

Eine CVE in einer weit verbreiteten Systembibliothek wird publik. Das Security-Team fragt: Sind wir betroffen? Und jetzt beginnt das Fingerzeigen. Das Base-Image pflegt das Platform-Team — aber die Teams pinnen Versionen in ihren Dockerfiles. Das Rebuild triggern müsste die CI — aber die Pipeline-Templates gehören der Plattform, die Pipelines den Teams. Drei Tage später hat niemand gepatcht, weil jeder dachte, der andere sei dran.

Das ist kein Tooling-Problem, sondern ein ungelöstes Verantwortungsmodell. Aus der Public Cloud kennst du das Shared-Responsibility-Modell: Der Provider verantwortet die Sicherheit der Cloud (Hardware, Hypervisor, physische Standorte), der Kunde die Sicherheit in der Cloud (Daten, Konfiguration, Zugriffe). Eine interne Plattform fügt eine dritte Schicht ein: Das Platform-Team ist gegenüber den Stream-Teams selbst „Provider” — und übernimmt damit Pflichten, die es explizit machen muss. Genau das ist der Unterschied zwischen einer Plattform und einem Haufen geteilter Infrastruktur.

Die Verantwortungsmatrix: Ebene für Ebene

Das Modell wird konkret, wenn du es als Matrix über die Plattform-Schichten aufschreibst. Eine bewährte Aufteilung für eine Kubernetes-basierte IDP:

• Cloud/Hardware: Cloud-Provider. Punkt.
• Cluster-Lebenszyklus (Control Plane, Node-Upgrades, CNI, Cluster-Verfügbarkeit): Platform-Team. Stream-Teams merken Upgrades idealerweise gar nicht (Lektion 38).
• Shared Services (Ingress, GitOps-Controller, Observability-Stack, Registry, Secrets-Backend): Platform-Team betreibt und hält SLOs ein (Lektion 36); Stream-Teams konsumieren über definierte Schnittstellen.
• Golden Paths und Templates (Pipeline-Vorlagen, Base-Images, Standard-Charts): Platform-Team pflegt sie; Stream-Teams sind verantwortlich, Updates zu übernehmen — es sei denn, die Plattform rollt sie automatisch aus. Diese Zeile ist die häufigste Streitquelle, dazu gleich mehr.
• Anwendungscode, App-Konfiguration, App-Alerts, Datenmodell: Stream-Team. Die Plattform liefert Werkzeuge (Observability as a Service, Lektion 32), aber das Team trägt die Bereitschaft für die eigene Anwendung.
• Policies und Risikoakzeptanz: Das Security-Team definiert Anforderungen, das Platform-Team implementiert sie als Policy-as-Code (Lektion 28), die Stream-Teams erfüllen sie. Security baut keine Gates in jede Pipeline einzeln — das wäre das alte Modell, das Plattformen gerade ablösen.

Wichtig ist die Form: pro Zeile genau ein Verantwortlicher. Sobald in einer Zelle „gemeinsam” steht, hast du das Base-Image-Problem von oben reproduziert. „Gemeinsam” heißt in der Praxis: niemand.

Die Grenze wandert mit dem Abstraktionsgrad

Der entscheidende Gedanke, der gute von mittelmäßigen Interview-Antworten trennt: Die Verantwortungsgrenze ist keine Naturkonstante, sondern eine Funktion dessen, wie viel die Plattform abstrahiert. Bietet deine Plattform rohe Namespaces an, sind Ressourcen-Limits, NetworkPolicies und Pod-Security Sache der Teams. Bietet sie eine Compute-Abstraktion wie in Lektion 31 („gib mir Container-Image und Skalierungsregeln, den Rest mache ich”), wandern all diese Pflichten zur Plattform — mit ihnen aber auch die On-Call-Last und die Schuld, wenn etwas klemmt.

Das ist der eigentliche Preis von Abstraktion, und du solltest ihn benennen können: Jede Schicht, die du den Teams abnimmst, übernimmst du. Deshalb gehört zu jeder Self-Service-Capability die Frage „Können wir die Verantwortung dafür auch tragen — personell, in der Rotation, im Audit?”

Escape Hatches drehen die Logik um: Wer den Golden Path verlässt — eigenes Helm-Chart statt Standard-Chart, eigene Pipeline statt Template — übernimmt die Verantwortung für genau diesen Teil zurück. Das ist legitim und gewollt, aber es muss explizit passieren: dokumentiert, mit Ansprechpartner, idealerweise technisch markiert (z. B. ein Label am Workload), damit im Incident sofort sichtbar ist, ob der Standardpfad oder eine Sonderlocke betroffen ist. Ein stiller Escape Hatch ist eine Verantwortungslücke mit Zeitzünder.

Das Modell festschreiben: Plattform-Vertrag statt Stammeswissen

Damit das Modell trägt, braucht es eine schriftliche Form — oft „Platform Contract” oder „Terms of Service” genannt. Hinein gehören: die Verantwortungsmatrix, die SLOs der Plattform-Dienste samt Support-Zeiten, die Pflichten der Teams (Updates übernehmen innerhalb welcher Frist, Quotas respektieren, App-On-Call stellen), die Eskalationswege im Incident und die Regeln für Escape Hatches. Das Dokument lebt in Git, Änderungen laufen als PR mit Review beider Seiten — derselbe Mechanismus, den du für ADRs (Lektion 12) kennst.

Zwei Prüfsteine zeigen, ob das Modell funktioniert. Erstens der Incident-Test: Wird bei einem Vorfall sofort klar, wessen Runbook gilt und wer geweckt wird (Lektion 39)? Zweitens der Audit-Test: Kann jede Kontrolle einem Owner zugeordnet werden? Auditoren fragen genau das — und „das macht irgendwie die Plattform” ist ein Finding. Dieser Faden wird in Lektion 43 (Compliance-by-Design) wieder aufgenommen.

Praxis

Erstelle eine Verantwortungsmatrix für eine fiktive, aber konkrete Plattform: Kubernetes auf Managed-Cloud, GitOps-Deployment, zentrale Registry mit kuratierten Base-Images, Backstage-Portal, 20 Stream-Teams.

Vorgaben:

1. Mindestens zehn Zeilen (von „Node-OS-Patches” bis „Alerting auf Business-Metriken”), drei Spalten: Platform-Team, Stream-Team, Security-Team. Pro Zeile genau ein „R” (responsible); andere Beteiligungen als „C” (consulted) oder „I” (informed).
2. Spiele dann drei Szenarien gegen deine Matrix und notiere, ob sie eine eindeutige Antwort liefert: (a) CVE im Base-Image, (b) ein Team überschreitet dauerhaft seine Ressourcen-Quota und drosselt Nachbarn, (c) ein Team will eine Datenbank-Engine betreiben, die die Plattform nicht anbietet.
3. Für jedes Szenario ohne eindeutige Antwort: Matrix nachschärfen, nicht das Szenario wegdiskutieren.

Zeitansatz: 45–60 Minuten. Die Matrix ist ein hervorragendes Artefakt, auf das du im Interview verweisen kannst.

Typische Stolperfallen

„Gemeinsame Verantwortung” als Zellinhalt: Klingt kooperativ, bedeutet aber, dass im Ernstfall niemand handelt. Immer genau einen Verantwortlichen benennen, Beteiligung separat ausweisen.

Abstraktion übernehmen, Verantwortung nicht: Die Plattform nimmt Teams die NetworkPolicies ab, aber als der Traffic eines Teams blockiert wird, soll das Team selbst debuggen. Wer die Kontrolle nimmt, nimmt auch die Pflicht.

Security-Team als Türsteher statt Policy-Owner: Wenn Security jede Ausnahme einzeln freigeben muss, wird es zum Bottleneck und die Plattform zur Durchreiche. Skalierbar ist nur: Security definiert Policies, die Plattform erzwingt sie maschinell, Ausnahmen laufen als dokumentierter Prozess.

Das Modell existiert nur in Köpfen: Beim Personalwechsel oder im 3-Uhr-Incident zählt nur, was aufgeschrieben und auffindbar ist.

Interview-Vorbereitung

Auf die Standardfrage „Wie regelst du Verantwortlichkeiten zwischen Platform-Team und Entwicklungsteams?” antwortest du in vier Schritten: Analogie ziehen (Shared Responsibility wie in der Cloud, mit dem Platform-Team als internem Provider) → Matrix skizzieren (drei, vier Ebenen mit je einem Owner) → das Wanderungsprinzip (mehr Abstraktion = mehr Verantwortung bei der Plattform; Escape Hatch = Verantwortung wandert zurück) → Verankerung (Platform Contract in Git, Incident- und Audit-tauglich).

Typische Follow-ups:

• „Ein Team verlässt den Golden Path und es knallt — wer ist schuld?” — Das Team, sofern der Escape Hatch explizit und dokumentiert war; war er still geduldet, trägt die Plattform Mitverantwortung für die fehlende Markierung.
• „Was verantwortet das Security-Team konkret?” — Anforderungen und Risikoakzeptanz definieren; die technische Durchsetzung liegt als Policy-as-Code bei der Plattform.
• „Wie verhindert ihr, dass die Plattform zur Black Box wird, für die niemand sonst Verantwortung fühlt?” — Über sichtbare SLOs, transparente Statusseiten und klar dokumentierte Team-Pflichten im Contract.
• „Was ändert sich bei stark regulierten Workloads?” — Die Matrix bekommt zusätzliche Zeilen (Datenklassifizierung, Aufbewahrung), und Auditierbarkeit jeder Zuordnung wird Pflicht statt Kür.

Zusammenfassung

Shared Responsibility auf Plattform-Ebene heißt: Das Platform-Team ist interner Provider mit expliziten Pflichten, die Stream-Teams verantworten ihre Anwendungen, Security definiert Policies, die die Plattform maschinell durchsetzt. Das Modell lebt als Matrix mit genau einem Owner pro Zeile, festgeschrieben in einem versionierten Platform Contract. Die Grenze wandert mit dem Abstraktionsgrad — und Escape Hatches verschieben sie kontrolliert zurück.

Die nächste Lektion macht aus dem „Wer” ein „Wie”: Zero Trust — wie eine Plattform so gebaut wird, dass kein Akteur und kein Netzsegment implizit vertrauenswürdig ist.