Plattform als Produkt

Die Plattform beginnt an ihrer Schnittstelle

Interne Plattform — Eine zusammenhängende Menge von Fähigkeiten, über die Produktteams Infrastruktur und Betriebsdienste mit konsistenten Schnittstellen selbst anfordern, benutzen und beobachten. Die Implementierung darf aus Cloud-Diensten, internen Diensten und Automatisierung bestehen; für Nutzer zählt der Vertrag an der Grenze.

Ein Portal allein ist noch keine Plattform. Hinter einer Schaltfläche kann weiterhin ein Ticket landen, das ein Operator am nächsten Morgen manuell bearbeitet. Umgekehrt kann bereits ein dokumentierter API-Aufruf mit automatischer Prüfung, eindeutiger Rückgabe und benanntem Supportweg eine brauchbare Plattformfähigkeit sein. CNCF beschreibt Plattformen über konsistente Erfahrungen wie Weboberflächen, Projektvorlagen und Self-Service-APIs. Entscheidend ist deshalb nicht die Oberfläche, sondern ob ein Team eine wiederkehrende Aufgabe ohne individuelle Übergabe vollständig erledigen kann.

Diese Grenze verhindert auch eine zweite Verwechslung: Eine Plattform muss nicht jede technische Schicht verbergen. Abstraktion ist nützlich, wenn sie eine wiederkehrende Entscheidung sicher vorwegnimmt. Sie wird schädlich, wenn sie Informationen entfernt, die Nutzer für Kapazität, Kosten, Fehlersuche oder Recovery brauchen. Ein Feld wie regionClass: local kann mehrere Providerdetails kapseln; die daraus folgende Datenresidenz, Fehlerdomäne und Latenzannahme müssen trotzdem sichtbar bleiben.

Vom Nutzerweg statt vom Werkzeug ausgehen

DORA empfiehlt, kritische Nutzerwege zu kartieren, etwa „einen neuen Dienst bereitstellen“ oder „eine Produktionsstörung diagnostizieren“. Das schützt vor einer verbreiteten Fehlentscheidung: Das Plattformteam beginnt mit dem Werkzeug, das es gut kennt, und sucht danach einen Bedarf. Ein Kubernetes-Cluster, ein Servicekatalog oder ein neues Portal kann technisch sauber sein und trotzdem keinen Engpass der Produktteams beseitigen.

Werkzeugfrage

Welche Portalsoftware oder welches Orchestrierungswerkzeug führen wir ein?

Nutzerfrage

Welche wiederkehrende Aufgabe kostet Teams heute Übergaben, Wartezeit oder vermeidbare Fehler?

Erfolgskriterium

Woran erkennen Nutzer und Plattformteam, dass dieser Weg schneller oder verlässlicher geworden ist?

Betriebsfrage

Wer reagiert, wenn der Weg oder eine dahinterliegende Fähigkeit ausfällt?

Nutzerforschung muss dafür nicht groß sein. Beobachte zwei Teams beim tatsächlichen Ablauf, sammle die Übergaben und Wartezeiten, und prüfe anschließend, ob dieselbe Reibung bei weiteren Teams auftritt. Besonders wertvoll sind Nichtnutzer: Adoption allein sagt nur, dass Teams ausweichen. Erst Gespräche und Ablaufdaten unterscheiden fehlende Fähigkeit, schweres Onboarding, unklare Rückgaben und unbekanntes Angebot.

Der Golden Path ist ein gepflegtes Angebot

Golden Path — Eine dokumentierte und automatisierte Vorlage für einen häufigen Nutzerweg. Sie kombiniert Fähigkeiten, setzt sichere Standardwerte und liefert die Signale, die Teams für Betrieb und Fehlersuche benötigen.

AWS empfiehlt, zunächst einen einzelnen Golden Path für einen häufigen Ablauf zu identifizieren und von der Umgebungserzeugung bis zur Beobachtbarkeit zu automatisieren. CNCF beschreibt solche Pfade als Vorlagen plus Dokumentation. Ein Golden Path ist damit mehr als ein Repository-Template: Er umfasst auch Identität, Netzgrenzen, Deploymentweg, Telemetrie, Kostenzuordnung, Lebenszyklus und eine verständliche Fehlerausgabe.

• Eingaben: wenige, benannte Entscheidungen wie Owner, Datenklasse, Umgebung und Kapazitätsklasse.
• Sichere Vorgaben: Logging, Verschlüsselung, Tags und minimale Rollen sind vorhanden, bevor ein Team sie vergessen kann.
• Ausgaben: Endpunkte, Secret-Referenzen, Dashboard, Kostenstelle und Status sind maschinenlesbar auffindbar.
• Nachweise: Anfrage, Policy-Prüfung, angewandte Version und Ergebnis bleiben miteinander verknüpft.
• Rückweg: Abbruch, Wiederholung, Stilllegung und Eskalation sind Teil des Pfads.

Sichere Vorgaben brauchen außerdem einen benannten Änderungsweg. Wenn die Plattform morgen Verschlüsselung, Logaufbewahrung oder erlaubte Regionen ändert, betrifft das nicht nur neue Bestellungen. Der Produktvertrag muss festlegen, ob bestehende Instanzen automatisch nachgezogen, als Abweichung gemeldet oder durch eine Migration geführt werden. Sonst existieren unter demselben Produktnamen mehrere unbekannte Sicherheitsstände.

Angebot und Guardrail sind zwei verschiedene Entscheidungen

CNCF nennt Plattformen optional und komponierbar: Teams sollen Teile nutzen und bei begründetem Bedarf eigene Fähigkeiten betreiben können. Daraus folgt keine freie Sicherheitszone. Ein Golden Path ist das bevorzugte Angebot; organisationsweite Identitäts-, Egress-, Audit- oder Standortregeln sind Guardrails. Wer beide verwechselt, macht aus einem gut getesteten Weg einen goldenen Käfig oder lässt mit jeder Ausnahme auch die Schutzgrenze fallen.

Golden Path

Optimiert einen häufigen Ablauf; darf bei belegtem Sonderbedarf verlassen werden.

Guardrail

Begrenzt Risiko organisationsweit; eine Abweichung braucht ein eigenes, befristetes Verfahren.

Produktentscheidung

Neue Variante aufnehmen, wenn wiederkehrender Bedarf ihren dauerhaften Betrieb rechtfertigt.

Ausnahmeentscheidung

Sonderweg sichtbar halten, Owner und Verfall festlegen, Grundkontrollen weiter anwenden.

Ein Team mit gemessener GPU-Anforderung darf also einen nicht angebotenen Computeweg benötigen. Daraus folgt weder, dass die Plattform sofort eine GPU-Produktlinie tragen muss, noch dass das Team ein Konto außerhalb von Audit und Egress-Kontrolle erhält. Das Team übernimmt den abweichenden Betriebsanteil; die Plattform macht den Sonderweg sichtbar und lernt aus wiederkehrender Nachfrage.

Self-Service endet erst bei einer verständlichen Rückgabe

Self-Service bedeutet nach CNCF, Fähigkeiten auf Anforderung mit minimalem manuellem Eingriff zu erhalten. Eine angenommene Anfrage ist aber kein bereitgestellter Dienst. Der Vertrag braucht Zustände wie accepted, policy-denied, provisioning, ready und failed; zu jedem Fehler gehören betroffene Ressource, prüfbare Ursache, erneuter Versuch und Eskalationsweg. Ohne diese Rückgabe verschiebt die Plattform das Ticket lediglich hinter eine API.

Idempotent heißt hier: Eine Wiederholung derselben fachlichen Anfrage erzeugt nicht unbemerkt eine zweite Datenbank oder ein zweites Netzwerk. Dafür braucht der Vertrag einen stabilen Schlüssel wie requestId oder eine gewünschte Ressourcenidentität. Ob ein konkretes Backend diese Semantik unterstützt, muss die Plattform prüfen; das Wort allein macht einen nicht idempotenten Cloud-Aufruf nicht sicher.

Der Produktvertrag ist ein versioniertes Artefakt

Ein Feld wie size: medium ist nur dann eine brauchbare Abstraktion, wenn seine Wirkung dokumentiert und beobachtbar bleibt. Nutzer müssen nicht jede Providerklasse kennen, aber sie müssen wissen, welche Kapazitätsannahme, Verfügbarkeitsgrenze und Kostenklasse sie wählen. Das Plattformteam trägt die Zuordnung hinter dem Feld und muss eine Änderung dieser Zuordnung wie eine Produktänderung behandeln.

Auch Ausgaben sind Verträge, keine freundlichen Hinweise. Wenn ein Team den Datenbankendpunkt aus einer Chatnachricht kopieren muss, kann keine nachgelagerte Automatisierung zuverlässig daran anknüpfen. Eine maschinenlesbare Referenz erlaubt dagegen, Deployment, Secret-Bezug, Dashboard und Stilllegung an dieselbe Ressourcenidentität zu binden. Der Vertrag sollte dabei Referenzen statt geheime Werte ausgeben: secretRef zeigt auf den kontrollierten Bezugsweg, während ein Klartextpasswort neue Kopien und unbekannte Aufbewahrungsorte erzeugt.

Ownership wird an jeder Schicht ausgesprochen

Eine Plattform kann die Bedienung vereinheitlichen, ohne jede Implementierung selbst zu betreiben. CNCF empfiehlt die dünnste sinnvolle Schicht und verweist darauf, dass Cloudanbieter oder andere interne Teams die eigentliche Fähigkeit tragen können. Dadurch entstehen mindestens drei Owner: Der Anbieter betreibt seinen Dienst innerhalb seiner Zusage, das Plattformteam betreibt Vertrag und Integration, das Produktteam betreibt Nutzung und Anwendung.

Anbieter

Dienststeuerung und zugesagte Providerfunktion; keine Verantwortung für Anwendungskonfiguration oder fachliche Datenqualität.

Plattformteam

Bestellschema, sichere Vorgaben, Automatisierung, gemeinsame Signale, Dokumentation und Eskalation zum Anbieter.

Produktteam

Fachlicher Zweck, Daten, Lastverhalten, Anwendungskonfiguration, Bereitschaft der Anwendung und Nutzung der bereitgestellten Signale.

Geteilt

Vorfallanalyse an der Grenze: Jede Seite liefert Evidenz ihrer Schicht und bestätigt die Übergabe.

Support ist Teil des Produkts

CNCF zählt Wissen und Support ausdrücklich zur Plattform. Ein Supportvertrag beschreibt daher mehr als einen Kanal. Er nennt unterstützte Fähigkeiten und Versionen, Reaktionsweg, benötigte Evidenz, Bereitschaftszeiten, Eskalationskette und die Grenze zur Anwendung. Ohne diese Angaben entscheiden nachts Lautstärke und persönliche Beziehungen darüber, welches Team arbeitet.

• Die Plattform liefert Status der Fähigkeit, Quota- und Fehlerdaten, relevante Änderungen und die requestId.
• Das Produktteam liefert Nutzerwirkung, Anwendungsänderungen, Verbindungs- oder Aufrufmuster und einen erreichbaren Owner.
• Eine Stützmaßnahme bleibt eng, befristet und mit Rückbautermin versehen.
• Eine Übergabe endet erst, wenn die nächste verantwortliche Rolle sie bestätigt hat.
• Eine dauerhafte Änderung am gemeinsamen Produkt läuft nach der Störung durch den normalen Reviewweg.

Wenn nur ein Mandant nach einem Rollout sein Verbindungslimit erreicht, darf die Plattform ein befristetes Limit anheben, um Wirkung zu begrenzen. Sie übernimmt damit nicht den Anwendungscode. Ein dauerhaftes globales Limit wäre dagegen eine Produktänderung mit Wirkung auf alle Nutzer. Die Trennung schützt sowohl Produktteams vor pauschalem Wegschicken als auch die Plattformbereitschaft vor grenzenloser Zuständigkeit.

Der Supportweg muss auch den Ausfall der Plattform selbst abdecken. Liegen Statusseite, Runbook und Eskalationskontakt ausschließlich hinter derselben Identität oder demselben Portal, das gerade gestört ist, verschwindet mit der Plattform auch ihr Rückweg. Ein kleiner unabhängiger Zugang zu Status, Kontakten und den ersten Diagnoseinformationen kostet zusätzliche Pflege, erhält aber die Handlungsfähigkeit bei einem Kontrollpfad-Ausfall.

Erfolg braucht Nutzung, Wirkung und Betriebsqualität

Eine Plattform kann hohe Adoption durch Zwang erreichen und trotzdem Zeit kosten. Sie kann schnelle Bereitstellung liefern und bei jedem Fehler ein Ticket benötigen. DORA empfiehlt deshalb eine ausgewogene Sicht aus Delivery-Metriken, Nutzerzufriedenheit, Adoption beziehungsweise Bindung und Erfolg wichtiger Aufgaben. Für den Betrieb kommen Verfügbarkeit und Fehler der Plattformwege hinzu.

Nutzung

Welche geeigneten Teams beginnen den Pfad und verwenden ihn nach dem Onboarding weiter?

Aufgabenerfolg

Wie viele Anfragen erreichen ready; wie lange dauert der Weg; an welchem Schritt brechen Nutzer ab?

Entlastung

Wie viele Übergaben und manuelle Plattformtickets benötigt derselbe Nutzerweg noch?

Qualität

Wie oft erzeugt der Pfad fehlerhafte Bereitstellungen, Nacharbeit oder Rücknahmen?

Erfahrung

Verstehen Nutzer Status und Fehler; würden sie den Weg für denselben Zweck erneut wählen?

Segmentiere die Messung nach Produkt, Version und Nutzerweg. Ein globaler Mittelwert kann verbergen, dass Testumgebungen in Minuten entstehen, während Produktionsbestellungen regelmäßig am Freigabe-Gate warten. Ebenso kann eine hohe Erfolgsquote entstehen, weil Teams die schwierigen Fälle gar nicht erst einreichen. Abbruchstelle, erneute Versuche und spätere Supporttickets ergänzen daher den Endstatus. Sie zeigen, ob der Pfad Arbeit beseitigt oder nur an eine andere Stelle verschiebt.

Aus Messwerten folgt noch keine Roadmap. Eine häufige Fehlermeldung kann auf schlechte Dokumentation, einen zu engen Vertrag oder einen sinnvollen Guardrail hinweisen. Verbinde das Signal mit betroffenen Nutzerwegen und entscheide dann: Erklärung verbessern, sichere Vorgabe ändern, neue Produktvariante bauen oder die Ablehnung bewusst beibehalten. Auch eine nicht gebaute Funktion ist so eine begründete Produktentscheidung.

Versionen, Änderungen und Stilllegung gehören zum Angebot

Ein Golden Path altert. Provider-APIs ändern sich, sichere Vorgaben werden strenger, Teams benötigen neue Fähigkeiten. Deshalb trennt der Vertrag eine stabile apiVersion von der internen Template- oder Modulversion. Eine kompatible Umsetzung darf sich hinter derselben Vertragsversion ändern; eine Änderung an Pflichtfeldern oder Bedeutung braucht einen neuen Vertrag und einen Migrationsweg.

Stilllegung ist ebenfalls ein Nutzerweg. Ein Löschknopf ohne Prüfung kann Daten, DNS-Namen oder Auditnachweise entfernen, die andere Prozesse noch brauchen. Der Vertrag muss anzeigen, was endet, welche Aufbewahrung weiter gilt und wer die fachliche Freigabe erteilt. Der Preis dieser Sorgfalt ist ein langsameres Ende; der Gewinn ist, dass verwaiste Ressourcen und überraschende Datenverluste nicht gegeneinander ausgespielt werden.

Die kleinste tragfähige Plattform wächst durch Belege

DORA warnt vor dem umfassenden Plattformbau vor der ersten Nutzung. Beginne mit einem häufigen, teuren Nutzerweg und genau den Fähigkeiten, die ihn Ende zu Ende tragen. Das kann zunächst ein Repository-Template, eine Pipeline und zwei dokumentierte Cloudprodukte sein. Ein Portal lohnt sich erst, wenn es einen vorhandenen Vertrag besser zugänglich macht; es ersetzt keinen fehlenden Vertrag.

Der Betriebsvertrag für die folgenden Entscheidungen

In den Übungen behandelst du die Plattform als Produkt und als laufenden Dienst. Du leitest eine Roadmap aus Nichtnutzung ab, trennst Golden Path und Guardrail, prüfst die Rückgabe eines Self-Service-Vorgangs, ordnest Verantwortung an Anbieter-, Plattform- und Produktgrenze, findest Lücken in einem YAML-Produktvertrag und führst eine alte Vertragsversion geordnet aus dem Betrieb.

• Starte beim wiederkehrenden Nutzerweg und seinem messbaren Problem.
• Definiere Eingabe, Wirkung, Ausgabe, Beobachtung und Ende als einen Vertrag.
• Lass begründete Sonderwege innerhalb organisationsweiter Guardrails sichtbar.
• Benenne pro Handlung einen Owner und fordere Evidenz an jeder Schicht.
• Miss Nutzung zusammen mit Aufgabenerfolg, Entlastung und Betriebsqualität.
• Versioniere und beende Plattformprodukte mit demselben Ernst wie ihre Einführung.