Werner Vogels’ “You Build It, You Run It” uitgelegd

Wat “You Build It, You Run It” eigenlijk betekent

“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.

Het kernidee: leveren en bedienen is één baan

In de praktijk betekent dit dat hetzelfde productteam dat features ontwerpt en code schrijft ook:

• de dienst in productie monitort
• reageert als deze faalt
• de betrouwbaarheid in de loop van de tijd verbetert
• afwegingen maakt tussen nieuw werk en operationeel werk

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.

Een praktisch operationeel model, geen slogan

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 wie het bedoeld is

• Product-/serviceteams: om echt end-to-end eigenaarschap en snellere leercycli te creëren.
• Engineering managers: om duidelijke grenzen te stellen (“dit team is eigenaar van deze service”) en capaciteit voor operationeel werk te plannen.
• Platformteams: om eigenaarschap makkelijker te maken door paved roads te bieden — zonder stiekem de productverantwoordelijkheid van de teams over te nemen.

Waarom deze filosofie veranderde hoe teams software uitrollen

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.

Het overdrachtsprobleem: trage feedback en vage verantwoordelijkheid

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.

Waarom eigenaarschap levering versnelt en herhaling reduceert

“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.

Het is geen one-size-fits-all

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.

Waar het vandaan kwam: Werner Vogels en de servicemindset

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.

Waarom het cloudtijdperk de lat hoger legde

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:

• Kleinere, langlevende services met duidelijke eigenaren
• Snelle feedbackloops tussen codewijzigingen en productiegedrag
• Operationele gewoonten die als productfeatures behandeld worden (monitoring, capaciteitsplanning, runbooks)

Gerelateerde ideeën

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.

Inspiratie, geen kant-en-klare blauwdruk

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.

Eigenaarschap: wat teams op zich nemen als ze “run it” doen

“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.

Waar ‘eigenaarschap’ over gaat

Het runnen van een service betekent zorgen voor end-to-end uitkomsten:

• Betrouwbaarheid: gebruikers kunnen erop rekenen en fouten worden snel afgehandeld.
• Prestaties: het blijft snel genoeg onder normale en piekbelasting.
• Kosten: het wordt niet stilletjes het duurste budgetitem.
• Beveiliging & compliance: risico’s worden tijdens levering aangepakt, niet achteraf.
• Support: klanten en interne gebruikers krijgen duidelijke, tijdige hulp.

Wat “run it” in de praktijk inhoudt

In een normale week gaat “run it” minder over heldendaden en meer over routine-operaties:

• Het opzetten van monitoring en dashboards zodat het team de gezondheid in één oogopslag ziet.
• Het definiëren van alerts die actiegericht zijn (niet luidruchtig) en gekoppeld aan gebruikersimpact.
• Het afhandelen van incidenten: triage, mitigatie, communicatie en opvolgwerk.
• Het beheren van capaciteit: schaalplannen, loadtesting en resource-limieten.
• Het bijhouden van runbooks zodat iedereen on-call consistent kan reageren.

Aansprakelijkheid is geen schuld geven

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.

Duidelijke grenzen en een benoemde eigenaar

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 goed doen (zonder mensen op te branden)

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.

Maak on-call menselijk door ontwerp

Gezond on-call gaat vooral over voorspelbaarheid en ondersteuning.

• Rotaties die passen bij de teamgrootte: vermijd heroïsche schema’s. Is de dekking mager, verklein de scope (minder services per rotatie) of voeg een gedeelde secondary toe.
• Escalatiepaden: primary responder, dan secondary, dan een domeinexpert — zodat niemand alleen vastzit om 3 uur 's nachts.
• Hersteltijd na zware nachten: comp-tijd of later beginnen na pages, en tijd vrij na grote incidenten. Rust is onderdeel van betrouwbaarheid.
• Runbooks en “eerste 15 minuten”-checklists: responders moeten een duidelijk stappenplan hebben, geen giswerk.

Severity-niveaus: page alleen als het ertoe doet

Definieer severity-niveaus zodat het systeem niet voor elke imperfectie paged.

• Sev 1 (page): klant-impactende uitval, dataverliesrisico, beveiligingsincident of harde SLO-overschrijding.
• Sev 2 (page tijdens kantoortijd of page als het aanhoudt): gedegradeerde service met reële gebruikersimpact.
• Sev 3 (ticket): niet-dringende bugs, flakkerende alerts, kleine stijgingen in foutpercentages, capaciteitsmetingen.

Een eenvoudige regel: als iemand wakker maken de uitkomst niet verandert, is het een ticket, geen page.

Het echte doel: volgende maand minder pages

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.

SLO's, SLI's en error budgets: praktische vangrails

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.

SLI vs SLO vs SLA (in gewone taal)

• SLI (Service Level Indicator): een meting van hoe de service zich gedraagt. Denk: “Wat zien we echt in productie?”
• SLO (Service Level Objective): een doel voor een SLI. Denk: “Naar welk betrouwbaarheidsniveau streven we?”
• SLA (Service Level Agreement): een belofte aan klanten, vaak met boetes of credits. Denk: “Wat garanderen we contractueel.”

Handige geheugenregel: SLI = metric, SLO = doel, SLA = externe afspraak.

Voorbeelden van SLIs die je kunt meten

Goede SLIs zijn specifiek en gekoppeld aan gebruikerservaring, zoals:

• Latentie: “95% van de verzoeken voltooit in minder dan 300 ms.”
• Beschikbaarheid: “Verzoeken slagen (geen 5xx) 99,9% van de tijd.”
• Jobsuccesratio (voor async systemen): “99,5% van nachtelijke exports voltooit succesvol voor 06:00.”

Error budgets: hoe snelheid en stabiliteit in balans blijven

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.

Hoe SLO's planning sturen

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.”

Veilig uitrollen: productie-klaarheid en releasepraktijken

“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.

Must-haves voordat je lanceert

Voordat een service als “klaar” wordt beschouwd, hebben teams meestal een paar operationele basics op orde:

• Dashboards die zicht geven op gebruikersgerichte gezondheid (latentie, foutpercentages, verkeer) en belangrijke afhankelijkheden.
• Alerts die actiegericht zijn (duidelijke drempels, duidelijke eigenaar, geen luidruchtige “FYI”-pages).
• Runbooks voor veelvoorkomende fouten: wat eerst te controleren, hoe te mitigeren en wanneer te escaleren.
• Backups en restore-drills (de drill is net zo belangrijk als de backup) plus een gedocumenteerd retentiebeleid.

Progressieve levering: in kleinere, veiligere stappen uitrollen

In plaats van alles tegelijk voor iedereen uit te rollen, beperkt progressive delivery de impact:

• Feature flags laten je code uitrollen en de blootstelling beheersen, met een duidelijk plan voor opruimen.
• Canary-releases sturen een klein percentage verkeer naar de nieuwe versie en vergelijken metrics met de baseline.
• Snelle rollbacks (of roll-forwards) zijn geoefend en geautomatiseerd zodat herstel geen geïmproviseerde actie wordt.

Als je rollback standaardiseert, behandel het als een first-class capability: hoe sneller je veilig kunt terugdraaien, hoe realistischer “you run it” wordt.

Vertrouwen opbouwen met load- en fouttests

Twee tests verminderen onbekende risico's:

• Load testing valideert capaciteitsaanames en onthult bottlenecks voordat klanten dat doen.
• Failure testing (bijv. timeouts van afhankelijkheden, gedode instanties, weggevallen verbindingen) controleert of de service gracieus degradeert en of alerts afgaan zoals verwacht.

Een eenvoudige productie-klaar checklist

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 en postmortems: van uitval naar leren

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.

Een eenvoudige incidentworkflow

De meeste teams komen uit op dezelfde fasen:

• Detecteren: monitoring alerts, klantmeldingen of geautomatiseerde anomaliedetectie.
• Triage: bevestig wat kapot is, schat severity, wijs een incidentlead toe en start een tijdlijn.
• Mitigeren: stop het bloeden (rollback, feature flag uit, schaal omhoog, blokkeer kwaad verkeer), herstel vervolgens de volledige service.
• Communiceren: houd updates consistent — wat is geraakt, huidige status en volgende update-tijd.
• Leren: nadat de service stabiel is, analyseer bijdragende factoren en voorkom herhaling.

Als je een praktisch sjabloon wilt voor deze flow, houd een lichtgewicht checklist bij zoals /blog/incident-response-checklist.

Blameless postmortems (en wat je noteert)

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:

• Klantimpact: wie werd geraakt, hoe lang en hoe ernstig.
• Tijdlijn: sleutelgebeurtenissen, beslissingen en wanneer signalen verschenen.
• Root en bijdragende oorzaken: technische en procesfactoren (bijv. onduidelijk eigenaarschap, ontbrekende alerts).
• Wat goed ging / wat niet: inclusief communicatie.

Actiepunten die echt herhaling voorkomen

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.

Tools die service-eigenaarschap makkelijker maken

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).

De minimalen die elk team nodig heeft

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.

• Gecentraliseerde logs: doorzoekbaar, lang genoeg bewaard om incidenten te onderzoeken, en waar mogelijk gestructureerd.
• Metrics: golden signals (latency, traffic, errors, saturation) plus businesskritische metrics.
• Distributed traces: om een request over services te volgen en knelpunten te vinden.
• Alerting: actiegerichte alerts gekoppeld aan klantimpact, niet luidruchtige symptomen.
• Ticketing / incidentworkflow: een plek om werk te volgen, incidenten aan opvolging te koppelen en fixes te laten uitrollen.

Als je monitoringverhaal gefragmenteerd is, besteden teams meer tijd aan zoeken dan aan oplossen. Een eendrachtige observability-aanpak helpt; zie /product/observability.

Eigenaarschap zichtbaar maken op schaal

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).

Tools moeten gewoonten versterken

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.

De rol van platformteams: ondersteuning zonder eigendom weg te nemen

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.

Paved roads, sjablonen, guardrails

Een goed platform biedt defaults die moeilijk verkeerd te doen en makkelijk toe te passen zijn:

• Golden-path-sjablonen voor nieuwe services (repo-structuur, logging, alerts, dashboards)
• Standaard CI/CD-pijplijnen met veilige deploymentopties (canary, blue/green, automatische rollback)
• Productieklaar runtime basics (health checks, rate limits, configconventies)

Guardrails moeten risicovol gedrag tegengaan zonder uit te sluiten. Denk “secure by default” in plaats van “open een ticket en wacht.”

Gedeelde services vs. gedeeld eigenaarschap

Platformteams kunnen gedeelde services runnen — zonder het eigenaarschap van productservices over te nemen.

• Gedeelde services: authenticatie/autorisatie, secrets management, containerplatform, artifact registry, observability-stack.
• Producteigenaarschap: elk team blijft verantwoordelijk voor de betrouwbaarheid, prestaties, dataintegriteit en on-call van hun services.

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.

Hoe platforms cognitieve last verminderen

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:

• One-click pipeline-setup met consistente testgates
• Centrale auth die service-to-service identiteit ondersteunt
• Beheerde secrets met rotatiebeleid
• Basismonitoring die common metrics automatisch instrumenteert

Het resultaat is snellere levering met minder “custom ops snowflakes”, terwijl de kernbelofte blijft: het team dat bouwt, runt de service.