DevOps bir araç seti değil, kodun bilgisayardan üretime nasıl ulaştığını şekillendiren bir kültür. Otomatik test ve dağıtım hattından kod olarak altyapıya, üretimde olanı görmenizi sağlayan observability'den ekibin gerçek hızını ölçen DORA metriklerine — bu sayfa, hız ile güvenin birlikte nasıl büyütüldüğünü sadeleştirmek için hazırlandı.
Bir geliştirici dalı (branch) ana çizgiye birleştirdiğinde, kodun üretime ulaşana kadar geçtiği her duraktan oluşan bu hat ne kadar otomatik, hızlı ve güvenilirse ekibin gerçek hızı da o kadar yüksek olur. Sürüm hattının üç aşamasını ayırmak — sık karıştırılan iki "CD" dahil — kurulumu netleştirir.
Her commit otomatik olarak derlenir; birim ve entegrasyon testleri, statik analiz ve güvenlik taraması koşar. Amaç, ana dalın her an "yeşil" kalması — bir sonraki adıma sağlam bir taban hazırlanmasıdır.
Yeşil her build, üretime gidebilir kalitede bir paket olarak hazırlanır ve stage ortamında doğrulanır. Üretime geçiş için elle bir onay bekler. Sürümün ne zaman çıkacağı hâlâ insan kararıdır.
Onay adımı da otomasyona devredilmiştir: testten geçen her build doğrudan üretime gider. Geri alma kolay, dağıtım küçük olmalıdır; "büyük sürüm" diye bir konu artık masada değildir.
Konsoldan tıklayarak kurulan altyapı kimsenin tam olarak hatırlamadığı bir geçmişe dönüşür — yedek bir bölgeyi acilen ayağa kaldırmak gerektiğinde bu boşluk maliyetli olur. IaC, sunucu, ağ ve servis yapılandırmasını sürüm kontrolüne alır. GitOps ise bir adım daha ileri gider: deponun durumu üretimin durumudur; arada el ile yapılan değişiklik sürüklenme olarak tespit edilir, ya geri alınır ya da depoya yazılır.
Doğru ayrım: IaC nasıl tanımlandığı (kod), GitOps nereden uygulandığı (Git, çekme akışı) konusudur. İkisi birlikte çalışır.
# depo, üretimin tek doğru tanımıdır
resource "aws_db_instance" "primary" {
instance_class = "db.r6g.large"
allocated_storage = 200
backup_retention = 14
deletion_protection = true
}
# plan, gerçek ile depo arasındaki farkı gösterir
Plan: 1 to add, 2 to change, 0 to destroy
# GitOps döngüsü
push → PR → review → merge
↓
cluster otomatik senkronize olur
↓
drift varsa uyarı / geri almaMonitoring "önceden bildiğim soruları sormak", observability ise "yeni bir sorun çıktığında onu sorabilecek veriyi elimde bulundurmak"tır. Üç sinyalin bir arada yorumlanması bu farkı yaratır.
Sinyaller toplandıktan sonra SLO ile bir vaat tanımlanır. Hata bütçesi, ekibe ne kadar risk alabileceğini söyler; tükendiğinde dağıtım yavaşlatılır, kazanıldığında yeni özelliklere alan açılır. Sinyal toplama ve burn-rate alarm tasarımı için Observability & Loglama.
Zaman serisinde toplanan sayılar — istek oranı, gecikme, hata yüzdesi. Uyarı kurmak ve trend izlemek için en uygun sinyal; "neden" sorusunu yalnız başına yanıtlayamaz.
Bir isteğin neden başarısız olduğunu metin olarak anlatır. Yapılandırılmış (JSON) loglar arama ve filtrelemeyi sadeleştirir; hacmi büyüdüğü için saklama politikası gerektirir.
Bir kullanıcı isteğinin servisler arasındaki yolculuğunu adım adım gösterir. Mikroservislerde "gecikme nereden geliyor?" sorusunu yanıtlayan tek sinyaldir; OpenTelemetry ortak standarttır.
# bir vaat — ve bütçesi
SLI = başarılı istek / toplam istek
SLO = %99.9 (30 günlük pencere)
hata bütçesi = %0.1 ≈ 43 dakika / 30 gün
# bütçe nasıl harcanır
bütçe sağlamsa → sürüm hızı serbest, deney yapılabilir
bütçe yarıladı → yeni özelliklere yavaşla
bütçe bitti → freeze — yalnızca güvenilirlik işiGoogle'ın yıllarca süren DORA araştırması, yüksek performanslı ekipleri ayırt eden dört metrik tanımladı. Hız (deployment frequency, lead time) ve istikrar (change failure rate, MTTR) ikilisini birlikte okumak gerek; biri yükselirken diğeri çökerse iyileşme değil, başka bir yere ödenmiş bir maliyet vardır.
Her ikisi de "CD" kısaltmasıyla yazılır ama farklı anlama gelir. Continuous Delivery her yeşil build'i üretime hazır tutar; çıkış için bir onay bekler. Continuous Deployment bu onayı da kaldırır — testten geçen her şey otomatik üretime gider. Hangisinde olduğunuzu netleştirin; karışıklık genelde "otomatik dağıtım" tartışmasının kaynağıdır.
Monitoring önceden bildiğiniz soruları sorar: CPU yüksek mi, hata oranı arttı mı? Observability daha önce karşılaşmadığınız bir sorunu, sistemden çekebileceğiniz veriyle çözebilme yetisidir. İkincisinin temeli yapılandırılmış log, yüksek kardinaliteli metric ve dağıtık trace'tir; biri olmadan diğeri eksik kalır.
SLI ölçtüğünüz şeydir (başarılı istek oranı, p99 gecikme). SLO hedefiniz ("%99.9"). SLA ise müşteriye verilen sözleşmesel taahhüt — ihlal edildiğinde tazminat doğurur. SLO içeride sıkı tutulur, SLA dışarıda daha gevşek anlatılır; arada bir tampon bırakmak sağlıklıdır.
Canary dağıtım, yeni sürümü önce trafiğin küçük bir yüzdesine açar; metrikler iyiyse oran kademeli büyür — risk küçük adımlara bölünür. Blue/Green iki paralel ortam tutar, yeni sürüm hazırsa trafik bir anda değişir; geri alma da bir o kadar hızlıdır. Stateful sistemlerde blue/green veri tabanı senkronizasyonu nedeniyle daha pahalıdır.
IaC altyapının nasıl tanımlandığı (Terraform/OpenTofu/Pulumi gibi kod) konusudur. GitOps bu kodun nereden uygulandığı (Git deposundan, çekme modeliyle) konusudur. IaC olmadan GitOps olmaz; GitOps olmadan IaC manuel apply'larla yine de kullanılabilir.
Sürüm hattı, observability ve DORA metrikleri üzerine temel kuruluşların yayınları.
Mevcut CI/CD kurulumunuzu, altyapı kodu kapsamınızı ve observability sinyallerinizi masaya yatıralım — hız ile güveni aynı anda büyüten bir kurulumu birlikte planlayalım.