29 sep 2025·7 min
Werner Vogels’ “You Build It, You Run It” uitgelegd
Leer wat Werner Vogels bedoelde met “You Build It, You Run It” en hoe je het toepast: eigenaarschap, on-call, SLO's, incidentrespons en veiliger uitrollen.
Leer wat Werner Vogels bedoelde met “You Build It, You Run It” en hoe je het toepast: eigenaarschap, on-call, SLO's, incidentrespons en veiliger uitrollen.
“You build it, you run it” is één van die zinnen die blijft hangen omdat hij kort en krachtig is. Het gaat niet om motivatieposters of “meer DevOps worden.” Het is een duidelijke verklaring over verantwoordelijkheid: het team dat een service oplevert, blijft ook aanspreekbaar voor hoe die service zich in productie gedraagt.
In de praktijk betekent dit dat hetzelfde productteam dat features ontwerpt en code schrijft ook:
Het betekent niet dat iedereen opeens infrastructuurexpert wordt. Het betekent dat de feedbackloop echt is: als je iets uitrolt dat meer uitval, pager-geluid of klantpijn veroorzaakt, voelt je team dat direct — en leert het snel.
Deze filosofie is makkelijk te herhalen en moeilijk te implementeren tenzij je het als een operationeel model met expliciete verwachtingen behandelt. “Run it” omvat meestal on-call (in enige vorm), het dragen van incidentverantwoordelijkheid, het schrijven van runbooks, het onderhouden van dashboards en continu verbeteren van de service.
Het impliceert ook randvoorwaarden: je kunt teams niet vragen “het te runnen” zonder ze de tools, toegang en bevoegdheid te geven om problemen te verhelpen — plus tijd in hun roadmap om dat werk te doen.
Voor “You Build It, You Run It” organiseerden veel bedrijven softwarewerk als een estafette: ontwikkelaars schreven code en ‘gooiden het over de schutting’ naar een operations-team om te deployen en draaiende te houden.
Die overdracht loste een kortetermijnprobleem op — iemand met ervaring hield productie in de gaten — maar veroorzaakte grotere problemen.
Wanneer een afzonderlijk ops-team productie bezit, leren ontwikkelaars vaak laat (of nooit) over problemen. Een bug kan als een vaag ticket dagen later opduiken: “service is traag” of “CPU is hoog.” Tegen die tijd ontbreken context, logs zijn geroteerd en de mensen die de wijziging maakten zijn verder gegaan.
Overdrachten vervagen ook eigenaarschap. Als er een uitval is, denkt dev misschien “ops lost het op,” terwijl ops denkt “dev heeft iets risicovol uitgerold.” Het resultaat is voorspelbaar: langere incidentresoluties, terugkerende faalmodi en een cultuur waarin teams lokaal optimaliseren in plaats van voor de klantbeleving.
“You Build It, You Run It” verkort de lus. Hetzelfde team dat een wijziging oplevert, is verantwoordelijk voor hoe het zich in productie gedraagt. Dat duwt praktische verbeteringen naar upstream: duidelijkere alerts, veiligere rollouts, betere dashboards en code die makkelijker te bedienen is.
Paradoxaal genoeg leidt het vaak tot snellere levering. Als teams hun releaseproces vertrouwen en productiegedrag begrijpen, kunnen ze kleinere wijzigingen sneller uitrollen — waardoor de blast radius van fouten kleiner wordt en problemen eenvoudiger te diagnosticeren zijn.
Niet elke organisatie start met gelijke bezetting, compliance-eisen of legacy-systemen. De filosofie is een richting, geen schakelaar. Veel teams adopteren het geleidelijk — te beginnen met gedeeld on-call, betere observability en duidelijkere servicegrenzen — voordat ze volledig end-to-end eigenaarschap nemen.
Werner Vogels, CTO van Amazon, populariseerde de uitspraak “You build it, you run it” terwijl hij beschreef hoe Amazon (en later AWS) wilde dat teams over software zouden denken: niet als een project dat je overdraagt, maar als een service die je bedient.
De sleutelverschuiving was net zo psychologisch als technisch. Als een team weet dat het gepaged wordt bij fouten, veranderen ontwerpbeslissingen. Je geeft om verstandige defaults, heldere alerting, graceful degradation en deploypaden die je kunt terugdraaien. Met andere woorden: bouwen omvat ook plannen voor de rommeligheid van het echte leven.
Het AWS-tijdperk maakte betrouwbaarheid en snelheid ononderhandelbaar. Cloudklanten verwachten dat API’s 24/7 beschikbaar zijn en dat verbeteringen continu komen — niet in kwartaal-oude grote releases.
Die druk stimuleerde:
Deze filosofie overlapt met de bredere DevOps-beweging: verklein de kloof tussen dev en ops, minimaliseer overdrachten en maak uitkomsten (beschikbaarheid, latency, support load) onderdeel van de ontwikkellus. Het past ook bij het idee van kleine autonome teams die onafhankelijk kunnen uitrollen.
Het is verleidelijk Amazon’s aanpak als sjabloon te kopiëren. Maar “You Build It, You Run It” is meer een richting dan een strikt organisatiemodel. Teamgrootte, regelgeving, productrijpheid en uptime-eisen kunnen aanpassingen vereisen — gedeelde on-call rotaties, platformondersteuning of gefaseerde adoptie.
Als je een praktische vertaling van de mindset wilt, spring naar /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
“You Build It, You Run It” is eigenlijk een uitspraak over eigenaarschap. Als jouw team een service oplevert, is jouw team verantwoordelijk voor hoe die service zich in de echte wereld gedraagt — niet alleen of hij tests haalt op de dag van release.
Het runnen van een service betekent zorgen voor end-to-end uitkomsten:
In een normale week gaat “run it” minder over heldendaden en meer over routine-operaties:
Dit model werkt alleen wanneer aansprakelijkheid betekent “wij lossen het op,” niet “we zoeken een zondebok.” Als iets faalt, is het doel te begrijpen wat in het systeem het mogelijk maakte — ontbrekende alerts, onduidelijke limieten, risicovolle deploys — en die voorwaarden te verbeteren.
Eigenaarschap wordt rommelig wanneer services vaag zijn. Definieer servicegrenzen (wat het doet, waar het van afhankelijk is, wat het belooft) en wijs een genoemd eigenaarsteam toe. Die duidelijkheid vermindert overdrachten, versnelt incidentrespons en maakt prioriteiten inzichtelijk wanneer betrouwbaarheid en features concurreren.
On-call is centraal voor “You Build It, You Run It” omdat het de feedbackloop sluit. Als hetzelfde team dat een wijziging oplevert ook de operationele impact voelt (latentiespieken, mislukte deploys, klantklachten), worden prioriteiten duidelijker: betrouwbaarheidswerk wordt geen “probleem van iemand anders” en de snelste manier om meer te kunnen uitrollen is vaak het systeem rustiger maken.
Gezond on-call gaat vooral over voorspelbaarheid en ondersteuning.
Definieer severity-niveaus zodat het systeem niet voor elke imperfectie paged.
Een eenvoudige regel: als iemand wakker maken de uitkomst niet verandert, is het een ticket, geen page.
On-call is geen straf; het is een signaal. Elke luidruchtige alert, herhaald falen of handmatige fix moet terugvloeien naar engineering-werk: betere alerts, automatisering, veiligere releases en systeemwijzigingen die de noodzaak om te paged wegnemen.
Als “you run it” echt is, hebben teams een gedeelde manier nodig om over betrouwbaarheid te praten zonder dat elk gesprek een meningsverschil wordt. Dat bieden SLIs, SLOs en error budgets: duidelijke doelen en een eerlijke afweging tussen snelheid en stabiliteit.
Handige geheugenregel: SLI = metric, SLO = doel, SLA = externe afspraak.
Goede SLIs zijn specifiek en gekoppeld aan gebruikerservaring, zoals:
Een error budget is de hoeveelheid ‘slechtheid’ die je kunt veroorloven terwijl je nog steeds je SLO haalt (bijv. bij 99,9% beschikbaarheid is het maandelijkse error budget 0,1% downtime).
Als de service gezond is en je binnen het budget zit, kunnen teams meer delivery-risico nemen (features, experimenten). Als je het budget te snel verbrandt, krijgt betrouwbaarheidswerk prioriteit.
SLO's maken betrouwbaarheid tot een planningsinput. Als je error budget laag is, kan de volgende sprint prioriteit geven aan rate limiting, veiligere rollouts of het fixen van flakkerende afhankelijkheden — omdat het missen van het SLO een duidelijke kostenpost heeft. Is het budget ruim, dan kun je productwerk met vertrouwen prioriteren zonder te gissen of “ops het wel oplost.”
“You build it, you run it” werkt alleen als uitrollen naar productie routine is — geen risicovolle gebeurtenis. Het doel is onzekerheid voor de lancering te verminderen en de blast radius erna te beperken.
Voordat een service als “klaar” wordt beschouwd, hebben teams meestal een paar operationele basics op orde:
In plaats van alles tegelijk voor iedereen uit te rollen, beperkt progressive delivery de impact:
Als je rollback standaardiseert, behandel het als een first-class capability: hoe sneller je veilig kunt terugdraaien, hoe realistischer “you run it” wordt.
Twee tests verminderen onbekende risico's:
Houd het lichtgewicht: een pagina checklist in je repo of tickettemplate (bijv. “Observability,” “On-call readiness,” “Data protection,” “Rollback plan,” “Capacity tested,” “Runbooks linked”). Maak “niet klaar” een normale status — veel beter dan leren in productie.
Incidenten zijn waar “you run it” echt wordt: een service degradeert, klanten merken het en het team moet snel en helder reageren. Het doel is geen heroïek — het is een herhaalbare workflow die impact vermindert en verbeteringen oplevert.
De meeste teams komen uit op dezelfde fasen:
Als je een praktisch sjabloon wilt voor deze flow, houd een lichtgewicht checklist bij zoals /blog/incident-response-checklist.
Een blameless postmortem betekent niet “niemand maakte fouten.” Het betekent dat je je richt op hoe het systeem en proces het mogelijk maakten dat de fout in productie kwam, niet op het beschamen van individuen. Dat moedigt vroege en volledige informatiedeling aan, wat essentieel is voor leren.
Documenteer:
Goede postmortems eindigen met concrete, toegewezen opvolgacties, gewoonlijk in vier categorieën: toolingverbeteringen (betere alerts/dashboards), tests (regressies en edge-cases), automatisering (veiliger deploy/rollback, guardrails) en documentatie (runbooks, duidelijkere operationele stappen). Wijs een eigenaar en een due date toe — anders blijft leren theoretisch.
Tooling is hefboomwerk dat “You Build It, You Run It” duurzaam maakt — maar het kan eigenaarschap niet vervangen. Als een team operations als “iemand anders’ probleem” behandelt, documenteert het mooiste dashboard alleen de chaos. Goede tools verminderen wrijving: ze maken het juiste (observeren, reageren, leren) makkelijker dan het foute (raden, beschuldigen, negeren).
Minimaal hebben service-eigenaren een consistente manier nodig om te zien wat hun software in productie doet en snel te handelen als dat niet goed gaat.
Als je monitoringverhaal gefragmenteerd is, besteden teams meer tijd aan zoeken dan aan oplossen. Een eendrachtige observability-aanpak helpt; zie /product/observability.
Als organisaties groeien, wordt “wie is eigenaar?” een betrouwbaarheidsrisico. Een servicecatalogus (of intern developer-portal) lost dit op door eigenaarschap en operationele context op één plek te houden: teamnaam, on-call rotatie, escalatiepad, runbooks, afhankelijkheden en links naar dashboards.
De sleutel is eigenschapsmetadata die actueel blijft. Maak het onderdeel van de workflow: nieuwe services mogen niet live zonder een eigenaar, en wijzigingen in eigenaarschap worden behandeld als codewijzigingen (reviewed, getracked).
De beste setups sturen teams naar gezond gedrag: sjablonen voor runbooks, geautomatiseerde alerts gekoppeld aan SLOs en dashboards die in seconden het antwoord geven op “Zijn gebruikers getroffen?”. Maar het menselijke systeem blijft belangrijk — teams hebben tijd nodig om deze tools te onderhouden, alerts te snoeien en continu te verbeteren hoe ze de service bedienen.
Platformteams maken “You Build It, You Run It” makkelijker vol te houden. Hun taak is niet om productie voor iedereen te runnen — het is om een goed verlichte route te bieden (paved roads) zodat productteams services kunnen beheren zonder elke sprint operations opnieuw uit te vinden.
Een goed platform biedt defaults die moeilijk verkeerd te doen en makkelijk toe te passen zijn:
Guardrails moeten risicovol gedrag tegengaan zonder uit te sluiten. Denk “secure by default” in plaats van “open een ticket en wacht.”
Platformteams kunnen gedeelde services runnen — zonder het eigenaarschap van productservices over te nemen.
De grens is simpel: het platformteam is eigenaar van de uptime en support van het platform; productteams zijn eigenaar van hoe hun services het platform gebruiken.
Als teams niet op dag één expert hoeven te zijn in CI/CD, auth of secrets, kunnen ze zich richten op gedrag van de service en gebruikersimpact.
Voorbeelden die werklast wegnemen:
Het resultaat is snellere levering met minder “custom ops snowflakes”, terwijl de kernbelofte blijft: het team dat bouwt, runt de service.
Het betekent dat het team dat een service ontwerpt, bouwt en uitrolt ook verantwoordelijk is voor wat er gebeurt nadat die service live staat: monitoring, on-call reacties, opvolging van incidenten en verbeteringen aan betrouwbaarheid.
Het is een model voor verantwoordelijkheid (duidelijk eigenaarschap), geen keuze voor een bepaald hulpmiddel of een wijziging in functietitels.
Het betekent niet dat elke engineer een fulltime infrastructuurspecialist moet worden.
Het betekent wel:
Als een apart ops-team productie beheert, komt feedback vaak te laat en wordt verantwoordelijkheid vaag: ontwikkelaars voelen de productiepijn niet, en ops mist context over recente wijzigingen.
End-to-end eigenaarschap verbetert doorgaans:
“Run it” omvat meestal:
Begin met humane standaarden:
Een goed on-call-systeem streeft ernaar minder meldingen volgende maand, niet naar het normaliseren van heldendaden.
Gebruik een eenvoudige regel: als iemand wakker maken de uitkomst niet verandert, maak er dan een ticket van.
Praktisch:
Ze creëren gedeelde, meetbare betrouwbaarheidstargets:
Als het budget snel opraakt, geef prioriteit aan betrouwbaarheid; is het gezond, dan kun je meer delivery-risico nemen.
Pas releasepraktijken toe die onzekerheid en blast radius verkleinen:
Voer incidenten volgens een herhaalbare workflow uit:
Schrijf daarna blameless postmortems gericht op systeem- en procesfouten, met opvolgacties die:
Een eenvoudige checklist zoals /blog/incident-response-checklist kan helpen de workflow te standaardiseren.
Een platformteam moet paved roads bieden (templates, CI/CD, guardrails, gedeelde services) terwijl productteams het eigenaarschap van hun services behouden.
Een praktische scheiding: