Pelajari apa yang dimaksud Werner Vogels dengan “You Build It, You Run It” dan cara menerapkannya: kepemilikan, on-call, SLO, respons insiden, dan pengiriman yang lebih aman.
“You build it, you run it” adalah salah satu ungkapan yang melekat karena lugas. Ini bukan tentang poster motivasi atau “lebih jadi DevOps.” Ini adalah pernyataan jelas tentang tanggung jawab: tim yang mengirimkan sebuah layanan juga tetap bertanggung jawab atas bagaimana layanan itu berperilaku di produksi.
Dalam praktiknya, ini berarti tim produk yang sama yang merancang fitur dan menulis kode juga:\n
Ini tidak berarti semua orang tiba-tiba menjadi ahli infrastruktur. Maksudnya loop umpan balik menjadi nyata: jika Anda merilis sesuatu yang meningkatkan outage, kebisingan pager, atau rasa sakit pelanggan, tim Anda merasakannya secara langsung—dan belajar dengan cepat.
Filosofi ini mudah diulang dan sulit diimplementasikan kecuali Anda memperlakukannya sebagai model operasi dengan ekspektasi eksplisit. “Run it” biasanya termasuk jadwal on-call (dalam beberapa bentuk), kepemilikan respons insiden, penulisan runbook, pemeliharaan dashboard, dan perbaikan berkelanjutan pada layanan.
Ini juga mengimplikasikan batasan: Anda tidak bisa meminta tim untuk “run it” tanpa memberi mereka alat, akses, dan wewenang untuk memperbaiki masalah—ditambah waktu dalam roadmap mereka untuk melakukan pekerjaan itu.
Sebelum “You Build It, You Run It,” banyak perusahaan mengatur pekerjaan perangkat lunak seperti perlombaan estafet: developer menulis kode, lalu “melemparkannya” ke tim operasi untuk men-deploy dan menjaga agar tetap berjalan.
Handoff itu menyelesaikan masalah jangka pendek—seseorang yang berpengalaman mengawasi produksi—tetapi menciptakan masalah yang lebih besar.
Ketika tim ops terpisah yang memiliki produksi, developer sering mengetahui masalah terlambat (atau tidak sama sekali). Bug mungkin muncul sebagai tiket kabur beberapa hari kemudian: “layanan lambat” atau “CPU tinggi.” Saat itu konteks hilang, log sudah ter-rotasi, dan orang yang membuat perubahan sudah pindah.
Handoff juga membuat kepemilikan kabur. Jika terjadi outage, dev mungkin berasumsi “ops akan menangkapnya,” sementara ops berasumsi “dev merilis sesuatu yang berisiko.” Hasilnya dapat diprediksi: resolusi insiden lebih lama, mode kegagalan berulang, dan budaya di mana tim mengoptimalkan lokal alih-alih untuk pengalaman pelanggan.
“You Build It, You Run It” memperketat loop. Tim yang sama yang merilis perubahan bertanggung jawab atas bagaimana perubahan itu berperilaku di produksi. Itu mendorong perbaikan praktis ke hulu: alert yang lebih jelas, rollout yang lebih aman, dashboard yang lebih baik, dan kode yang lebih mudah dioperasikan.
Paradoksnya, ini sering menghasilkan pengiriman yang lebih cepat. Saat tim percaya pada proses rilis mereka dan memahami perilaku produksi, mereka bisa merilis perubahan lebih kecil lebih sering—mengurangi blast radius kesalahan dan memudahkan diagnosis masalah.
Tidak semua organisasi memulai dengan staf, kepatuhan, atau sistem legacy yang sama. Filosofi ini adalah arah, bukan saklar. Banyak tim mengadopsinya secara bertahap—mulai dari on-call bersama, observabilitas yang lebih baik, dan batas layanan yang jelas—sebelum mengambil kepemilikan end-to-end penuh.
Werner Vogels, CTO Amazon, memopulerkan frasa “You build it, you run it” saat mendeskripsikan bagaimana Amazon (dan kemudian AWS) ingin tim berpikir tentang perangkat lunak: bukan sebagai proyek yang Anda serahkan, tetapi sebagai layanan yang Anda operasikan.
Perubahan kuncinya psikologis sebanyak teknis. Ketika sebuah tim tahu mereka akan dipanggil saat terjadi kegagalan, keputusan desain berubah. Anda peduli pada default yang masuk akal, alert yang jelas, degradasi yang anggun, dan jalur deploy yang bisa Anda rollback. Dengan kata lain, membangun termasuk merencanakan bagian-bagian yang berantakan dari kehidupan nyata.
Pemikiran layanan era AWS membuat keandalan dan kecepatan tak bisa ditawar. Pelanggan cloud mengharapkan API tersedia sepanjang waktu, dan mengharapkan perbaikan datang terus-menerus—bukan dalam gelombang rilis besar per kuartal.
Tekanan itu mendorong:
Filosofi ini tumpang tindih dengan gerakan DevOps yang lebih luas: menutup jarak antara “dev” dan “ops,” mengurangi handoff, dan menjadikan hasil (ketersediaan, latensi, beban dukungan) bagian dari loop pengembangan. Ini juga cocok dengan gagasan tim otonom kecil yang bisa merilis secara independen.
Godaannya adalah memperlakukan pendekatan Amazon sebagai template yang harus disalin. Tetapi “You Build It, You Run It” lebih merupakan arah daripada struktur organisasi kaku. Ukuran tim Anda, batasan regulasi, kematangan produk, dan persyaratan uptime mungkin memerlukan adaptasi—rotasi on-call bersama, dukungan platform, atau adopsi bertahap.
Jika Anda ingin cara praktis menerjemahkan mindset ini ke tindakan, lompat ke /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
“You Build It, You Run It” sebenarnya pernyataan tentang kepemilikan. Jika tim Anda merilis sebuah layanan, tim Anda bertanggung jawab atas bagaimana layanan itu berperilaku di dunia nyata—bukan hanya apakah lulus tes pada hari rilis.
Menjalankan layanan berarti peduli pada hasil secara end-to-end:
Pada minggu biasa, “run it” kurang tentang aksi heroik dan lebih tentang operasi rutin:
Model ini bekerja hanya jika akuntabilitas berarti “kami yang memperbaiki,” bukan “kami mencari orang untuk dihukum.” Ketika sesuatu rusak, tujuannya adalah memahami apa dalam sistem yang memperbolehkan hal itu—alert yang hilang, batas yang tidak jelas, deployment berisiko—dan memperbaiki kondisi tersebut.
Kepemilikan menjadi berantakan ketika layanan kabur. Definisikan batas layanan (apa yang dilakukannya, apa yang bergantung padanya, apa yang dijanjikannya) dan tetapkan tim pemilik bernama. Kejelasan itu mengurangi handoff, mempercepat respons insiden, dan membuat prioritas jelas ketika keandalan dan fitur saling bersaing.
On-call adalah inti dari “You Build It, You Run It” karena menutup loop umpan balik. Ketika tim yang sama yang merilis perubahan juga merasakan dampak operasional (lonjakan latensi, deploy gagal, keluhan pelanggan), prioritas menjadi jelas: pekerjaan keandalan berhenti menjadi “masalah orang lain,” dan cara tercepat untuk merilis lebih banyak sering kali membuat sistem lebih tenang.
On-call yang sehat terutama tentang prediktabilitas dan dukungan.
Definisikan level severity agar sistem tidak membangunkan untuk setiap ketidaksempurnaan.
Aturan sederhana: jika membangunkan seseorang tidak akan mengubah hasil, itu tiket, bukan page.
On-call bukan hukuman; itu sinyal. Setiap alert berisik, kegagalan berulang, atau perbaikan manual harus memberi umpan balik ke pekerjaan engineering: alert yang lebih baik, otomatisasi, rilis yang lebih aman, dan perubahan sistem yang menghilangkan kebutuhan untuk memanggil sama sekali.
Jika “you run it” nyata, tim butuh cara bersama untuk berbicara tentang keandalan tanpa mengubah setiap diskusi menjadi opini. Di sinilah SLIs, SLOs, dan error budgets berguna: target jelas dan trade-off yang adil antara bergerak cepat dan menjaga stabilitas.
Cara mudah mengingat: SLI = metrik, SLO = target, SLA = komitmen eksternal.
SLI yang baik spesifik dan terkait pengalaman pengguna, seperti:
Error budget adalah jumlah “buruknya” yang boleh Anda tanggung sambil tetap memenuhi SLO (mis. jika SLO Anda 99.9% ketersediaan, error budget bulanan Anda 0.1% downtime).
Saat layanan sehat dan Anda dalam budget, tim bisa mengambil lebih banyak risiko pengiriman. Saat Anda membakar budget terlalu cepat, pekerjaan keandalan menjadi prioritas.
SLO mengubah keandalan menjadi input perencanaan. Jika error budget rendah, sprint berikutnya mungkin menekankan rate limiting, rollout yang lebih aman, atau memperbaiki dependency flaky—karena melewatkan SLO memiliki biaya jelas. Jika budget melimpah, Anda bisa memprioritaskan kerja produk tanpa menebak apakah “ops akan baik-baik saja.”
“You build it, you run it” hanya bekerja jika pengiriman ke produksi adalah rutinitas—bukan acara bernilai tinggi. Tujuannya mengurangi ketidakpastian sebelum peluncuran dan membatasi blast radius setelahnya.
Sebelum sebuah layanan dianggap “siap,” tim biasanya perlu beberapa dasar operasional:
Daripada merilis semuanya ke semua orang sekaligus, delivery progresif membatasi dampak:
Jika tim Anda menstandarkan rollback, perlakukan itu sebagai kemampuan kelas-satu: semakin cepat Anda bisa revert dengan aman, semakin realistis “you run it.”
Dua tes mengurangi "unknown unknowns":
Sederhanakan: satu halaman checklist di repo atau template tiket (mis. “Observability,” “Kesiapan on-call,” “Perlindungan data,” “Rencana rollback,” “Kapasitas diuji,” “Runbook terlink”). Jadikan status “belum siap” sebagai normal—lebih baik daripada belajar di produksi.
Insiden adalah tempat “you run it” menjadi nyata: layanan menurun, pelanggan memperhatikan, dan tim harus merespons cepat dan jelas. Tujuannya bukan heroik—melainkan workflow yang dapat diulang yang mengurangi dampak dan menghasilkan perbaikan.
Kebanyakan tim berkonvergensi pada fase yang sama:
Jika Anda ingin template praktis untuk alur ini, simpan checklist ringan (lihat /blog/incident-response-checklist).
Postmortem tanpa menyalahkan tidak berarti “tak ada yang melakukan kesalahan.” Maksudnya Anda fokus pada bagaimana sistem dan proses memperbolehkan kesalahan mencapai produksi, bukan mempermalukan individu. Itu yang membuat orang mau berbagi detail lebih awal, yang penting untuk pembelajaran.
Dokumentasikan:
Postmortem yang baik diakhiri dengan tindak lanjut konkret, biasanya dalam empat kategori: perbaikan tooling (alert/dashboard lebih baik), tes (regresi dan kasus tepi), otomatisasi (deploy/rollback yang lebih aman, guardrail), dan dokumentasi (runbook, langkah operasional yang lebih jelas). Tetapkan pemilik dan tenggat—kalau tidak, pembelajaran tetap teoritis.
Tooling adalah leverage yang membuat “You Build It, You Run It” berkelanjutan—tetapi tidak bisa menggantikan kepemilikan nyata. Jika tim menganggap operasi sebagai “masalah orang lain,” dashboard tercanggih hanya akan mendokumentasikan kekacauan. Alat yang baik mengurangi friction: membuat hal yang benar (mengamati, merespons, belajar) lebih mudah daripada yang salah (menebak, menyalahkan, mengabaikan).
Setidaknya, pemilik layanan butuh cara konsisten untuk melihat apa yang software mereka lakukan di produksi dan bertindak cepat saat tidak baik.
Jika cerita monitoring Anda terfragmentasi, tim menghabiskan lebih banyak waktu berburu daripada memperbaiki. Pendekatan observabilitas terpadu membantu; lihat /product/observability.
Seiring organisasi tumbuh, “siapa yang punya ini?” menjadi risiko keandalan. Katalog layanan (atau portal developer internal) menyelesaikan ini dengan menyimpan kepemilikan dan konteks operasional di satu tempat: nama tim, rotasi on-call, jalur eskalasi, runbook, dependensi, dan link ke dashboard.
Kuncinya adalah metadata kepemilikan yang tetap mutakhir. Jadikan itu bagian dari workflow: layanan baru tidak boleh live tanpa pemilik, dan perubahan kepemilikan diperlakukan seperti perubahan kode (direview, dilacak).
Setup terbaik mendorong tim ke perilaku sehat: template runbook, alert otomatis terkait SLO, dan dashboard yang menjawab “apakah pengguna terdampak?” dalam hitungan detik. Tapi sistem manusia tetap penting—tim butuh waktu untuk memelihara alat ini, memangkas alert, dan terus memperbaiki cara mereka mengoperasikan layanan.
Tim platform membuat “You Build It, You Run It” lebih mudah dijalani. Tugas mereka bukan menjalankan produksi untuk semua—melainkan menyediakan jalur yang terang (paved roads) supaya tim produk bisa memiliki layanan tanpa menemukan ulang operasi setiap sprint.
Platform yang baik menawarkan default yang sulit salah dan mudah diadopsi:
Guardrail harus mencegah perilaku berisiko tanpa menghambat pengiriman. Pikirkan “aman secara default” daripada “buka tiket dan tunggu.”
Tim platform dapat menjalankan layanan bersama—tanpa mengambil kepemilikan layanan produk.
Batasnya sederhana: tim platform memiliki uptime dan dukungan platform; tim produk memiliki cara layanan mereka menggunakan platform.
Saat tim tidak harus menjadi ahli CI/CD, auth, atau secret di hari pertama, mereka bisa fokus pada perilaku layanan dan dampak pengguna.
Contoh yang menghilangkan pekerjaan berulang:
Hasilnya adalah pengiriman lebih cepat dengan lebih sedikit “custom ops snowflakes,” sambil mempertahankan janji inti: tim yang membangun layanan tetap yang menjalankannya.
“You build it, you run it” dapat memperbaiki keandalan dan kecepatan—tetapi hanya jika organisasi mengubah kondisi di sekitar tim. Banyak kegagalan terlihat seperti slogan diadopsi, tetapi kebiasaan pendukung tidak diikuti.
Beberapa pola muncul berulang:
Beberapa lingkungan perlu pendekatan yang disesuaikan:
Filosofi ini paling cepat gagal saat kerja keandalan diperlakukan sebagai “tambahan.” Kepemimpinan harus secara eksplisit mengalokasikan kapasitas untuk:
Tanpa perlindungan itu, on-call menjadi pajak—bukannya loop umpan balik yang memperbaiki sistem.
Melakukan ini paling baik sebagai perubahan bertahap, bukan pengumuman seluruh perusahaan. Mulai kecil, buat kepemilikan terlihat, lalu perluas.
Pilih satu layanan yang terdefinisi baik (idealnya dengan pengguna jelas dan risiko terkelola).
Tentukan:
Kunci: tim yang merilis perubahan juga memiliki hasil operasional untuk layanan itu.
Sebelum memperluas ke lebih banyak layanan, pastikan tim pilot bisa beroperasi tanpa heroik:
Gunakan sekumpulan indikator kecil yang menunjukkan apakah kepemilikan memperbaiki pengiriman dan stabilitas:
Jika Anda mengadopsi “you build it, you run it” sambil juga mencoba mempercepat pengiriman, bottleneck sering sama: dari ide → layanan siap produksi dengan kepemilikan jelas dan cerita rollback aman.
Koder.ai adalah platform vibe-coding yang membantu tim membangun aplikasi web, backend, dan mobile lewat antarmuka chat (React di web, Go + PostgreSQL di backend, Flutter untuk mobile). Untuk tim yang condong ke kepemilikan layanan, beberapa fitur memetakan dengan jelas ke model operasi:
Pilih layanan pilot Anda minggu ini dan jadwalkan kickoff 60 menit untuk menetapkan SLO pertama, rotasi on-call, dan pemilik runbook. Jika Anda mengevaluasi tooling untuk mendukung ini (pengiriman, rollback, dan workflow seputar kepemilikan), lihat /pricing untuk tier gratis, pro, business, dan enterprise Koder.ai—plus opsi seperti hosting, deployment, dan domain kustom.
Artinya tim yang merancang, membangun, dan menerapkan sebuah layanan juga bertanggung jawab atas apa yang terjadi setelah layanan tersebut live: pemantauan, respons on-call, tindak lanjut insiden, dan perbaikan keandalan.
Ini adalah model tanggung jawab (kepemilikan yang jelas), bukan pilihan alat atau perubahan jabatan.
Bukan berarti setiap engineer harus menjadi spesialis infrastruktur penuh waktu.
Artinya:
Dengan tim ops terpisah, umpan balik datang terlambat dan tanggung jawab menjadi kabur: developer mungkin tidak merasakan dampak produksi, dan ops mungkin tidak punya konteks perubahan terbaru.
Kepemilikan end-to-end biasanya meningkatkan:
“Run it” biasanya mencakup:
Mulai dengan default yang manusiawi:
Sistem on-call yang baik bertujuan mengurangi jumlah page bulan depan, bukan menormalisasi heroik.
Gunakan aturan sederhana: jika membangunkan seseorang tidak akan mengubah hasil, buat itu tiket.
Secara praktis:
Mereka menciptakan target keandalan yang dapat diukur bersama:
Saat budget cepat habis, prioritaskan pekerjaan keandalan; saat sehat, ambil lebih banyak risiko pengiriman fitur.
Adopsi praktik rilis yang mengurangi ketidakpastian dan blast radius:
Jalankan insiden dengan alur yang dapat diulang:
Lalu tulis postmortem tanpa menyalahkan yang fokus pada celah proses dan sistem, dengan tindak lanjut yang:
Checklist ringan seperti /blog/incident-response-checklist bisa membantu menstandarisasi alur.
Tim platform harus menyediakan paved roads (template, CI/CD, guardrail, layanan bersama) sementara tim produk mempertahankan kepemilikan hasil layanan mereka.
Batas praktis:
