29. Sept. 2025·8 Min
Werner Vogels’ „You Build It, You Run It“ erklärt
Erfahre, was Werner Vogels mit „You Build It, You Run It“ meinte und wie man es anwendet: Eigentümerschaft, On‑Call, SLOs, Incident‑Response und sicheres Deployment.
Erfahre, was Werner Vogels mit „You Build It, You Run It“ meinte und wie man es anwendet: Eigentümerschaft, On‑Call, SLOs, Incident‑Response und sicheres Deployment.
„You build it, you run it“ bleibt hängen, weil die Aussage direkt ist. Es geht nicht um Motivationsposter oder „mehr DevOps sein“. Es ist eine klare Feststellung zur Verantwortung: Das Team, das einen Service ausliefert, bleibt auch dafür verantwortlich, wie dieser Service in Produktion funktioniert.
In der Praxis bedeutet das, dass dasselbe Produktteam, das Features designt und Code schreibt, auch:
Das heißt nicht, dass alle über Nacht Infrastruktur‑Expert:innen werden. Es bedeutet, dass die Feedback‑Schleife real ist: Wenn du etwas auslieferst, das Ausfälle, Pagerlärm oder Kundenleid erhöht, spürt dein Team das direkt — und lernt schnell.
Diese Philosophie ist leicht zu wiederholen und schwer umzusetzen, wenn man sie nicht als Betriebsmodell mit klaren Erwartungen behandelt. „Run it“ umfasst typischerweise On‑Call (in irgendeiner Form), Incident‑Ownership, Runbooks, Dashboards und kontinuierliche Verbesserungen.
Es impliziert auch Voraussetzungen: Teams kann man nicht einfach „run it“ aufbürden, ohne ihnen die Werkzeuge, Zugänge und die Befugnis zur Behebung zu geben — plus Zeit im Roadmap‑Plan für die operative Arbeit.
Vor „You Build It, You Run It“ organisierten viele Firmen Arbeit wie ein Staffelrennen: Entwickler:innen schreiben Code und werfen ihn dann „über die Mauer“ an ein Operations‑Team zum Deploy und Betrieb.
Dieser Handoff löste kurzfristig ein Problem — jemand Erfahrenes beobachtete Produktion — aber er schuf größere Probleme.
Wenn ein separates Ops‑Team die Produktion betreut, erfahren Entwickler:innen Probleme oft spät (oder gar nicht). Ein Bug taucht vielleicht als vage Ticket Tage später auf: „Service ist langsam“ oder „CPU ist hoch“. Dann fehlen Kontexte, Logs sind rotiert und die, die die Änderung gemacht haben, sind weitergezogen.
Handoffs verwischen auch die Verantwortung. Wenn ein Ausfall passiert, denkt Dev vielleicht „Ops fängt das schon auf“, während Ops annimmt „Dev hat etwas Riskantes ausgeliefert“. Das Ergebnis ist vorhersehbar: längere Incident‑Lösungszeiten, wiederkehrende Fehlerbilder und eine Kultur, in der Teams lokal optimieren statt für die Kundenerfahrung.
„You Build It, You Run It“ verkürzt die Schleife. Dasselbe Team, das eine Änderung ausliefert, ist accountable dafür, wie sie sich in Produktion verhält. Das treibt praktische Verbesserungen vor: klarere Alerts, sichere Rollouts, bessere Dashboards und Code, der leichter zu betreiben ist.
Paradoxerweise führt das oft zu schnellerer Lieferung. Wenn Teams dem Release‑Prozess vertrauen und Produktionsverhalten verstehen, können sie kleinere Änderungen häufiger ausliefern — das reduziert den Blast‑Radius von Fehlern und macht Probleme leichter diagnostizierbar.
Nicht jede Organisation startet mit gleicher Personalstärke, Compliance‑Vorgaben oder Legacy‑Systemen. Die Philosophie ist eine Richtung, kein Schalter. Viele Teams führen sie schrittweise ein — mit geteiltem On‑Call, besserer Observability und klareren Servicegrenzen — bevor sie volle End‑to‑End‑Eigentümerschaft übernehmen.
Werner Vogels, CTO von Amazon, popularisierte den Satz „You build it, you run it“, indem er beschrieb, wie Amazon (und später AWS) wollte, dass Teams über Software denken: nicht als Projekt, das man abgibt, sondern als Service, den man betreibt.
Die Schlüsselverschiebung war psychologisch ebenso wichtig wie technisch. Wenn ein Team weiß, dass es für Ausfälle gepaged wird, ändern sich Design‑Entscheidungen. Man achtet auf sinnvolle Defaults, klare Alerts, graceful Degradation und Rückrollpfade. In anderen Worten: Bauen beinhaltet auch das Planen für die unordentlichen Aspekte des Realbetriebs.
Die AWS‑Ära machte Zuverlässigkeit und Geschwindigkeit unverhandelbar. Cloud‑Kunden erwarten APIs rund um die Uhr verfügbar und kontinuierliche Verbesserungen — nicht nur große Releases im Quartal.
Dieser Druck förderte:
Diese Philosophie überschneidet sich mit der DevOps‑Bewegung: die Lücke zwischen Dev und Ops schließen, Handoffs reduzieren und Ergebnisse (Verfügbarkeit, Latenz, Support‑Last) in die Entwicklungs‑Schleife einbeziehen. Sie passt auch zur Idee kleiner autonomer Teams, die unabhängig ausliefern können.
Es ist verlockend, Amazons Vorgehen als Schablone zu übernehmen. Aber „You Build It, You Run It“ ist eher eine Richtung als ein strikter Organisationsplan. Teamgröße, regulatorische Vorgaben, Produktreife und Uptime‑Anforderungen erfordern Anpassungen — geteilte On‑Call‑Rotationen, Plattform‑Support oder stufenweise Einführung.
Wenn du eine praktische Übersetzung der Denkweise in Maßnahmen willst, springe zu /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
„You Build It, You Run It“ ist im Kern eine Aussage über Eigentümerschaft. Wenn dein Team einen Service ausliefert, ist dein Team dafür verantwortlich, wie dieser Service sich in der Realität verhält — nicht nur, ob er am Release‑Tag Tests besteht.
Einen Service zu betreiben bedeutet, sich um End‑to‑End‑Ergebnisse zu kümmern:
In einer normalen Woche geht es beim „Run it“ weniger um Heldentaten und mehr um Routine‑Betrieb:
Dieses Modell funktioniert nur, wenn Verantwortung bedeutet „wir übernehmen die Behebung“, nicht „wir suchen jemanden zum Bestrafen“. Wenn etwas ausfällt, ist das Ziel herauszufinden, was im System das Versagen erlaubt hat — fehlende Alerts, unklare Limits, riskante Deployments — und diese Bedingungen zu verbessern.
Ownership wird kompliziert, wenn Services schwammig sind. Definiere Service‑Grenzen (was der Service macht, wovon er abhängt, was er verspricht) und weise ein namentlich benanntes verantwortliches Team zu. Diese Klarheit reduziert Handoffs, beschleunigt Incident‑Antworten und macht Prioritäten offensichtlich, wenn Zuverlässigkeit und Features konkurrieren.
On‑Call ist zentral für „You Build It, You Run It“, weil es die Feedback‑Schleife schließt. Wenn dasselbe Team, das eine Änderung ausliefert, auch die operativen Auswirkungen spürt (Latenzspitzen, fehlgeschlagene Deploys, Kundenbeschwerden), werden Prioritäten klarer: Zuverlässigkeitsarbeit wird nicht mehr „jemandes anderes Problem“ und der schnellste Weg, mehr auszuliefern, ist oft das System ruhiger zu machen.
Gesundes On‑Call dreht sich vor allem um Planbarkeit und Unterstützung.
Definiere Schweregrade, damit das System nicht wegen jeder Unvollkommenheit page‑t.
Eine einfache Regel: wenn das Wecken niemanden am Ergebnis ändern würde, ist es ein Ticket, kein Page.
On‑Call ist kein Bestrafungsinstrument; es ist ein Signal. Jeder laute Alert, jeder wiederkehrende Fehler oder jede manuelle Reparatur sollte in Engineering‑Arbeit münden: bessere Alerts, Automation, sichere Releases und Systemänderungen, die das Page‑Bedürfnis ganz entfernen.
Wenn „run it“ ernst gemeint ist, brauchen Teams eine gemeinsame Sprache für Zuverlässigkeit, ohne dass jede Diskussion zur Meinungsfrage wird. Genau das liefern SLIs, SLOs und Error Budgets: klare Ziele und faire Trade‑offs zwischen Tempo und Stabilität.
Merksatz: SLI = Messgröße, SLO = Ziel, SLA = externe Verpflichtung.
Gute SLIs sind konkret und am Nutzererlebnis ausgerichtet, z. B.:
Ein Error Budget ist die Menge an „Schlechtigkeit“, die du dir leisten kannst, während du dein SLO noch erfüllst (z. B. bei 99,9 % Verfügbarkeit hast du monatlich 0,1 % Ausfallbudget).
Ist der Service gesund und du bist innerhalb des Budgets, kannst du mehr Liefer‑Risiko eingehen (Features, Experimente). Brennst du das Budget zu schnell, hat Zuverlässigkeitsarbeit Vorrang.
SLOs machen Zuverlässigkeit zu einem Planungsinput. Ist dein Error‑Budget niedrig, könnte der nächste Sprint Rate‑Limiting, sichere Rollouts oder das Beheben flaky Abhängigkeiten priorisieren — denn das Verfehlen des SLO hat klare Kosten. Ist Budget vorhanden, kannst du Produktarbeit mit ruhigerem Gewissen vorantreiben.
„You Build It, You Run It“ funktioniert nur, wenn Deployments zur Produktion Routine sind — kein high‑stakes‑Event. Ziel ist, Unsicherheit vor dem Launch zu reduzieren und den Blast‑Radius danach zu begrenzen.
Bevor ein Service als „ready“ gilt, braucht das Team typischerweise ein paar operative Basics:
Anstatt alles gleichzeitig für alle freizuschalten, begrenzt progressive Delivery die Auswirkungen:
Standardisiere Rollbacks als erstklassige Fähigkeit: je schneller du sicher zurücksetzen kannst, desto realistischer wird „you run it“.
Zwei Tests reduzieren „unknown unknowns":
Halte es leichtgewichtig: eine einseitige Checkliste im Repo oder Ticket‑Template (z. B. „Observability“, „On‑Call‑Bereitschaft“, „Datenschutz“, „Rollback‑Plan“, „Kapazität getestet“, „Runbooks verlinkt"). Mache „not ready“ zum normalen Status — besser als in Produktion zu lernen.
Incidents sind der Moment, in dem „you run it“ real wird: ein Service degradiert, Kund:innen bemerken es und das Team muss schnell und klar reagieren. Ziel sind keine Heldentaten, sondern ein wiederholbarer Ablauf, der Auswirkungen reduziert und Verbesserungen produziert.
Die meisten Teams folgen ähnlichen Phasen:
Willst du eine praktische Vorlage für diesen Ablauf, behalte eine leichte Checkliste griffbereit (siehe /blog/incident-response-checklist).
Ein blameless Postmortem heißt nicht „niemand hat Fehler gemacht“. Es bedeutet, dass du dich auf wie das System und die Prozesse den Fehler in Produktion haben passieren lassen konzentrierst, nicht auf das Beschämen von Personen. Das motiviert frühzeitiges Teilen von Details, was fürs Lernen essentiell ist.
Dokumentiere:
Gute Postmortems enden mit konkreten, verantworteten Nacharbeiten, typischerweise in vier Kategorien: Tooling‑Verbesserungen (bessere Alerts/Dashboards), Tests (Regressionen und Edge‑Cases), Automatisierung (sichere Deploy/Rollback, Guardrails) und Dokumentation (Runbooks, klarere operative Schritte). Weise eine:n Owner und ein Fälligkeitsdatum zu — sonst bleibt Lernen theoretisch.
Tools sind der Hebel, der „You Build It, You Run It“ nachhaltig macht — aber sie können echte Eigentümerschaft nicht ersetzen. Wenn ein Team Operationen als „jemandes anderes Problem“ betrachtet, dokumentiert das schickste Dashboard nur das Chaos. Gute Tools reduzieren Reibung: sie machen das Richtige (beobachten, reagieren, lernen) leichter als das Falsche (raten, beschuldigen, ignorieren).
Mindestens brauchen Service‑Owner eine konsistente Möglichkeit zu sehen, was ihre Software in Produktion macht, und schnell handeln zu können, wenn sie es nicht tut.
Ist deine Monitoring‑Landschaft fragmentiert, verbringen Teams mehr Zeit mit Suchen als mit Beheben. Ein einheitlicher Observability‑Ansatz hilft; siehe /product/observability.
Mit Wachstum wird „Wer besitzt das?“ selbst zum Risiko für Zuverlässigkeit. Ein Service‑Katalog (oder internes Developer‑Portal) löst das, indem Ownership und operative Kontexte an einem Ort stehen: Teamname, On‑Call‑Rotation, Eskalationspfad, Runbooks, Abhängigkeiten und Links zu Dashboards.
Wichtig ist aktuelles Ownership‑Metadata. Mach es zum Workflow‑Teil: Neue Services dürfen nicht live gehen ohne Owner, und Ownership‑Änderungen werden wie Code‑Änderungen behandelt (reviewed, getrackt).
Die besten Setups schubsen Teams in gesunde Verhaltensweisen: Runbook‑Vorlagen, automatisierte Alerts an SLOs gekoppelt und Dashboards, die in Sekunden beantworten „Sind Nutzer betroffen?“. Dennoch zählt das menschliche System — Teams brauchen Zeit, diese Tools zu pflegen, Alerts zu bereinigen und kontinuierlich ihre Betriebsweise zu verbessern.
Plattform‑Teams machen „You Build It, You Run It“ einfacher zu leben. Ihre Aufgabe ist nicht, Produktion für alle zu betreiben, sondern einen gut beleuchteten Weg (paved roads) bereitzustellen, damit Produktteams Services besitzen können, ohne jede Sprint‑Iteration Operations neu erfinden zu müssen.
Eine gute Plattform bietet Defaults, die schwer zu vermasseln und leicht zu übernehmen sind:
Guardrails sollten riskantes Verhalten verhindern, ohne das Ausliefern zu blockieren. Denke „secure by default“ statt „Ticket aufmachen und warten".
Plattform‑Teams können geteilte Dienste betreiben — ohne die Produkt‑Service‑Ownership zu übernehmen.
Die Grenze ist simpel: Das Plattform‑Team besitzt die Verfügbarkeit und den Support der Plattform; Produktteams besitzen, wie ihre Services die Plattform nutzen.
Wenn Teams nicht am ersten Tag Experten in CI/CD, Auth oder Secrets sein müssen, können sie sich auf das Verhalten des Services und den Nutzer‑Impact konzentrieren.
Beispiele, die lästige Arbeit entfernen:
Das Ergebnis ist schnellere Auslieferung mit weniger „custom ops snowflakes“, während das Kernversprechen erhalten bleibt: Das Team, das baut, betreibt den Service.
„You Build It, You Run It“ kann Zuverlässigkeit und Tempo verbessern — aber nur, wenn die Organisation die Rahmenbedingungen für das Team ändert. Viele Scheitern sehen so aus, dass der Slogan übernommen wurde, die unterstützenden Gewohnheiten aber nicht.
Einige Muster tauchen immer wieder auf:
Manche Umgebungen brauchen Anpassungen:
Diese Philosophie scheitert am schnellsten, wenn Zuverlässigkeitsarbeit als „Zusatz“ behandelt wird. Führung muss explizit Kapazität reservieren für:
Ohne diesen Schutz wird On‑Call zur Steuer — statt zur Feedback‑Schleife, die das System verbessert.
Die Einführung funktioniert am besten als gestufte Veränderung, nicht als Unternehmensankündigung. Starte klein, mache Ownership sichtbar und erweitere dann.
Wähle einen einzelnen, gut begrenzten Service (idealerweise mit klaren Nutzern und kontrollierbarem Risiko).
Definiere:
Wichtig: Das Team, das Änderungen ausliefert, owns auch die operativen Outcomes dieses Services.
Bevor du auf mehr Services ausweitest, sorge dafür, dass das Pilotteam ohne Heldentum operieren kann:
Nutze einen kleinen Satz Indikatoren, die zeigen, ob Ownership die Auslieferung und Stabilität verbessert:
Wenn du „you build it, you run it" einführst und gleichzeitig schneller ausliefern willst, ist der Flaschenhals oft derselbe: vom Idea → production‑ready Service mit klarer Ownership und sicherer Rollback‑Story zu kommen.
Koder.ai ist eine Vibe‑Coding‑Plattform, die Teams hilft, Web-, Backend‑ und Mobile‑Apps über eine Chat‑Schnittstelle zu bauen (React fürs Web, Go + PostgreSQL fürs Backend, Flutter für Mobile). Für Teams, die Service‑Ownership anstreben, passen einige Features gut zum Betriebsmodell:
Wähle diese Woche deinen Pilot‑Service und plane ein 60‑minütiges Kickoff, um das erste SLO, die On‑Call‑Rotation und Runbook‑Owner zu setzen. Wenn du Tools zur Unterstützung evaluierst (Deployment, Rollback und Workflows rund um Ownership), sieh dir /pricing für Koder.ai‑Pläne an — Free, Pro, Business und Enterprise — plus Hosting‑, Deployment‑ und Custom‑Domain‑Optionen.
Das bedeutet, dass das Team, das einen Service entwirft, baut und deployed, auch danach die Verantwortung trägt: Monitoring, On‑Call‑Antwort, Nachbearbeitung von Incidents und Arbeit an der Zuverlässigkeit.
Es ist ein Verantwortungsmodell (klare Eigentümerschaft), nicht nur eine Werkzeugwahl oder eine Änderung von Jobtiteln.
Es heißt nicht, dass jeder Entwickler ein Vollzeit‑Infrastruktur‑Experte werden muss.
Es bedeutet:
Wenn ein separates Ops‑Team die Produktion betreibt, kommt Feedback verzögert und Verantwortung wird unscharf: Entwickler merken Produktionsprobleme oft spät, und Ops hat nicht immer den Kontext zu Änderungen.
End‑to‑end‑Eigentümerschaft verbessert typischerweise:
„Run it“ umfasst meist:
Beginne mit menschenfreundlichen Vorgaben:
Ein gutes On‑Call‑System zielt darauf ab, nächsten Monat weniger Pages zu haben — nicht Heroismus zu normalisieren.
Eine einfache Regel: wenn das Wecken niemanden am Ergebnis ändern würde, dann ist es ein Ticket, kein Page.
Praktisch:
Sie schaffen messbare Zuverlässigkeitsziele:
Wenn das Budget schnell verbraucht wird, priorisiere Zuverlässigkeitsarbeit; ist es gesund, kann mehr Liefer‑Risiko eingegangen werden.
Adoptiere Release‑Praktiken, die Unsicherheit und Blast‑Radius reduzieren:
Führe Incidents mit einem wiederholbaren Ablauf durch:
Schreibe dann blameless Postmortems, die sich auf System‑ und Prozesslücken konzentrieren, mit Follow‑ups, die:
Eine leichte Checkliste wie /blog/incident-response-checklist hilft, den Ablauf zu standardisieren.
Eine Plattform sollte paved roads anbieten (Templates, CI/CD, Guardrails, geteilte Dienste), während Produktteams weiterhin die Ergebnisse ihrer Services verantworten.
Praktisch: