29 set 2025·8 min
“You Build It, You Run It” di Werner Vogels spiegato
Scopri cosa intendeva Werner Vogels con “You Build It, You Run It” e come applicarlo: ownership, on-call, SLO, risposta agli incidenti e rilasci più sicuri.
Scopri cosa intendeva Werner Vogels con “You Build It, You Run It” e come applicarlo: ownership, on-call, SLO, risposta agli incidenti e rilasci più sicuri.
“You build it, you run it” è una di quelle frasi che restano perché è diretta. Non riguarda poster motivazionali o “essere più DevOps”. È una dichiarazione chiara di responsabilità: il team che distribuisce un servizio è anche responsabile di come quel servizio si comporta in produzione.
In pratica, significa che lo stesso team di prodotto che progetta le funzionalità e scrive il codice inoltre:
Non vuol dire che tutti diventino esperti di infrastruttura da un giorno all'altro. Vuol dire che il ciclo di feedback è reale: se rilasci qualcosa che aumenta outage, rumore dei pager o disagio per i clienti, il tuo team lo sente direttamente—e impara in fretta.
Questa filosofia è facile da ripetere e difficile da implementare a meno che non la tratti come un modello operativo con aspettative esplicite. “Run it” tipicamente include essere on-call (in qualche forma), gestire la risposta agli incidenti, scrivere runbook, mantenere dashboard e migliorare continuamente il servizio.
Implica anche vincoli: non puoi chiedere ai team di “gestirlo” senza fornire strumenti, accessi e autorità per correggere i problemi—oltre al tempo nel loro roadmap per fare quel lavoro.
Prima di “You Build It, You Run It”, molte aziende organizzavano il lavoro software come una staffetta: gli sviluppatori scrivevano codice, poi lo “lanciavano oltre il muro” a un team ops che lo distribuiva e lo teneva in esecuzione.
Quel passaggio risolveva un problema a breve termine—qualcuno esperto guardava la produzione—ma creava problemi più grandi.
Quando un team ops separato possiede la produzione, gli sviluppatori spesso scoprono i problemi tardi (o mai). Un bug può emergere come un ticket vago giorni dopo: “servizio lento” o “CPU alta”. A quel punto il contesto è perso, i log sono ruotati e chi ha fatto la modifica è passato oltre.
I passaggi sfumano anche la proprietà. Se capita un outage, dev può pensare “ops lo prenderà in carico”, mentre ops pensa “dev ha rilasciato qualcosa di rischioso”. Il risultato è prevedibile: risoluzioni di incidenti più lunghe, modalità di falla ripetute e una cultura in cui i team ottimizzano localmente invece che per l'esperienza utente.
“You Build It, You Run It” accorcia il ciclo. Lo stesso team che rilascia una modifica è responsabile di come si comporta in produzione. Questo spinge miglioramenti pratici a monte: alert più chiari, rollout più sicuri, dashboard migliori e codice più semplice da gestire.
Paradossalmente, spesso porta a consegne più veloci. Quando i team si fidano del processo di rilascio e comprendono il comportamento in produzione, possono spedire cambiamenti più piccoli più frequentemente—riducendo il raggio d'azione degli errori e rendendo i problemi più facili da diagnosticare.
Non tutte le organizzazioni partono con personale uguale, requisiti di conformità o sistemi legacy. La filosofia è una direzione, non un interruttore. Molti team la adottano gradualmente—partendo da on-call condiviso, osservabilità migliore e confini di servizio più chiari—prima di arrivare alla piena proprietà end-to-end.
Werner Vogels, CTO di Amazon, ha reso popolare la frase “You build it, you run it” descrivendo come Amazon (e poi AWS) voleva che i team pensassero al software: non come un progetto da consegnare, ma come a un servizio da gestire.
Lo spostamento chiave fu tanto psicologico quanto tecnico. Quando un team sa che verrà contattato per i guasti, le decisioni di design cambiano. Ci si preoccupa di default sensati, alert chiari, degradazione elegante e percorsi di deploy che si possono ripristinare. In altre parole, costruire include pianificare le parti disordinate della vita reale.
Il pensiero dei servizi nell'era AWS ha reso affidabilità e velocità non negoziabili. I clienti cloud si aspettano API disponibili 24/7 e miglioramenti continui—non solo grandi rilasci trimestrali.
Quella pressione ha incoraggiato:
Questa filosofia si sovrappone al movimento più ampio DevOps: ridurre il divario tra “dev” e “ops”, diminuire i passaggi e rendere gli esiti (disponibilità, latenza, carico di supporto) parte del ciclo di sviluppo. Si integra anche con l'idea di piccoli team autonomi che possono rilasciare indipendentemente.
È allettante considerare l'approccio di Amazon come un modello da copiare. Ma “You Build It, You Run It” è più una direzione che un organigramma rigido. Dimensione del team, vincoli normativi, maturità del prodotto e requisiti di uptime possono richiedere adattamenti—rotazioni on-call condivise, supporto della piattaforma o adozione graduale.
Se vuoi un modo pratico per tradurre la mentalità in azione, vai a blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
“You Build It, You Run It” è in realtà una dichiarazione sulla proprietà. Se il tuo team rilascia un servizio, il tuo team è responsabile di come quel servizio si comporta nel mondo reale—non solo se supera i test il giorno del rilascio.
Gestire un servizio significa curarsi degli esiti end-to-end:
In una settimana normale, “run it” riguarda meno gli eroi e più le operazioni di routine:
Questo modello funziona solo quando responsabilità significa “noi risolviamo il problema”, non “cerchiamo qualcuno da punire”. Quando qualcosa si rompe, l'obiettivo è capire cosa nel sistema ha permesso l'errore—alert mancanti, limiti poco chiari, deploy rischiosi—e migliorare quelle condizioni.
La proprietà diventa caotica quando i servizi sono sfumati. Definisci confini del servizio (cosa fa, da cosa dipende, cosa promette) e assegna un team proprietario nominato. Questa chiarezza riduce i passaggi, accelera la risposta agli incidenti e rende le priorità evidenti quando affidabilità e funzionalità competono.
L'on-call è centrale in “You Build It, You Run It” perché chiude il ciclo di feedback. Quando lo stesso team che rilascia una modifica sente anche l'impatto operativo (picchi di latenza, deploy falliti, lamentele dei clienti), le priorità diventano più chiare: il lavoro di affidabilità smette di essere “problema di qualcun altro” e il modo più rapido per spedire di più è spesso rendere il sistema più stabile.
Un on-call sano riguarda soprattutto prevedibilità e supporto.
Definisci livelli di severità così il sistema non sveglia per ogni imperfezione.
Una regola semplice: se svegliare qualcuno non cambierebbe l'esito, dovrebbe essere un ticket, non una pagina.
L'on-call non è una punizione; è un segnale. Ogni alert rumoroso, ogni fallimento ripetuto o ogni correzione manuale dovrebbe trasformarsi in lavoro di ingegneria: alert migliori, automazione, rilasci più sicuri e cambiamenti che eliminano la necessità di paginare.
Se “lo gestisci” è reale, i team hanno bisogno di un modo condiviso per parlare di affidabilità senza trasformare ogni discussione in opinione. Questo è il ruolo di SLIs, SLOs e error budget: obiettivi chiari e un compromesso equo tra velocità e stabilità.
Un modo utile per ricordare: SLI = metrica, SLO = obiettivo, SLA = impegno esterno.
Buoni SLI sono specifici e legati all'esperienza utente, per esempio:
Un error budget è la quantità di “malfunzionamento” che puoi permetterti rimanendo entro l'SLO (per esempio, se l'SLO è 99.9% di disponibilità, il budget mensile è lo 0.1% di downtime).
Quando il servizio è sano e sei dentro il budget, i team possono prendere più rischi di delivery (rilasciare funzionalità, esperimenti). Quando stai bruciando budget troppo velocemente, il lavoro di affidabilità diventa prioritario.
Gli SLO trasformano l'affidabilità in un input di pianificazione. Se il tuo error budget è basso, lo sprint successivo potrebbe enfatizzare rate limiting, rollout più sicuri o riparare dipendenze fluttuanti—perché mancare l'SLO ha un costo chiaro. Se il budget è abbondante, puoi dare precedenza al lavoro di prodotto senza indovinare se “ops se la caverà”.
“You build it, you run it” funziona solo se distribuire in produzione è routinario—non un evento ad alto rischio. L'obiettivo è ridurre l'incertezza prima del lancio e limitare il blast radius dopo il lancio.
Prima che un servizio sia considerato “ready”, i team in genere hanno bisogno di alcune basi operative:
Invece di rilasciare tutto a tutti in una volta, la progressive delivery limita l'impatto:
Se il tuo team standardizza il rollback, trattalo come una capacità di prima classe: più veloce è il revert sicuro, più realistico diventa “you run it”.
Due test riducono gli “unknown unknowns”:
Tienila leggera: una pagina nel repo o nel template del ticket (es. “Observability,” “On-call readiness,” “Data protection,” “Rollback plan,” “Capacity tested,” “Runbooks linked”). Considera “non pronto” uno stato normale—molto meglio che scoprirlo in produzione.
Gli incidenti sono il luogo in cui “you run it” diventa reale: un servizio degrada, i clienti notano e il team deve rispondere in modo rapido e chiaro. L'obiettivo non è l'eroismo—è un flusso ripetibile che riduce l'impatto e produce miglioramenti.
La maggior parte dei team converge sulle stesse fasi:
Se vuoi un template pratico per questo flusso, tieni a portata di mano una checklist leggera (vedi blog/incident-response-checklist).
Un postmortem senza colpe non significa “nessuno ha sbagliato.” Significa concentrarsi su come il sistema e il processo hanno permesso all'errore di arrivare in produzione, non sul dare la colpa alle persone. Questo incoraggia la condivisione precoce dei dettagli, essenziale per l'apprendimento.
Documenta:
I buoni postmortem finiscono con follow-up concreti, tipicamente in quattro categorie: miglioramenti degli strumenti (alert/dashboard migliori), test (regressioni e casi limite), automazione (deploy/rollback più sicuri, guardrail) e documentazione (runbook, passi operativi più chiari). Assegna un proprietario e una scadenza—altrimenti l'apprendimento resta teorico.
Gli strumenti sono la leva che rende sostenibile “You Build It, You Run It”—ma non possono sostituire la vera proprietà. Se un team tratta le operazioni come “problema di qualcun altro”, anche la dashboard più sofisticata documenterà solo il caos. Buoni strumenti riducono l'attrito: rendono più facile fare la cosa giusta (osservare, rispondere, imparare) rispetto a quella sbagliata (indovinare, incolpare, ignorare).
Al minimo, i proprietari del servizio hanno bisogno di un modo coerente per vedere cosa fa il loro software in produzione e agire rapidamente quando non va.
Se la tua storia di monitoring è frammentata, i team passano più tempo a cercare che a correggere. Un approccio unificato all'osservabilità aiuta; vedi product/observability.
Con la crescita dell'organizzazione, “chi possiede questo?” diventa un rischio per l'affidabilità. Un catalogo dei servizi (o portale sviluppatori interno) risolve questo tenendo ownership e contesto operativo in un unico posto: nome del team, rotazione on-call, percorso di escalation, runbook, dipendenze e link alle dashboard.
La chiave è metadata di ownership che resti aggiornato. Rendilo parte del workflow: i nuovi servizi non possono andare live senza un proprietario e i cambi di ownership sono trattati come cambi di codice (reviewati, tracciati).
Le configurazioni migliori spingono i team verso comportamenti sani: template per runbook, alert automatici legati agli SLO e dashboard che rispondono in pochi secondi alla domanda “gli utenti sono impattati?”. Ma il sistema umano conta ancora—i team hanno bisogno di tempo per mantenere questi strumenti, ripulire gli alert e migliorare continuamente come operano il servizio.
I team di piattaforma rendono più facile vivere con “You Build It, You Run It”. Il loro compito non è gestire la produzione per tutti—è fornire una strada ben illuminata (a volte chiamata “paved roads”) così i team di prodotto possono possedere i servizi senza reinventare le operazioni a ogni sprint.
Una buona piattaforma offre default facili da adottare e difficili da sbagliare:
I guardrail dovrebbero prevenire comportamenti rischiosi senza bloccare il rilascio. Pensare “secure by default” piuttosto che “apri un ticket e aspetta”.
I team di piattaforma possono gestire servizi condivisi—senza però prendersi la proprietà dei servizi di prodotto.
Il confine è semplice: il team di piattaforma possiede l'uptime e il supporto della piattaforma; i team di prodotto possiedono come il loro servizio la usa.
Quando i team non devono diventare esperti di CI/CD, auth o segreti dal primo giorno, possono concentrarsi sul comportamento del servizio e sull'impatto utente.
Esempi che rimuovono lavoro indifferenziato:
Il risultato è consegna più rapida con meno “snowflake ops” personalizzati, mantenendo però la promessa centrale: il team che costruisce il servizio lo gestisce ancora.
“You build it, you run it” può migliorare affidabilità e velocità—ma solo se l'organizzazione cambia le condizioni attorno al team. Molti fallimenti sembrano adottare lo slogan, ma non le abitudini di supporto.
Alcuni schemi ricorrono spesso:
Alcuni contesti richiedono un approccio su misura:
Questa filosofia fallisce più rapidamente quando il lavoro di affidabilità è trattato come “extra.” La leadership deve riservare esplicitamente capacità per:
Senza questa protezione, l'on-call diventa una tassa—invece che un ciclo di feedback che migliora il sistema.
Implementarlo funziona meglio come un cambiamento a fasi, non come un annuncio aziendale. Inizia in piccolo, rendi visibile la proprietà e poi espandi.
Scegli un singolo servizio ben delimitato (idealmente con utenti chiari e rischio gestibile).
Definisci:
La chiave: il team che rilascia le modifiche possiede anche gli esiti operativi di quel servizio.
Prima di estendere ad altri servizi, assicurati che il team pilota possa operare senza eroismi:
Usa un piccolo set di indicatori che mostrino se la proprietà sta migliorando rilascio e stabilità:
Se stai adottando “you build it, you run it” mentre cerchi anche di accelerare la consegna, il collo di bottiglia spesso è lo stesso: passare dall'idea → a un servizio pronto per la produzione con ownership chiara e una storia di rollback sicura.
Koder.ai è una piattaforma vibe-coding che aiuta i team a costruire app web, backend e mobile tramite un'interfaccia chat (React per il web, Go + PostgreSQL per il backend, Flutter per mobile). Per i team che puntano alla proprietà del servizio, alcune funzionalità si allineano chiaramente al modello operativo:
Scegli il tuo servizio pilota questa settimana e programma un kickoff di 60 minuti per definire il primo SLO, la rotazione on-call e i proprietari dei runbook. Se stai valutando strumenti per supportare questo (rilascio, rollback e i workflow attorno alla proprietà), consulta le opzioni di pricing di Koder.ai e i vari piani—free, pro, business ed enterprise—più opzioni come hosting, deployment e domini personalizzati.
Significa che il team che progetta, costruisce e distribuisce un servizio è anche responsabile di cosa succede dopo che è in produzione: monitoraggio, risposte on-call, follow-up degli incidenti e miglioramenti della affidabilità.
È un modello di responsabilità (proprietà chiara), non una scelta di strumenti o un cambiamento di ruoli.
Non significa che ogni ingegnere debba diventare uno specialista infrastrutturale a tempo pieno.
Significa:
Con un team ops separato, il feedback arriva tardi e la responsabilità si offusca: gli sviluppatori potrebbero non percepire il dolore in produzione e gli ops potrebbero non conoscere il contesto delle modifiche recenti.
La proprietà end-to-end di solito migliora:
“Run it” di solito include:
Inizia con scelte umane di base:
Un buon sistema on-call mira a ridurre il numero di pagine il mese prossimo, non a normalizzare gli eroi.
Usa una regola semplice: se svegliare qualcuno non cambierebbe l'esito, crea un ticket invece di una pagina.
Praticamente:
Creano obiettivi condivisi e misurabili:
Quando il budget si consuma velocemente, priorizza il lavoro di affidabilità; quando è sano, puoi prendere più rischi di delivery.
Adotta pratiche di rilascio che riducono incertezza e blast radius:
Gestisci gli incidenti con un flusso ripetibile:
Poi scrivi postmortem senza colpe focalizzati su gap di sistema e processo, con follow-up che siano:
Una checklist leggera come blog/incident-response-checklist può aiutare a standardizzare il flusso.
Il team di piattaforma dovrebbe fornire paved roads (template, CI/CD, guardrail, servizi condivisi come auth e osservabilità) mentre i team di prodotto mantengono la proprietà dei risultati dei loro servizi.
Un confine pratico: