Werner Vogels’in “You Build It, You Run It” ifadesinin ne anlama geldiğini, sahiplik, on-call, SLO’lar, olay müdahalesi ve daha güvenli yayımlar bağlamında nasıl uygulanacağını öğrenin.
“Sen yaparsın, sen işletirsin” gibi bir ifade akılda kalır çünkü çok net ve serttir. Motivasyon posterleri ya da “daha fazla DevOps olmak” meselesi değildir. Bu, sorumluluk hakkında açık bir beyan: bir servisi yayınlayan ekip, o servisin üretimde nasıl davrandığından da sorumludur.
Pratikte bu, özellikleri tasarlayan ve kod yazan aynı ürün ekibinin ayrıca şunları da yaptığı anlamına gelir:
Herkesin bir gecede altyapı uzmanı olması gerektiği anlamına gelmez. Anlamı şudur: geri bildirim döngüsü gerçek olur: bir şey yayınlayıp kesintileri, pager gürültüsünü ya da müşteri sıkıntısını artırırsanız, ekip bunu doğrudan hisseder—ve hızlı öğrenir.
Bu felsefe tekrar edilmesi kolay ama uygulanması zordur; eğer onu açık beklentilerle bir işletme modeli olarak ele almazsanız işe yaramaz. “İşlet” genellikle bir şekilde on-call olmayı, olay müdahalesini sahiplenmeyi, runbook yazmayı, panoları korumayı ve servisi sürekli iyileştirmeyi içerir.
Ayrıca kısıtlar getirir: ekiplerden “işletin” demeden önce onlara sorunları düzeltmek için gerekli araçları, erişimi ve yetkiyi—ve yol haritalarında buna ayıracak zamanı—vermeksiniz diyemezsiniz.
“You Build It, You Run It” öncesinde pek çok şirket yazılım işini bir bayrak yarışına benzetiyordu: geliştiriciler kod yazdı, sonra "duvardan atıp" operasyon ekibine veriyordu; onlar dağıtım ve işletmeden sorumluydu.
Bu el değiştirme kısa vadede bir problemi çözdü—üretimi deneyimli biri izliyordu—ama daha büyük sorunlar yarattı.
Ayrı bir ops ekibi üretimi sahipleniyorsa, geliştiriciler genellikle problemleri geç (veya hiç) öğrenir. Bir hata belki günler sonra belirsiz bir ticket olarak gelir: “servis yavaş” ya da “CPU yüksek.” O zaman bağlam kaybolur, loglar rotasyon olur ve değişikliği yapan kişiler çoktan ayrılmış olur.
Handoff ayrıca sahipliği bulanıklaştırır. Bir kesinti olduğunda geliştirici "ops yakalar" varsayar, ops ise "dev riskli bir şey yayınladı" der. Sonuç tahmin edilebilir: daha uzun olay çözümü, tekrarlayan hata modları ve ekiplerin müşteri deneyimi yerine yerel optimizasyona yönelmesi.
“You Build It, You Run It” döngüyü sıkılaştırır. Aynı değişikliği yayınlayan ekip, üretimde nasıl davrandığından sorumludur. Bu pratik iyileştirmeleri yukarı doğru iter: daha net alarmlar, daha güvenli rollout’lar, daha iyi panolar ve işletmesi daha kolay kod.
Paradoksal olarak, bu genellikle daha hızlı teslimata yol açar. Ekipler yayımlama sürecine güvendikçe ve üretim davranışını anladıkça, daha küçük değişiklikleri daha sık gönderebilir—hataların etki alanını azaltır ve problemleri teşhis etmeyi kolaylaştırır.
Her kuruluş aynı kadro, uyum gereksinimleri veya miras sistemlerle başlamaz. Bu felsefe bir yönlendirmedir, bir anahtar değil. Pek çok ekip bunu kademeli olarak benimser—önce paylaşılan on-call, daha iyi gözlemlenebilirlik ve net servis sınırları—sonra tam uçtan uca sahipliğe geçer.
Amazon’un CTO’su Werner Vogels, "You build it, you run it" ifadesini popülerleştirdi; Amazon (ve sonrasında AWS) ekiplerinin yazılımı bir proje olarak değil, işletilen bir servis olarak düşünmesini istediğini anlatırken kullandı.
Ana değişim teknik kadar psikolojiktir. Bir ekip başarısızlık için sayfa alacağını bildiğinde, tasarım kararları değişir. Mantıklı varsayımlar, net uyarılar, zarif düşüşler ve geri alabileceğiniz dağıtım yolları önem kazanır. Başka bir deyişle, inşa etmek gerçek hayatın dağınık kısımlarını planlamayı içerir.
AWS dönemi servis düşüncesi güvenilirlik ve hızı vazgeçilmez kıldı. Bulut müşterileri API’lerin her zaman erişilebilir olmasını ve geliştirmelerin sürekli gelmesini bekliyor—çeyreklik büyük sürüm dalgaları değil.
Bu baskı şunları teşvik etti:
Bu felsefe daha geniş DevOps hareketiyle örtüşür: “dev” ile “ops” arasındaki boşluğu kapatmak, el değiştirmeleri azaltmak ve kullanılabilirlik/latency/destek yükü gibi sonuçları geliştirme döngüsüne dahil etmek. Ayrıca bağımsız, küçük takımların bağımsız olarak yayın yapabilmesi fikrine de uyuyor.
Amazon’un yaklaşımını doğrudan şablon olarak almak cazip olabilir. Ancak “You Build It, You Run It” daha çok bir yöndür; katı bir örgüt şeması değil. Takım büyüklüğünüz, düzenleyici kısıtlarınız, ürün olgunluğunuz ve çalışma süresi gereksinimleriniz uyarlamalar gerektirebilir—paylaşılan on-call rotasyonları, platform desteği veya aşamalı benimseme gibi.
Eğer zihniyeti eyleme çevirmek istiyorsanız, ayrıntılı adım adım rehbere bakın.
“You Build It, You Run It” aslında sahiplik hakkında bir beyanattır. Ekibiniz bir servisi yayınlıyorsa, ekip o servisin gerçek dünyada nasıl davrandığından sorumludur—sadece yayın günü testleri geçip geçmediğiyle sınırlı değildir.
Bir servisi işletmek uçtan uca sonuçlarla ilgilenmeyi gerektirir:
Normal bir haftada “run it” kahramanlık değil, rutin operasyonlar hakkındadır:
Bu model yalnızca hesap verebilirlik “biz düzeltiriz” anlamına geldiğinde işler; “suçlu arama” anlamına gelmemelidir. Bir şey bozulduğunda amaç, sistemdeki hangi koşulun bunun üretime ulaşmasına izin verdiğini anlamak—eksik alarmlar, belirsiz limitler, riskli dağıtımlar—ve bu koşulları iyileştirmektir.
Sahiplik servisler muğlak olduğunda karışır. Servis sınırlarını (ne yaptığı, neye bağımlı olduğu, ne taahhüt ettiği) tanımlayın ve isimlendirilmiş bir sahip ekip atayın. Bu netlik el değiştirmeleri azaltır, olay yanıtını hızlandırır ve güvenilirlik ile özellik rekabet ettiğinde öncelikleri belirgin kılar.
On-call “You Build It, You Run It” için merkezidir çünkü geri bildirim döngüsünü kapatır. Aynı ekibin yaptığı değişiklikleri operasyonel etkisini (latency artışı, başarısız deploy’lar, müşteri şikayetleri) hissetmesi öncelikleri netleştirir: güvenilirlik işi artık “başkasının işi” değil ve daha fazla yayın yapmanın en hızlı yolu genellikle sistemi sakinleştirmektir.
Sağlıklı on-call çoğunlukla öngörülebilirlik ve destekle ilgilidir.
Sistem her kusur için sayfa atmaması için ciddiyet seviyeleri tanımlayın.
Basit kural: birini uyandırmanın sonucu değiştirmeyeceği durum bir ticket olmalı, page değil.
On-call bir ceza değildir; bir sinyaldir. Her gürültülü uyarı, tekrarlayan hata veya manuel düzeltme mühendislik işine geri dönmeli: daha iyi alarmlar, otomasyon, daha güvenli sürümler ve sayfa gereksinimini ortadan kaldıracak sistem değişiklikleri.
Eğer “sen işletirsin” gerçekse, ekiplerin güvenilirlik hakkında tartışmayı görüşlere bırakmayacak ortak bir dili olmalı. İşte SLIs, SLOs ve hata bütçeleri: net hedefler ve hızlı hareket ile istikrar arasında adil bir takas sağlar.
Hatırlamak için: SLI = metrik, SLO = hedef, SLA = dış taahhüt.
İyi SLI’lar spesifik ve kullanıcı deneyimine bağlıdır, örneğin:
Hata bütçesi, SLO’yu karşılamaya devam ederken harcayabileceğiniz “kötülük” miktarıdır (örneğin, %99.9 kullanılabilirlik için aylık hata bütçeniz %0.1 kesinti olur).
Servis sağlıklı ve bütçe içindeyse, ekipler daha fazla teslimat riski alabilir. Bütçeyi hızla harcıyorsanız, güvenilirlik işleri öncelik kazanır.
SLO’lar güvenilirliği plan girdisine dönüştürür. Hata bütçeniz düşükse, bir sonraki sprint hız sınırlama, daha güvenli rollout’lar veya kırılgan bağımlılıkların düzeltilmesi gibi güvenilirlik odaklı işler içermelidir—çünkü SLO’yu kaçırmanın net bir maliyeti vardır. Bütçe bolsa, ürün işlerine güvenle öncelik verilebilir.
“You build it, you run it” yalnızca üretime gönderme rutin haline gelirse işe yarar—yüksek riskli bir olay olmamalı. Hedef, yayın öncesi belirsizliği azaltmak ve yayın sonrası etki alanını sınırlamaktır.
Bir servis “hazır” sayılmadan önce genellikle birkaç operasyonel temel gereklidir:
Her şeyi aynı anda herkese yayınlamak yerine kademeli teslimat etkiyi sınırlar:
Rollback standart hale getiriliyorsa, bunu birinci sınıf yetenek olarak ele alın: ne kadar hızlı güvenle geri dönebilirseniz, “sen işletirsin” o kadar gerçekçi olur.
İki test “bilinmeyen bilinmeyenleri” azaltır:
Hafif tutun: repoda veya ticket şablonunda bir sayfa checklist (ör. “Gözlemlenebilirlik,” “On-call hazırlığı,” “Veri koruma,” “Rollback planı,” “Kapasite test edildi,” “Runbooklar bağlı”). “Hazır değil” durumu normal olsun—üretimde öğrenmekten çok daha iyidir.
Olaylar “sen işletirsin”in gerçeğe dönüştüğü anlardır: bir servis bozulur, müşteriler fark eder ve ekip hızlı ve net şekilde yanıt vermeli.
Çoğu ekip benzer aşamalarda uzlaşır:
Bu akış için hafif bir checklist bulundurmak pratik olur.
Suçlayıcı olmayan postmortem "kimse hata yapmadı" anlamına gelmez. Amaç, hatanın üretime ulaşmasına izin veren sistem ve süreç eksiklerini araştırmaktır. Bu, insanların ayrıntıları erken paylaşmasını sağlar—öğrenme için şarttır.
Belgeleyin:
İyi postmortemler somut, sahipli ve zaman bağlı takiplerle biter; genelde dört kovaya girer: araç iyileştirmeleri (daha iyi panolar/uyarılar), testler (regresyonlar ve uç durumlar), otomasyon (daha güvenli deploy/rollback, guardrail’lar) ve dokümantasyon (runbooklar, net operasyon adımları). Bir sahip ve bitiş tarihi atayın—aksi takdirde öğrenme teorik kalır.
Araçlar “You Build It, You Run It”i sürdürülebilir kılan kaldıraçtır—ama araçlar gerçek sahipliğin yerini alamaz. Ekip operasyonu "başkasının işi" olarak görürse en güzel pano kaosu belgelemekten öte gitmez. İyi araçlar sürtünmeyi azaltır: doğru şeyi (gözlemek, yanıtlamak, öğrenmek) yapmak yanlış şeyi (tahmin yürütmek, suçlamak, görmezden gelmek) yapmaktan daha kolay olmalıdır.
En azından servis sahiplerinin yazılımlarının üretimde ne yaptığını görmenin ve sorun çıktığında hızlıca aksiyon almanın tutarlı bir yolu olmalı:
İzleme dağınıksa ekipler av peşinde fazlaca zaman harcar; birleşik bir gözlemlenebilirlik yaklaşımı yardımcı olur.
Organizasyon büyüdükçe “bunu kim sahipleniyor?” güvenilirlik riski haline gelir. Bir servis kataloğu (veya dahili geliştirici portalı) sahipliği ve operasyonel bağlamı tek bir yerde tutar: ekip adı, on-call rotasyonu, yükseltme yolu, runbooklar, bağımlılıklar ve panolara bağlantılar.
Anahtar, güncel kalan sahiplik meta verisidir. Yeni servislerin sahip olmadan canlıya alınmaması gibi iş akışına dahil edin; sahiplik değişiklikleri kod değişikliği gibi (incelenen, izlenen) olsun.
En iyi kurulumlar ekipleri sağlıklı davranışlara yönlendirir: runbook şablonları, SLO’lara bağlı otomatik alarmlar ve "kullanıcılar etkileniyor mu" sorusunu saniyeler içinde cevaplayan panolar. Ama insan sistemi yine önemlidir—ekiplere bu araçları korumak, alarmları budamak ve işletme biçimlerini sürekli iyileştirmek için zaman verilmeli.
Platform ekipleri “You Build It, You Run It”ı yaşamaya daha kolay kılar. Görevleri herkes için üretimi yürütmek değil—ürün ekiplerinin her sprintte operasyonu yeniden keşfetmeden sahip olabileceği iyi aydınlatılmış yollar (paved roads) sağlamaktır.
İyi bir platform, yanlış yapmayı zorlaştıran ve benimsemeyi kolaylaştıran varsayılanlar sunar:
Guardrail’lar gönderimi engellemek yerine riskli davranışı önlemeli. "Varsayılan olarak güvenli" düşünün.
Platform ekipleri paylaşılan servisleri çalıştırabilir—ama ürün servislerinin sahipliğini devralmamalıdır.
Sınır basittir: platform ekibi platformun çalışma süresinden sorumludur; ürün ekipleri platformu kullanarak kendi servislerinin davranışını sahiplenir.
Ekipler ilk günden CI/CD, auth veya secret yönetiminde uzman olmak zorunda kalmazsa, servis davranışı ve kullanıcı etkisine odaklanabilirler.
Örnekler:
Sonuç: daha az özel operasyonel iş ile daha hızlı teslimat; aynı zamanda temel vaat korunur: servisi inşa eden ekip, onu çalıştırır.
“You build it, you run it” güvenilirlik ve hızı artırabilir—ama organizasyon ekip etrafındaki koşulları değiştirmedikçe başarılı olamaz. Birçok başarısızlık, sloganın benimsendiği ama destekleyici alışkanlıkların alınmadığı durumlarda görülür.
Tekrar eden bazı örüntüler:
Bazı ortamlar uyarlama gerektirir:
Bu felsefe, güvenilirlik işi "fazladan" muamelesi gördüğünde en hızlı çöker. Liderlik açıkça şu için kapasite ayırmalı:
Bu korunma yoksa, on-call vergi haline gelir—oysa doğru işleyince on-call sistemi sistemi iyileştiren bir geri bildirim döngüsüdür.
Bunu uygulamak şirket genelinde bir duyuru değil, aşamalı bir değişim olarak daha iyi işler. Küçük başla, sahipliği görünür kıl ve sonra genişletin.
Net sınırları olan bir servis seçin (kullanıcıları belirgin ve riski yönetilebilir olan).
Tanımlayın:
Anahtar: değişiklikleri yayınlayan ekip, o servisin operasyonel sonuçlarından da sorumludur.
Daha fazla servise genişlemeden önce pilot ekibin kahramanlık olmadan çalışabildiğinden emin olun:
Üç-beş göstergeyle sahipliğin teslimat ve stabiliteyi iyileştirip iyileştirmediğini görün:
Eğer “sen yaparsın, sen işletirsin”i benimserken aynı zamanda teslimatı hızlandırmaya çalışıyorsanız, darboğaz genellikle aynıdır: fikirden → üretime hazır bir servise, net sahiplikle ve güvenli rollback öyküsüyle ulaşmak.
Koder.ai bir vibe-coding platformudur; sohbet arayüzü üzerinden web, backend ve mobil uygulamalar oluşturmanıza yardımcı olur (web için React, backend için Go + PostgreSQL, mobil için Flutter). Servis sahipliğine kayan ekipler için birkaç özellik işletme modeliyle iyi uyuşur:
Bu hafta pilot servisinizi seçin ve ilk SLO’yu, on-call rotasyonunu ve runbook sahiplerini belirlemek için 60 dakikalık bir başlangıç toplantısı planlayın. Araç ve iş akışı değerlendirmesi yapıyorsanız (gönderme, geri alma ve sahiplik etrafındaki iş akışları), fiyatlandırma sayfasına göz atın veya uygun planları inceleyin.
Bu, servisi tasarlayan, inşa eden ve dağıtan ekibin aynı zamanda canlıya çıktıktan sonra da ne olduğundan sorumlu olması demektir: izleme, on-call yanıtı, olay sonrası takipler ve güvenilirlik iyileştirmeleri.
Bu bir sorumluluk modelidir (net sahiplik); bir araç seçimi ya da sadece iş tanımı değişikliği değildir.
Her mühendisin tam zamanlı bir altyapı uzmanı olması gerektiği anlamına gelmez.
Anlamı şudur:
Ayrı bir ops ekibi olduğunda geri bildirim gecikir ve sorumluluk bulanıklaşır: geliştiriciler üretim etkisini hissetmeyebilir, ops ekipse yapılan değişikliklerin bağlamına sahip olmayabilir.
Uçtan uca sahiplik genellikle şunları iyileştirir:
“Run it” genellikle şunları içerir:
İnsancıl varsayımlarla başlayın:
İyi bir on-call sistemi amaç olarak “gelecek ay daha az sayfa” hedefler; kahramanlığı normalleştirmek değil.
Basit bir kural: birini uyandırmak sonucu değiştirmeyecekse, bu bir ticket olmalı, page değil.
Pratikte:
SLI: ne ölçtüğünüz (ör. istek başarı oranı)
SLO: o ölçüm için hedef (ör. %99.9)
Hata bütçesi: SLO’yu sağlarken harcayabileceğiniz düzensizlik miktarı
Bütçe hızlı tükeniyorsa öncelik güvenilirlik işlerine verilir; bütçe iyiyse daha fazla teslimat riski alınabilir.
Aşağıdaki uygulamalar bu modeli sürdürülebilir kılar:
Olayları tekrarlanabilir bir akışla yönetin:
Sonra suçlayıcı olmayan (blameless) postmortemler yazın; sistem ve süreç açıklarını belgeleyin ve takipler:
Olay müdahalesi kontrol listesi gibi hafif bir şablon süreci standartlaştırmaya yardımcı olur.
Platform ekipleri “paved roads” (yol döşeme) sağlayarak benimsemeyi kolaylaştırmalı: şablonlar, CI/CD, guardrail’lar, ortak servisler. Ancak ürün ekiplerinin hizmetin davranışı ve güvenilirliği üzerindeki sahipliğini elinden almamalıdır.
Pratik sınır:
