Platform Engineer vs. DevOps vs. SRE
Rollenabgrenzung, Schnittstellen und wie die Disziplinen zusammenwirken.
Lernziele
Nach dieser Lektion kannst du DevOps, SRE und Platform Engineering präzise voneinander abgrenzen — nach Natur, Fokus, Kunde und Kernmetrik — und erklären, wie die drei in einer Organisation produktiv zusammenwirken. Du erkennst die typischen Vermischungen („DevOps-Engineer gesucht”) und kannst im Interview eine Antwort geben, die über Buzzword-Definitionen hinausgeht.
Das Problem: drei Begriffe, ein Brei
Stellenanzeigen suchen „DevOps Engineers”, die in Wahrheit Ops-Arbeit machen sollen. Teams nennen sich SRE, betreiben aber einfach das Monitoring. Und „Platform” steht auf jedem zweiten Team-Namensschild. Diese Begriffsverwirrung ist nicht nur kosmetisch: Wer die Konzepte vermischt, baut Organisationen mit unklaren Verantwortlichkeiten — und scheitert in Interviews an der beliebten Abgrenzungsfrage.
Der Schlüssel zur sauberen Antwort: Die drei Begriffe liegen auf unterschiedlichen Ebenen. DevOps ist eine Kultur und Arbeitsweise, SRE ist eine konkrete Engineering-Praxis für Zuverlässigkeit, Platform Engineering ist eine Produkt-Disziplin. Sie konkurrieren nicht — sie beantworten verschiedene Fragen.
DevOps: Kultur, kein Jobtitel
DevOps entstand um 2009 als Gegenbewegung zur Mauer zwischen Entwicklung („wir wollen Änderungen ausliefern”) und Betrieb („wir wollen Stabilität, also möglichst keine Änderungen”). Die Kernidee: gemeinsame Verantwortung über den gesamten Lebenszyklus, kurze Feedback-Schleifen, Automatisierung statt Übergaben. Daraus stammen Praktiken wie Continuous Integration und Delivery sowie die DORA-Metriken als Messlatte für Delivery-Performance.
Wichtig für die Abgrenzung: DevOps beschreibt wie eine Organisation arbeitet, nicht wer angestellt wird. Ein „DevOps-Team” als separates Silo zwischen Dev und Ops ist genau genommen ein Widerspruch zur Idee — es baut eine dritte Mauer, wo zwei abgerissen werden sollten. Trotzdem hat sich der Jobtitel etabliert; im Interview punktest du, wenn du diese Spannung benennen kannst, ohne dogmatisch zu werden.
SRE: Zuverlässigkeit als Engineering-Problem
Site Reliability Engineering ist Googles Antwort auf die Frage, wie man Betrieb mit Software-Engineering-Methoden betreibt — der oft zitierte Satz dazu: „SRE is what happens when you ask a software engineer to design an operations team.” SRE bringt ein präzises Begriffsgerüst mit:
- SLI/SLO: messbare Indikatoren (z. B. Anteil erfolgreicher Requests) und Zielwerte dafür.
- Error Budget: die erlaubte Unzuverlässigkeit. Bei einem SLO von 99,9 % sind 0,1 % Fehler das Budget — solange es nicht aufgebraucht ist, darf schnell geliefert werden; ist es verbraucht, hat Stabilisierung Vorrang. Das löst den Dev-vs.-Ops-Konflikt über eine Zahl statt über Meinungen.
- Toil-Reduktion: manuelle, wiederkehrende Betriebsarbeit wird gemessen und systematisch wegautomatisiert.
Der Kunde von SRE ist letztlich der Endnutzer, dessen Erfahrung die SLOs schützen. Der Fokus ist Zuverlässigkeit im Betrieb — nicht Developer Experience.
Platform Engineering: Cognitive Load als Gegner
Platform Engineering adressiert ein Problem, das DevOps selbst erzeugt hat: Wenn jedes Team alles selbst verantwortet, wächst der Cognitive Load pro Team mit jeder Technologie im Stack. Die Plattform-Antwort: Ein dediziertes Team extrahiert generische Komplexität (Cluster, Pipelines, Observability, Secrets) in ein Self-Service-Produkt — die IDP aus Lektion 1.
Der Kunde ist der interne Entwickler, die Kernmetriken sind Developer Experience und Delivery-Geschwindigkeit der Stream-Teams. Entscheidend ist die Pointe: Platform Engineering schafft „you build it, you run it” nicht ab, sondern verschiebt die Abstraktionsebene. Entwickler betreiben weiterhin ihre Anwendung — aber auf einer Plattform, statt auf rohem Kubernetes. Verantwortung bleibt, die Themenbreite sinkt.
Als Merkhilfe für die Abgrenzung:
| DevOps | SRE | Platform Engineering | |
|---|---|---|---|
| Natur | Kultur & Praktiken | Engineering-Disziplin | Produkt-Disziplin |
| Leitfrage | Wie liefern wir schnell und gemeinsam? | Wie zuverlässig muss es sein — und wie erreichen wir das? | Wie senken wir den Load der Entwicklerteams? |
| Kunde | die Organisation | Endnutzer (via SLO) | interne Entwickler |
| Typische Metrik | DORA-Metriken | SLO-Erfüllung, Error Budget | Adoption, Time-to-First-Deploy, DevEx |
Wie die drei zusammenspielen — und wo es kracht
In einer reifen Organisation greifen die Ebenen ineinander: Die DevOps-Kultur gibt das Zielbild (Teams liefern eigenverantwortlich und schnell). Die Plattform macht das Zielbild bei Skalierung praktikabel, indem sie Self-Service und sichere Defaults liefert. SRE-Praktiken sichern die Zuverlässigkeit — und zwar auf zwei Ebenen: SLOs für die Plattform selbst (das Plattform-Team ist SRE für sein eigenes Produkt, siehe die internen SLOs aus Lektion 2) und SLO-Tooling als Capability für die Stream-Teams.
Zwei Konstellationen führen regelmäßig zu Problemen:
Das Plattform-Team wird SRE für alle Apps. Wenn das Plattform-Team bei jedem Anwendungs-Incident gerufen wird, kollabiert das Modell: Es wird zum Flaschenhals, und die Stream-Teams verlernen den Betrieb ihrer eigenen Software. Die Grenze muss klar sein — Plattform-Incidents gehören dem Plattform-Team, App-Incidents den App-Teams.
SRE ohne Mandat. Ein SRE-Team, das SLOs definiert, aber keine Konsequenzen durchsetzen kann (Error Budget verbraucht, Feature-Arbeit läuft trotzdem weiter), produziert Dashboards statt Zuverlässigkeit.
Praxis: Szenarien zuordnen
Ordne die folgenden fünf Situationen jeweils der primär zuständigen Disziplin zu (DevOps-Kultur, SRE, Platform Engineering) und begründe in ein bis zwei Sätzen. Schreibe die Antworten auf, bevor du weiterliest — die Begründung ist wichtiger als das Label:
- Die Checkout-API verfehlt seit zwei Wochen ihr Latenz-Ziel; das Team will trotzdem weiter Features liefern.
- Jedes der 30 Teams pflegt eine eigene, leicht abweichende CI-Pipeline; Onboarding neuer Teams dauert Wochen.
- Deployments passieren nur freitags, weil Dev und Ops sich gegenseitig nicht trauen und ein Change-Advisory-Board jede Änderung prüft.
- Das Management will wissen, ob sich die Delivery-Performance der Organisation im letzten Jahr verbessert hat.
- Ein neues Team braucht eine Staging-Umgebung und wartet seit acht Tagen auf ein Ticket.
(Zur Kontrolle: 1 → SRE/Error Budget, 2 → Platform, 3 → DevOps-Kultur, 4 → DORA-Metriken aus dem DevOps-Umfeld, 5 → Platform/Self-Service.) Formuliere anschließend für Szenario 2 und 5 je einen Satz, wie die Plattform-Lösung konkret aussähe.
Typische Stolperfallen
„Platform Engineering ersetzt DevOps.” Diese Schlagzeile taucht regelmäßig auf und ist falsch. Plattformen operationalisieren die DevOps-Idee bei Skalierung — sie schaffen sie nicht ab.
SRE auf Monitoring reduzieren. SRE ist ein Steuerungsmodell mit SLOs und Error Budgets, kein anderes Wort für „betreibt Prometheus”.
Rollen statt Ebenen vergleichen. Wer die drei Begriffe als konkurrierende Jobtitel behandelt, verfehlt den Kern: Kultur, Praxis und Produkt-Disziplin können (und sollten) koexistieren.
Die Verantwortungsgrenze verschweigen. Ohne explizite Regel, wer welche Incidents trägt, driftet jede Plattform-Organisation in den „Plattform-Team macht alles”-Modus.
Interview-Vorbereitung
Auf die Standardfrage „Wie grenzt du Platform Engineering von DevOps und SRE ab?” antwortest du am stärksten über die Ebenen: DevOps ist Kultur (Leitfrage: gemeinsam schnell liefern), SRE ist Engineering-Praxis für Zuverlässigkeit (Leitfrage: wie zuverlässig, gemessen per SLO), Platform Engineering ist Produkt-Disziplin (Leitfrage: Cognitive Load der Entwickler senken). Dann ein Satz zum Zusammenspiel: Die Plattform macht DevOps skalierbar, SRE-Praktiken sichern Plattform und Apps ab.
Rechne mit diesen Follow-ups:
- „Ist DevOps tot, wie manche behaupten?” — Nein; gescheitert ist die Interpretation, jedes Team müsse alles selbst können. Genau diese Lücke füllt die Plattform.
- „Wer trägt bei euch die Incidents — Plattform oder App-Team?” — App-Incidents beim App-Team, Plattform-Incidents beim Plattform-Team; die Grenze muss dokumentiert sein.
- „Was ist ein Error Budget und wofür ist es gut?” — Die erlaubte Unzuverlässigkeit unterhalb des SLO; es übersetzt den Konflikt „Features vs. Stabilität” in eine objektive Entscheidungsregel.
- „Kann ein Team gleichzeitig Platform- und SRE-Team sein?” — In kleinen Organisationen ja; entscheidend ist, dass beide Aufträge (Produkt bauen, Zuverlässigkeit steuern) explizit sind und nicht einer den anderen verdrängt.
Zusammenfassung
DevOps, SRE und Platform Engineering liegen auf verschiedenen Ebenen: Kultur, Zuverlässigkeits-Praxis, Produkt-Disziplin. DevOps gibt das Zielbild eigenverantwortlicher Delivery, SRE steuert Zuverlässigkeit über SLOs und Error Budgets, Platform Engineering senkt den Cognitive Load der Teams durch eine Self-Service-IDP — und macht damit das DevOps-Versprechen bei fünfzig Teams einlösbar. Die kritische Grenze im Alltag: Das Plattform-Team betreibt die Plattform, nicht die Anwendungen darauf.
Die nächste Lektion geht ins Handwerkszeug der Plattform-Seite: Wie designt man Golden Paths, die Teams freiwillig nutzen — und wie dünn darf eine Plattform sein?