Sıfır Kesinti (Zero-Downtime) Dağıtım Stratejileri

Production ortamına yeni sürüm çıkarken kullanıcıların hata ekranıyla karşılaşması, ödeme işlemlerinin yarıda kalması veya API istemcilerinin bağlantı hatası alması artık kabul edilmesi zor sonuçlardır. Bu nedenle Sıfır Kesinti (Zero-Downtime) Dağıtım Stratejileri yalnızca DevOps ekiplerinin ilgilendiği teknik bir konu değil, doğrudan müşteri deneyimini ve gelir sürekliliğini etkileyen bir reliability yaklaşımıdır. Yaklaşık on yıllık production deneyiminde en sık gördüğüm hata, ekiplerin Kubernetes kullanmaya başladıklarında kesintisiz deployment problemini otomatik olarak çözdüklerini düşünmeleridir. Oysa gerçek çözüm; uygulama mimarisi, veritabanı değişiklikleri, trafik yönetimi, health check, graceful shutdown, gözlemlenebilirlik ve rollback tasarımının birlikte ele alınmasını gerektirir. Bu rehberde zero-downtime deployment nasıl yapılır, sıfır kesinti ile uygulama güncelleme yöntemleri nelerdir ve production seviyesinde güvenli release akışı nasıl kurulur sorularını uygulamada karşılaşabileceğiniz örneklerle ele alacağız.

Zero-Downtime Deployment Nedir?

Zero-downtime deployment, yeni bir uygulama sürümü yayınlanırken hizmetin erişilebilir kalmasını hedefleyen dağıtım yaklaşımıdır. Kullanıcı açısından ideal sonuç, deployment yapıldığını hiç fark etmemektir. Bunun sağlanabilmesi için eski sürüm trafik almaya devam ederken yeni sürümün hazırlanması gerekir. Yeni sürüm sağlık kontrollerini geçtikten sonra trafik kontrollü biçimde ona aktarılır. Sıfır Kesinti (Zero-Downtime) Dağıtım Stratejileri bu geçişin hangi yöntemle ve hangi risk kontrolleriyle gerçekleştirileceğini belirler.

Sıfır Kesinti Ne Anlama Gelir?

Sıfır kesinti, deployment sürecinde servisin kullanılabilirliğinin korunması anlamına gelir. HTTP istekleri gereksiz 500 hataları almamalı, aktif işlemler deployment yüzünden yarıda kesilmemeli ve istemciler hizmet dışı mesajıyla karşılaşmamalıdır. Buradaki amaç yalnızca pod veya process çalışıyor görünmesini sağlamak değildir. Gerçek kullanıcı işlemlerinin başarılı biçimde tamamlanması esas alınmalıdır. Bu nedenle teknik availability metrikleri kadar ödeme başarı oranı, sipariş tamamlama oranı veya giriş başarı oranı gibi iş metrikleri de takip edilmelidir.

Zero-Downtime ve Near-Zero-Downtime Arasındaki Fark

Zero-downtime hedefi kullanıcı tarafından algılanabilir bir kesinti yaşanmamasıdır. Near-zero-downtime ise birkaç saniyelik veya çok kısa süreli hizmet kaybının kabul edilebilir olduğu sistemleri tanımlar. Bazı dahili araçlarda üç veya beş saniyelik geçiş süresi operasyonel olarak sorun yaratmayabilir. Ancak ödeme API'leri, yoğun SaaS servisleri veya mobil uygulamaların backend katmanlarında aynı süre ciddi hata hacmine dönüşebilir. Hangi hedefin gerekli olduğunu belirlerken SLA, SLO, trafik hacmi ve işlemlerin iş değeri birlikte değerlendirilmelidir.

Deployment Sırasında Kullanıcı Ne Görür?

İyi tasarlanmış bir deployment sırasında kullanıcı normal uygulama deneyimini görmeye devam eder. Bir istek eski sürüme giderken sonraki istek yeni sürüme yönlenebilir ve kullanıcı bunun farkına varmamalıdır. Bu durum eski ve yeni sürümlerin belirli bir süre uyumlu çalışabilmesini zorunlu hale getirir. Session, API sözleşmeleri ve database şeması bu geçiş dönemini desteklemelidir. Kullanıcının gördüğü herhangi bir hata çoğu zaman deployment tekniğinden önce bu uyumluluk noktalarından birindeki eksikliğe işaret eder.

Neden Klasik Stop–Deploy–Start Yaklaşımı Yeterli Değildir?

Stop, deploy ve start yaklaşımında çalışan servis önce kapatılır, yeni sürüm yüklenir ve ardından yeniden başlatılır. Bu sırada load balancer arkasında başka sağlıklı instance bulunmuyorsa kullanıcı talepleri doğrudan hata alır. Başlangıç süresi uzadıkça kesinti de uzar ve sorun özellikle container başlangıcında migration veya cache hazırlığı yapan uygulamalarda büyür. Ayrıca yeni sürüm açılmazsa servis eski haline dönene kadar erişilemez kalabilir. Production ortamında çoklu instance ve kademeli geçiş bu yüzden daha güvenli bir temel oluşturur.

Hangi Sistemlerde Sıfır Kesinti Kritik Hale Gelir?

Sıfır kesinti gereksinimi genellikle yüksek trafik, doğrudan gelir etkisi veya sürekli erişilebilirlik beklentisi bulunan sistemlerde belirginleşir. Bir servis kısa süre kapandığında kullanıcı yalnızca sayfayı yenilemiyorsa, arka planda veri veya para kaybı riski de değerlendirilmelidir. API tüketicileri otomatik retry yapabildiği için birkaç saniyelik kesinti bile trafik dalgasına dönüşebilir. Ayrıca uluslararası sistemlerde herkesin uyuduğu ortak bir bakım penceresi bulunmayabilir. Bu nedenle kritik sistemlerde deployment tasarımı uygulamanın ilk mimari kararlarından biri haline gelmelidir.

Finans

Finans uygulamalarında yarım kalan işlemler doğrudan parasal sonuç üretebilir. Bir ödeme talebi deployment sırasında kesilirse istemcinin tekrar denemesi duplicate transaction riskini artırabilir. Bu nedenle zero-downtime ile birlikte idempotency, transaction takibi ve güvenli retry tasarımı gerekir. Deployment sırasında aktif finansal işlemlerin tamamlanması için connection draining süreleri gerçek işlem sürelerine göre belirlenmelidir. Rollback kararı da yeni sürümün oluşturduğu finansal kayıtların eski sürüm tarafından doğru okunup okunamayacağı dikkate alınarak verilmelidir.

E-Ticaret

E-ticaret sistemlerinde birkaç dakikalık kesinti satış kaybı ve terk edilmiş sepet olarak geri dönebilir. Özellikle kampanya saatlerinde küçük hata oranları bile çok sayıda müşteriyi etkiler. Sepet ve kullanıcı session bilgisinin tek bir application instance belleğinde tutulması deployment sırasında session kaybına yol açabilir. Shared session store veya stateless token yaklaşımı bu riski azaltır. Sipariş, stok ve ödeme akışları için teknik metriklerin yanında dönüşüm oranı gibi business KPI'ları da release doğrulamasına dahil edilmelidir.

SaaS

SaaS ürünlerinde müşteriler sistemi farklı saat dilimlerinde sürekli kullanabilir. Bu nedenle klasik gece bakım penceresi yaklaşımı büyüdükçe sürdürülebilirliğini kaybeder. Tenant bazlı canary rollout, yeni sürümü önce küçük bir müşteri grubunda doğrulamak için yararlı olabilir. Ancak tenant'lar arasında ortak database veya queue kullanılıyorsa veri uyumluluğu dikkatle tasarlanmalıdır. Release sürecinin otomatik promotion ve rollback kriterleriyle yönetilmesi SaaS operasyonlarında ekip üzerindeki manuel yükü de azaltır.

Telekom

Telekom sistemleri yüksek istek hacmi ve kesintisiz bağlantı beklentisi nedeniyle deployment açısından özel dikkat ister. Uzun yaşayan bağlantılar yalnızca yeni HTTP isteklerini başka instance'a yönlendirmekle yönetilemez. Aktif bağlantıların drain edilmesi ve istemcinin güvenli şekilde yeniden bağlanabilmesi gerekir. Region bazlı rollout blast radius'u sınırlamak için yararlı bir yöntemdir. Teknik performans yanında çağrı, mesaj veya bağlantı başarı oranları release kriterlerine dahil edilmelidir.

Sağlık

Sağlık sistemlerinde erişilebilirlik kullanıcı konforunun ötesinde operasyonel süreklilik anlamına gelebilir. Kritik kayıtlara erişim deployment nedeniyle gereksiz yere kesilmemelidir. Veri bütünlüğü ve audit kayıtları her release sırasında korunmalıdır. Database migration işlemleri eski ve yeni uygulamanın birlikte çalışabileceği aşamalı bir modelle yapılmalıdır. Teknik ekipler deployment planını yalnızca uygulama sürümüne değil, bağımlı sistemler ve veri akışları üzerinden de değerlendirmelidir.

7/24 API Servisleri

Sürekli erişilebilir API'lerde bakım penceresi kavramı çoğu zaman pratik değildir. İstemciler farklı ülkelerde, farklı saatlerde ve farklı retry politikalarıyla servise erişebilir. Birkaç saniyelik hata bile otomatik retry nedeniyle beklenenden fazla yük oluşturabilir. Backward-compatible API sözleşmeleri eski ve yeni sürümün aynı anda trafik almasını kolaylaştırır. Sağlıklı bir rollout için error rate, latency ve dependency durumları sürüm bazında ölçülmelidir.

Sıfır Kesinti İçin Temel Mimari Gereksinimler

Sıfır kesinti için deployment aracından önce uygulamanın mimari davranışı hazırlanmalıdır. Tek instance çalışan bir serviste instance yeniden başladığında trafik alacak alternatif bulunmaz. Benzer şekilde session bellekte tutuluyorsa kullanıcı farklı instance'a yönlendirildiğinde oturum problemi yaşayabilir. API ve database değişiklikleri eski ve yeni sürümlerin bir süre birlikte yaşayacağı düşünülerek hazırlanmalıdır. Observability ve otomatik rollback ise sorun fark edildiğinde etkilenme alanını küçültür.

Birden Fazla Application Instance

En az iki uygulama instance'ı sıfır kesintiye yaklaşmanın temel koşullarından biridir. Bir instance güncellenirken diğerinin trafik taşımaya devam etmesi gerekir. Ancak yalnızca replica sayısını iki yapmak yeterli değildir. Kapasite planı tek instance kaybında kalan instance'ların yükü karşılayabileceğini doğrulamalıdır. Yoğun sistemlerde deployment sırasında ek kapasite oluşturmak için surge yaklaşımı kullanılabilir.

Load Balancer

Load balancer, trafiğin sağlıklı instance'lar arasında dağıtılmasını sağlar. Yeni instance hazır olmadan ona istek gönderilmemesi burada kritik öneme sahiptir. Aynı şekilde kapanacak instance yeni trafik almaktan çıkarılmalı ancak aktif taleplerini tamamlaması için süre verilmelidir. Blue-green dağıtımlarda load balancer trafik switch noktası olarak da kullanılabilir. Canary senaryolarında ise ağırlıklı trafik yönlendirmesi daha kontrollü bir rollout sağlar.

Health Check

Health check yalnızca process çalışıyor mu sorusunu yanıtlamamalıdır. Uygulamanın gerçekten trafik almaya hazır olup olmadığını gösterecek kontroller tasarlanmalıdır. Başlatılan process port açmış olsa bile cache hazırlığı veya gerekli initialization işlemleri tamamlanmamış olabilir. Load balancer veya Kubernetes readiness sonucu üzerinden bu instance'a trafik verip vermeyeceğine karar verir. Yanlış tasarlanmış health check, sağlam uygulamayı trafikten çıkarabileceği gibi hazır olmayan uygulamaya trafik de gönderebilir.

Stateless Application

Stateless uygulamalar instance değişimini daha kolay hale getirir. Kullanıcıya ait kritik durum application memory içinde tutulmadığında istekler farklı instance'lara güvenle yönlendirilebilir. Bu yaklaşım rolling ve canary deployment stratejilerinde esnekliği artırır. State gerekiyorsa Redis, database veya başka paylaşımlı bir katmanda tutulabilir. Böylece instance kapanması kullanıcı oturumunun veya devam eden iş akışının kaybolması anlamına gelmez.

Shared Session Store

Shared session store, birden fazla application instance'ın aynı oturum bilgisini kullanmasını sağlar. Kullanıcının ilk isteği eski sürüme, sonraki isteği yeni sürüme gitse bile session devam eder. Redis bu amaçla sık kullanılan seçeneklerden biridir. Session veri formatının da sürümler arasında uyumlu kalması gerekir. Aksi halde ortak store kullanıldığı halde yeni sürüm eski session kaydını okuyamayabilir.

Backward-Compatible API

Backward-compatible API, consumer uygulamaların yeni deployment nedeniyle kırılmamasını hedefler. Yeni alan eklemek genellikle mevcut alanı silmekten daha güvenlidir. Alan kaldırılması gerekiyorsa önce kullanımının sona erdiği doğrulanmalıdır. Mikroservislerde consumer-driven contract test bu uyumluluğun pipeline içinde kontrol edilmesine yardımcı olur. Eski ve yeni service sürümlerinin aynı anda çalışacağı düşüncesi API değişikliklerinin temel tasarım ilkesi olmalıdır.

Backward-Compatible Database

Database şeması deployment sırasındaki en kritik paylaşımlı bağımlılıklardan biridir. Rolling veya blue-green sırasında eski ve yeni uygulama aynı database'i kullanabilir. Bir column'ı doğrudan silmek veya rename etmek eski sürümü anında bozabilir. Bunun yerine additive değişiklikler ve expand-and-contract yaklaşımı tercih edilir. Contract adımı eski sürümün artık kullanılmadığı doğrulandıktan sonra ayrı bir release'te uygulanır.

Otomatik Rollback

Otomatik rollback, tanımlanmış hata eşikleri aşıldığında yeni sürümün geri çekilmesini sağlar. Bunun için önce hangi metriklerin release başarısını temsil ettiği belirlenmelidir. Sadece CPU yüksekliği çoğu zaman yeterli karar sinyali değildir. HTTP 5xx, latency ve domain-specific KPI birlikte değerlendirildiğinde daha güvenilir sonuç alınır. Database veya event schema değişikliği yapılmışsa rollback'ın gerçekten güvenli olup olmadığı ayrıca test edilmelidir.

Observability

Ölçemediğiniz rollout'u güvenli şekilde yönetmeniz zordur. Metrikler performansı, loglar uygulama davranışını ve distributed tracing servisler arası sorunları görünür hale getirir. Her deployment'a version label veya deployment ID eklemek eski ve yeni sürümü karşılaştırmayı kolaylaştırır. Release marker sayesinde hata artışının hangi deployment sonrasında başladığı hızla görülebilir. Monitoring tasarımı konusunda daha kapsamlı bir kaynak için https://www.diyarbakiryazilim.com.tr/posts/sunucu-izleme-monitoring-ve-alarm-mekanizmalari sayfası incelenebilir.

Zero-Downtime Deployment Nasıl Çalışır?

Temel zero-downtime akışında mevcut sürüm kullanıcı trafiğini taşımaya devam ederken yeni sürüm paralel olarak başlatılır. Yeni instance'lar hazır olmadan production trafiği almaz. Health check ve smoke test sonuçları olumlu olduğunda trafik kontrollü şekilde yeni sürüme yönelir. Bu sırada teknik ve business metrikleri izlenir. Yeni sürüm kararlı olduğunda eski sürüm yeni trafik almaktan çıkarılır ve aktif bağlantılarını tamamladıktan sonra kapatılır.

Mevcut Sürüm Trafik Alır

Deployment başladığında mevcut sürüm çalışmaya devam eder. Bu davranış kullanıcının yeni artifact hazırlanırken kesinti yaşamamasını sağlar. Eski sürüm yeterli kapasiteye sahip olmalıdır. Deployment öncesinde mevcut hata oranı baseline olarak kaydedilebilir. Böylece yeni sürüm sonrasındaki değişim daha doğru karşılaştırılır.

Yeni Sürüm Paralel Olarak Başlatılır

Yeni sürüm eski sürümü kapatmadan paralel biçimde ayağa kaldırılır. Container image veya başka immutable artifact önceden üretilmiş olmalıdır. Uygulama başlangıç sürecini tamamlayana kadar trafik dışında tutulur. Bu sırada environment configuration ve secret erişimleri doğrulanabilir. Startup problemi yaşanırsa eski sürüm hizmet vermeye devam ettiği için kullanıcı etkisi sınırlı kalır.

Health Check'ler Tamamlanır

Yeni instance'ın çalışıyor görünmesi onun production trafiğine hazır olduğu anlamına gelmez. Readiness kontrolleri kritik başlangıç koşullarının tamamlandığını doğrulamalıdır. Gerekiyorsa temel smoke request'leri de bu aşamada çalıştırılır. Kontrol başarısızsa promotion yapılmamalıdır. Pipeline yeni sürümü otomatik olarak durdurabilir veya önceki state'i koruyabilir.

Yeni Sürüm Production Trafiği Almaya Başlar

Yeni sürüm doğrulandıktan sonra kontrollü miktarda trafik almaya başlayabilir. Rolling deployment'ta trafik replica değişimiyle doğal olarak dağılır. Canary yaklaşımında yüzde veya kullanıcı segmenti üzerinden daha hassas kontrol mümkündür. İlk trafik oranının düşük tutulması blast radius'u sınırlar. Yüksek trafik alan sistemlerde küçük yüzdeler bile anlamlı örnek büyüklüğü sağlayabilir.

Metrikler İzlenir

Traffic shift sonrasında yalnızca pod durumuna bakmak yeterli değildir. HTTP hata oranı, P95 ve P99 latency, database hata oranı ve queue lag izlenmelidir. İşe özel KPI'lar da bu ölçüme eklenmelidir. Yeni sürüm baseline sürümle karşılaştırılabilir. Tanımlanmış threshold aşıldığında rollout durdurulmalı veya rollback tetiklenmelidir.

Eski Sürüm Trafikten Çıkarılır

Yeni sürüm yeterince doğrulandığında eski instance yeni trafik almaktan çıkarılır. Bu adım doğrudan process'i kapatmak anlamına gelmemelidir. Load balancer önce yeni request yönlendirmeyi durdurmalıdır. Var olan bağlantıların tamamlanması için drain süresi bırakılmalıdır. Böylece deployment sırasında aktif kullanıcı işlemlerinin kesilme ihtimali azalır.

Aktif Bağlantılar Drain Edilir

Connection draining, kapanacak instance üzerinde devam eden taleplere tamamlanma zamanı verir. Normal HTTP request'lerde birkaç saniye yeterli olabilir. WebSocket, SSE veya gRPC streaming bağlantılarında çok daha farklı bir strateji gerekir. Timeout değeri gerçek trafik davranışına göre belirlenmelidir. Sonsuza kadar drain beklemek de deployment'ın tamamlanmasını engelleyebileceği için üst sınır tanımlanmalıdır.

Eski Instance'lar Kapatılır

Eski instance aktif işlerini tamamladıktan sonra güvenli biçimde kapatılabilir. Uygulama SIGTERM sinyalini yakalamalı ve yeni iş kabulünü durdurmalıdır. Açık resource'lar kapatılmalı, gerekli flush işlemleri tamamlanmalıdır. Grace period sonunda hâlâ kapanmayan process zorla sonlandırılabilir. Bu davranış production trafik profiliyle önceden test edilmelidir.

Deployment Stratejileri Nelerdir?

Sıfır kesinti ile uygulama güncelleme yöntemleri nelerdir sorusunun tek bir cevabı yoktur. Rolling, blue-green, canary, shadow, feature flag ve progressive delivery farklı risk profillerine hitap eder. Seçim uygulamanın mimarisine, altyapı kapasitesine, trafik hacmine ve rollback gereksinimine göre yapılmalıdır. Blue-green canary ve rolling deployment stratejileri karşılaştırması yapılırken yalnızca deployment hızına bakmak yeterli olmaz. Database uyumluluğu, kullanıcı segmentasyonu ve operasyonel maliyet de kararın parçasıdır.

Recreate Deployment

Recreate yaklaşımı eski sürümü tamamen kapatıp ardından yeni sürümü başlatır. Uygulaması kolaydır ancak doğal olarak kesinti penceresi oluşturur. Development veya kısa kesintinin kabul edildiği dahili sistemlerde kullanılabilir. Kritik production servislerinde çoğu zaman uygun değildir. Çoklu replica ve rolling update modeline geçiş ilk iyileştirme adımı olabilir.

Rolling Deployment

Rolling deployment instance'ları kademeli olarak yeni sürümle değiştirir. Eski ve yeni sürüm belirli bir süre birlikte çalışır. Bu nedenle backward compatibility önem kazanır. Ek altyapı maliyeti blue-green modeline göre daha düşük olabilir. Kubernetes Deployment nesnesi bu modeli doğal olarak destekler.

Blue-Green Deployment

Blue-green yaklaşımında iki ayrı environment bulunur. Production trafiği mevcut ortamdayken yeni sürüm diğer ortamda hazırlanır. Testler tamamlandıktan sonra trafik bir bütün olarak yeni ortama geçirilir. Eski ortam rollback için kısa süre korunabilir. Hızlı cutover avantajına karşılık iki environment'ın kapasite maliyeti dikkate alınmalıdır.

Canary Deployment

Canary deployment yeni sürümü önce küçük trafik grubuna açar. Metrikler olumlu kaldıkça trafik oranı yükseltilir. Sorun görülürse rollout tüm kullanıcıları etkilemeden durdurulabilir. Bu yöntem özellikle yüksek trafik alan servislerde güçlü risk kontrolü sağlar. Sağlıklı canary için otomatik analiz ve açık success criteria gereklidir.

A/B Deployment

A/B deployment çoğunlukla ürün deneyi amacı taşır. Kullanıcı grupları farklı sürüm veya davranışlara yönlendirilir. Buradaki temel ölçüm reliability yerine business outcome olabilir. Conversion, engagement veya başka deney metrikleri izlenebilir. Canary ile benzer trafik segmentasyonu kullansa da hedefi farklıdır.

Shadow Deployment

Shadow deployment production trafiğinin bir kopyasını yeni sürüme gönderir. Yeni sürümün cevabı kullanıcıya dönmez. Böylece gerçek workload altında davranış gözlemlenebilir. Yazma işlemleri varsa side effect oluşmaması için özel önlem gerekir. Read-only veya etkisizleştirilmiş trafik shadow testlerinde daha güvenlidir.

Feature Flag Deployment

Feature flag deployment ile kodun production'a çıkması ile özelliğin kullanıcılara açılması ayrılır. Yeni kod pasif durumda deploy edilebilir. Ardından belirli kullanıcı grupları veya trafik yüzdesi için özellik etkinleştirilir. Sorun yaşandığında yeni deployment yapmadan flag kapatılabilir. Flag yaşam döngüsü yönetilmezse zamanla gereksiz teknik yük oluşabilir.

Progressive Delivery

Progressive delivery, yeni sürümün küçük adımlarla ve ölçümler üzerinden ilerletilmesini sağlar. Traffic shifting, automated analysis, promotion ve rollback aynı akışın parçalarıdır. Böylece release kararı yalnızca pipeline'ın başarılı çalışmasına bağlı kalmaz. Production davranışı gerçek karar girdisi haline gelir. Argo Rollouts ve service mesh entegrasyonları bu yaklaşımın Kubernetes ortamında uygulanmasını kolaylaştırabilir.

Recreate Deployment Nedir?

Recreate deployment, mevcut application instance'larının tamamını kaldırdıktan sonra yeni sürümü başlatan basit bir dağıtım modelidir. Mimari olarak anlaşılması kolaydır. Ancak eski ve yeni sürümün örtüşmediği bir zaman aralığı oluşur. Bu süre kullanıcı açısından doğrudan downtime anlamına gelebilir. Kesintinin kabul edilmediği production servislerinde daha gelişmiş rollout yöntemlerine geçilmelidir.

Recreate Nasıl Çalışır?

Önce çalışan eski instance'lar durdurulur. Ardından yeni artifact veya container image deploy edilir. Yeni uygulama başlatılır ve health check sonucu beklenir. Bu süre boyunca başka replica yoksa servis trafik karşılayamaz. Başlangıç hatası durumunda downtime planlanandan daha uzun sürebilir.

Neden Downtime Oluşturur?

Downtime oluşmasının nedeni eski ve yeni sürüm arasında çalışan instance kalmamasıdır. Application startup süresi doğrudan kesinti süresine eklenir. Migration işlemleri başlangıca bağlıysa bu süre daha da uzayabilir. Load balancer yönlendirebileceği sağlıklı backend bulamaz. Sonuç olarak kullanıcılar hata veya timeout ile karşılaşır.

Hangi Senaryolarda Kabul Edilebilir?

Development ortamları recreate deployment için uygun olabilir. Çok düşük öneme sahip dahili araçlarda da kısa bakım penceresi kabul edilebilir. Tek kullanıcılı sistemlerde işletme saatleri dışında planlı kapatma yeterli görülebilir. Burada karar teknik tercih değil iş gereksinimidir. Kullanıcı etkisi ve kesinti maliyeti yükseldikçe recreate yaklaşımından uzaklaşmak gerekir.

Recreate'ten Rolling Deployment'a Geçiş

Geçişin ilk adımı uygulamayı birden fazla instance ile çalışabilir hale getirmektir. Session ve local state bağımlılıkları belirlenmelidir. Load balancer ve doğru readiness kontrolü eklenmelidir. Eski ve yeni sürümün birlikte çalışabilmesi için API ve database compatibility sağlanmalıdır. Daha sonra rollout ayarları küçük adımlarla production trafik profili üzerinde test edilebilir.

Rolling Deployment Nedir?

Rolling deployment, instance'ların tamamını aynı anda değiştirmek yerine belirli bir hızla yeni sürüme geçiren yöntemdir. Kubernetes dünyasında en sık kullanılan rollout modellerinden biridir. Uygun replica sayısı ve readiness kontrolleriyle kullanıcı kesintisi büyük ölçüde önlenebilir. Bununla birlikte eski ve yeni sürüm bir süre beraber çalışır. Bu nedenle veri modeli ve API sözleşmeleri sürümler arasında uyumlu olmalıdır.

Rolling Update Nasıl Çalışır?

Controller yeni sürümden bir veya daha fazla instance oluşturur. Yeni instance hazır hale geldiğinde eski instance'lardan biri kaldırılır. Bu döngü tüm replica'lar yenilenene kadar devam eder. maxSurge ve maxUnavailable geçiş hızını ve kapasiteyi etkiler. Readiness başarısızsa rollout ilerlemesi durabilir.

Instance'ların Kademeli Değiştirilmesi

Kademeli değişim blast radius'u sınırlamanın basit yollarından biridir. Bir instance sorunluysa tüm kapasite aynı anda etkilenmez. Yeni sürüm küçük ölçekte production trafiği görmeye başlar. Ancak otomatik analiz yoksa problem yalnızca rollout yavaşladığı için kendiliğinden durmayabilir. Metrik bazlı gate eklemek güvenliği artırır.

Eski ve Yeni Sürümlerin Aynı Anda Çalışması

Rolling deployment'ın temel sonucu version skew durumudur. Bazı request'ler eski, bazı request'ler yeni sürüme gider. Paylaşılan database iki sürüm tarafından aynı anda kullanılabilir. API çağrıları farklı sürümler arasında gerçekleşebilir. Bu nedenle breaking change tek deployment içinde uygulanmamalıdır.

Rolling Deployment Avantajları

Rolling update ayrı bir tam environment gerektirmediği için kaynak kullanımı açısından verimli olabilir. Kubernetes tarafından doğal şekilde yönetilebilir. Küçük ekipler için başlangıç noktası olarak uygulanması görece kolaydır. Çoklu replica servislerde kesintisiz geçiş sağlayabilir. Deployment hızının rollout ayarlarıyla kontrol edilebilmesi de önemli bir avantajdır.

Rolling Deployment Dezavantajları

Eski ve yeni sürüm birlikte çalıştığı için compatibility gereksinimi yüksektir. Rollback sırasında instance'ların yeniden eski sürüme çevrilmesi zaman alabilir. Stateful workload'larda davranış daha dikkatli planlanmalıdır. Uygulama hatası yalnızca health check ile anlaşılmıyorsa rollout ilerlemeye devam edebilir. Bu nedenle production validation katmanı eklemek gerekir.

Rolling Deployment Ne Zaman Kullanılmalı?

Çoklu replica ve stateless servisler rolling update için iyi adaydır. Kaynak maliyetini sınırlı tutmak isteyen ekipler için de uygundur. Uygulama ve database backward-compatible değişikliklerle geliştirilebiliyorsa model daha güvenli çalışır. Çok hızlı tek adımlı rollback gerekiyorsa blue-green daha avantajlı olabilir. Riskin trafik yüzdesiyle daha ince yönetilmesi gerekiyorsa canary düşünülebilir.

Kubernetes Rolling Update Ayarları

Kubernetes ve CI/CD pipeline ile zero-downtime deployment nasıl uygulanır sorusunun önemli bölümlerinden biri Deployment strategy ayarlarının doğru seçilmesidir. Replica sayısı, maxSurge ve maxUnavailable uygulamanın rollout sırasındaki gerçek kapasitesini belirler. minReadySeconds kısa süreli sahte readiness sonuçlarının rollout'u hızla ilerletmesini engelleyebilir. progressDeadlineSeconds başarısız rollout'un sonsuza kadar beklemesini önler. Bu değerler kopyalanacak sabit reçeteler değil, uygulamanın startup süresi ve trafik karakteristiğine göre ayarlanacak operasyonel parametrelerdir.

replicas

replicas aynı anda kaç application pod'u çalıştırmak istediğinizi belirler. Tek replica ile pod değişimi sırasında kesinti riski yüksektir. En az iki replica çoğu web servisi için daha sağlıklı başlangıç sağlar. Ancak gerçek sayı kapasite hesabına göre belirlenmelidir. Bir pod eksildiğinde kalan pod'ların peak trafiği karşılayabilmesi kontrol edilmelidir.

maxSurge

maxSurge rollout sırasında desired replica sayısının üzerine kaç ek pod çıkılabileceğini belirler. Değer 1 veya yüzdesel biçimde tanımlanabilir. Ek kapasite yeni pod hazır olurken eski pod'u çalışır tutmayı kolaylaştırır. Cluster kaynakları sınırlıysa scheduler yeni pod için yer bulamayabilir. Bu nedenle maxSurge seçimi cluster headroom ile birlikte değerlendirilmelidir.

maxUnavailable

maxUnavailable rollout sırasında kaç replica'nın unavailable olabileceğini belirler. Zero-downtime hedefleyen kritik servislerde sıklıkla 0 tercih edilir. Böylece yeni pod hazır olmadan çalışan kapasite azaltılmaz. Ancak yanlış readiness veya kaynak yetersizliği rollout'un ilerlememesine neden olabilir. Değer availability hedefi ve cluster kapasitesiyle birlikte seçilmelidir.

minReadySeconds

minReadySeconds pod Ready olduktan sonra belirli süre sağlıklı kalmasını bekler. Bazı uygulamalar açıldıktan birkaç saniye sonra dependency veya cache problemi gösterebilir. Sıfır değeri bu tür geçici sorunları fark etmeden rollout'u hızlandırabilir. Uygulama davranışı biliniyorsa kısa bir stabilizasyon penceresi faydalıdır. Çok yüksek değer ise gereksiz deployment süresi yaratabilir.

progressDeadlineSeconds

progressDeadlineSeconds rollout'un ilerlemediğinin ne zaman başarısız sayılacağını belirler. Image pull sorunu, crash veya readiness başarısızlığı rollout'u durdurabilir. Pipeline bu durumu algılayıp otomatik müdahale edebilir. Değer uygulamanın normal startup ve readiness süresinden daha uzun seçilmelidir. Aksi halde sağlıklı ancak yavaş başlayan deployment hatalı biçimde başarısız sayılabilir.

revisionHistoryLimit

revisionHistoryLimit eski ReplicaSet geçmişinin ne kadar korunacağını belirler. Yeterli revision history hızlı rollback operasyonunu kolaylaştırır. Çok yüksek sayı gereksiz kaynak ve obje birikimine yol açabilir. Çok düşük sayı ise geçmiş sürüme dönme seçeneklerini sınırlayabilir. Release sıklığına ve rollback politikasına uygun bir değer seçilmelidir.

Zero-Downtime İçin Örnek RollingUpdate Politikası

Genel başlangıç yaklaşımı olarak maxUnavailable değerini 0 tutmak ve kontrollü surge kapasitesi kullanmak tercih edilebilir. Bu sayede mevcut sağlıklı replica sayısı yeni pod hazır olmadan azalmaz. Readiness probe gerçek trafik kabul koşulunu doğru göstermelidir. Graceful shutdown da eski pod kapanırken aktif request'leri korumalıdır. Production'a geçmeden önce bu politikanın yük testi altında doğrulanması gerekir.

maxUnavailable: 0

Bu ayar rollout sırasında kullanılabilir replica sayısının desired kapasitenin altına inmesini engeller. Yeni pod hazır olmadan eski pod kapatılmaz. Kesinti riskini azaltmak açısından güçlü bir varsayılandır. Cluster'da yeni pod için yeterli kaynak bulunması gerekir. Aksi halde rollout kapasite yetersizliği nedeniyle bekleyebilir.

maxSurge: 1 veya Yüzdesel Değer

maxSurge 1 küçük deployment'larda anlaşılır ve kontrollü bir davranış sağlar. Büyük replica sayılarında yüzdesel değer rollout'u hızlandırabilir. Örneğin onlarca pod bulunan bir serviste tek podluk surge gereksiz yavaş kalabilir. Yüzde seçilirken database ve diğer dependency'lerin geçici ek kapasiteyi karşılayabileceği doğrulanmalıdır. Rollout hızının yalnızca application CPU kapasitesiyle belirlenmemesi önemlidir.

Blue-Green Deployment Nedir?

Blue-green deployment iki ayrı ancak mümkün olduğunca eşdeğer application environment kullanır. Blue mevcut production sürümü temsil ederken Green yeni sürümün hazırlandığı ortam olabilir. Yeni ortam deployment, smoke test ve gerekli validation süreçlerinden geçer. Hazır olduğunda production trafiği yeni ortama geçirilir. Eski ortam kısa süre korunursa rollback işlemi yalnızca trafik yönünü geri çevirmek kadar hızlı olabilir.

Blue Environment

Blue çoğu senaryoda o anda kullanıcı trafiği alan aktif environment'tır. Uygulamanın mevcut production sürümü burada çalışır. Green hazırlanırken blue hizmet vermeye devam eder. Bu sayede deployment işlemi kullanıcı trafiğinden ayrılır. Traffic switch sonrasında blue rollback adayı olarak geçici süre saklanabilir.

Green Environment

Green yeni sürümün production trafiği almadan önce ayağa kaldırıldığı environment'tır. Configuration mümkün olduğunca blue ile aynı olmalıdır. Burada smoke test ve dependency kontrolleri yapılabilir. Green tamamen hazır hale gelmeden trafik switch gerçekleştirilmemelidir. Yeni sürüm aktif olduktan sonra roller bir sonraki release'te tersine dönebilir.

Yeni Sürümü Pasif Ortamda Hazırlamak

Pasif ortam hazırlığı deployment riskini kullanıcı trafiğinden ayırır. Image pull, startup veya configuration hataları aktif production'ı doğrudan etkilemez. Uygulama tüm bağımlılıklarıyla ayağa kaldırılabilir. Database ortak kullanılıyorsa migration tasarımı yine backward-compatible olmalıdır. Pasif environment application riskini azaltır ancak paylaşılan dependency riskini otomatik olarak ortadan kaldırmaz.

Production Benzeri Test

Green ortamın production ile aynı configuration ve dependency modeline yakın olması önemlidir. Smoke test kritik endpoint'lerin temel davranışını doğrular. Authentication, database read/write ve dış servis bağlantıları kontrol edilebilir. Ancak gerçek production trafiği görülmediği için her hata önceden yakalanamaz. Bu nedenle switch sonrasında yoğun observability ve gerektiğinde hızlı rollback gerekir.

Traffic Switch

Traffic switch blue-green deployment'ın kritik anıdır. Load balancer, reverse proxy, Kubernetes Service veya service mesh üzerinden yapılabilir. Switch mümkün olduğunca atomik ve geri alınabilir olmalıdır. DNS tabanlı değişikliklerde cache nedeniyle geçiş aynı anda tamamlanmayabilir. Switch sonrasında yeni environment'ın hata ve latency değerleri hemen izlenmelidir.

Eski Ortamı Rollback İçin Saklamak

Eski environment'ı kısa süre açık tutmak rollback süresini önemli ölçüde azaltır. Yeni sürüm sorun çıkarırsa trafik tekrar eski ortama yönlendirilebilir. Ancak database şeması veya yeni sürümün yazdığı veri eski uygulamayla uyumsuzsa bu rollback güvenli olmayabilir. Bu nedenle rollback yalnızca infrastructure switch olarak düşünülmemelidir. Veri ve external side effect uyumluluğu release tasarımının başında değerlendirilmelidir.

Blue-Green Deployment Avantajları

Blue-green yaklaşımının en güçlü yönü deployment ile traffic cutover işlemini birbirinden ayırmasıdır. Yeni sürüm kullanıcı trafiği almadan önce hazırlanıp doğrulanabilir. Traffic switch hızlıdır ve eski environment korunuyorsa rollback da hızlı olabilir. Ortam izolasyonu başlangıç ve configuration sorunlarının aktif production'ı doğrudan bozmasını önler. Bunun bedeli ise geçici olarak iki production kapasitesine yakın altyapı ihtiyacıdır.

Çok Hızlı Cutover

Yeni environment zaten hazır olduğu için kullanıcı trafiğinin geçişi deployment süresinden bağımsızdır. Load balancer veya service selector değişikliği kısa sürede tamamlanabilir. Application startup süresi kullanıcı cutover penceresine yansımaz. Bu davranış planlanabilir release süreci sağlar. DNS gibi cache etkisi bulunan yöntemler gerçek anlamda anlık geçiş için daha az uygundur.

Hızlı Rollback

Eski environment açık tutuluyorsa rollback yalnızca traffic route'u geri çevirmek olabilir. Bu işlem yeni container'ların yeniden oluşturulmasından daha hızlıdır. Ancak database migration veya side effect varsa application rollback'ının veri rollback'ıyla aynı şey olmadığı unutulmamalıdır. Rollback runbook'u release öncesinde test edilmelidir. Gerçek güvenlik, switch hızından çok eski sürümün yeni state'i okuyabilmesine bağlıdır.

Production Benzeri Test

Green ortam production configuration ile ayağa kaldırıldığı için deployment artifact'i gerçek koşullara yakın biçimde doğrulanır. Integration ve smoke test burada çalıştırılabilir. Load balancer'a eklenmeden dependency erişimleri kontrol edilebilir. Bu durum environment kaynaklı sürprizleri azaltır. Yine de gerçek kullanıcı davranışı ancak trafik geçtikten sonra görülebilir.

Ortam İzolasyonu

Blue ve green birbirinden ayrıldığında yeni sürümün process veya runtime problemleri aktif sürümü doğrudan bozmaz. Container, configuration ve dependency ayarları ayrı doğrulanabilir. Ancak shared database veya shared queue gibi bileşenler izolasyonu azaltabilir. Bu paylaşımlı katmanlar iki sürümle uyumlu kalmalıdır. İzolasyon sınırlarının mimari diyagram üzerinde açıkça gösterilmesi faydalıdır.

Deployment Süresince Kullanıcı Kesintisinin Önlenmesi

Yeni environment hazırlanırken mevcut production normal biçimde trafik taşır. Kullanıcı deployment'ın image pull veya startup aşamalarından etkilenmez. Switch yalnızca yeni ortam hazır olduğunda gerçekleştirilir. Connection draining doğru yapılırsa aktif işlemler de korunabilir. Bu nedenle blue-green yüksek erişilebilirlik beklentisi bulunan servislerde güçlü bir seçenektir.

Blue-Green Deployment Dezavantajları

Blue-green her sistem için varsayılan çözüm değildir. İki environment çalıştırmak altyapı maliyetini artırabilir. Stateful sistemlerde iki ortamın aynı veri katmanıyla nasıl çalışacağı ciddi tasarım gerektirir. Büyük mikroservis platformlarında tüm stack'i ikiye katlamak operasyonel ve finansal açıdan ağır olabilir. Ayrıca tüm trafiğin bir anda yeni sürüme geçmesi canary modeline kıyasla daha geniş blast radius oluşturur.

İki Kat Altyapı Gereksinimi

Yeni ortam aktif olmadan önce mevcut ortamla birlikte çalışır. Bu nedenle geçiş anında yaklaşık iki kat application kapasitesi gerekebilir. Büyük sistemlerde maliyet önemli hale gelir. Otomatik scaling ve geçici kapasite modeli maliyeti azaltabilir. Yine de cluster, database connection ve diğer dependency limitleri önceden hesaplanmalıdır.

Stateful Sistem Karmaşıklığı

Application environment'ı ikiye ayırmak database state'ini otomatik olarak ikiye ayırmaz. İki sürüm aynı tablo veya queue üzerinde işlem yapabilir. Veri formatı değişiklikleri bu yüzden risklidir. Stateful workload için migration ve failback senaryoları ayrıca tasarlanmalıdır. Uygulama katmanındaki hızlı switch veri katmanında aynı hızda geri dönüş anlamına gelmez.

Database Paylaşımı

Blue ve green aynı database'i kullanıyorsa schema her iki sürümle uyumlu olmalıdır. Breaking migration yeni environment daha aktif olmadan eski production'ı bozabilir. Expand-and-contract bu problemi azaltmak için güçlü bir yöntemdir. Yeni column önce eklenir ve eski column bir süre korunur. Contract işlemi eski sürümün artık çalışmayacağı doğrulandıktan sonra yapılır.

Büyük Mikroservis Sistemlerinde Maliyet

Onlarca veya yüzlerce servis bulunan platformlarda tüm environment'ı kopyalamak pahalı olabilir. Her servisin aynı anda blue-green modeli kullanması gerekli değildir. Kritik servisler için blue-green, diğer servisler için rolling yaklaşımı seçilebilir. Servis bağımlılıkları bu karma modeli destekleyecek şekilde backward-compatible olmalıdır. Maliyet hesabı yalnızca compute değil database connection, cache ve network kapasitesini de içermelidir.

Tüm Trafiği Bir Anda Yeni Sürüme Geçirmenin Riski

Blue-green switch genellikle trafiğin büyük bölümünü kısa sürede yeni sürüme taşır. Staging testlerinde görülmeyen hata bir anda tüm kullanıcıları etkileyebilir. Bu yüzden switch sonrası otomatik rollback kriterleri önemlidir. Bazı ekipler blue-green ortamlarını weighted traffic ile birleştirerek canary benzeri geçiş uygular. Böylece environment izolasyonu korunurken risk daha küçük adımlarla yönetilebilir.

Blue-Green Traffic Switching Nasıl Yapılır?

Traffic switching için kullanılabilecek yöntem altyapı katmanına göre değişir. Load balancer, reverse proxy, Kubernetes Service, Ingress veya service mesh genellikle hızlı ve kontrol edilebilir seçenekler sunar. DNS değişikliği de kullanılabilir ancak TTL ve client cache nedeniyle gerçek anlık geçiş garanti edilmez. Seçilen mekanizma rollback sırasında aynı hız ve güvenilirlikle tersine çevrilebilmelidir. Connection draining desteği de değerlendirme kriterleri arasında bulunmalıdır.

Load Balancer ile

Load balancer backend pool veya target group değiştirerek blue-green switch yapabilir. Yeni environment health check'leri geçtikten sonra aktif target haline getirilir. Eski target'lar yeni trafik almaktan çıkarılır. Connection draining açık bağlantıların tamamlanmasına izin verir. Rollback gerektiğinde eski backend pool tekrar aktif hale getirilebilir.

Reverse Proxy ile

Reverse proxy upstream configuration değişikliği üzerinden trafiği yeni environment'a yönlendirebilir. Configuration reload mümkünse aktif bağlantıları kesmeden yapılmalıdır. NGINX veya HAProxy gibi katmanlarda bu model sık görülür. Health check ve upstream state doğru yönetilmelidir. Configuration değişiklikleri version control üzerinden izlenirse rollback daha güvenli olur.

Kubernetes Service Selector ile

Kubernetes Service selector label değerini değiştirerek blue ve green pod grupları arasında trafik taşınabilir. Yeni pod'lar farklı version label ile hazırlanır. Validation tamamlandıktan sonra Service yeni label'a yönlendirilir. Endpoint propagation sırasında kısa geçiş davranışı test edilmelidir. Graceful shutdown eski pod'ların aktif isteklerini korumaya devam etmelidir.

Ingress ile

Ingress katmanı host veya path routing üzerinden yeni environment'a trafik yönlendirebilir. Bazı controller'lar weighted traffic desteği de sağlar. Bu özellik blue-green ile canary yaklaşımını birleştirmeye yardımcı olabilir. Controller reload davranışı ve connection handling production öncesinde test edilmelidir. TLS ve session affinity ayarları da geçiş tasarımına dahil edilmelidir.

Service Mesh ile

Service mesh trafik ağırlığını application deployment'ından ayrı yönetebilir. Yüzdesel routing, header routing ve retry politikaları daha merkezi biçimde tanımlanabilir. Canary ve progressive delivery akışlarında bu önemli esneklik sağlar. Ancak service mesh operasyonel yük ve yeni failure mode'lar da ekler. Platform ekibinin observability ve troubleshooting pratiği bu nedenle güçlü olmalıdır.

DNS ile

DNS üzerinden hostname yeni environment IP veya endpoint'ine yönlendirilebilir. Uygulaması basit görünse de cache davranışı geçişi öngörülemez hale getirebilir. Resolver ve client'lar TTL değerine her zaman beklenen biçimde uymayabilir. Bu nedenle anlık rollback ihtiyacı bulunan sistemlerde tek başına DNS zayıf kalabilir. Global traffic management senaryolarında ise başka mekanizmalarla birlikte faydalı olabilir.

DNS TTL Problemi

TTL değeri DNS kaydının ne kadar süre cache'te tutulacağını belirtir. Düşük TTL geçişi hızlandırabilir ancak tüm client'ların aynı anda yeni kaydı almasını garanti etmez. Bazı resolver'lar kayıtları beklenenden uzun saklayabilir. Bu durum blue ve green ortamlarının geçiş boyunca birlikte trafik almasına neden olabilir. Her iki environment da bu dönem için uyumlu tutulmalıdır.

DNS Cache Nedeniyle Gerçek Anlamda Anlık Switch Yapılamaması

DNS update merkezi olarak hızlı gerçekleşse bile client cache sonucu gecikmeli olabilir. Mobil ağlar ve kurumsal resolver'lar farklı cache süreleri uygulayabilir. Böylece eski endpoint saatler boyunca az miktarda trafik almaya devam edebilir. Eski environment'ı hemen kapatmak bu kullanıcılara hata döndürür. Bu nedenle DNS tabanlı rollout'ta overlap süresi planlanmalıdır.

Canary Deployment Nedir?

Canary deployment yeni sürümü önce sınırlı bir production trafik grubuna açar. Amaç sorun varsa tüm kullanıcılar etkilenmeden erken sinyal almaktır. Trafik yüzdesi, tenant, region veya kullanıcı özelliği üzerinden segment oluşturulabilir. Başarı kriterleri karşılandıkça rollout adım adım büyütülür. Sıfır Kesinti (Zero-Downtime) Dağıtım Stratejileri içinde risk kontrolü açısından en güçlü yöntemlerden biri olarak görülebilir.

Küçük Kullanıcı Grubuyla Başlamak

İlk canary adımı mümkün olduğunca küçük ancak ölçüm için anlamlı olmalıdır. Yüksek trafik alan servislerde yüzde 1 bile binlerce request üretebilir. Düşük trafikte ise aynı oran yeterli örnek oluşturmayabilir. Kullanıcı grubunun risk seviyesi de düşünülmelidir. Internal employee veya beta kullanıcı grubu ilk aşama için daha uygun olabilir.

Trafiği Kademeli Artırmak

Canary rollout tek adımda yüzde 1'den yüzde 100'e çıkmamalıdır. Her aşamada yeterli ölçüm penceresi bırakılmalıdır. Örneğin yüzde 1, 5, 25, 50 ve 100 adımları kullanılabilir. Trafik arttıkça yüksek yük altında ortaya çıkan sorunlar gözlenebilir. Her promotion kararı tanımlı teknik ve business threshold'lara dayanmalıdır.

Canary Success Criteria

Success criteria rollout başlamadan önce tanımlanmalıdır. HTTP 5xx oranı, P95 latency ve database error rate sık kullanılan metriklerdir. Domain-specific KPI daha da değerli olabilir. Ödeme servisinde ödeme başarı oranı doğrudan karar girdisi yapılabilir. Tek bir metriğe bağlı promotion yerine birkaç sinyalin birlikte kullanılması daha güvenlidir.

Canary Abort

Abort yeni sürüm rollout'unun durdurulması anlamına gelir. Error threshold aşıldığında otomatik tetiklenebilir. Yeni canary replica'larına trafik gönderimi kesilir. Eski stable sürüm tüm trafiği yeniden alır. Incident kaydı ve deployment bilgisi otomatik olarak ilişkilendirilirse inceleme süreci hızlanır.

Full Promotion

Full promotion tüm trafik başarıyla doğrulanan yeni sürüme aktarıldığında gerçekleşir. Son adım öncesinde sistemin peak yük davranışı değerlendirilmelidir. Yüzde 50 seviyesinde görülmeyen kapasite sorunu yüzde 100'de ortaya çıkabilir. Promotion sonrası observation window bırakmak yararlıdır. Eski sürüm tamamen kaldırılmadan önce rollback gereksinimi değerlendirilmelidir.

Canary Rollback

Canary rollback yeni sürümün trafik oranını sıfıra indirerek stable sürüme dönmeyi hedefler. Code-only hata durumlarında genellikle güvenlidir. Database veya event schema değişikliği yapıldıysa durum farklıdır. Yeni sürümün oluşturduğu verinin eski sürümle uyumluluğu kontrol edilmelidir. Bazen hızlı bir roll-forward, teknik olarak rollback'tan daha güvenli çözüm olabilir.

Canary Traffic Dağılımı Nasıl Planlanır?

Canary yüzdeleri rastgele seçilmemelidir. Amaç her aşamada yeterli örnek alırken etkilenebilecek kullanıcı sayısını sınırlamaktır. Trafik hacmi, hata oranının normal seviyesi ve ölçüm süresi planı etkiler. Düşük trafik sistemlerinde yüzdesel rollout yerine belirli kullanıcı veya tenant seçimi daha anlamlı olabilir. Yüksek trafikte küçük yüzdeler bile kısa zamanda istatistiksel açıdan güçlü sinyal verebilir.

%1 → %5 → %25 → %50 → %100

Bu akış pratik bir başlangıç örneğidir. Yüzde 1 temel production doğrulaması için kullanılır. Yüzde 5 ve 25 aşamalarında daha geniş trafik davranışı ölçülür. Yüzde 50 iki sürümü karşılaştırmak için güçlü bir pencere oluşturur. Yüzde 100'e geçmeden önce hata ve business KPI değerlerinin baseline ile uyumlu olduğu doğrulanmalıdır.

Her Aşamada Bekleme Süresi

Bekleme süresi uygulamanın trafik hızına ve hata tiplerine bağlıdır. Dakikada yüz bin request alan sistemde birkaç dakika yeterli sinyal verebilir. Düşük trafik servisinde aynı süre anlamsız olabilir. Bazı problemler cache expiry veya background job döngüsü sonrasında ortaya çıkar. Measurement window bu davranışları kapsayacak uzunlukta seçilmelidir.

Minimum Sample Size

Minimum sample size hatalı kararların azaltılmasına yardımcı olur. On request üzerinden yüzde sıfır hata görmek güçlü sinyal değildir. Pipeline promotion kararını hem süre hem request sayısı koşuluna bağlayabilir. Domain event sayısı HTTP request sayısından daha uygun ölçüm olabilir. Örneğin ödeme servisi için minimum başarılı işlem sayısı ayrıca tanımlanabilir.

Düşük Trafikli Sistemlerde Canary Problemi

Düşük trafikte küçük yüzdeler yeterli veri üretmez. Birkaç kullanıcı hatası oranı gereğinden fazla değiştirebilir. Promotion gereksiz uzun sürebilir. Bu durumda internal users, synthetic traffic veya tenant-based rollout tercih edilebilir. Ayrıca staging load testleri production canary sinyallerini desteklemek için kullanılabilir.

Yüksek Trafikli Sistemlerde Canary Avantajı

Yüksek trafik küçük canary yüzdelerinde bile hızlı veri üretir. Yüzde 1 trafik yeni sürümün performans karakteristiğini kısa zamanda gösterebilir. Blast radius düşük kalırken güçlü istatistiksel sinyal elde edilir. Otomatik analiz bu ortamda özellikle etkili çalışır. Ancak alert threshold'ları normal trafik varyasyonuna göre kalibre edilmelidir.

Canary Kullanıcıları Nasıl Seçilir?

Canary grubu yalnızca rastgele yüzdeden oluşmak zorunda değildir. Header, cookie, user ID, tenant, çalışan hesabı veya region gibi özelliklerle kontrollü segment oluşturulabilir. Hangi yöntemin seçileceği ürün yapısına ve risk dağılımına bağlıdır. Örneğin kurumsal SaaS sisteminde önce internal tenant üzerinden doğrulama yapmak daha güvenli olabilir. Segment seçiminin production trafik çeşitliliğini yeterince temsil edip etmediği de değerlendirilmelidir.

Rastgele Trafik Yüzdesi

Rastgele yüzde yönlendirmesi en genel canary yöntemidir. Her request belirli olasılıkla yeni sürüme gönderilir. Stateless servislerde uygulanması kolaydır. Session veya multi-step işlem varsa aynı kullanıcının farklı sürümlere gitmesi sorun yaratabilir. Bu durumda sticky routing veya kullanıcı bazlı segment daha uygun olabilir.

Header Bazlı Routing

Belirli HTTP header taşıyan istekler canary sürüme yönlendirilebilir. Internal test ekipleri özel header ile yeni sürümü production ortamında deneyebilir. Normal kullanıcı trafiği stable sürümde kalır. Header'ın dış kullanıcı tarafından kolayca manipüle edilmesi güvenlik açısından değerlendirilmelidir. Bu yöntem genellikle ilk doğrulama adımı için kullanışlıdır.

Cookie Bazlı Routing

Cookie bazlı routing aynı kullanıcının canary sürümde kalmasını sağlayabilir. Web uygulamalarında tutarlı deneyim sağlar. Cookie'nin domain, expiration ve security ayarları doğru yapılandırılmalıdır. API istemcileri cookie kullanmıyorsa yöntem uygun olmayabilir. Release tamamlandığında eski routing cookie'lerinin temizlenmesi de planlanmalıdır.

User ID Bazlı Routing

User ID ile deterministik segment oluşturulabilir. Aynı kullanıcı her istekte aynı sürüme yönlenir. Multi-step kullanıcı akışlarında bu özellik yararlıdır. Hash tabanlı dağıtım yüzdeleri kontrollü biçimde artırılabilir. Kullanıcı kimliğinin routing katmanına güvenli biçimde aktarılması gerekir.

Tenant Bazlı Routing

Multi-tenant SaaS ortamlarında rollout tenant bazında yapılabilir. Önce dahili veya düşük riskli tenant'lar seçilebilir. Sorun çıktığında etkilenme alanı açık biçimde tanımlıdır. Shared database kullanılıyorsa schema yine tüm tenant ve sürümler için uyumlu olmalıdır. Büyük tenant'ların trafik ağırlığı hesaba katılmadan yalnızca tenant sayısıyla yüzde hesaplamak yanıltıcı olabilir.

Internal Employee

Şirket çalışanları production release'in ilk kullanıcı grubu olabilir. Bu yaklaşım gerçek production altyapısında erken geri bildirim sağlar. Kullanıcı etkisi dış müşterilere ulaşmadan birçok sorun görülebilir. Ancak çalışan davranışı gerçek müşteri trafiğini tam temsil etmeyebilir. Internal aşamadan sonra kontrollü gerçek kullanıcı canary'si yine gereklidir.

Beta Kullanıcı

Beta programına katılan kullanıcılar yeni özellikleri erken denemeyi kabul etmiş gruptur. Canary rollout bu kullanıcılarla başlayabilir. Ürün davranışı ve reliability birlikte gözlenebilir. Beta kullanıcı sayısı düşükse teknik metrikler için yeterli sample oluşmayabilir. Bu nedenle rollout yüzdesi ve kullanıcı segmenti birlikte kullanılabilir.

Region Bazlı Rollout

Region rollout çok bölgeli sistemlerde blast radius'u coğrafi olarak sınırlar. Önce küçük veya daha düşük riskli region seçilebilir. Database replication ve cross-region dependency davranışı dikkatle izlenmelidir. Region başarılıysa sıradaki bölgeye geçilir. Global rollback mekanizmasının da her aşamada çalışabilir durumda olması gerekir.

Blue-Green ve Canary Arasındaki Fark

Blue-green ve canary aynı problemi farklı risk modeliyle çözer. Blue-green yeni environment'ı tamamen hazırlar ve ardından büyük bir traffic switch uygular. Canary ise yeni sürümün trafik payını kademeli biçimde yükseltir. Blue-green hızlı rollback ve environment izolasyonu sağlarken canary blast radius kontrolünde öne çıkar. Hangi yöntemin uygun olduğu altyapı maliyeti, trafik miktarı ve release riskine göre belirlenmelidir.

Traffic Switching

Blue-green modelinde trafik genellikle tek veya birkaç büyük adımda yeni environment'a geçer. Canary modelinde küçük yüzdeler kullanılır. Bu fark problem ortaya çıktığında etkilenen kullanıcı sayısını doğrudan etkiler. Weighted routing altyapısı varsa iki yaklaşım birleştirilebilir. Örneğin Green environment önce yüzde 5 trafik alarak doğrulanabilir.

Blast Radius

Canary'nin temel avantajı blast radius'u küçük tutabilmesidir. Yüzde 1 rollout'ta ciddi hata olsa bile kullanıcıların çoğu stable sürümde kalır. Blue-green tam switch sonrası sorun varsa tüm trafik etkilenebilir. Buna karşılık hızlı rollback etkilenme süresini kısaltabilir. Kritik sistemlerde blast radius ve rollback süresi birlikte değerlendirilmelidir.

Rollback Hızı

Blue-green eski environment hazır tutulduğunda çok hızlı rollback sağlar. Canary'de de traffic weight sıfıra çekilerek hızlı geri dönüş yapılabilir. Ancak rolling benzeri replica dönüşümü gerekiyorsa süreç daha uzun sürebilir. Her iki modelde database uyumluluğu rollback güvenliğinin asıl belirleyicisidir. Trafiği geri çevirebilmek veriyi otomatik olarak eski haline getirmez.

Altyapı Maliyeti

Blue-green çoğu zaman iki environment kapasitesi gerektirir. Canary mevcut cluster içinde birkaç yeni replica ile başlayabilir. Bu nedenle canary compute açısından daha ekonomik olabilir. Ancak gelişmiş traffic management ve metric analysis altyapısı operasyonel yatırım gerektirir. Toplam maliyet yalnızca sunucu sayısı üzerinden hesaplanmamalıdır.

Validation Süresi

Blue-green green environment üzerinde kapsamlı test yapmaya izin verir. Ancak gerçek kullanıcı trafiği cutover sonrasında gelir. Canary production traffic altında aşamalı doğrulama yapar. Bu nedenle rollout süresi daha uzun olabilir. Kritik servislerde daha uzun validation süresi kabul edilebilir bir güvenlik bedelidir.

Kullanıcı Segmentasyonu

Canary kullanıcı segmentasyonu konusunda daha esnektir. Tenant, user ID veya region bazlı rollout yapılabilir. Blue-green çoğunlukla environment seviyesinde düşünülür. Weighted routing eklendiğinde blue-green de segmentli hale getirilebilir. Tasarımın amacı araç isimlerine bağlı kalmak yerine release riskini yönetmek olmalıdır.

Hangi Senaryoda Hangisi Tercih Edilmeli?

Hızlı cutover ve hızlı environment rollback önemliyse blue-green güçlü seçenektir. Yüksek trafik ve düşük blast radius hedefleniyorsa canary daha uygun olabilir. Kaynak maliyeti sınırlıysa rolling deployment da yeterli çözüm olabilir. Stateful workload ve database migration modeli her durumda kararı etkiler. En iyi yöntem çoğu platformda tek strateji değil, servis tipine göre seçilen bir kombinasyondur.

Rolling vs Blue-Green vs Canary Karşılaştırması

Rolling, blue-green ve canary yöntemlerinin hiçbiri her uygulama için tek başına en iyi çözüm değildir. Rolling kaynak verimliliği ve sadelik sunar. Blue-green hızlı cutover ile güçlü rollback seçeneği sağlar. Canary ise riskin gerçek traffic üzerinden küçük adımlarla ölçülmesine olanak tanır. Kurumsal zero-downtime deployment ve DevOps otomasyon hizmeti planlanırken servislerin risk profiline göre farklı stratejiler birlikte kullanılabilir.

Downtime

Üç yöntem de doğru tasarlandığında kullanıcı kesintisini önleyebilir. Rolling için yeterli replica ve readiness gerekir. Blue-green için traffic switch ve draining doğru çalışmalıdır. Canary için stable kapasite rollout boyunca korunmalıdır. Database breaking change varsa deployment stratejisi ne olursa olsun downtime veya hata oluşabilir.

Deployment Riski

Canary riski en küçük trafik yüzdesiyle başlatabildiği için güçlü kontrol sağlar. Rolling riski instance bazında yayar. Blue-green validation'ı production dışında yapar ancak cutover sonrası geniş kullanıcı kitlesi etkilenebilir. Otomatik metric analysis tüm modellerin riskini azaltır. Risk seviyesi yalnızca strategy adıyla değil uygulama mimarisiyle belirlenir.

Infrastructure Cost

Blue-green genellikle en fazla geçici kapasiteyi ister. Rolling mevcut kapasiteye küçük surge ekleyerek çalışabilir. Canary de sınırlı yeni replica ile başlayabilir. Ancak service mesh veya gelişmiş observability maliyeti canary'nin platform yükünü artırabilir. Compute ve operasyon maliyeti beraber değerlendirilmelidir.

Rollback Complexity

Blue-green trafik switch'i geri çevirebildiği için code rollback açısından basittir. Canary traffic weight'i stable sürüme çekebilir. Rolling rollback eski image'ın yeniden kademeli yayılmasını gerektirebilir. Database değişikliği varsa üçünde de ek risk bulunur. Bu nedenle rollback stratejisi migration tasarımından ayrı ele alınmamalıdır.

Backward Compatibility Gereksinimi

Rolling modelde eski ve yeni sürüm doğrudan birlikte çalıştığı için compatibility zorunludur. Canary'de de aynı durum vardır. Blue-green tam ayrılmış gibi görünse de shared database nedeniyle eski sürüm rollback için uyumlu kalmalıdır. API consumer'ları deployment anında güncellenmiyorsa compatibility yine gereklidir. Sonuç olarak production sistemlerinin çoğunda backward compatibility temel prensiptir.

Stateful Workload Uyumluluğu

Stateful workload üç modelde de ek planlama ister. Persistent volume, leader election ve distributed lock davranışları rollout sırasında değişebilir. Database node değişimi application deployment'ından farklı strateji gerektirir. Queue consumer'ların in-flight message işlemleri korunmalıdır. Stateful servis için readiness kadar safe termination mekanizması da önemlidir.

Operasyonel Karmaşıklık

Rolling en az yeni altyapı bileşeniyle başlayabilir. Blue-green environment yönetimi ve switching mekanizması gerektirir. Canary traffic splitting ve metric analysis nedeniyle daha gelişmiş otomasyon ister. Progressive delivery bu operasyonları standartlaştırabilir. Ekibin gözlemleme ve incident response yetkinliği kullanılan yöntem kadar önemlidir.

Progressive Delivery Nedir?

Progressive delivery release'in production ortamında ölçümlerle kontrollü biçimde ilerletilmesini ifade eder. Continuous delivery kodun güvenle deploy edilebilir olmasını hedeflerken progressive delivery gerçek kullanıcı trafiğini promotion kararına dahil eder. Trafik küçük yüzdelerle yeni sürüme yönlendirilir. Automated analysis belirlenmiş metrikleri değerlendirir. Sonuç olumluysa rollout ilerler, olumsuzsa durur veya geri alınır.

Continuous Delivery'den Farkı

Continuous delivery artifact'in güvenle production'a çıkabilecek durumda olmasını sağlar. Progressive delivery deployment sonrası trafik davranışını da kontrol mekanizmasına ekler. Pipeline başarıyla tamamlanmış olsa bile production metriği bozulursa promotion yapılmaz. Bu durum release güvenliğini artırır. İki yaklaşım birbirinin alternatifi değil, tamamlayıcısıdır.

Risk Kontrollü Release

Yeni sürüm önce küçük kullanıcı grubuna açılır. Problem varsa etkilenen kullanıcı sayısı sınırlı kalır. Release riskinin tamamı tek anda production'a yüklenmez. Traffic step ve metric threshold'ları risk seviyesine göre değiştirilebilir. Kritik ödeme servisi ile düşük riskli içerik servisi aynı rollout politikasına sahip olmak zorunda değildir.

Traffic Shifting

Traffic shifting yeni ve stable sürüm arasındaki trafik oranını yönetir. Service mesh veya ingress controller bu görevi üstlenebilir. Yüzde bazlı adımlar otomatik pipeline tarafından değiştirilebilir. Kullanıcı veya tenant segmentleriyle de routing yapılabilir. Her adım sonrası yeterli observation window bırakılmalıdır.

Automated Analysis

Automated analysis deployment kararını insan gözleminin ötesine taşır. Sistem belirli metrikleri düzenli aralıklarla toplar. Canary sürüm baseline ile karşılaştırılabilir. Threshold aşılırsa rollout durdurulabilir. Yanlış threshold çok sık abort veya hatalı promotion üretebileceği için sürekli kalibrasyon gerekir.

Automated Promotion

Promotion success criteria karşılandığında sonraki trafik aşamasına geçiştir. Manuel onay gereksinimi risk seviyesine göre korunabilir. Düşük riskli servisler tamamen otomatik ilerleyebilir. Kritik production servislerinde belirli aşamada insan onayı tercih edilebilir. Promotion olayları audit edilebilir biçimde kaydedilmelidir.

Automated Rollback

Rollback tanımlı failure koşullarında stable sürümü yeniden aktif hale getirir. Traffic weight hızlı biçimde eski sürüme döndürülebilir. Alert ve incident kaydı aynı anda tetiklenebilir. Veri değişikliği varsa otomatik rollback öncesinde güvenlik koşulları daha sınırlayıcı olmalıdır. Bazı hatalarda yeni sürümün düzeltilip roll-forward yapılması daha doğru seçenek olabilir.

Argo Rollouts ile Progressive Delivery

Argo Rollouts Kubernetes üzerinde gelişmiş rollout stratejileri uygulamak için kullanılabilir. Standart Deployment nesnesine kıyasla canary ve blue-green akışları için daha zengin kontrol sağlar. AnalysisTemplate üzerinden metrik tabanlı promotion veya abort tasarlanabilir. Argo CD ile birleştirildiğinde GitOps tabanlı release akışı kurulabilir. Kubernetes ve CI/CD pipeline ile zero-downtime deployment nasıl uygulanır sorusunun pratik yanıtlarından biri bu araçların doğru mimari ilkelerle birlikte kullanılmasıdır.

Kubernetes Deployment ile Argo Rollout Farkı

Kubernetes Deployment temel rolling update davranışını güçlü biçimde yönetir. Argo Rollouts ise traffic splitting ve analysis aşamalarını genişletir. Canary step, pause ve metric check tanımlanabilir. Blue-green preview environment oluşturulabilir. Daha gelişmiş kontrol ek operasyon bilgisi gerektirdiği için ekip ihtiyacına göre seçilmelidir.

Blue-Green Strategy

Argo Rollouts blue-green modelinde active ve preview service ayırabilir. Yeni ReplicaSet preview üzerinden test edilir. Promotion sonrasında active service yeni sürüme yönlenir. Eski ReplicaSet rollback için belirli süre tutulabilir. Database uyumluluğu yine deployment controller tarafından otomatik çözülmez.

Canary Strategy

Canary strategy trafik oranlarını step olarak tanımlayabilir. Örneğin yüzde 5 traffic ardından pause uygulanabilir. Analysis başarılı olursa sıradaki adıma geçilir. Service mesh veya ingress entegrasyonuyla gerçek weighted traffic yönetilebilir. Uygulamanın readiness ve shutdown davranışı temel Kubernetes kurallarıyla uyumlu olmalıdır.

AnalysisTemplate

AnalysisTemplate rollout başarısını ölçmek için metrik sorgularını tanımlar. Prometheus gibi sistemlerden veri alınabilir. HTTP error rate veya latency threshold'u belirlenebilir. Başarısız analiz rollout'u durdurabilir. Business KPI gerekiyorsa ilgili metriğin monitoring sistemine güvenilir biçimde taşınması gerekir.

Promotion

Promotion yeni sürümün rollout sürecinde bir sonraki aşamaya ilerlemesidir. Otomatik veya manuel tetiklenebilir. Preview ortamın active hale gelmesi blue-green promotion örneğidir. Canary'de traffic weight'in artırılması promotion sayılır. Her promotion kararının ölçüm sonuçlarıyla ilişkilendirilmesi audit açısından faydalıdır.

Abort

Abort rollout'un başarısız kabul edilip ilerlemesinin durdurulmasıdır. Canary trafik stable sürüme geri alınabilir. Problemli ReplicaSet inceleme için geçici olarak korunabilir. Alert sistemi olaydan haberdar edilmelidir. Abort nedeninin deployment metadata'sıyla kaydedilmesi kök neden analizini kolaylaştırır.

Rollback

Rollback eski revision'a geri dönmeyi ifade eder. Code-only değişiklikte bu oldukça düz olabilir. Database migration sonrası aynı işlem riskli olabilir. Rollback runbook'u gerçek production bağımlılıklarını hesaba katmalıdır. Otomasyon yalnızca güvenliği doğrulanmış rollback sınıflarında kullanılmalıdır.

Argo CD ile GitOps Entegrasyonu

Argo CD Git repository'deki desired state'i cluster ile senkronize eder. Deployment configuration değişiklikleri commit geçmişi üzerinden izlenebilir. Argo Rollouts release davranışını yönetirken Argo CD state reconciliation sağlar. Bu ayrım operasyonel sorumlulukları daha görünür kılar. Git revert eski configuration'a dönüş için kullanılabilir ancak runtime data değişikliklerini geri almaz.

Traffic Management Katmanı

Zero-downtime deployment'ın başarısı application kadar trafik katmanına da bağlıdır. Kubernetes Service temel service discovery sağlar. Ingress, reverse proxy, cloud load balancer veya service mesh daha gelişmiş routing davranışları sunabilir. Canary için weighted traffic, blue-green için hızlı switch ve termination için connection draining önemlidir. Seçilecek katman mevcut platform yetkinliğiyle uyumlu olmalıdır.

Kubernetes Service

Kubernetes Service pod'lara sabit erişim noktası sağlar. Selector üzerinden hangi pod'ların endpoint olacağını belirler. Readiness başarısız olan pod normalde endpoint listesinden çıkarılır. Blue-green modelinde selector değişimi kullanılabilir. Endpoint propagation davranışı deployment testlerinde ölçülmelidir.

NGINX Ingress

NGINX Ingress HTTP routing ve TLS termination gibi işlevler sunabilir. Canary yönlendirme özellikleri belirli kurulumlarda kullanılabilir. Header veya ağırlık bazlı trafik ayırma senaryoları oluşturulabilir. Timeout ve keep-alive ayarları draining davranışını etkiler. Configuration değişikliklerinin reload etkisi production öncesi doğrulanmalıdır.

Traefik

Traefik dinamik service discovery ile Kubernetes ortamlarında trafik yönetebilir. Routing configuration'ı cluster kaynaklarından okuyabilir. Weighted service yaklaşımı rollout senaryolarında kullanılabilir. Middleware davranışları release sürecine dahil edilmelidir. Operasyon ekibi kullanılan routing modelini monitoring ile görünür hale getirmelidir.

HAProxy

HAProxy yüksek performanslı reverse proxy ve load balancer olarak kullanılabilir. Backend health check ve connection draining davranışı detaylı yapılandırılabilir. Blue-green switch backend ağırlıkları üzerinden yapılabilir. Canary için weighted routing uygulanabilir. Timeout değerleri uzun request ve persistent connection ihtiyaçlarına göre seçilmelidir.

AWS ALB

AWS ALB target group bazlı trafik yönlendirme sunar. Weighted target group yaklaşımı bazı rollout senaryolarında kullanılabilir. Health check yeni instance'ların trafik almaya hazır olmasını belirler. Deregistration delay connection draining için önemlidir. Cloud load balancer ayarları application graceful shutdown süresiyle uyumlu olmalıdır.

Azure Application Gateway

Azure Application Gateway application layer routing sağlar. Backend health durumunu izleyerek sağlıklı instance'lara trafik gönderebilir. Routing rule ve backend pool tasarımı blue-green yaklaşımında kullanılabilir. Connection ve probe ayarları deployment davranışını etkiler. Platform seviyesindeki health check application readiness semantiğiyle uyumlu tutulmalıdır.

Istio

Istio VirtualService ve DestinationRule ile gelişmiş trafik kontrolü sunabilir. Canary sürümler arasında yüzdesel dağıtım yapılabilir. Header bazlı routing de desteklenen yaygın kullanım senaryolarındandır. Telemetry rollout analizi için ek görünürlük sağlar. Service mesh'in getirdiği operasyonel yük kullanım kararında hesaba katılmalıdır.

Linkerd

Linkerd servisler arası iletişimde observability ve trafik özellikleri sağlayabilir. Kubernetes tabanlı progressive delivery araçlarıyla birlikte kullanılabilir. Mesh üzerinden servis metrikleri sürüm davranışını anlamaya yardımcı olur. Yeni proxy katmanı latency ve troubleshooting modelini etkiler. Bu nedenle rollout öncesinde platform ekibinin failure mode'ları öğrenmesi gerekir.

Envoy

Envoy modern proxy altyapılarında sık kullanılan bir data plane bileşenidir. Weighted routing, timeout ve retry gibi özellikler sunabilir. Service mesh çözümlerinin altında da kullanılabilir. Deployment sırasında connection davranışı proxy configuration'ına bağlıdır. Retry ayarları yanlış yapılandırılırsa hata sırasında dependency yükünü artırabilir.

Readiness Probe Zero-Downtime İçin Neden Kritiktir?

Readiness probe bir pod'un process olarak çalışmasından daha önemli bir soruya cevap verir: Bu pod şu anda production trafiği kabul etmeye hazır mı? Yeni pod Ready olmadan Service endpoint listesine girmemelidir. Kapanacak pod da termination başlarken mümkün olduğunca hızlı biçimde ready durumundan çıkarılmalıdır. Yanlış probe yeni sürümü erken trafiğe sokabilir veya sağlıklı kapasiteyi gereksiz yere azaltabilir. Zero-downtime hedefinde readiness yalnızca Kubernetes ayarı değil, application lifecycle sözleşmesidir.

Readiness Probe Nedir?

Readiness probe pod'un trafik almaya uygunluğunu kontrol eder. Başarısız olduğunda container mutlaka restart edilmez. Bunun yerine pod Service endpoint'lerinden çıkarılır. Bu fark liveness probe ile karıştırılmamalıdır. Readiness endpoint'i uygulamanın gerçek trafik kabul durumunu yansıtmalıdır.

Pod Ready Olmadan Trafik Almamalı

Uygulama portu açılmış olsa bile başlangıç işlemleri tamamlanmamış olabilir. Cache initialization, route registration veya gerekli local state hazırlığı zaman alabilir. Bu aşamada trafik gelirse ilk kullanıcılar hata yaşayabilir. Readiness true ancak uygulama gerçekten hazır olduğunda dönmelidir. Startup süresi değişkense sabit sleep kullanmak yerine gerçek hazır olma sinyali tercih edilmelidir.

Yanlış Readiness Probe'un Oluşturduğu Kesintiler

Probe her küçük dependency sorununda fail olursa tüm pod'lar aynı anda endpoint listesinden çıkabilir. Bu durumda çalışan servis olmasına rağmen load balancer backend bulamaz. Aşırı katı probe availability'yi azaltabilir. Aşırı gevşek probe ise bozuk pod'a trafik gönderebilir. Probe tasarımı dependency failure modeline göre dengelenmelidir.

Dependency Kontrolleri

Her dependency readiness içinde kontrol edilmemelidir. Örneğin geçici analytics servisi kesintisi ana API'nin trafik alamayacağı anlamına gelmeyebilir. Kritik database tamamen erişilemezse uygulama işlevsiz olabilir. Dependency'nin servisin temel işlevi için zorunlu olup olmadığı belirlenmelidir. Ayrıca probe sırasında dependency'ye fazla sorgu göndererek ek yük oluşturmaktan kaçınılmalıdır.

Readiness Probe Tasarımında Anti-Pattern'ler

Tüm dış servisleri her probe isteğinde senkron kontrol etmek yaygın bir hatadır. Bu tasarım dependency sorununu zincirleme availability problemine dönüştürebilir. Sadece process alive kontrolü yapmak ise readiness için fazla yüzeyseldir. Probe endpoint'inde ağır database sorgusu çalıştırmak da yüksek pod sayısında gereksiz yük yaratır. En doğru kontrol uygulamanın trafik alabilme durumunu hızlı ve güvenilir biçimde temsil eder.

Liveness, Readiness ve Startup Probe Farkı

Kubernetes probe türlerinin her biri farklı soruyu yanıtlar. Liveness process'in kurtarılamaz durumda olup olmadığını belirler. Readiness trafik kabul edebilme durumunu gösterir. Startup probe ise yavaş açılan uygulamalara başlangıç sürecini tamamlaması için ayrı pencere sağlar. Bu kontroller birbirinin yerine kullanıldığında gereksiz restart veya kesinti oluşabilir.

Liveness Probe

Liveness başarısızlığı container'ın restart edilmesine yol açabilir. Bu nedenle yalnızca restart ile düzelebilecek durumlar için kullanılmalıdır. Geçici database kesintisi her zaman pod restart nedeni değildir. Aksi halde database problemi yüzlerce pod'un aynı anda restart olmasına dönüşebilir. Probe failure davranışı dependency incident senaryolarıyla test edilmelidir.

Readiness Probe

Readiness pod'u öldürmek yerine trafik rotasyonundan çıkarır. Geçici olarak request kabul edemeyen pod için bu davranış uygundur. Pod tekrar hazır olduğunda endpoint listesine dönebilir. Deployment sırasında yeni pod'un promotion koşuludur. Graceful shutdown başlangıcında da pod'un yeni trafik almamasını sağlamak için önemlidir.

Startup Probe

Startup probe yavaş başlayan application'ların liveness tarafından erken öldürülmesini önler. Özellikle legacy servislerde başlangıç süresi uzun olabilir. Startup başarılı olduktan sonra diğer probe'lar normal şekilde çalışır. Bu sayede liveness threshold'larını gereksiz yüksek tutmak gerekmez. Uzun startup'ın gerçek nedeni ayrıca performans açısından incelenmelidir.

Hangi Kontrol Hangi Probe'a Yazılmalı?

Restart ile düzelecek process deadlock durumu liveness için adaydır. Trafik kabul koşulları readiness içinde değerlendirilmelidir. Uzun initialization süreci startup probe ile ele alınabilir. Aynı endpoint'i üç probe için kullanmak semantik ayrımı kaybettirebilir. Uygulama lifecycle'ının bu üç durumu kod seviyesinde açıkça temsil edilmesi daha sağlıklıdır.

Database Kesilince Pod Restart Edilmeli mi?

Çoğu durumda hayır. Database dış bağımlılık olduğu için pod restart etmek database'i düzeltmez. Hatta tüm pod'lar aynı anda restart olup ek bağlantı yükü yaratabilir. Readiness davranışı uygulamanın database olmadan servis verip veremediğine göre belirlenebilir. Liveness yalnızca process'in kendi içinde kurtarılamaz durumda olduğu senaryolara ayrılmalıdır.

Graceful Shutdown Nedir?

Graceful shutdown çalışan instance'ı aktif işlemlerini mümkün olduğunca güvenli tamamladıktan sonra kapatma yaklaşımıdır. Zero-downtime deployment sırasında yalnızca yeni pod'u hazır etmek yeterli değildir. Eski pod'un da doğru biçimde trafikten çıkması gerekir. Uygulama SIGTERM aldığında yeni request kabulünü durdurmalı, devam eden request'leri tamamlamalı ve resource cleanup yapmalıdır. Süre dolduğunda process kapanmamışsa zorla sonlandırma uygulanabilir.

SIGTERM

SIGTERM process'e kapanması gerektiğini bildiren standart sinyaldir. Kubernetes pod termination sırasında container process'ine bu sinyali gönderir. Uygulamanın sinyali yakalayan handler'ı olmalıdır. Handler yeni iş kabulünü durdurup cleanup sürecini başlatabilir. SIGTERM'i yok sayan uygulama grace period sonunda SIGKILL ile sonlandırılabilir.

Yeni Request Kabulünü Durdurmak

Kapanacak instance'ın yeni iş almaya devam etmesi shutdown süresini uzatır. Önce readiness false hale getirilebilir. Load balancer endpoint propagation tamamlandıktan sonra yeni trafik başka instance'lara gider. Küçük bir propagation gecikmesi olabileceği için termination sırası önemlidir. Uygulama bu aralıkta gelen istekleri kontrollü biçimde yönetebilmelidir.

Instance'ı Load Balancer'dan Çıkarmak

Instance deregistration yeni bağlantıların durmasını sağlar. Ancak mevcut bağlantılar hemen kesilmemelidir. Load balancer draining özelliği aktif request'lerin tamamlanmasına izin verir. Kubernetes ortamında Service endpoint güncellemesinin propagation süresi hesaba katılmalıdır. Platform ve application shutdown timeout'ları birbiriyle uyumlu olmalıdır.

Aktif Request'leri Tamamlamak

Uygulama kapanmadan önce devam eden request sayısını takip edebilir. Sayaç sıfıra indiğinde process güvenle çıkabilir. Uzun request'ler için maksimum bekleme süresi tanımlanmalıdır. Client retry ve idempotency timeout durumundaki veri tutarlılığını destekler. Kritik işlemler background job'a devrediliyorsa job acknowledgement davranışı ayrıca tasarlanmalıdır.

Resource Cleanup

Database connection, file handle ve message consumer bağlantıları düzgün kapatılmalıdır. Telemetry buffer'ları mümkünse flush edilmelidir. Queue consumer yeni mesaj almayı durdurmalı ve in-flight mesajlarını tamamlamalıdır. Distributed lock tutuluyorsa güvenli biçimde serbest bırakılmalıdır. Cleanup işlemi sonsuz beklememeli ve belirli deadline içinde tamamlanmalıdır.

Süre Dolunca SIGKILL

Grace period sonsuz değildir. Süre sonunda process hâlâ çalışıyorsa runtime zorla sonlandırabilir. SIGKILL yakalanamaz ve cleanup fırsatı vermez. Bu yüzden uygulamanın normal shutdown süresi grace period'dan kısa olmalıdır. Production metrikleri gerçek shutdown sürelerini ölçmek için kullanılabilir. Gerekirse timeout değeri gözlemlenen P99 işlem süresine göre güncellenebilir.

Kubernetes Graceful Shutdown

Kubernetes pod termination süreci birkaç bileşenin doğru sıralanmasını gerektirir. terminationGracePeriodSeconds toplam kapanış penceresini tanımlar. preStop hook belirli hazırlık işlemleri için kullanılabilir ancak tek çözüm olarak görülmemelidir. Readiness değişimi ve endpoint propagation nedeniyle yeni isteklerin kısa süre gelmeye devam edebileceği varsayılmalıdır. SIGTERM handler aktif işleri tamamlayarak process'i güvenli biçimde sonlandırmalıdır.

terminationGracePeriodSeconds

Bu değer pod'a zorla kapatılmadan önce verilen toplam zamanı belirler. Varsayılan değer her workload için doğru olmayabilir. Normal HTTP API ile uzun süren batch worker aynı grace süresine sahip olmak zorunda değildir. Çok kısa değer aktif işlemleri keser. Çok uzun değer deployment ve node drain operasyonlarını gereksiz yavaşlatabilir.

preStop Hook

preStop hook termination öncesinde ek komut çalıştırmaya izin verir. Bazı ekipler endpoint propagation için kısa bekleme uygular. Ancak sabit sleep gerçek sistem davranışını garanti etmez. Uygulamanın kendi shutdown handler'ı yine bulunmalıdır. preStop süresi de toplam termination grace penceresine dahildir.

Readiness State Değişimi

Termination başlayan pod yeni trafik almamalıdır. Readiness state'in hızlı biçimde false olması bu amacı destekler. Service endpoint listesi güncellendiğinde yeni request başka pod'lara gider. Propagation anlık olmayabilir. Bu nedenle uygulama kısa geçiş boyunca yeni request'leri tamamen reddetmek yerine kontrollü davranış gösterebilir.

Endpoint Propagation Gecikmesi

Readiness değişimi cluster içindeki tüm networking bileşenlerine aynı mikro saniyede ulaşmaz. EndpointSlice, proxy ve load balancer güncellemeleri kısa gecikme oluşturabilir. Pod bu sırada kapatılırsa birkaç request başarısız olabilir. Graceful shutdown tasarımı bu gecikmeyi hesaba katmalıdır. Gerçek değer staging ve production telemetry üzerinden ölçülebilir.

SIGTERM Handler

SIGTERM handler application framework seviyesinde tanımlanmalıdır. HTTP server yeni connection kabulünü durdurabilir. Existing request'lerin bitmesi beklenebilir. Queue veya scheduler bileşenleri de kendi shutdown prosedürlerini çalıştırmalıdır. Handler'ın hata verdiği durumlar testlerle doğrulanmalıdır.

Pod Kapanmadan Önce Aktif İşlerin Tamamlanması

Aktif işlerin sayısı veya lifecycle state'i application tarafından takip edilebilir. Shutdown sırasında yeni background task oluşturulmamalıdır. Uzun süren işler güvenli checkpoint mekanizmasına sahip olabilir. Süre yetmezse retry edilebilir tasarım veri kaybını önler. Idempotency duplicate execution riskini azaltır.

Connection Draining Nedir?

Connection draining kapanacak instance'a yeni bağlantı gönderilmesini durdururken mevcut bağlantıların kontrollü biçimde tamamlanmasına izin verir. HTTP request'lerde bu süreç genellikle kısadır. WebSocket, SSE ve gRPC streaming gibi uzun bağlantılarda saatler sürebilecek connection'lar bulunabilir. Bu nedenle drain timeout servis türüne göre değişmelidir. Client reconnection tasarımı uzun yaşayan bağlantılarda zero-downtime deneyiminin önemli parçasıdır.

Load Balancer Connection Draining

Load balancer target'ı draining state'e alabilir. Yeni connection başka backend'e gönderilir. Mevcut connection'lar belirli süre açık tutulur. Timeout sonunda kalan bağlantılar kapatılabilir. Bu süre application termination grace ile uyumlu olmalıdır.

HTTP Keep-Alive

Keep-alive aynı TCP connection üzerinden birden fazla HTTP isteği taşıyabilir. Instance draining başladığında yeni request kabul davranışı proxy ve server ayarlarına bağlıdır. Connection'ın sonsuza kadar açık kalması istenmez. Server belirli noktada connection close sinyali gönderebilir. Client'ın yeni connection açarak sağlıklı backend'e geçmesi beklenir.

Uzun Süren Request

Rapor üretme veya büyük export işlemleri dakikalar sürebilir. Deployment bu request devam ederken başlarsa kısa grace period işlemi yarıda kesebilir. Timeout gerçek request dağılımına göre belirlenmelidir. Çok uzun işlemler asynchronous job modeline taşınabilir. Böylece frontend request kısa sürer ve job güvenli retry ile tamamlanabilir.

WebSocket

WebSocket bağlantıları uzun süre açık kalabilir. Tüm connection'ların doğal biçimde kapanmasını beklemek deployment'ı süresiz uzatabilir. Server kontrollü close frame gönderip client'ı yeniden bağlanmaya yönlendirebilir. Client reconnect sırasında kısa jitter kullanabilir. Session resume varsa kullanıcı deneyimi daha akıcı olur.

SSE

Server-Sent Events uzun süreli HTTP stream kullanır. Deployment sırasında stream kapanabilir. Client standart reconnect davranışıyla başka instance'a bağlanabilir. Last-Event-ID benzeri mekanizmalar veri kaybını azaltabilir. Server ve client birlikte tasarlanmadığında kullanıcı kısa süreli event boşluğu yaşayabilir.

gRPC Streaming

gRPC streaming bağlantıları uzun yaşayabilir. Load balancer draining stream tamamlanana kadar bekleyebilir. Ancak sonsuz stream için kontrollü reconnect tasarımı gerekir. Client retry politikası idempotency ve stream semantiğine uygun olmalıdır. Deployment öncesi connection maximum age kullanmak bağlantıların düzenli yenilenmesini sağlayabilir.

Drain Timeout Nasıl Belirlenir?

Drain timeout tahmin yerine gerçek trafik ölçümlerine dayanmalıdır. Normal request P99 süresi başlangıç noktası olabilir. Long-lived connection sınıfları ayrıca değerlendirilmelidir. Timeout termination grace değerinden uzun olursa pod önce kapanabilir. Uygulama, proxy ve load balancer timeout zinciri birlikte incelenmelidir.

Uzun Süren Request'lerde Zero-Downtime

Uzun süren request'ler normal stateless HTTP API'lerden farklı lifecycle gerektirir. Deployment başladıktan sonra request'in hangi instance üzerinde tamamlanacağı açık olmalıdır. Draining ve graceful shutdown request'i mümkün olduğunca korur. Ancak sınırsız süre beklemek deployment'ı bloke edebilir. Idempotency, retry ve gerektiğinde request resume tasarımı kesinti etkisini azaltır.

Request Deployment Sırasında Başladıysa Ne Olur?

Request eski instance üzerinde başladıysa ideal olarak aynı instance üzerinde tamamlanmalıdır. Load balancer mevcut bağlantıyı hemen kesmemelidir. Pod termination süresi request'in normal bitişine izin vermelidir. Süre aşılırsa client timeout veya connection reset görebilir. İşlem retry edilecekse duplicate side effect oluşturmayacak şekilde tasarlanmalıdır.

Load Balancer Draining

Draining eski backend'e yeni request gönderimini keser. Devam eden request normal şekilde akmaya devam eder. Bu davranış deployment sırasında request continuity sağlar. Timeout gerçek workload'a göre seçilmelidir. Proxy loglarından forced termination sayısı takip edilebilir.

Graceful Shutdown

Application shutdown handler active request sayısını izleyebilir. Yeni iş kabulü durdurulduktan sonra sayaç sıfıra yaklaşması beklenir. Deadline sonunda kalan request'ler kontrollü hata ile sonlandırılabilir. Framework'ün HTTP server shutdown API'si kullanılabilir. Bu davranış integration test ile deployment senaryosunda denenmelidir.

Request Timeout

Request timeout kullanıcı deneyimi ve kaynak yönetimi açısından sınır oluşturur. Deployment grace değeri request timeout'tan kısa seçilirse normal request'ler gereksiz kesilebilir. Çok uzun timeout ise kaynakların uzun süre tutulmasına neden olur. İşlem gerçekten uzun sürüyorsa asynchronous model daha doğru olabilir. Timeout zinciri client, proxy ve application katmanında uyumlu olmalıdır.

Idempotency

Idempotency aynı işlemin retry edildiğinde ikinci yan etki oluşturmamasını hedefler. Payment veya order creation için idempotency key kullanılabilir. Deployment sırasında connection koparsa client güvenle tekrar deneyebilir. Server önceki sonucu idempotency store üzerinden döndürebilir. Bu tasarım zero-downtime hedefini yalnızca bağlantı seviyesinden iş mantığı seviyesine taşır.

Request Resume Tasarımı

Büyük upload veya export işlemleri yeniden başlatılabilir tasarlanabilir. Client kaldığı noktadan devam edebilir. İş state'i tek application instance belleğine bağlı olmamalıdır. Persistent job veya object storage üzerinden checkpoint tutulabilir. Böylece deployment process değişse bile uzun işlem devam edebilir.

WebSocket ve SSE Bağlantılarında Deployment

WebSocket ve SSE deployment sırasında özel dikkat gerektirir çünkü bağlantılar normal request gibi saniyeler içinde tamamlanmaz. Instance saatlerce aktif connection taşıyabilir. Deployment'ı tüm bağlantılar doğal biçimde kapanana kadar bekletmek pratik olmayabilir. Kontrollü reconnect ve session resume yaklaşımı gerekir. Kullanıcı açısından gerçek zero-downtime çoğu zaman bağlantının hiç kopmamasından çok, kopuşun otomatik ve veri kaybı olmadan toparlanması anlamına gelir.

Uzun Süreli Connection Problemi

Uzun connection instance lifecycle'ını deployment lifecycle'ına bağlar. Pod kapatılmak istendiğinde aktif connection hâlâ kullanılabilir. Çok uzun grace period cluster operasyonlarını zorlaştırır. Bu nedenle bağlantıların maksimum yaşam süresi sınırlandırılabilir. Client reconnect mekanizması temel sistem davranışı olarak kabul edilmelidir.

Connection Draining

Draining yeni bağlantıların eski instance'a gitmesini durdurur. Mevcut WebSocket connection kısa süre açık kalabilir. Server daha sonra kontrollü close mesajı gönderebilir. Client yeni connection'ı başka instance'a kurar. Bu süreç deployment sırasında bağlantıların yavaşça yeni sürüme taşınmasını sağlar.

Reconnection

Client reconnect otomatik olmalıdır. Anlık reconnect dalgası yaratmamak için exponential backoff ve jitter kullanılabilir. Authentication token'ın reconnect sırasında hâlâ geçerli olması gerekir. Yeni instance eski session bilgisini okuyabilmelidir. Connection state gerekiyorsa paylaşımlı store veya resume token tasarımı kullanılabilir.

Client Retry

Retry yalnızca connection kurma seviyesinde düşünülmemelidir. Client gönderdiği son message'ın işlenip işlenmediğini bilemeyebilir. Message ID ve acknowledgement mekanizması duplicate riskini azaltır. Server idempotent işlem yapabiliyorsa retry daha güvenli hale gelir. Network failure senaryoları deployment testlerinin parçası olmalıdır.

Session Resume

Session resume client'ın yeni connection üzerinde önceki akışa devam etmesini sağlar. Son işlenen event ID veya cursor tutulabilir. Yeni instance bu bilgiyi paylaşımlı backend üzerinden okuyabilir. Kullanıcının tekrar giriş yapması veya ekranı yenilemesi gerekmez. Özellikle gerçek zamanlı dashboard ve notification sistemlerinde deneyimi önemli ölçüde iyileştirir.

Deployment Öncesi Connection Lifetime Sınırı

Connection maximum age tanımlamak tüm bağlantıların zaman içinde yenilenmesini sağlar. Böylece aylarca yaşayan tek bir connection deployment'ı bloke etmez. Server expiration yaklaşırken client'a reconnect sinyali gönderebilir. Jitter kullanmak tüm connection'ların aynı saniyede yenilenmesini önler. Bu yöntem load balancer draining ile birlikte kullanıldığında rollout daha öngörülebilir olur.

Session Yönetimi

Session state zero-downtime deployment sırasında sık gözden kaçan sorunlardan biridir. Kullanıcı oturumu application memory'de tutuluyorsa instance değişimi session kaybı oluşturabilir. Sticky session geçici çözüm sağlayabilir ancak rollout esnekliğini azaltır. Shared session store veya stateless JWT modeli instance bağımsızlığı sağlar. Blue-green switch sonrasında eski session formatının yeni sürüm tarafından okunabilmesi de kontrol edilmelidir.

In-Memory Session Neden Problem Oluşturur?

In-memory session belirli bir process'e bağlıdır. Kullanıcının sonraki isteği başka replica'ya giderse session bulunamayabilir. Deployment sırasında eski pod kapandığında session tamamen kaybolur. Sticky routing riski azaltır ancak pod failure durumunu çözmez. Kritik oturum bilgisi paylaşımlı veya taşınabilir yapıda tutulmalıdır.

Sticky Session

Sticky session aynı kullanıcıyı belirli instance'a yönlendirir. Legacy uygulamaları çoklu replica'ya geçirmek için kısa vadede yararlı olabilir. Ancak instance kapanırsa kullanıcı başka backend'e taşınır ve state kaybolabilir. Load balancing dağılımı da dengesiz hale gelebilir. Uzun vadede stateless veya shared session modeline geçmek daha güçlü çözümdür.

Shared Session Store

Session merkezi store'da tutulduğunda tüm replica'lar aynı bilgiyi okuyabilir. Rolling deployment bu sayede kullanıcı oturumunu korur. Session schema eski ve yeni uygulamayla uyumlu olmalıdır. Store yüksek erişilebilir tasarlanmalıdır çünkü yeni ortak dependency haline gelir. Session expiration politikası da rollout sırasında beklenmeyen logout yaratmamalıdır.

Redis

Redis shared session store için yaygın bir seçenektir. Düşük latency ile çoklu application instance'a ortak state sağlar. Redis cluster veya replication yapısı availability hedeflerine uygun kurulmalıdır. Session serialization formatındaki değişiklikler version skew dikkate alınarak yapılmalıdır. Yeni sürüm eski session'ı okuyamıyorsa deployment teknik olarak başarılı olsa bile kullanıcı deneyimi bozulur.

Stateless JWT

JWT session bilgisinin belirli bölümünü client tarafında taşıyabilir. Application instance değiştirmek session continuity'yi bozmaz. Ancak token revoke ve permission değişiklikleri ayrı tasarım ister. Token schema ve claim değişiklikleri backward-compatible yapılmalıdır. Büyük veya hassas state'i token içine koymak doğru yaklaşım değildir.

Blue-Green Switch Sonrası Session Sürekliliği

Traffic green environment'a geçtiğinde kullanıcının yeniden login olması istenmemelidir. Her iki environment aynı session store'u kullanabilir. Encryption veya signing key'leri geçiş döneminde uyumlu tutulmalıdır. Secret rotation deployment ile aynı anda yapılıyorsa eski ve yeni key için overlap gerekebilir. Session continuity smoke test senaryolarına dahil edilmelidir.

Cache ve Zero-Downtime Deployment

Cache veri modeli sürümler arasında uyumsuz olduğunda deployment sonrası zor teşhis edilen hatalar ortaya çıkabilir. Eski ve yeni uygulama aynı cache key'i farklı formatta yorumlayabilir. Versioned cache key bu riski azaltır. Yeni environment trafiğe açılmadan önce cache warming yapılması latency artışını önleyebilir. Cache invalidation planı release lifecycle'ının parçası olmalıdır.

Cache Schema Uyumluluğu

Cache value serialization formatı değişiyorsa iki sürüm aynı kaydı okuyamayabilir. Rolling deployment sırasında bu doğrudan hata üretir. Yeni format eski sürüm tarafından okunabilir tasarlanabilir. Alternatif olarak key version değiştirilebilir. Cache formatı application API kadar ciddi bir compatibility sözleşmesi olarak görülmelidir.

Eski ve Yeni Sürümün Aynı Cache'i Kullanması

Shared cache deployment sırasında iki sürüm tarafından aynı anda kullanılabilir. Her iki sürüm aynı key'e yazıyorsa format çatışması oluşabilir. Dual-read veya versioned key geçişi çözebilir. Cache TTL doğal migration mekanizması olarak kullanılabilir. Ancak kritik state cache'e bağlıysa yalnızca TTL'ye güvenmek risklidir.

Versioned Cache Key

Key'e version eklemek eski ve yeni cache formatlarını ayırır. Örneğin profile:v1 ve profile:v2 paralel yaşayabilir. Yeni sürüm önce v2 okumaya başlayabilir. Eski sürüm v1 kullanmaya devam eder. Geçiş tamamlandıktan sonra eski namespace TTL ile temizlenebilir.

Cache Warming

Yeni sürüm ilk kez trafik aldığında cache tamamen boş olabilir. Bu durum database'e ani yük bindirebilir. Blue-green environment production switch öncesinde önemli cache kayıtlarını hazırlayabilir. Canary doğal olarak cache'i küçük trafikle kademeli ısıtabilir. Warming işlemi gerçek production query yükünü aşmamalıdır.

Cache Invalidation

Invalidation deployment sırasında toplu cache miss üretebilir. Tüm cache'i tek anda silmek database üzerinde thundering herd oluşturabilir. Versioned key veya kademeli invalidation daha güvenlidir. Cache miss rate deployment metriği olarak izlenebilir. Release sonrası latency artışının nedeni çoğu zaman application kodu değil cache davranışı olabilir.

Blue-Green Öncesi Cache Hazırlığı

Green environment gerekli cache namespace'ini önceden hazırlayabilir. En sık kullanılan veriler warm edilir. Yeni cache formatı varsa eski sürümün key'leriyle çakışmamalıdır. Warming tamamlanmadan tam traffic switch yapılması latency sıçraması yaratabilir. Cache hit rate promotion kriterlerinden biri olarak kullanılabilir.

Zero-Downtime Database Migration Neden Zordur?

Database application instance'larından farklı olarak kalıcı ve paylaşılan state taşır. Eski ve yeni uygulama deployment sırasında aynı schema üzerinde çalışabilir. Breaking schema change bu nedenle eski sürümü anında kırabilir. Büyük migration table lock veya uzun transaction oluşturabilir. Rollback sonrasında eski uygulamanın yeni schema ve yeni verilerle çalışabilmesi de ayrıca düşünülmelidir.

Application ve Database Ayrı Yaşam Döngülerine Sahiptir

Application image kolayca eski revision'a döndürülebilir. Database state aynı kolaylıkta geri çevrilemez. Migration milyonlarca kaydı değiştirmiş olabilir. Yeni sürüm yeni veri formatında kayıt üretmiş olabilir. Bu nedenle code deployment ile data evolution farklı lifecycle olarak yönetilmelidir.

Eski ve Yeni Uygulama Aynı Database'i Kullanabilir

Rolling ve canary sırasında iki application sürümü aynı database'e bağlanır. Blue-green de çoğu zaman aynı veri katmanını paylaşır. Schema her iki sürümün query'leriyle uyumlu olmalıdır. Yeni column eklemek genellikle güvenlidir. Eski column'ı kaldırmak ise eski sürüm tamamen devreden çıkmadan yapılmamalıdır.

Breaking Schema Change

Column rename veya drop doğrudan breaking change olabilir. Eski application query'si artık geçersiz hale gelir. Deployment birkaç dakika version skew yaşasa bile hata üretir. Expand-and-contract değişikliği birkaç release'e bölerek bu riski azaltır. Database migration review sürecinde backward compatibility açık kontrol maddesi olmalıdır.

Table Lock

Büyük tabloda DDL işlemi lock oluşturabilir. Lock süresince application query'leri bekleyebilir. Bu durum pod'lar sağlıklı olsa bile kullanıcı açısından downtime gibi görünür. Database engine'in online DDL özellikleri araştırılmalıdır. Migration staging üzerinde production boyutuna yakın veriyle test edilmelidir.

Uzun Süren Migration

Milyonlarca satırlık backfill tek transaction içinde yapılmamalıdır. Uzun transaction lock, replication lag ve rollback maliyeti yaratabilir. Batch processing daha güvenli kontrol sağlar. Rate limit production workload'a göre ayarlanabilir. Migration progress ve database latency birlikte izlenmelidir.

Rollback Sonrası Schema Uyumluluğu

Yeni application geri alındığında eski sürüm yeni schema ile çalışmaya devam edebilmelidir. Contract change erken uygulanırsa rollback imkansız hale gelebilir. Yeni sürüm farklı formatta veri yazdıysa eski sürüm bu kaydı okuyabilmelidir. Rollback testleri production benzeri data ile yapılmalıdır. Migration stratejisinin amacı yalnızca forward deployment değil güvenli geri dönüş penceresi yaratmaktır.

Backward-Compatible Database Migration

Backward-compatible migration eski ve yeni uygulamanın aynı schema üzerinde birlikte çalışmasını sağlar. Additive change yaklaşımı mevcut yapıyı bozmak yerine yeni alan ekler. Yeni column önce nullable olabilir. Application yeni alanı kullanmaya başladıktan sonra veri backfill edilir. Eski alanın kaldırılması ancak tüm consumer'ların yeni yapıya geçtiği doğrulandıktan sonra yapılır.

Additive Change

Additive change mevcut column veya table'ı değiştirmek yerine yeni yapı ekler. Eski application etkilenmeden çalışmaya devam eder. Yeni application yeni alanı kullanmaya başlayabilir. Bu yöntem rollout ve rollback için güvenli pencere oluşturur. Sonraki release'te kullanılmayan eski yapı kaldırılabilir.

Nullable Column

Yeni column ilk aşamada nullable eklenebilir. Böylece eski application insert yaparken yeni alanı doldurmak zorunda kalmaz. Yeni sürüm alanı kontrollü biçimde yazmaya başlayabilir. Backfill tamamlandıktan sonra gerekiyorsa constraint eklenebilir. Constraint değişikliği de lock ve validation maliyeti açısından ayrı planlanmalıdır.

Yeni Table Ekleme

Yeni table eklemek çoğu durumda eski application davranışını bozmaz. Yeni sürüm bu tabloya veri yazmaya başlayabilir. Foreign key veya trigger gibi ek etkiler dikkatle değerlendirilmelidir. Büyük schema operasyonları production load altında test edilmelidir. Eski sürümün yeni table'ı bilmemesi sorun oluşturmamalıdır.

Yeni Index Ekleme

Yeni index query performansını artırabilir ancak oluşturma işlemi production trafiğini etkileyebilir. Database engine destekliyorsa concurrent veya online index creation tercih edilebilir. CPU, IO ve replication lag izlenmelidir. Büyük tabloda index build saatler sürebilir. Migration pipeline'ın timeout değerleri bu gerçeğe göre ayarlanmalıdır.

Eski Uygulamanın Yeni Şemayla Çalışabilmesi

Migration tamamlandıktan sonra eski application kısa süre çalışmaya devam edebilir. Rolling rollout bunun doğal sonucudur. Bu nedenle eski query'lerin kullandığı table ve column'lar korunmalıdır. Constraint değişiklikleri eski write davranışını bozmamalıdır. Compatibility testleri eski application binary'si yeni schema üzerinde çalıştırılarak doğrulanabilir.

Yeni Uygulamanın Eski Şemayla Çalışabilmesi

Bazen application rollout migration tamamlanmadan başlayabilir. Bu durumda yeni sürüm eski schema'yı da anlayabilmelidir. Feature flag ile yeni alan kullanımı migration sonrasına ertelenebilir. Migration-first yaklaşımı daha basit olabilir ancak her sistemde mümkün değildir. Pipeline dependency açık biçimde tanımlanmalıdır.

Expand-and-Contract Pattern

Expand-and-contract database değişikliklerini birkaç güvenli aşamaya böler. Expand aşamasında yeni schema eklenir ancak eski yapı korunur. Migrate aşamasında veri ve application davranışı yeni modele taşınır. Contract aşamasında artık kullanılmayan eski yapı kaldırılır. Bu model column rename gibi basit görünen ancak zero-downtime açısından riskli değişiklikleri güvenli hale getirir.

Expand

Expand mevcut schema'yı bozmadan yeni yapının eklenmesidir. Yeni column, table veya index oluşturulabilir. Eski application hiçbir değişiklik yapılmamış gibi çalışmaya devam eder. Yeni application gerektiğinde iki modeli birlikte destekler. Bu aşamada destructive operation yapılmaz.

Yeni Column/Table Ekle

Yeni alan mevcut yapıya ek olarak oluşturulur. Column mümkünse nullable veya safe default ile başlatılır. Büyük table için DDL lock etkisi ölçülür. Yeni table oluşturuluyorsa index ve constraint maliyeti hesaplanır. Migration production deploy'dan ayrı gözlemlenebilir adım olarak çalıştırılabilir.

Eski Yapıyı Koruma

Eski column veya table hemen kaldırılmaz. Stable application kullanmaya devam edebilir. Rollback yapıldığında eski sürüm işlevini sürdürür. Bu overlap süresi deployment güvenliğinin ana unsurudur. Cleanup işi ayrı backlog ve migration planında takip edilmelidir.

Migrate

Migrate aşamasında application ve veri yeni yapıya geçirilir. Mevcut kayıtlar backfill edilebilir. Bir süre dual read veya dual write uygulanabilir. Veri tutarlılığı karşılaştırma job'larıyla doğrulanabilir. Trafik tamamen yeni modele geçtiğinde contract için hazırlık tamamlanır.

Backfill

Backfill eski kayıtları yeni column veya table'a taşır. İşlem batch halinde yapılmalıdır. Her batch sonrası progress kaydedilebilir. Rate limit production latency artarsa düşürülebilir. Backfill tekrar çalıştırıldığında aynı sonucu üretecek idempotent yapıda olmalıdır.

Dual Read

Dual read geçiş sırasında iki veri kaynağını karşılaştırmak için kullanılabilir. Primary olarak eski alan okunurken yeni alan shadow olarak kontrol edilebilir. Farklar metric haline getirilebilir. Güven arttığında primary read yeni alana çevrilir. Bu model rollout riskini azaltır ancak code complexity geçici olarak artar.

Dual Write

Dual write aynı değişikliği eski ve yeni yapıya yazar. Böylece geçiş süresince iki veri modeli güncel tutulur. Partial failure olasılığı dikkate alınmalıdır. Transaction sınırı veya retry mekanizması buna göre tasarlanır. Uzun süre dual write bırakmak bakım yükü yarattığı için contract tarihi belirlenmelidir.

Contract

Contract artık kullanılmayan eski schema'nın kaldırıldığı son aşamadır. Bu işlem en erken tüm application sürümleri yeni modele geçtiğinde yapılmalıdır. Rollback penceresi kapanmış olmalıdır. Eski consumer veya background job bulunmadığı doğrulanmalıdır. Destructive migration ayrı release olarak planlanırsa risk daha görünür hale gelir.

Eski Okuma/Yazmayı Durdur

Application artık eski field'a erişmemelidir. Telemetry ile eski query veya event kullanımının sıfırlandığı kontrol edilebilir. Feature flag üzerinden eski yol kapatılabilir. Bir observation period bırakmak faydalıdır. Beklenmeyen consumer görülürse contract migration ertelenebilir.

Eski Column/Table'ı Sil

Silme işlemi en son adımdır. Geri dönüşü zor olduğu için backup ve rollback planı değerlendirilmelidir. Büyük table operasyonunun lock etkisi ayrıca ölçülmelidir. Schema cleanup code ve data sahipliği netleştirir. Bu işlem rollout ile aynı dakikada yapılmak zorunda değildir.

Column Rename Zero-Downtime Nasıl Yapılır?

Column rename tek SQL komutuyla yapılabilse de eski application için breaking change oluşturabilir. Güvenli yaklaşım yeni column eklemekle başlar. Application bir süre iki alana yazar ve eski veriler yeni column'a backfill edilir. Read path yeni column'a geçirildikten sonra eski alanın kullanımı gözlenir. Eski column ancak sonraki deployment'ta ve rollback penceresi kapandıktan sonra kaldırılır.

Doğrudan RENAME Neden Risklidir?

Eski application eski column adıyla query göndermeye devam eder. Rename tamamlandığı anda bu query hata verir. Rolling deployment'ta bazı pod'lar eski sürüm olduğu için production hata oranı yükselir. Rollback da eski column artık bulunmadığı için sorunlu hale gelir. Bu nedenle rename işlemi mantıksal olarak birkaç release'e bölünmelidir.

Yeni Column Ekle

İlk adım yeni isimle ikinci column oluşturmaktır. Eski column korunur. Yeni alan başlangıçta nullable olabilir. Application deployment'ı iki alanın da bulunduğu schema üzerinde çalışabilir. Böylece version skew sırasında her iki sürüm desteklenir.

İki Alana Yaz

Yeni application write sırasında hem eski hem yeni column'ı güncelleyebilir. Bu davranış geçiş döneminde veriyi senkron tutar. Partial failure senaryosu transaction içinde ele alınabilir. Write path metriği ile dual-write hataları izlenmelidir. Eski sürüm hâlâ yalnızca eski column'a yazabileceği için backfill veya sync stratejisi gerekebilir.

Eski Veriyi Backfill Et

Geçmiş kayıtlar yeni column'a taşınmalıdır. Büyük table için batch processing kullanılmalıdır. İşlem tekrar çalıştırılabilir olmalıdır. Progress checkpoint ile izlenebilir. Database latency ve replication lag yükselirse backfill hızı otomatik azaltılabilir.

Yeni Column'dan Oku

Backfill ve dual write doğrulandıktan sonra read path yeni column'a çevrilir. Feature flag üzerinden kademeli geçiş yapılabilir. Bir süre iki alanın değerleri karşılaştırılabilir. Fark metrikleri sıfıra yaklaştığında güven artar. Stable ve rollback sürümlerinin davranışı hâlâ kontrol edilmelidir.

Eski Column'ı Sonraki Deployment'ta Sil

Eski column aynı release içinde silinmemelidir. Önce eski application revision'larının devreden çıktığı doğrulanmalıdır. Background job ve rapor sorguları da kontrol edilmelidir. Observation period sonrasında contract migration uygulanabilir. Böylece rollback ve version skew için güvenli zaman penceresi korunur.

Büyük Tablolarda Database Migration

Büyük tablolar üzerinde yapılan migration production performansını doğrudan etkileyebilir. Lock süresi, IO tüketimi ve replication lag beklenenden yüksek olabilir. Online DDL veya concurrent index creation destekleniyorsa kullanılmalıdır. Backfill küçük batch'lere bölünerek rate limit uygulanabilir. Migration progress ile application latency aynı dashboard üzerinde takip edilirse production etkisi daha hızlı anlaşılır.

Table Lock Riski

DDL işlemleri database engine ve operasyon türüne göre lock oluşturabilir. Büyük tabloda saniyelik lock bile yüksek trafikte çok sayıda request'i bekletebilir. Queue oluşunca recovery sonrasında ani yük patlaması yaşanabilir. Migration production boyutunda staging verisiyle test edilmelidir. Lock timeout ve statement timeout politikaları bilinçli seçilmelidir.

Online DDL

Online DDL schema değişikliği sırasında normal query'lerin devam etmesini hedefler. Destek seviyesi database engine ve operation türüne göre farklıdır. Her ALTER komutunun online olduğu varsayılmamalıdır. Official engine davranışı ve version özellikleri kontrol edilmelidir. Production metric'leri migration boyunca izlenmelidir.

Concurrent Index Creation

Concurrent index creation write trafiğini tamamen bloke etmeden index oluşturmayı sağlar. Yine de CPU ve disk IO üzerinde yük oluşturabilir. Büyük index işlemleri replication lag yaratabilir. Başarısız index build cleanup gerektirebilir. Pipeline aynı migration'ı tekrar çalıştırırken mevcut index state'ini doğru kontrol etmelidir.

Batch Backfill

Batch backfill veriyi küçük parçalar halinde günceller. Her batch kısa transaction kullanabilir. Böylece lock ve transaction log baskısı azalır. Batch size metric'lere göre değiştirilebilir. İşlem kesilirse son checkpoint'ten devam edebilmelidir.

Rate-Limited Backfill

Rate limit migration'ın production workload ile yarışmasını engeller. Database latency yükseldiğinde migration hızı azaltılabilir. Yoğun saatlerde işlem durdurulabilir. Gece veya düşük trafik döneminde hız artırılabilir. Bu davranış uzun migration'ları daha güvenli hale getirir.

Migration Progress Monitoring

Kaç kaydın tamamlandığı ve kaç kaydın kaldığı ölçülmelidir. Tahmini bitiş süresi operasyon ekibine görünür olmalıdır. Error count ve retry sayısı ayrı metrik tutulmalıdır. Backfill durursa alarm üretilmelidir. Progress bilgisi deployment status'undan bağımsız izlenmelidir.

Production Trafiğine Etkisini Ölçmek

Migration sırasında database P95 latency ve lock wait değerleri izlenebilir. Application error rate artışı migration ile korele edilmelidir. Replication lag read replica kullanan sistemlerde kritik göstergedir. CPU ve disk saturation da takip edilmelidir. Belirlenen threshold aşılırsa migration otomatik yavaşlatılabilir veya durdurulabilir.

Database Migration ile Application Deployment Ayrılmalı mı?

Çoğu production sisteminde database migration ile application deployment'ın mantıksal olarak ayrı adımlar olması daha güvenlidir. Migration-first bazı additive değişiklikler için uygun olabilir. App-first yaklaşımı application'ın eski schema ile çalışabildiği durumlarda kullanılabilir. Ayrı pipeline uzun migration'ların application release'i bloke etmesini önleyebilir. Backward compatibility gate hangi sıranın güvenli olduğunu otomatik kontrol etmeye yardımcı olur.

Migration-First

Önce backward-compatible schema değişikliği uygulanır. Daha sonra yeni application deploy edilir. Yeni nullable column eklemek buna iyi örnektir. Eski application migration sonrası çalışmaya devam etmelidir. Migration başarısızsa application rollout henüz başlamadığı için recovery daha basit kalır.

App-First

Yeni application önce deploy edilebilir ancak yeni schema özelliğini hemen kullanmamalıdır. Feature flag yeni davranışı kapalı tutabilir. Migration tamamlandığında özellik açılır. Bu model bazı distributed sistemlerde rollout esnekliği sağlar. Yeni application'ın eski database schema ile güvenli çalıştığı test edilmelidir.

Ayrı Migration Pipeline

Uzun data migration ayrı pipeline üzerinden yönetilebilir. Application release birkaç saatlik backfill'i beklemek zorunda kalmaz. Migration progress bağımsız izlenir. Retry ve pause özellikleri daha kontrollü uygulanabilir. Deployment pipeline yalnızca gerekli compatibility gate'leri kontrol eder.

Backward Compatibility Gate

Pipeline schema change'in eski application'ı bozup bozmadığını kontrol edebilir. Migration linting destructive operation'ları işaretleyebilir. Contract test eski query'leri yeni schema üzerinde çalıştırabilir. Riskli migration manuel approval gerektirebilir. Gate süreci standartlaştırarak review kalitesini artırır.

Contract Migration'ı Geciktirmek

Destructive operation rollout ile aynı anda yapılmamalıdır. Eski version'lar tamamen devreden çıkana kadar beklenir. Rollback penceresi kapandıktan sonra cleanup yapılır. Bu gecikme bilinçli reliability yatırımıdır. Takip edilmezse eski schema birikimi oluşacağı için migration backlog düzenli temizlenmelidir.

Automated Migration Linting

Migration SQL'i pipeline içinde statik olarak analiz edilebilir. DROP COLUMN, blocking index veya non-null change gibi riskler işaretlenebilir. Her database engine için kurallar farklı olabilir. Lint sonucu tek başına production güvenliği garanti etmez. Ancak review sürecinde erken uyarı sağlayarak yaygın hataları azaltır.

Stateful Servislerde Zero-Downtime

Stateful servislerde zero-downtime yalnızca replica değişimiyle çözülemez. Database, queue, cache ve persistent volume kendi veri tutarlılığı kurallarına sahiptir. Distributed lock ve leader election rollout sırasında iki sürümün aynı işi üstlenmesini engellemelidir. Stateful component için graceful handoff tasarlanmalıdır. Application deployment stratejisinden ayrı operasyon playbook'ları gerekebilir.

Database

Database persistent state taşıdığı için rollback en dikkatli planlanan bileşenlerden biridir. Schema migration backward-compatible olmalıdır. Replication ve failover davranışı deployment sırasında izlenmelidir. Connection pool değişimleri sudden connection spike yaratmamalıdır. Application release ile database version upgrade aynı anda yapılmak zorunda değildir.

Queue

Queue eski ve yeni consumer'ların aynı anda mesaj işlemesine izin verebilir. Message schema iki sürüm tarafından anlaşılmalıdır. Consumer shutdown yeni message fetch'i durdurmalıdır. In-flight mesaj acknowledgement öncesi kaybolmamalıdır. Duplicate delivery idempotent consumer ile güvenli hale getirilmelidir.

Cache

Cache state geçici olsa bile deployment davranışını etkileyebilir. Format değişikliği versioned key gerektirebilir. Cache flush database'e ani yük yaratabilir. Warm-up kontrollü uygulanmalıdır. Cache availability problemi readiness tasarımını gereksiz yere tüm servisi kapatacak şekilde etkilememelidir.

Persistent Volume

Persistent volume belirli pod veya node davranışlarına bağlı olabilir. ReadWriteOnce volume aynı anda birden fazla replica tarafından kullanılamayabilir. Rolling update pod scheduling sırasında volume attach gecikmesi yaratabilir. StatefulSet update stratejisi workload özelliklerine göre seçilmelidir. Veri consistency ve fencing mekanizmaları ayrıca değerlendirilmelidir.

Distributed Lock

Distributed lock bir işin aynı anda tek instance tarafından yapılmasını sağlayabilir. Deployment sırasında eski ve yeni instance overlap yaşadığında önem kazanır. Lock lease süreli olmalıdır. Process ölürse lock sonsuza kadar tutulmamalıdır. Fencing token kritik write operasyonlarında stale owner riskini azaltabilir.

Leader Election

Leader election scheduler veya coordinator görevlerini tek instance'a verebilir. Leader kapanırken yeni instance görevi devralmalıdır. Election timeout çok uzun olursa kısa hizmet boşluğu oluşabilir. Çok kısa timeout split-brain riskini artırabilir. Deployment testleri leader termination senaryosunu içermelidir.

Queue Consumer Deployment'larında Zero-Downtime

Queue consumer'larda kullanıcı HTTP isteği görmese bile deployment sırasında veri kaybı veya duplicate processing oluşabilir. Eski ve yeni consumer kısa süre birlikte çalışır. Message formatı iki sürüm tarafından anlaşılmalıdır. Shutdown sırasında consumer yeni mesaj almayı durdurmalı ve in-flight mesajını güvenli biçimde tamamlamalıdır. Idempotent consumer tasarımı retry ve redelivery durumlarını güvenli hale getirir.

Eski ve Yeni Consumer'ın Aynı Anda Çalışması

Rolling deployment sırasında iki consumer version aynı queue'yu okuyabilir. Event schema iki sürümle uyumlu olmalıdır. Yeni producer'ın yayınladığı mesaj eski consumer'ı kırmamalıdır. Consumer version skew production'ın normal durumu olarak kabul edilmelidir. Contract test event payload seviyesinde uygulanabilir.

Message Format Compatibility

Yeni field eklemek genellikle optional tutulmalıdır. Eski consumer bilmediği alanı yok sayabilmelidir. Required field silmek breaking change oluşturabilir. Schema registry compatibility kontrolü kullanışlıdır. Event evolution API evolution kadar planlı yapılmalıdır.

Consumer Draining

Shutdown başlayan consumer yeni message fetch etmeyi durdurmalıdır. İşlemekte olduğu mesajı tamamlaması beklenir. Timeout aşılırsa mesaj yeniden queue'ya dönebilir. Bu durumda duplicate processing güvenli olmalıdır. Graceful consumer shutdown uygulama framework'ünde açıkça uygulanmalıdır.

Acknowledgement

Message ancak işlem başarıyla tamamlandıktan sonra acknowledgement almalıdır. Erken ack process crash durumunda veri kaybına yol açabilir. Geç ack ise duplicate delivery ihtimalini artırır. Idempotency bu nedenle temel tasarım unsurudur. Ack politikası queue sisteminin delivery guarantee modeliyle uyumlu olmalıdır.

In-Flight Message

Deployment başladığında consumer bir mesaj üzerinde çalışıyor olabilir. Process hemen öldürülürse işlem yarım kalır. Grace period mesajın tamamlanmasına izin vermelidir. İş süresi uzun ise lease veya heartbeat mekanizması kullanılabilir. Yeniden teslim edilen mesaj kaldığı state'e göre güvenle işlenmelidir.

Duplicate Processing

Queue sistemlerinde at-least-once delivery duplicate ihtimalini doğal olarak oluşturur. Deployment bu olasılığı artırabilir. Aynı payment event iki kez işlenmemelidir. Event ID üzerinden processed state tutulabilir. Business operation idempotent yapılırsa deployment ve network failure daha güvenli yönetilir.

Idempotent Consumer

Idempotent consumer aynı message yeniden geldiğinde ikinci yan etki oluşturmaz. Message ID veya business key kullanılabilir. Database unique constraint ek güvenlik sağlayabilir. İşlem ve processed marker mümkünse aynı transaction sınırında tutulmalıdır. Bu model zero-downtime queue deployment'ın temel güvenlik mekanizmalarındandır.

Background Job ve Worker Deployment

Background worker'lar request-response servislerden farklı kapanış davranışı gösterir. Bir job dakikalar veya saatler sürebilir. Worker deployment ortasında kapanırsa job state'inin ne olacağı önceden belirlenmelidir. Graceful shutdown, lease, visibility timeout ve retry birlikte tasarlanmalıdır. Job'ın tekrar çalışması mümkünse işlem idempotent olmalıdır.

Job Ortasında Worker Kapanırsa Ne Olur?

Sağlıklı sistemde job kaybolmamalıdır. Queue visibility timeout dolduktan sonra başka worker işi tekrar alabilir. Eğer partial side effect oluştuysa retry bunu dikkate almalıdır. Checkpoint yaklaşımı uzun job'larda faydalıdır. Job state'i process memory yerine persistent store'da tutulabilir.

Graceful Worker Shutdown

Worker SIGTERM aldıktan sonra yeni job çekmeyi durdurmalıdır. Mevcut job için tamamlanma süresi verilebilir. Süre çok uzunsa checkpoint bırakıp güvenli çıkış yapılabilir. Shutdown state monitoring sisteminde görünmelidir. Worker zorla sonlandırma testleri staging ortamında yapılmalıdır.

Lease ve Visibility Timeout

Lease job'ın belirli worker tarafından işlendiğini geçici olarak belirtir. Worker ölürse lease süresi sonunda job tekrar alınabilir. Süre normal job işlem süresinden kısa olursa duplicate execution artar. Çok uzun olursa failure recovery gecikir. Heartbeat lease'i devam eden iş boyunca yenileyebilir.

Retry

Retry transient failure'larda faydalıdır. Sabit hızlı retry dependency outage sırasında yükü artırabilir. Exponential backoff ve jitter tercih edilebilir. Retry count ve dead-letter davranışı tanımlanmalıdır. Deployment kaynaklı geçici bağlantı kesintileri bu modelle güvenli şekilde toparlanabilir.

Idempotency

Background job retry edilebiliyorsa idempotency kritik hale gelir. Aynı fatura iki kez üretilmemelidir. Business key üzerinden unique operation tanımlanabilir. Partial progress kayıt altına alınabilir. Job tasarımının başında retry normal durum olarak kabul edilmelidir.

Version Compatibility

Queue'da bekleyen job eski application version tarafından oluşturulmuş olabilir. Yeni worker payload'ı okuyabilmelidir. Job schema version alanı taşıyabilir. Breaking değişiklik durumunda birden fazla handler geçici olarak desteklenebilir. Eski job'ların tamamen tükendiği doğrulanmadan eski handler kaldırılmamalıdır.

Cron Job ve Scheduler Deployment Problemleri

Scheduler deployment sırasında aynı job'ın iki sürüm tarafından aynı anda başlatılması riski taşır. Rolling update kısa süre iki scheduler instance çalıştırabilir. Distributed lock veya leader election bu duplicate execution'ı engeller. Scheduler'ın ana application'dan ayrılması lifecycle kontrolünü kolaylaştırır. Job versioning eski ve yeni schedule davranışlarının uyumunu yönetmeye yardımcı olur.

Aynı Job'ın İki Sürüm Tarafından Çalıştırılması

Eski ve yeni pod aynı cron schedule'ı çalıştırabilir. Bu durumda aynı iş iki kez tetiklenir. Idempotent job olsa bile gereksiz kaynak tüketimi oluşur. Distributed lock execution ownership belirleyebilir. Tek scheduler replica kullanmak basit görünse de failover ihtiyacını ayrıca çözmek gerekir.

Distributed Lock

Scheduler job başlamadan önce ortak lock alabilir. Sadece lock sahibi işlemi çalıştırır. Lease süresi process crash sonrasında otomatik recovery sağlar. Lock key job ve schedule window'a göre oluşturulabilir. Kritik sistemlerde fencing mekanizması stale worker'ın yazmasını engelleyebilir.

Leader Election

Scheduler instance'larından biri leader seçilebilir. Yalnızca leader cron tetiklemelerini yapar. Deployment sırasında leadership yeni pod'a devredilir. Election süresinin job schedule hassasiyetine uygun olması gerekir. Missed job recovery politikası ayrıca tanımlanmalıdır.

Scheduler'ı Application'dan Ayırmak

Scheduler ayrı deployment olduğunda web API rollout'undan etkilenmez. Kaynak ve replica politikası bağımsız yönetilir. Release sıklığı farklı tutulabilir. Failure domain ayrımı incident etkisini azaltır. Ancak shared code veya schema compatibility yine korunmalıdır.

Job Versioning

Scheduled job payload'ına version eklenebilir. Worker hangi logic'in uygulanacağını açıkça bilir. Yeni schedule eski job'larla birlikte geçiş dönemi yaşayabilir. Eski handler cleanup zamanı telemetry ile belirlenebilir. Versioning uzun süreli queued workload'larda backward compatibility sağlar.

Microservice Ortamında Zero-Downtime

Mikroservis mimarisinde tüm servislerin aynı saniyede deploy edilmesi hem gerekli değildir hem de riski büyütebilir. Her servis bağımsız yaşam döngüsüne sahip olmalıdır. API ve event sözleşmeleri version skew desteklemelidir. Consumer-driven contract testing bağımlı servislerin farkında olmadan kırılmasını önlemeye yardımcı olur. Service dependency graph rollout sırası gerçekten önemli olan değişikliklerde karar vermeyi kolaylaştırır.

Tüm Servisleri Aynı Anda Deploy Etmemek

Toplu deployment blast radius'u büyütür. Hata olduğunda hangi servisin problemi oluşturduğunu anlamak zorlaşır. Bağımsız rollout root cause analizini kolaylaştırır. Her servis kendi canary metric'lerine sahip olabilir. Shared schema change gerekiyorsa compatibility üzerinden kontrollü sıra oluşturulur.

API Backward Compatibility

Provider yeni sürüme geçerken consumer eski kalabilir. Yeni endpoint eski request formatını desteklemelidir. Field silmek yerine deprecation süreci kullanılabilir. Optional field eklemek genellikle daha güvenlidir. Contract test pipeline'da bu davranışı doğrulayabilir.

Consumer-Driven Contract Testing

Consumer hangi provider davranışına bağımlı olduğunu test olarak tanımlar. Provider deployment öncesinde bu contract'ları çalıştırır. Breaking change production'a ulaşmadan görülebilir. Contract test tüm integration testlerin yerine geçmez. Ancak bağımsız microservice release güvenliğini önemli ölçüde artırır.

Event Schema Compatibility

Event producer yeni payload yayınladığında eski consumer hâlâ production'da olabilir. Yeni alanlar optional eklenmelidir. Mevcut alanın anlamını değiştirmek risklidir. Schema registry compatibility policy kullanışlıdır. Event retention uzun ise eski event'lerin yeni consumer tarafından da okunabilmesi gerekir.

Versioned API

Breaking change kaçınılmaz olduğunda versioned API kullanılabilir. v1 ve v2 belirli süre birlikte sunulur. Consumer'lar kontrollü biçimde yeni versiyona taşınır. Kullanım metriği eski version'ın ne zaman kaldırılabileceğini gösterir. Sonsuz version desteği bakım yükünü artırdığı için deprecation tarihi açık olmalıdır.

Service Dependency Graph

Dependency graph hangi servislerin birbirini çağırdığını gösterir. Breaking olmayan değişikliklerde özel deployment sırası gerekmeyebilir. Riskli migration'da graph geçiş planını belirlemeye yardımcı olur. Distributed tracing gerçek runtime bağımlılıklarını ortaya çıkarabilir. Dokümantasyon ile telemetry birlikte kullanıldığında daha doğru dependency görünümü elde edilir.

API Backward Compatibility

API backward compatibility zero-downtime rollout'un en önemli sözleşmelerinden biridir. Eski client veya service yeni provider sürümüne geçiş anında güncellenmeyebilir. Additive değişiklikler bu nedenle daha güvenlidir. Alan silme, tip değiştirme veya anlam değiştirme işlemleri deprecation süreciyle yönetilmelidir. Consumer contract testleri release öncesinde uyumsuzluğu yakalayabilir.

Additive API Changes

Yeni optional field eklemek mevcut consumer'ları çoğu zaman bozmaz. Yeni endpoint eklemek de eski contract'ı korur. Response parser bilinmeyen alanları tolere etmelidir. Yeni behavior varsayılan olarak eski semantiği değiştirmemelidir. Additive yaklaşım bağımsız deployment'ı kolaylaştırır.

Field Silmeyi Ertelemek

Bir field artık kullanılmıyor görünse bile consumer telemetry kontrol edilmelidir. Eski mobile client aylarca kullanımda kalabilir. Field önce deprecated olarak işaretlenebilir. Kullanım sıfıra yaklaştığında removal planlanır. Breaking cleanup ayrı major API version'ına taşınabilir.

Optional Fields

Yeni field required yapılırsa eski consumer request'i başarısız olabilir. Geçiş döneminde optional field daha güvenlidir. Server field yoksa default davranış uygulayabilir. Consumer yeni field gelmediğinde de çalışabilmelidir. İki yönlü tolerance version skew için güçlü model oluşturur.

API Versioning

Versioning breaking contract değişikliklerini izole etmeye yardımcı olur. URL, header veya content negotiation yaklaşımı kullanılabilir. Eski version için deprecation süresi tanımlanmalıdır. Kullanım metriği migration ilerlemesini gösterir. Yeni version yalnızca isim değişikliği için gereksiz oluşturulmamalıdır.

Consumer Contract Test

Consumer beklentileri otomatik test haline getirilebilir. Provider pipeline bu testleri deployment öncesinde çalıştırır. Response field ve status code değişiklikleri erken görülür. Contract test gerçek production dependency davranışını tamamen kapsamayabilir. Integration ve synthetic testlerle birlikte kullanılmalıdır.

Deprecation Policy

Deprecation policy bir API özelliğinin ne kadar süre destekleneceğini açıklar. Consumer ekiplerin migration planı yapmasını kolaylaştırır. Removal tarihi telemetry ile doğrulanmalıdır. Kritik consumer henüz geçmediyse risk değerlendirmesi yapılır. Açık policy bağımsız ekipler arasındaki release koordinasyonunu azaltır.

Event-Driven Sistemlerde Zero-Downtime

Event-driven mimaride producer ve consumer aynı anda deploy edilmez. Kafka veya RabbitMQ üzerinde eski event'ler uzun süre kalabilir. Schema evolution bu nedenle hem backward hem forward compatibility gerektirebilir. Consumer version skew normal çalışma durumu olarak kabul edilmelidir. Schema registry veya açık versioning kuralları event kontratını yönetmeyi kolaylaştırır.

Kafka

Kafka event'leri retention süresi boyunca saklayabilir. Yeni consumer geçmişte üretilmiş eski schema'yı okuyabilir. Yeni producer mesajı eski consumer tarafından da işlenebilir olmalıdır. Partition rebalance deployment sırasında kısa processing duraklaması oluşturabilir. Graceful consumer shutdown rebalance etkisini azaltabilir.

RabbitMQ

RabbitMQ acknowledgement ve redelivery mekanizmaları deployment sırasında önemlidir. Consumer kapandığında unacked mesaj tekrar queue'ya dönebilir. Idempotency duplicate processing riskini azaltır. Prefetch değeri draining süresini etkiler. Çok yüksek prefetch bir pod kapanırken çok sayıda in-flight mesaj bırakabilir.

Event Schema Evolution

Event schema değişiklikleri immutable geçmiş veri gerçeğini dikkate almalıdır. Eski event'i değiştiremezsiniz. Yeni consumer eski schema'yı okuyabilmelidir. Yeni field optional eklenebilir. Field semantiğinin değiştirilmesi yeni field oluşturmaktan daha risklidir.

Schema Registry

Schema registry event formatlarını merkezi olarak takip eder. Compatibility rule producer release öncesinde kontrol edilebilir. Backward veya forward policy use case'e göre seçilir. Registry kullanmak kötü schema tasarımını otomatik düzeltmez. Event sahipliği ve deprecation süreci yine gereklidir.

Forward Compatibility

Forward compatibility eski consumer'ın daha yeni schema ile üretilmiş veriyi işleyebilmesini ifade eder. Bilinmeyen alanların yok sayılması bunu destekleyebilir. Required semantics değişikliği risktir. Canary producer yeni event'i küçük trafik grubunda yayınlasa bile aynı topic'teki consumer'lar etkilenebilir. Event rollout application traffic rollout'tan farklı düşünülmelidir.

Backward Compatibility

Backward compatibility yeni consumer'ın eski event'leri okuyabilmesini sağlar. Replay veya consumer offset reset durumunda önemlidir. Required yeni field eski event'lerde bulunmayabilir. Default değer veya optional schema gerekir. Test dataset'i geçmiş schema version'larını içermelidir.

Consumer Version Skew

Farklı consumer instance'ları aynı anda farklı code version çalıştırabilir. Rolling deployment bunu doğal olarak oluşturur. Message formatı her ikisi için güvenli olmalıdır. Business behavior değişiyorsa aynı event'in iki version tarafından farklı yorumlanması analiz edilmelidir. Gerekirse event version veya feature flag kullanılabilir.

Feature Flags ile Zero-Downtime Release

Feature flag kod deployment'ını kullanıcıya feature release etmekten ayırır. Yeni kod production'a kapalı durumda çıkabilir. Internal kullanıcılar veya küçük trafik yüzdesiyle özellik açılabilir. Hata durumunda yeniden deployment yapmadan kill switch kullanılabilir. Bu yaklaşım database migration ve yeni integration gibi riskli özelliklerin rollout'unu daha kontrollü hale getirir.

Deployment ile Release'i Ayırmak

Deployment code'un production ortamına ulaşmasıdır. Release ise kullanıcının yeni davranışı görmeye başlamasıdır. Feature flag bu iki olayı farklı zamanlara böler. Teknik ekip deployment'ı düşük riskli pencereye alabilir. Ürün ekibi feature activation'ı business planına göre yönetebilir.

Dark Launch

Dark launch yeni kodun production'da çalışıp kullanıcıya görünmemesidir. Backend yeni hesaplamayı shadow şekilde yapabilir. Sonuç eski behavior ile karşılaştırılabilir. Side effect oluşturulmaması gerekir. Confidence arttığında feature flag üzerinden gerçek release yapılabilir.

Feature Toggle

Feature toggle belirli kod yolunu runtime configuration ile açıp kapatır. Deployment gerekmeden davranış değiştirilebilir. Flag evaluation hızlı ve yüksek erişilebilir olmalıdır. Ana request path'i remote flag service outage'ına bağımlı hale getirilmemelidir. Güvenli default değer tanımlanmalıdır.

User Segment

Feature yalnızca belirli kullanıcı grubuna açılabilir. Internal, beta veya belirli tenant segmentleri kullanılabilir. Sorun oluşursa etkilenme alanı sınırlı kalır. Segment kuralı authorization mekanizması yerine kullanılmamalıdır. Rollout metriği segment bazında ayrı izlenmelidir.

Percentage Rollout

Flag sistemi belirli yüzde kullanıcı için özelliği etkinleştirebilir. User ID hash ile deterministik dağıtım yapılabilir. Aynı kullanıcı her istekte tutarlı deneyim alır. Yüzde kademeli artırılabilir. Business ve error metrics her aşamada değerlendirilmelidir.

Kill Switch

Kill switch riskli özelliği hızlı biçimde kapatır. Incident sırasında full deployment rollback gerektirmeyebilir. Flag propagation süresinin kısa olması önemlidir. Default fallback behavior güvenli olmalıdır. Kill switch gerçek incident tatbikatlarında test edilmelidir.

Rollback Yerine Feature Disable

Yeni sürümde sadece tek feature sorunluysa tüm code'u rollback etmek gereksiz olabilir. Flag kapatılarak stable behavior korunabilir. Bu özellikle aynı release içinde çok sayıda bağımsız değişiklik olduğunda faydalıdır. Database breaking change varsa feature disable her problemi çözmez. Flag sınırları application architecture ile uyumlu tasarlanmalıdır.

Feature Flag Kullanmanın Riskleri

Feature flags güçlü olsa da kontrolsüz kullanıldığında code path sayısını hızla artırabilir. Flag debt eski koşulların codebase içinde kalmasına neden olur. Birbiriyle etkileşen çok sayıda flag test matrisini büyütür. Configuration drift farklı environment'larda farklı davranış yaratabilir. Her flag için owner, amaç ve expiration date tanımlamak bu riski azaltır.

Flag Debt

Geçici flag kalıcı hale geldiğinde code complexity artar. Her yeni geliştirme eski koşulu dikkate almak zorunda kalır. Test senaryoları çoğalır. Flag cleanup release tamamlandıktan sonra planlanmalıdır. Dashboard aktif ve expired flag'leri görünür hale getirebilir.

Eski Flag'lerin Temizlenmemesi

Kullanımı tamamlanmış flag code içinde gereksiz branch bırakır. Bir yıl sonra hangi tarafın gerçek behavior olduğu anlaşılmayabilir. Cleanup için ayrı ticket oluşturmak yerine release definition of done'a eklemek yararlıdır. Flag usage telemetry temizleme kararını destekler. Silme işlemi de normal code review sürecinden geçmelidir.

Birbiriyle Etkileşen Flag'ler

İki flag dört davranış kombinasyonu oluşturabilir. Flag sayısı arttıkça kombinasyon sayısı hızla büyür. Tüm kombinasyonları test etmek pratik olmayabilir. Birbiriyle güçlü bağımlı flag'ler tek rollout modeli altında birleştirilebilir. Critical path üzerinde flag sayısı sınırlı tutulmalıdır.

Configuration Drift

Staging ve production farklı flag state taşıyabilir. Testte görülen behavior production'dan farklı hale gelir. Flag configuration version control veya audit history ile takip edilmelidir. Environment farkları görünür olmalıdır. Kritik rollout öncesinde hedef segment ve flag state otomatik doğrulanabilir.

Flag Owner ve Expiration Date

Her flag'in sorumlu ekibi bulunmalıdır. Expiration date geçici flag'in unutulmasını önler. Süresi dolan flag için otomatik bildirim üretilebilir. Kalıcı operational flag ile temporary release flag ayrılmalıdır. Sahiplik modeli feature flag sisteminin uzun vadeli bakımını kolaylaştırır.

Shadow Deployment Nedir?

Shadow deployment gerçek production trafiğini yeni sürüme kopyalar ancak yeni sürümün cevabını kullanıcıya göndermez. Bu yöntem performans ve compatibility davranışını gerçek workload altında gözlemek için değerlidir. Yeni sürüm production data formatlarını ve request çeşitliliğini görür. Ancak write veya external side effect işlemleri duplicate etki oluşturabileceği için kontrol edilmelidir. Shadow test validation sağlar fakat kullanıcıya gerçek cevap vermediği için canary'nin yerini tamamen tutmaz.

Production Trafiğini Yeni Sürüme Kopyalamak

Proxy gelen request'in bir kopyasını shadow backend'e gönderebilir. Stable backend kullanıcı cevabını üretmeye devam eder. Shadow latency kullanıcı response süresini etkilememelidir. Trafik kopyalamanın ek network ve compute maliyeti vardır. Hassas veri erişimi güvenlik politikalarıyla uyumlu olmalıdır.

Response'u Kullanıcıya Döndürmemek

Shadow response yalnızca analiz için kullanılır. Kullanıcı stable version'ın cevabını alır. Böylece yeni sürüm hatası doğrudan kullanıcı etkisi yaratmaz. Response diff sistemi iki sürüm arasındaki farkları ölçebilir. Nondeterministic alanlar karşılaştırmada normalize edilmelidir.

Production Workload Testi

Sentetik load test gerçek kullanıcı çeşitliliğini her zaman yakalayamaz. Shadow gerçek request pattern'lerini yeni sürüme taşır. Cache, serialization ve query davranışları production'a yakın şekilde görülür. Capacity planı shadow ek yükünü hesaba katmalıdır. Test süresi peak traffic dönemini kapsayabilir.

Side Effect Problemi

Shadow request payment veya email gönderirse duplicate side effect oluşabilir. Bu nedenle write operasyonları engellenmelidir. Dependency'ler mock veya read-only mode ile kullanılabilir. Side effect suppression eksikse shadow deployment production verisini bozabilir. Shadow eligibility endpoint bazında tanımlanmalıdır.

Read-Only Shadow Traffic

GET benzeri read-only request'ler shadow için daha güvenlidir. Yine de read işlemi analytics event veya cache write oluşturabilir. Gerçek side effect listesi application davranışına göre belirlenmelidir. Database read load iki katına çıkabilir. Capacity ve rate limit bu nedenle test öncesinde gözden geçirilmelidir.

Shadow ile Canary Farkı

Shadow response kullanıcıya gitmediği için reliability riskini doğrudan test etmez. Canary gerçek kullanıcı response'unu yeni sürümden verir. Shadow daha düşük kullanıcı riskiyle workload compatibility ölçer. Canary business ve latency etkisini gerçek sonuç üzerinden değerlendirir. Kritik release'lerde shadow ardından canary uygulanabilir.

A/B Testing ile Canary Arasındaki Fark

A/B testing ile canary benzer trafik ayırma tekniklerini kullanabilir ancak amaçları farklıdır. Canary'nin temel hedefi yeni sürümün güvenilirliğini ölçmektir. A/B testing ürün davranışının business etkisini karşılaştırır. Canary error rate ve latency izlerken A/B experiment conversion veya engagement ölçebilir. Bu ayrım rollout karar mekanizmasının doğru kurulması için önemlidir.

Canary'nin Amacı Reliability

Canary yeni sürümün hata üretip üretmediğini anlamaya odaklanır. Teknik metric'ler temel karar sinyalidir. Business KPI de regression yakalamak için eklenebilir. Sorun görülürse rollout durdurulur. Amaç hangi tasarımın daha iyi satış yaptığı değil hangi sürümün güvenli olduğudur.

A/B'nin Amacı Deney

A/B test iki ürün varyantının kullanıcı davranışına etkisini ölçer. Her iki varyant teknik olarak sağlıklı olabilir. Conversion veya retention gibi iş metrikleri karşılaştırılır. Deney yeterli süre ve sample gerektirir. Sonuç product decision için kullanılır.

Traffic Segmentation

Her iki yaklaşım kullanıcıları gruplara ayırabilir. Deterministik user ID hash sık kullanılır. Canary segmenti risk yönetimi amacı taşır. A/B segmenti deney istatistiğini korumayı hedefler. Segment altyapısı ortak olabilir ancak karar mantığı ayrı tutulmalıdır.

Business Metric

Canary'de business metric hızlı regression sinyali olarak kullanılabilir. A/B testte business metric deney sonucunun merkezidir. Canary baseline'a göre ani düşüşte abort edebilir. A/B daha uzun süre istatistiksel anlamlılık bekler. Aynı dashboard iki amacı karıştırmamalıdır.

Statistical Significance

A/B test genellikle istatistiksel anlamlılık gerektirir. Canary için reliability threshold daha deterministik olabilir. Örneğin HTTP 5xx oranının yüzde 2'yi aşması doğrudan abort sebebi sayılabilir. Çok düşük hata oranlarında sample size yine önemlidir. Measurement design rollout amacına göre yapılmalıdır.

Deployment ve Product Experiment Ayrımı

Deployment code'un production'a güvenli taşınmasıyla ilgilidir. Product experiment yeni davranışın kullanıcı etkisini ölçer. Feature flag ikisini birbirinden ayırabilir. Önce release reliability canary ile doğrulanabilir. Ardından A/B experiment daha uzun süre business sonuçlarını ölçebilir.

Deployment Öncesi Kontroller

Zero-downtime başarısı production'a çıktıktan sonra başlayan bir süreç değildir. Unit, integration ve contract testler temel hataları önceden yakalar. Database compatibility test eski ve yeni sürümün schema davranışını doğrular. Security scan ve infrastructure validation release riskini azaltır. Smoke test ise deployment artifact'inin hedef environment'ta gerçekten çalıştığını kontrol eder.

Unit Test

Unit test küçük code parçalarının beklenen davranışını doğrular. Hızlı olduğu için pipeline'ın ilk aşamalarında çalıştırılabilir. Regression hatalarını production'dan önce yakalar. Zero-downtime'a doğrudan garanti vermez. Ancak hatalı sürümün rollout aşamasına ulaşma ihtimalini azaltır.

Integration Test

Integration test database, queue veya dış servis etkileşimlerini kontrol eder. Schema ve serialization sorunları burada görülebilir. Test environment production configuration'a makul ölçüde yakın olmalıdır. Gerçek dış servis yerine test endpoint kullanılabilir. Timeout ve retry davranışları da senaryolara dahil edilmelidir.

Contract Test

Contract test servisler arası API beklentilerini doğrular. Provider değişikliği consumer'ı bozuyorsa release öncesinde sinyal verir. Event schema için de benzer test uygulanabilir. Bağımsız microservice deployment'ını güvenli hale getirir. Contract test runtime availability kontrollerinin yerine geçmez.

Database Compatibility Test

Eski application yeni schema üzerinde test edilmelidir. Yeni application gerekiyorsa eski schema üzerinde de çalıştırılmalıdır. Migration rollback senaryosu doğrulanmalıdır. Destructive change otomatik olarak işaretlenebilir. Production data shape'e benzeyen test dataset'i edge case yakalama olasılığını artırır.

Smoke Test

Smoke test deployment sonrası kritik yolların temel çalışmasını doğrular. Health endpoint tek başına yeterli değildir. Login, database read/write ve ana API çağrıları test edilebilir. Test kısa ve güvenilir olmalıdır. Flaky smoke test gereksiz deployment abort'larına yol açabilir.

Security Scan

Container image ve dependency scan pipeline'a eklenebilir. Kritik vulnerability release'i durdurabilir. Policy severity ve exploitability bilgisine göre tasarlanmalıdır. Secret leakage scan de uygulanabilir. Security gate deployment güvenliğini reliability ile birlikte ele alır.

Infrastructure Validation

Manifest veya Terraform değişiklikleri syntax ve policy açısından kontrol edilmelidir. Resource limit ve probe eksikleri otomatik bulunabilir. Kubernetes admission policy riskli configuration'ı engelleyebilir. Deployment strategy ayarları platform standardıyla karşılaştırılabilir. Infrastructure change application release kadar review gerektirir.

Smoke Test ile Deployment Validation

Smoke test yeni sürümün yalnızca Ready görünmesini değil, temel işlevleri gerçekten yerine getirebildiğini doğrular. Blue-green ortamda traffic switch öncesi çalıştırılabilir. Canary rollout'ta ilk trafik adımından sonra tekrar uygulanabilir. Kritik endpoint, database, authentication ve dış bağımlılıklar test kapsamına alınmalıdır. Sonuç otomatik promotion gate olarak kullanılabilir.

Green Environment Testi

Green environment public trafik almadan önce smoke test edilebilir. Internal service endpoint üzerinden istek gönderilebilir. Database bağlantısı ve temel query doğrulanır. Configuration veya secret hataları cutover öncesinde görülür. Test production verisini bozacak yan etki oluşturmamalıdır.

Canary Testi

Canary replica gerçek routing üzerinden smoke request alabilir. Header bazlı route ile yalnızca test trafiği gönderilebilir. Basic functionality doğrulandıktan sonra kullanıcı trafiği açılır. Canary health yalnızca Kubernetes Ready state'ine bırakılmaz. Test sonucu rollout controller'a promotion sinyali verebilir.

Kritik Endpoint'ler

Her endpoint smoke test'e eklenmemelidir. Kullanıcı yolculuğunun en kritik birkaç işlemi seçilmelidir. Login, checkout veya temel API read örnek olabilir. Test hızlı tamamlanmalıdır. Çok uzun suite deployment recovery süresini artırabilir.

Database Read/Write

Read testi yalnızca connection kurulabildiğini değil gerçek query davranışını doğrular. Güvenli test kaydı üzerinden write yapılabilir. İşlem sonunda cleanup uygulanmalıdır. Permission ve schema hataları bu aşamada erken görülebilir. Production data üzerinde destructive test yapılmamalıdır.

Authentication

Authentication configuration deployment sırasında sık hata kaynağıdır. Token signing key veya identity provider bağlantısı doğrulanmalıdır. Test hesabı kontrollü kullanılabilir. Authorization kritik endpoint için ayrıca kontrol edilebilir. Secret rotation yapılmışsa eski ve yeni credential overlap davranışı test edilmelidir.

External Dependency

Dış servis erişimi smoke test'e dahil edilebilir. Ancak üçüncü taraf geçici outage her deployment'ı gereksiz durdurmamalıdır. Dependency criticality belirlenmelidir. Timeout kısa tutulmalıdır. Fallback davranışı varsa test senaryosu bunu da doğrulayabilir.

Otomatik Promotion Gate

Smoke test başarısızsa rollout ilerlememelidir. Pipeline veya rollout controller sonucu gate olarak kullanabilir. Başarılı test tek başına full promotion anlamına gelmez. Production metric observation devam etmelidir. Gate sonuçları deployment ID ile kaydedilmelidir.

Production Verification Nasıl Yapılır?

Production verification yeni sürümün gerçek sistem davranışını ölçer. Synthetic request hızlı temel kontrol sağlar. Real user traffic ise gerçek workload çeşitliliğini ortaya çıkarır. Error rate, latency, saturation, business KPI, log ve trace sinyalleri birlikte değerlendirilmelidir. Version label sayesinde yeni sürüm stable baseline ile doğrudan karşılaştırılabilir.

Synthetic Request

Synthetic request belirli aralıklarla kontrollü kullanıcı işlemi üretir. Deployment sonrası anında sinyal sağlar. Kritik endpoint farklı region'lardan test edilebilir. Test hesabı ve verisi production işlemlerinden ayrılmalıdır. Synthetic başarı gerçek kullanıcı trafiğinin tümünü temsil etmediği için tek metric olarak kullanılmamalıdır.

Real User Traffic

Gerçek kullanıcı trafiği beklenmeyen payload ve kullanım kalıplarını ortaya çıkarır. Canary bu veriyi düşük riskle toplar. Version bazlı metrikler yeni sürümün davranışını ayrı gösterir. Privacy politikaları telemetry tasarımında korunmalıdır. Promotion kararı yeterli sample sonrasında verilmelidir.

Error Rate

HTTP 5xx rate en temel release metric'lerinden biridir. Ancak expected 4xx hataları ayrı değerlendirilmelidir. Error rate yeni ve stable version arasında karşılaştırılabilir. Düşük trafik sisteminde tek hata oranı fazla oynatabilir. Minimum sample threshold bu nedenle önemlidir.

Latency

Average latency tek başına tail problemlerini gizleyebilir. P95 ve P99 yeni sürüm regression'larını daha iyi gösterebilir. Endpoint bazlı latency ayrımı root cause analizini kolaylaştırır. Database veya downstream latency trace üzerinden ayrıştırılabilir. Canary promotion threshold'u baseline'a göre yüzdesel değişim olarak tanımlanabilir.

Saturation

CPU, memory, connection pool ve thread pool saturation takip edilmelidir. Yeni sürüm aynı request sayısında daha fazla kaynak tüketebilir. Küçük canary yüzdesinde bu fark normalize edilerek karşılaştırılmalıdır. Resource limit'e yaklaşan pod ilerleyen traffic step'te sorun çıkarabilir. Capacity headroom promotion kararında dikkate alınmalıdır.

Business KPI

Teknik metrikler normal görünürken business işlem bozulabilir. Örneğin API 200 döndürür ancak ödeme kaydı oluşturulmuyor olabilir. Payment success rate, order completion veya signup conversion doğrudan sinyal sağlar. KPI metriği mümkün olduğunca gerçek time'a yakın üretilmelidir. Çok gecikmeli metric otomatik rollback için uygun olmayabilir.

Log Anomalileri

Yeni exception type veya warning artışı loglarda görülebilir. Version label ile yeni sürüm logları ayrılabilir. Sadece log count yerine pattern ve severity izlenebilir. Sensitive data loglanmamalıdır. Anomaly detection destekleyici sinyal olarak kullanılabilir.

Trace Hataları

Distributed tracing bir request'in hangi dependency'de yavaşladığını gösterir. Yeni sürüm farklı downstream call pattern oluşturabilir. Error span sayısı version bazında karşılaştırılabilir. Trace sampling oranı yeterli veri üretmelidir. Canary düşük trafik alıyorsa sampling politikası buna göre ayarlanabilir.

Canary Success Metrics Nasıl Seçilir?

Canary metriği kullanıcı deneyimi ile doğrudan ilişkili ve kısa sürede ölçülebilir olmalıdır. HTTP 5xx, P95/P99 latency ve resource usage teknik sağlık sinyalleridir. Database error rate ve queue lag dependency davranışını gösterir. Payment success veya conversion rate business regression yakalayabilir. Her servis için aynı metrik listesi kullanmak yerine domain-specific KPI tanımlamak daha doğru sonuç verir.

HTTP 5xx Rate

Server error rate release regression'ı için güçlü sinyaldir. Stable ve canary version ayrı hesaplanmalıdır. Mutlak threshold ile baseline relative threshold birlikte kullanılabilir. Trafik azsa minimum request sayısı aranmalıdır. Expected test error'ları metric'ten ayrıştırılmalıdır.

P95 Latency

P95 kullanıcıların büyük bölümünün gördüğü tail latency davranışını gösterir. Average değerden daha anlamlı regression sinyali olabilir. Canary sample yeterli değilse metric gürültülü hale gelir. Endpoint veya operation bazında ayrı ölçüm yapılabilir. Baseline'a göre yüzde artış threshold'u kullanılabilir.

P99 Latency

P99 daha uç kullanıcı deneyimini gösterir. Yüksek trafik sistemlerinde anlamlıdır. Düşük sample'da çok değişken olabilir. Database veya network spike yeni sürümle yanlış korele edilebilir. Birkaç measurement window üst üste ihlal koşulu false abort'u azaltabilir.

CPU/Memory

Yeni sürüm memory leak veya yüksek CPU tüketimi gösterebilir. Request başına resource consumption karşılaştırması daha adil olabilir. Küçük canary replica sayısında load dağılımı normalize edilmelidir. Memory artışı kısa observation window'da görünmeyebilir. Uzun release soak test bazı servislerde gerekli olabilir.

Database Error Rate

Schema veya query değişikliği database hata oranını yükseltebilir. Timeout, deadlock ve constraint error ayrı izlenebilir. Version label application tarafından query telemetry'ye taşınabilir. Migration ile deployment aynı dönemdeyse korelasyon dikkatli yapılmalıdır. Database error artışı hızlı abort için güçlü sinyal olabilir.

Queue Lag

Consumer release'i processing hızını düşürebilir. Queue lag artışı kullanıcı-facing metric'ten önce sorun sinyali verebilir. Stable consumer baseline ile karşılaştırılabilir. Traffic veya event rate değişimi hesaba katılmalıdır. Lag sürekli yükseliyorsa promotion durdurulmalıdır.

Payment Success Rate

Ödeme servisinde en önemli metriklerden biri başarılı ödeme oranıdır. HTTP 200 alınması gerçek payment success anlamına gelmeyebilir. Provider response ve business transaction state birlikte izlenmelidir. Canary segment yeterli ödeme hacmine ulaşmadan karar verilmemelidir. Küçük değişim bile yüksek hacimde ciddi finansal etki oluşturabilir.

Conversion Rate

Conversion teknik regression'ın kullanıcı davranışındaki sonucunu gösterebilir. Ancak doğal business varyasyonu nedeniyle kısa window'da gürültülü olabilir. Canary abort için geniş güvenlik bandı kullanılabilir. Uzun dönem product experiment ile karıştırılmamalıdır. Teknik metriklerle birlikte yorumlandığında daha güçlü sinyal sağlar.

Domain-Specific KPI

Her servis kendi iş sonucunu temsil eden metriğe sahip olmalıdır. Notification servisi delivery success rate izleyebilir. Search servisi zero-result oranını ölçebilir. Auth servisi login success oranını takip edebilir. Bu metrik release güvenliğini kullanıcı gerçekliğiyle bağlar.

Automated Rollback Nasıl Tasarlanır?

Otomatik rollback yalnızca bir hata görünce eski image'a dönmek değildir. Failure threshold, measurement window ve minimum sample count önceden tanımlanmalıdır. Canary baseline ile karşılaştırılmalıdır. Trigger oluştuğunda traffic rollback, alert ve incident kaydı koordineli biçimde çalışabilir. Database veya external side effect içeren release'lerde otomatik geri dönüşün güvenli olup olmadığı ayrıca sınıflandırılmalıdır.

Failure Threshold

Threshold servisin normal error budget davranışına göre belirlenmelidir. Çok düşük threshold gereksiz abort üretir. Çok yüksek threshold kullanıcı etkisini büyütür. Relative baseline comparison trafik varyasyonunu azaltabilir. Kritik business KPI için daha hassas eşik uygulanabilir.

Measurement Window

Window metriğin yeterli data toplaması için gereken süreyi belirler. Çok kısa pencere geçici spike nedeniyle rollback tetikleyebilir. Çok uzun pencere ciddi hatanın etkisini büyütür. Trafik hacmi seçimde ana faktördür. Farklı metrikler farklı observation window gerektirebilir.

Minimum Sample Count

Metric threshold yanında minimum request veya event sayısı belirlenmelidir. İki request'ten birinin hata vermesi yüzde 50 error rate oluşturur ancak yeterli sample değildir. Promotion ve abort kararları sample koşulunu bekleyebilir. Kritik güvenlik hataları sample beklemeden doğrudan durdurulabilir. Kural seti failure type'a göre ayrılmalıdır.

Baseline ile Karşılaştırma

Stable version aynı anda production trafiği aldığı için iyi kontrol grubudur. Canary latency ve error rate stable ile karşılaştırılabilir. Global dependency outage iki version'ı da etkiliyorsa rollback gereksiz olabilir. Relative fark bu durumu anlamaya yardımcı olur. Baseline'ın kendisi sağlıksızsa rollout otomatik olarak pause edilebilir.

Rollback Trigger

Trigger metric policy ihlal edildiğinde çalışır. Traffic canary'den çekilir. Rollout state abort olarak kaydedilir. Database compatibility güvenliyse replica'lar kaldırılabilir. Trigger'ın manuel override ve audit mekanizması bulunmalıdır.

Alert

Otomatik rollback olsa bile ekip bilgilendirilmelidir. Alert deployment ID ve başarısız metric'i içermelidir. Dashboard linki incident response'u hızlandırır. Gereksiz duplicate alert'ler gruplanmalıdır. Rollback başarılı oldu bilgisi ayrıca kaydedilmelidir.

Incident Creation

Yüksek önem seviyesinde otomatik incident oluşturulabilir. Release commit, author, version ve metric snapshot incident'e eklenebilir. Timeline deployment event'leriyle otomatik doldurulabilir. Bu veri postmortem sürecini kolaylaştırır. Incident kapanırken rollout policy'nin iyileştirilmesi de değerlendirilmelidir.

Rollback Her Zaman Güvenli midir?

Rollback çoğu ekipte güvenli çıkış yolu olarak düşünülür ancak her release için aynı derecede güvenli değildir. Database migration yeni schema oluşturmuş olabilir. Yeni sürüm eski application'ın anlamadığı veri yazmış olabilir. Event schema değişikliği consumer davranışını değiştirebilir. External payment veya transaction side effect geri alınamayacağı için bazı durumlarda roll-forward daha doğru seçenektir.

Database Migration Sonrası Rollback

Additive migration sonrası rollback genellikle daha güvenlidir. Destructive migration sonrası eski application çalışmayabilir. Yeni column'a yazılan verinin eski sürüm tarafından kullanılabilirliği kontrol edilmelidir. Rollback testinde yalnızca code değil yeni schema state kullanılmalıdır. Contract migration'ın geciktirilmesi bu yüzden önemlidir.

Event Schema Değişikliği

Yeni producer farklı event yayınladıysa mesajlar queue veya topic içinde kalır. Eski consumer rollback sonrası bu event'leri okuyamayabilir. Event backward compatibility önceden sağlanmalıdır. Gerekirse yeni schema ayrı event version olarak yayınlanır. Rollback planı already-produced message'ları hesaba katmalıdır.

Yeni Sürüm Tarafından Yazılmış Veriler

Yeni application yeni enum veya veri formatı yazmış olabilir. Eski sürüm bu değeri parse edemeyebilir. Code rollback anında error rate artabilir. Expand-and-contract ve tolerant reader pattern riski azaltır. Data compatibility release checklist'in açık maddesi olmalıdır.

External Side Effect

Email, ödeme veya üçüncü taraf API işlemi geri alınamayabilir. Application rollback bu etkileri silmez. Retry duplicate işlem oluşturabilir. Idempotency key external integration'da mümkünse kullanılmalıdır. Incident recovery state reconciliation gerektirebilir.

Payment ve Transaction İşlemleri

Finansal işlem rollback ile tersine çevrilecek sıradan state değildir. Payment provider işlemi tamamlamış olabilir. Application response kaybolsa bile para transferi gerçekleşmiş olabilir. Reconciliation ve idempotency kritik öneme sahiptir. Deployment stratejisi business transaction semantiğini dikkate almalıdır.

Roll-Forward'ın Daha Güvenli Olduğu Durumlar

Database state eski sürümle uyumsuz hale geldiyse hızlı fix release daha güvenli olabilir. Security patch geri alınmaması gereken değişiklik olabilir. Data migration'ın tersine çevrilmesi çok riskliyse roll-forward tercih edilebilir. Bu karar incident runbook içinde önceden sınıflandırılabilir. Ekibin rollback'ı otomatik varsayım olarak değil seçeneklerden biri olarak görmesi önemlidir.

Rollback vs Roll-Forward

Rollback önceki çalışan sürüme dönmeyi hedefler. Roll-forward ise problemi yeni bir düzeltme sürümüyle ileri yönde çözmektir. Code-only failure genellikle rollback için uygundur. Data migration veya irreversible side effect varsa roll-forward daha güvenli olabilir. Karar failure type, recovery süresi ve data compatibility üzerinden verilmelidir.

Code-Only Failure

Yeni code regression üretmiş ancak veri modelini değiştirmemiş olabilir. Stable image'a rollback hızlı çözümdür. Traffic yönü kısa sürede eski sürüme çekilebilir. Root cause daha sonra güvenli ortamda incelenir. Bu sınıf otomatik rollback için iyi adaydır.

Data Migration Failure

Migration yarıda kalmışsa önce database state anlaşılmalıdır. Application rollback veriyi otomatik düzeltmez. Idempotent migration tekrar çalıştırılabilir. Gerekirse forward fix schema'yı tamamlar. Veri güvenliği hızdan önce gelir.

Configuration Failure

Yanlış environment variable veya feature flag release'i bozabilir. Code rollback yerine configuration revert yeterli olabilir. Secret rotation sırasında eski credential hâlâ geçerliyse hızlı dönüş yapılabilir. Configuration versioning recovery'yi kolaylaştırır. Runtime config değişiklikleri audit edilmelidir.

Security Incident

Yeni sürüm security vulnerability kapatıyorsa eski sürüme rollback riski yeniden açabilir. Sorun farklı bir regression ise roll-forward tercih edilebilir. Incident commander security ve availability riskini birlikte değerlendirir. Geçici feature disable kullanılabilir. Recovery kararı yalnızca error rate üzerinden verilmemelidir.

Hangi Durumda Hangisi Kullanılmalı?

Failure yalnızca yeni code'a bağlı ve eski state uyumluysa rollback hızlıdır. Veri veya schema ileri yönde değişmişse roll-forward genellikle daha kontrollüdür. External side effect varsa geri dönüşün gerçek etkisi analiz edilmelidir. Runbook failure kategorilerine göre önerilen yolu önceden tanımlayabilir. Incident sırasında ilk kez karar modeli oluşturmak recovery süresini uzatır.

Deployment Yarıda Kalırsa Ne Olur?

Deployment'ın her zaman başarıyla veya temiz bir rollback ile biteceği varsayılmamalıdır. Pipeline network hatası nedeniyle yarıda kesilebilir. Cluster içinde old ve new instance karışımı kalabilir. Traffic state veya database migration state beklenenden farklı olabilir. Bu nedenle pipeline tekrar çalıştırılabilir ve deployment adımları mümkün olduğunca idempotent olmalıdır.

Pipeline State

Pipeline hangi adımın tamamlandığını kalıcı olarak bilmelidir. Runner process'inin kapanması state'i kaybettirmemelidir. Artifact version açık biçimde kaydedilmelidir. Retry aynı artifact'i kullanmalıdır. Yarım pipeline yeni ve farklı artifact üretmemelidir.

Old/New Instance Dağılımı

Cluster'da üç eski ve iki yeni pod kalmış olabilir. Recovery önce gerçek runtime state'i gözlemlemelidir. Blind rollback gereksiz pod churn yaratabilir. Controller desired state'e yeniden reconcile edebilir. Version label dashboard'da dağılımı görünür hale getirir.

Traffic State

Canary traffic yüzde 25 seviyesinde kalmış olabilir. Pipeline yeniden çalıştığında bu state'in farkında olmalıdır. Sıfırdan yüzde 1'e dönmek veya doğrudan yüzde 50'ye atlamak riskli olabilir. Traffic configuration desired state olarak version control'da tutulabilir. Runtime routing state ayrıca gözlemlenmelidir.

Database Migration State

Migration yüzde 60 backfill tamamlamış olabilir. Baştan çalıştırılan script duplicate veya error üretmemelidir. Checkpoint state devam noktası sağlar. Schema operation zaten uygulanmışsa script bunu tanıyabilmelidir. Migration idempotency recovery için temel gereksinimdir.

Tekrar Çalıştırılabilir Pipeline

Aynı pipeline ikinci kez çalıştırıldığında mevcut state'i güvenli biçimde algılamalıdır. Artifact yeniden build edilmek yerine aynı immutable artifact kullanılabilir. Deployment step desired version zaten varsa no-op olabilir. Migration step tamamlandıysa atlanabilir. Bu yaklaşım incident sırasında manuel müdahale ihtiyacını azaltır.

Idempotent Deployment Step'leri

Bir adım birden fazla çalıştığında aynı son state'i üretmelidir. Resource create işlemi exists durumunu yönetmelidir. Traffic update mevcut weight'i okuyabilir. Migration duplicate data oluşturmamalıdır. Idempotency otomasyon güvenilirliğini artırır.

Recovery Runbook

Runbook yarım deployment senaryosunda uygulanacak adımları açıklar. Önce traffic ve application state gözlemlenir. Database migration durumu kontrol edilir. Sonra rollback veya roll-forward kararı verilir. Runbook düzenli game day çalışmalarıyla test edilmelidir.

Immutable Deployment

Immutable deployment çalışan sunucu üzerindeki code'u yerinde değiştirmek yerine yeni artifact üretip yeni instance başlatır. Böylece hangi sürümün çalıştığı daha net olur. Container image digest artifact'i kesin olarak tanımlar. Aynı artifact staging ve production'a taşınabilir. Rollback eski immutable artifact'in tekrar aktif edilmesiyle daha öngörülebilir hale gelir.

Sunucu Üzerinde Kod Güncellememek

SSH ile production sunucusunda dosya değiştirmek configuration drift oluşturur. Hangi node'un hangi code'u çalıştırdığı belirsizleşebilir. Rollback manuel ve hataya açık hale gelir. Yeni instance modeli bu problemi azaltır. Production değişiklikleri pipeline üzerinden izlenebilir olmalıdır.

Yeni Artifact Üretmek

Her release versionlanmış artifact oluşturur. Artifact build tamamlandıktan sonra değiştirilmemelidir. Aynı binary veya image farklı environment'larda kullanılabilir. Environment farkları configuration ile yönetilir. Reproducibility incident analizini kolaylaştırır.

Container Image

Container image application ve runtime dependency'lerini paketler. Tag kullanışlı olsa da mutable olabilir. Production deployment belirli digest'e bağlanabilir. Image security scan release öncesinde çalıştırılabilir. Eski image rollback penceresi boyunca registry'de korunmalıdır.

Image Digest

Digest image içeriğini benzersiz biçimde tanımlar. latest gibi tag'in zaman içinde değişmesi riskini ortadan kaldırır. Deployment metadata'da digest kaydedilebilir. Incident sırasında hangi binary'nin çalıştığı kesin olarak bilinir. Git commit ile digest arasında traceability oluşturulmalıdır.

Immutable Infrastructure

Server configuration yerinde sürekli değiştirilmez. Yeni configuration yeni instance image veya declarative resource üzerinden uygulanır. Drift azalır. Rollback önceki infrastructure definition'a dönebilir. Stateful data katmanı yine ayrı lifecycle gerektirir.

Reproducible Deployment

Aynı commit aynı artifact'i üretmelidir. Build dependency version'ları pin edilebilir. Environment-specific code build etmekten kaçınılmalıdır. Release manifest hangi artifact ve config version'ın birlikte kullanıldığını gösterir. Reproducibility production sorununun staging'de yeniden oluşturulmasını kolaylaştırır.

Configuration ve Secret Değişikliklerinde Zero-Downtime

Zero-downtime yalnızca application code release'i için düşünülmemelidir. Configuration ve secret değişiklikleri de sürümler arası overlap gerektirir. Secret rotation sırasında eski ve yeni credential belirli süre birlikte geçerli olabilir. Database veya API key değişikliklerinde önce consumer yeni credential'ı öğrenir, ardından eski credential iptal edilir. Configuration versioning hangi release'in hangi ayarlarla çalıştığını görünür hale getirir.

Configuration Versioning

Configuration değişiklikleri source control veya versioned store üzerinden takip edilebilir. Hangi deployment'ın hangi config ile çalıştığı kaydedilir. Rollback code ve config birlikteliğini dikkate almalıdır. Tek bir global mutable config geçmiş davranışı yeniden oluşturmayı zorlaştırır. Deployment ID config version ile ilişkilendirilebilir.

Dynamic Configuration

Dynamic config runtime restart olmadan davranış değiştirir. Feature flag buna örnek olabilir. Propagation süresi bilinmelidir. Farklı instance'ların kısa süre farklı config kullanabileceği varsayılmalıdır. Breaking config değişiklikleri bu overlap dönemine uygun tasarlanmalıdır.

Secret Rotation

Secret rotation eski credential'ı anında iptal ederek yapılmamalıdır. Önce yeni secret oluşturulur. Application instance'ları yeni secret'ı kullanmaya geçer. Kullanım doğrulandıktan sonra eski secret kaldırılır. Bu iki aşamalı model deployment sırasında authentication kesintisini önler.

Eski ve Yeni Secret'ın Geçici Birlikte Geçerliliği

Overlap period version skew için güvenli pencere sağlar. Eski pod eski secret ile çalışmaya devam eder. Yeni pod yeni secret kullanabilir. Tüm eski connection'lar kapandıktan sonra eski credential revoke edilir. Overlap süresi gereksiz uzun bırakılmamalıdır.

Database Credential Rotation

Yeni database user veya password önce oluşturulabilir. Application config yeni credential'a geçirilir. Connection pool eski connection'ları zaman içinde kapatır. Yeni login başarı oranı izlenir. Tüm instance'lar geçtiğinde eski credential iptal edilir.

API Key Rotation

External provider birden fazla key destekliyorsa yeni key önce aktif edilir. Application rollout yeni key'i kullanmaya başlar. Request success metric takip edilir. Eski sürümler tamamen devreden çıkınca eski key revoke edilir. Provider tek key destekliyorsa geçiş için farklı koordinasyon mekanizması gerekebilir.

TLS Certificate Rotation ile Zero-Downtime

TLS certificate rotation yanlış sıralandığında tamamen sağlıklı application'ı erişilemez hale getirebilir. Eski ve yeni certificate için overlap süresi bırakmak güvenlidir. CA rotation daha da dikkatli planlanmalıdır çünkü trust store ve certificate değişiklikleri belirli sırayla ilerlemelidir. mTLS ortamında hem client hem server tarafı etkilenir. Certificate expiry monitoring son dakika operasyonlarını önler.

Eski ve Yeni Certificate'ın Overlap Süresi

Yeni certificate expiry gelmeden önce deploy edilmelidir. Load balancer veya server yeni sertifikayı kullanmaya geçer. Eski connection'lar eski TLS session ile bir süre devam edebilir. Yeni bağlantıların certificate doğrulaması izlenmelidir. Eski certificate ancak geçiş doğrulandıktan sonra kaldırılır.

CA Rotation

CA değişikliği certificate değişikliğinden daha geniş etki yaratır. Önce trust store hem eski hem yeni CA'yı kabul edebilir. Ardından yeni CA ile imzalanmış certificate deploy edilir. Tüm taraflar yeni CA'ya geçtiğinde eski CA trust'tan çıkarılır. Sıra ters uygulanırsa connection failure oluşabilir.

Trust Store Güncelleme Sırası

Consumer önce yeni CA'ya güvenmeye başlamalıdır. Provider daha sonra yeni certificate'a geçebilir. Eski CA geçiş sırasında trust store'da kalır. Observation sonrasında eski trust kaldırılır. Multi-service ortamında bu sıra otomasyonla takip edilmelidir.

mTLS Ortamında Rotation

mTLS hem client hem server sertifikalarını doğrular. Rotation iki yönlü olduğu için daha fazla overlap gerektirir. Client certificate issuer değişirse server trust store önce güncellenmelidir. Server certificate değişiminde client trust store aynı şekilde hazırlanır. Canary rotation küçük servis grubuyla test edilebilir.

Certificate Expiry Monitoring

Certificate expiry tarihleri metric haline getirilmelidir. Haftalar öncesinden alert üretilebilir. Otomatik renewal başarısızlığı ayrıca izlenmelidir. Sadece dosya expiry değil aktif endpoint certificate'ı dışarıdan doğrulanabilir. Bu yaklaşım planlanmamış TLS kesintilerini azaltır.

Multi-Region Zero-Downtime Deployment

Multi-region sistemlerde deployment riski coğrafi olarak kademeli yönetilebilir. Region-by-region rollout bir bölgeyi canary olarak kullanmaya izin verir. Global load balancer traffic weight ile yeni version'a sahip region'a küçük trafik gönderebilir. Cross-region database ve replication lag deployment kararını etkiler. Global rollback yalnızca application değil traffic ve data state'i kapsamalıdır.

Region-by-Region Rollout

İlk olarak düşük riskli veya küçük trafik region'ı seçilebilir. Yeni version burada deploy edilir. Teknik ve business metrikleri gözlenir. Başarı sonrası diğer region'lara geçilir. Aynı anda tüm region'ları değiştirmemek global blast radius'u azaltır.

Global Load Balancer

Global load balancer kullanıcıları region'lara yönlendirir. Health check başarısız region'ı trafikten çıkarabilir. Deployment sırasında weight kontrollü değiştirilebilir. Session veya data locality kısıtları routing kararını sınırlayabilir. DNS tabanlı global yönlendirmede TTL etkisi ayrıca değerlendirilmelidir.

Traffic Weight

Region traffic weight canary rollout için kullanılabilir. Yeni version bulunan region önce yüzde 5 global trafik alabilir. Capacity bu geçici dağılımı karşılamalıdır. Latency kullanıcı konumuna göre değişeceği için metric normalizasyonu gerekir. Promotion sonrası weight kademeli artırılabilir.

Region Canary

Bir region yeni sürüm için erken production test alanı olabilir. Ancak region trafiği global kullanıcı profilini tam temsil etmeyebilir. Payment provider veya data source region bazında farklı olabilir. Sonraki region'larda da kısa validation yapılmalıdır. Region canary tüm global rollout'un tek sinyali olarak görülmemelidir.

Cross-Region Database

Application rollout database write topology ile uyumlu olmalıdır. Single-writer sistemlerde uzak region latency artabilir. Multi-writer model conflict çözümü gerektirir. Schema migration tüm region application version'larıyla uyumlu olmalıdır. Database failover deployment ile aynı zaman aralığında planlanmamalıdır.

Replication Lag

Yeni version farklı query pattern nedeniyle replication lag artırabilir. Read-after-write davranışı region bazında bozulabilir. Lag release metric'ine dahil edilmelidir. Migration backfill bu değeri ayrıca yükseltebilir. Threshold aşılırsa region promotion durdurulmalıdır.

Global Rollback

Global rollback region'ların hangi version'da olduğunu bilmelidir. Traffic weight stable region'lara geri çekilebilir. Database schema rollback uyumluluğu kontrol edilmelidir. Her region aynı anda geri alınmak zorunda olmayabilir. Runbook region state ve global routing bilgisini birlikte göstermelidir.

Active-Active ve Active-Passive Deployment

Active-active modelde birden fazla environment veya region aynı anda production trafiği taşır. Active-passive modelde yedek environment normalde sınırlı veya hiç kullanıcı trafiği almaz. Deployment sırasında failover kullanılabilir. Data consistency iki modelde de kritik konudur. DNS ve global traffic management geçiş hızını ve kullanıcı davranışını etkiler.

Active-Active

Birden fazla site aynı anda aktif trafik alır. Deployment region bazında kademeli yapılabilir. Bir region sorun yaşarsa trafik diğerine kaydırılır. Data replication ve consistency modeli güçlü olmalıdır. Her region yeterli failover kapasitesine sahip olmalıdır.

Active-Passive

Primary site normal trafiği taşır. Passive site disaster recovery veya maintenance için hazır tutulur. Deployment passive üzerinde hazırlanıp failover yapılabilir. Passive environment'ın gerçekten güncel ve çalışır olduğu düzenli test edilmelidir. Uzun süre trafik almayan sistemde hidden configuration drift oluşabilir.

Deployment Sırasında Failover

Yeni sürüm önce passive tarafta hazırlanabilir. Smoke test sonrası trafik oraya geçirilebilir. Eski active rollback için korunur. Bu yaklaşım blue-green ile benzer davranış gösterebilir. Database replication direction ve write ownership geçişi en kritik noktadır.

Data Consistency

Active-active write conflict riski oluşturabilir. Strong consistency latency maliyeti getirebilir. Eventual consistency application semantics ile uyumlu olmalıdır. Deployment yeni data formatı ekliyorsa tüm region version'ları bunu anlayabilmelidir. Schema evolution global rollout'tan önce hazırlanmalıdır.

DNS ve Global Traffic Management

Global traffic manager health ve latency üzerinden region seçebilir. DNS routing kullanılıyorsa cache gecikmesi görülür. Anycast veya proxy tabanlı yöntem daha hızlı switch sağlayabilir. Failover sırasında session continuity değerlendirilmelidir. Traffic policy düzenli failover tatbikatlarıyla doğrulanmalıdır.

Zero-Downtime Deployment ve High Availability Arasındaki Fark

High availability servis arızalarında hizmetin erişilebilir kalmasını hedefler. Deployment stratejisi ise planlı version değişiklikleri sırasında availability'yi korur. İki kavram birbirini destekler ancak aynı şey değildir. Çoklu replica HA sağlayabilir fakat yanlış rolling configuration deployment sırasında kesinti yaratabilir. Benzer şekilde iyi deployment stratejisi tek failure domain'e bağlı sistemi altyapı arızasına karşı korumaz.

High Availability Neyi Çözer?

HA node, process veya zone failure durumlarında hizmet sürekliliğine odaklanır. Redundancy temel prensiptir. Load balancer sağlıksız instance'ı devreden çıkarabilir. Database replication veri katmanı availability'sini artırabilir. HA sürekli failure resilience hedefler.

Deployment Stratejisi Neyi Çözer?

Deployment stratejisi version değişikliğinin güvenli yapılmasını yönetir. Eski ve yeni sürüm geçişini belirler. Traffic shift, readiness ve rollback davranışını düzenler. Planlı değişikliklerin incident'e dönüşmesini önlemeyi amaçlar. Release-specific riskleri ele alır.

HA Olmadan Zero-Downtime Mümkün mü?

Tek instance sistemde gerçek zero-downtime çok zordur. Instance değiştirilirken trafik alacak alternatif yoktur. Özel process hot reload yöntemleri kullanılabilir ancak failure tolerance düşük kalır. En azından application seviyesinde redundancy genellikle gerekir. Bu nedenle HA prensipleri zero-downtime'ın temelini destekler.

Zero-Downtime Olmadan HA Yeterli mi?

Hayır. Üç replica çalıştırmak tek başına güvenli deployment sağlamaz. maxUnavailable yanlışsa tüm pod'lar kısa sürede devre dışı kalabilir. Breaking database migration tüm replica'ları aynı anda bozabilir. Readiness hatası load balancer'ın sağlıksız pod'a trafik göndermesine yol açabilir. HA capacity ile release engineering birlikte ele alınmalıdır.

Zero-Downtime Deployment ve Disaster Recovery Arasındaki Fark

Zero-downtime deployment normal release operasyonunun kullanıcıya kesinti yaşatmamasını hedefler. Disaster recovery büyük altyapı, region veya veri kaybı olaylarından geri dönmeye odaklanır. Rollback release failure için kullanılırken failover altyapı failure için daha uygun olabilir. Backup ve restore uzun süreli recovery mekanizmasıdır. Sağlıklı platform bu kavramların her biri için ayrı plan ve test bulundurur.

Release Failure

Yeni application sürümü error rate artırabilir. Canary abort veya blue-green rollback uygulanabilir. Stable infrastructure çalışmaya devam eder. Problem release artifact veya configuration kaynaklıdır. Recovery hedefi eski güvenli behavior'a dönmektir.

Infrastructure Failure

Node veya load balancer arızası release'ten bağımsız olabilir. HA mekanizması trafiği sağlıklı kaynağa yönlendirir. Deployment rollback sorunu çözmeyebilir. Infrastructure monitoring root cause'u gösterir. Recovery için redundancy ve automation kullanılır.

Region Failure

Tüm region erişilemez olabilir. Global traffic management kullanıcıyı başka region'a taşır. Data replication yeterli değilse RPO etkilenebilir. Deployment strategy tek başına bu durumu çözmez. Disaster recovery planı düzenli region failover testi içermelidir.

Backup/Restore

Backup veri kaybına karşı son savunma katmanıdır. Restore operasyonu dakikalar veya saatler sürebilir. Zero-downtime release sırasında normal rollback mekanizması olarak kullanılmamalıdır. Backup'ın var olması restore'un çalıştığı anlamına gelmez. Restore testleri düzenli yapılmalıdır.

Rollback

Rollback release değişikliğini geri alır. Code ve configuration seviyesinde hızlı olabilir. Data migration geri dönüşü daha zordur. Release runbook bu sınırları açıkça göstermelidir. Disaster recovery yerine günlük release kontrol mekanizması olarak düşünülür.

Failover

Failover trafiği yedek instance, zone veya region'a geçirir. Health check otomatik tetikleyebilir. Data consistency geçişin güvenliğini belirler. Failback ayrıca planlanmalıdır. Deployment sırasında failover yapmak mümkün olsa da iki operasyonun aynı anda gereksiz şekilde birleştirilmemesi daha güvenlidir.

Observability'nin Zero-Downtime Deployment'taki Rolü

Observability olmadan deployment'ın kullanıcıya gerçekten kesintisiz ulaşıp ulaşmadığını anlamak zordur. Metrics toplu davranışı, logs ayrıntılı olayları ve distributed tracing servisler arası gecikmeyi gösterir. Release marker hangi değişiklik sonrasında bozulma başladığını ortaya koyar. Deployment ID ve version label eski ile yeni sürümü karşılaştırmayı sağlar. Bu nedenle monitoring release pipeline'ın sonradan eklenen bir özelliği değil temel bileşenidir.

Metrics

Availability, error rate, latency ve throughput temel service metric'leridir. Version label metric üzerinde bulunmalıdır. Canary ve stable ayrı sorgulanabilir. Business KPI'lar aynı zaman aralığında karşılaştırılabilir. Metric retention post-incident analiz için yeterli olmalıdır.

Logs

Log satırında version veya deployment ID bulunması root cause analizini kolaylaştırır. Yeni exception pattern hızla görülebilir. Structured logging query kalitesini artırır. Sensitive data loglanmamalıdır. Log volume artışı da release regression sinyali olabilir.

Distributed Tracing

Trace request'in servisler arasındaki yolculuğunu gösterir. Yeni sürüm downstream çağrı sayısını artırmış olabilir. Latency hangi span'da oluştuğu görülebilir. Canary version trace attribute olarak işaretlenebilir. Sampling düşükse kritik error trace'leri ayrıca korunabilir.

Release Marker

Dashboard üzerine deployment zamanı işaretlenebilir. Metric değişimi release ile aynı grafikte görünür. Birden fazla servis deploy ediliyorsa her marker service name taşımalıdır. Incident timeline daha hızlı oluşturulur. Release marker otomatik pipeline event'inden üretilmelidir.

Deployment ID

Her rollout benzersiz ID alabilir. Log, metric ve trace bu kimlikle ilişkilendirilebilir. Aynı version farklı configuration ile tekrar deploy edildiğinde ayrım yapılır. Incident kaydı ilgili ID'yi taşıyabilir. Audit ve deployment analytics için güçlü bağ oluşturur.

Version Label

Version label stable ve canary metric'lerini karşılaştırmayı sağlar. Git SHA veya semantic version kullanılabilir. Label cardinality kontrol edilmelidir. Eski version metric'leri retention süresince analiz edilebilir. Dashboard query'leri rollout controller ile entegre edilebilir.

Correlation

Metric spike ile deployment event'i korele edilmelidir. Log exception ve trace latency aynı version üzerinde birleşebilir. Bu görünüm root cause süresini azaltır. Tek telemetry kaynağı çoğu zaman yeterli olmaz. Ortak timestamp ve deployment metadata correlation'ı kolaylaştırır.

Deployment Sonrası İzlenmesi Gereken Metrikler

Deployment başarı mesajı release sürecinin bittiği anlamına gelmez. Availability ve error rate kullanıcı etkisini gösterir. P50, P95 ve P99 latency performans dağılımını görünür kılar. Throughput, saturation, restart count, queue lag ve database latency sistem sağlığını tamamlar. Business KPI ise teknik başarı ile gerçek iş sonucunun aynı olup olmadığını doğrular.

Availability

Başarılı request oranı release boyunca izlenmelidir. SLO window ile karşılaştırılabilir. Region veya endpoint bazında ayrım yapılabilir. Canary küçük trafik aldığında ayrı availability metriği tutulmalıdır. Global availability stable version problemiyle karışmamalıdır.

Error Rate

Error rate HTTP ve application exception üzerinden ölçülebilir. Status code sınıfları ayrı takip edilmelidir. Yeni version hata oranı stable ile karşılaştırılır. Retry nedeniyle gerçek kullanıcı etkisi gizlenmemelidir. Error budget consumption deployment kararına bağlanabilir.

P50/P95/P99 Latency

P50 tipik kullanıcı deneyimini gösterir. P95 ve P99 tail latency problemlerini yakalar. Yeni release yalnızca P99'u bozabilir. Endpoint bazında dağılım daha anlamlı analiz sağlar. Latency threshold baseline'a göre tanımlanabilir.

Throughput

Request veya event sayısı trafik bağlamını verir. Error rate artışı traffic spike ile ilişkili olabilir. Canary trafik yüzdesinin gerçekten beklenen seviyede olduğu throughput üzerinden doğrulanabilir. Deployment sırasında ani throughput düşüşü routing hatasına işaret edebilir. Business throughput ayrıca ölçülebilir.

Saturation

CPU, memory, connection pool ve queue depth kaynak baskısını gösterir. Yeni version aynı trafik altında daha çok kaynak tüketebilir. Threshold'a yakın çalışan servis sonraki promotion step'te çökmeye yaklaşabilir. Autoscaling tepkisi izlenmelidir. Resource saturation latency ile birlikte yorumlanmalıdır.

Restart Count

Pod restart sayısı crash veya liveness problemini gösterebilir. Yeni version restart artışı güçlü regression sinyalidir. OOMKilled reason memory problemini ortaya çıkarabilir. Restart olan pod Ready görünerek error rate'i gizleyebilir. Deployment dashboard'unda restart count ayrıca gösterilmelidir.

Queue Lag

Worker release'i processing throughput'u azaltabilir. Queue lag yavaşça birikebilir. Kullanıcı hatası oluşmadan önce erken uyarı sağlar. Event rate değişimiyle normalize edilmelidir. Rollout sonrası uzun observation window gereken metriklerden biridir.

Database Latency

Yeni query pattern database latency'yi artırabilir. Application latency yükselmeden database metric sinyal verebilir. Read ve write latency ayrı izlenebilir. Lock wait ve connection pool usage tamamlayıcıdır. Migration aynı anda çalışıyorsa deployment correlation dikkatle yapılmalıdır.

Business KPI

Business KPI teknik olarak başarılı görünen release'in gerçek sonucunu ölçer. Checkout completion, payment success veya login success kullanılabilir. KPI düşüşü application error olmadan da gerçekleşebilir. Version veya user segment bazında karşılaştırma yapılabilir. Release safety ürün ve reliability verisini birlikte kullanmalıdır.

SLO ve Error Budget ile Deployment Yönetimi

SLO kullanıcıya verilen hizmet seviyesini ölçülebilir hedefe dönüştürür. Error budget bu hedef içinde kabul edilebilecek hata payını gösterir. Deployment release velocity ile reliability arasında bilinçli karar mekanizması kurabilir. Error budget hızla tükeniyorsa yeni feature release'leri geçici olarak durdurulabilir. Böylece zero-downtime yaklaşımı yalnızca teknik rollout değil işletilebilir service management modeli haline gelir.

Service Level Objective

SLO belirli zaman penceresinde hedef service level tanımlar. Örneğin successful request oranı üzerinden kurulabilir. Kullanıcı açısından anlamlı SLI seçilmelidir. Infrastructure uptime her zaman gerçek kullanıcı başarısını temsil etmez. Deployment metric threshold'ları SLO ile uyumlu olmalıdır.

Error Budget

Error budget hedef SLO ile yüzde 100 arasındaki izin verilen farktır. Sistem bu bütçeyi incident ve deployment hatalarında tüketir. Bütçe sağlıklıysa ekip daha hızlı release yapabilir. Tükenme hızlanırsa risk azaltıcı önlemler devreye girer. Bu yaklaşım reliability tartışmasını ölçülebilir hale getirir.

Deployment Risk Budget

Release'ler error budget tüketiminin önemli kaynağı olabilir. Deployment öncesinde mevcut budget durumu kontrol edilebilir. Budget düşükse daha yavaş canary veya ek approval uygulanabilir. Riskli release ertelenebilir. Böylece rollout policy service health'e dinamik uyum sağlar.

Error Budget Tükendiğinde Deployment Durdurmak

Budget tükenmiş sistem zaten SLO hedefinin gerisindedir. Yeni değişiklik ek risk oluşturabilir. Feature deployment geçici olarak durdurulup reliability çalışmasına öncelik verilebilir. Security veya acil fix release'leri ayrı policy ile devam edebilir. Kural işletme hedefleriyle birlikte tanımlanmalıdır.

Release Velocity ve Reliability Dengesi

Hiç release yapmamak reliability çözümü değildir. Büyük ve seyrek release daha fazla değişikliği tek seferde taşır. Küçük, sık ve otomatik ölçülen rollout riskin yönetilmesini kolaylaştırabilir. Error budget ekip için ortak karar dili sağlar. Amaç hız veya güvenlik arasında seçim yapmak değil ikisini ölçülü biçimde yönetmektir.

CI/CD Pipeline'da Zero-Downtime Akışı

Sağlıklı CI/CD akışı build ile başlayıp test, security scan ve immutable artifact üretimiyle devam eder. Database için önce additive expand migration uygulanabilir. Yeni version deploy edilir, readiness ve smoke test doğrulanır. Progressive traffic shift sırasında otomatik analysis sonucu promotion veya rollback kararı verilir. Contract migration ise eski sürüm ve rollback ihtiyacı ortadan kalktıktan sonraki release'e bırakılır.

Build

Source code deterministik biçimde build edilmelidir. Dependency version'ları kontrol altında tutulmalıdır. Build output release artifact'in temelidir. Aynı commit'ten farklı binary üretmek debugging'i zorlaştırır. Build metadata Git SHA ile ilişkilendirilmelidir.

Test

Unit, integration ve contract testler pipeline'ın erken aşamasında çalışır. Hızlı feedback hatalı artifact'in ilerlemesini engeller. Flaky testler güveni azaltır. Kritik deployment senaryoları integration test içine alınabilir. Test başarısı production validation'ın yerini tutmaz.

Artifact Oluşturma

Başarılı build immutable artifact üretir. Container image digest kaydedilir. Artifact registry'ye tek kez push edilir. Production aynı artifact'i kullanır. Environment farkı configuration üzerinden yönetilir.

Security Scan

Image ve dependency vulnerability scan çalıştırılır. Secret scanning source ve artifact üzerinde uygulanabilir. Kritik policy ihlali release'i durdurur. False positive yönetimi açık süreçle yapılmalıdır. Security result artifact metadata ile saklanabilir.

Database Expand Migration

Yeni nullable column veya table gibi safe change uygulanır. Eski application çalışmaya devam etmelidir. Migration metric'leri izlenir. Uzun backfill ayrı process'e bırakılabilir. Breaking contract operation bu aşamada yapılmaz.

Deploy New Version

Yeni image yeni replica veya environment üzerinde başlatılır. Eski sürüm trafik almaya devam eder. Configuration ve secret erişimi doğrulanır. Startup başarısızsa rollout ilerlemez. Yeni version label telemetry'ye eklenir.

Smoke Test

Kritik endpoint'ler yeni version üzerinde test edilir. Authentication ve database erişimi doğrulanır. Test başarısızsa traffic promotion yapılmaz. Sonuç deployment ID ile kaydedilir. Production-safe test data kullanılmalıdır.

Progressive Traffic Shift

İlk traffic oranı düşük tutulur. Metric observation sonrası ağırlık artırılır. Yüzde adımları servis riskine göre belirlenir. Tenant veya region rollout kullanılabilir. Her step otomatik veya manuel gate içerebilir.

Automated Analysis

Error rate, latency ve business KPI sorgulanır. Canary stable baseline ile karşılaştırılır. Minimum sample koşulu aranır. Threshold ihlalinde rollout abort edilir. Analiz sonucu audit log'a yazılır.

Promotion veya Rollback

Başarılı metric'ler full promotion'a izin verir. Failure durumunda stable sürüm tekrar tüm trafiği alır. Rollback data compatibility açısından güvenli olmalıdır. Gerekirse roll-forward incident procedure çalıştırılır. Karar otomatik incident kaydı oluşturabilir.

Contract Migration

Eski sürümün artık çalışmadığı doğrulanır. Deprecated column veya table kullanımı telemetry ile kontrol edilir. Rollback penceresi kapatılır. Ardından destructive cleanup uygulanabilir. Contract migration ayrı release olarak yönetildiğinde risk daha düşüktür.

GitOps ile Zero-Downtime Deployment

GitOps desired state'in Git repository içinde tanımlanmasını ve cluster'ın bu state'e otomatik yaklaşmasını sağlar. Deployment değişiklikleri commit üzerinden izlenebilir. Argo CD veya Flux reconciliation işlemini yönetebilir. Argo Rollouts progressive delivery davranışını ekleyebilir. Git revert configuration rollback için kullanışlıdır ancak database state veya external side effect'leri otomatik geri almaz.

Desired State

Cluster'da hangi version ve configuration'ın çalışması gerektiği deklaratif olarak tanımlanır. Runtime değişiklik desired state'ten saparsa drift oluşur. Controller bunu tespit edebilir. Deployment recovery manuel sunucu değişikliğine bağlı kalmaz. Desired state audit history sağlar.

Git Commit

Her deployment change commit ile izlenebilir. Review ve approval süreci uygulanabilir. Commit hangi image digest'in kullanılacağını gösterebilir. Incident sırasında ilgili değişiklik hızlıca bulunur. Commit merge zamanı release zamanı ile telemetry üzerinde ilişkilendirilebilir.

Argo CD

Argo CD Git desired state ile Kubernetes state'i reconcile eder. Sync status deployment görünürlüğü sağlar. Health status application readiness ile desteklenebilir. Rollout controller ile birlikte kullanıldığında responsibility ayrımı yapılmalıdır. Otomatik sync policy production riskine göre seçilmelidir.

Flux

Flux GitOps reconciliation için kullanılabilecek başka bir araçtır. Git veya image state değişikliklerini cluster'a uygulayabilir. Declarative deployment modelini destekler. Progressive rollout için ek controller veya entegrasyon gerekebilir. Tool seçiminden önce operasyon ekibinin mevcut platform standardı değerlendirilmelidir.

Argo Rollouts

Argo Rollouts canary ve blue-green strategy tanımlar. Traffic step ve analysis automation sağlar. GitOps desired state ile rollout runtime state arasında koordinasyon gerekir. Promotion manuel veya otomatik olabilir. Rollout status deployment dashboard'unda gösterilmelidir.

Progressive Delivery

Git commit merged olduğunda tüm trafik anında yeni version'a geçmek zorunda değildir. Controller küçük canary ile başlayabilir. Metric analysis success sonrasında step ilerler. Failure durumunda desired release korunurken rollout abort edilebilir. GitOps ile runtime safety birlikte tasarlanmalıdır.

Git Revert ile Rollback

Git revert önceki desired configuration'ı yeniden tanımlar. Controller cluster'ı eski state'e reconcile eder. Bu yaklaşım audit edilebilir rollback sağlar. Ancak eski application yeni database state ile uyumsuzsa sorun çözülmez. Git revert application rollback aracıdır, data restore mekanizması değildir.

Drift Detection

Production'da manuel değişiklik Git state'ten sapma oluşturabilir. Drift detection bu farkı görünür hale getirir. Otomatik reconciliation farkı düzeltebilir. Incident sırasında bilinçli manuel override varsa policy bunu geçici olarak desteklemelidir. Drift history production debugging için değerli veridir.

Zero-Downtime Deployment İçin Araçlar

Zero-downtime tek bir ürün satın alarak elde edilmez. Kubernetes workload orchestration sağlar. Argo Rollouts progressive delivery, Argo CD GitOps, Istio veya Linkerd traffic management, Prometheus ve Grafana observability tarafında kullanılabilir. Terraform ve Helm infrastructure ile application configuration yönetimini destekler. Araçlar ancak readiness, compatibility ve safe data evolution ilkeleri doğru uygulandığında gerçek değer üretir.

Kubernetes

Kubernetes replica, rolling update ve health probe mekanizmaları sunar. Service discovery ve scheduling temel platform özellikleridir. Deployment strategy doğru yapılandırılmalıdır. Stateful workload için StatefulSet gibi farklı controller'lar kullanılabilir. Kubernetes tek başına database compatibility sorununu çözmez.

Argo Rollouts

Argo Rollouts canary ve blue-green akışlarını genişletir. Metric analysis adımları tanımlanabilir. Traffic manager entegrasyonu weighted routing sağlar. Promotion ve abort otomatikleştirilebilir. Tool operasyon ekibinin monitoring kalitesi kadar etkilidir.

Argo CD

Argo CD Kubernetes için GitOps deployment yönetimi sunar. Desired state Git üzerinden izlenir. Drift detection ve sync görünürlüğü sağlar. Argo Rollouts ile birlikte progressive delivery kurulabilir. Application data migration yine ayrı mekanizma gerektirir.

Flagger

Flagger progressive delivery otomasyonu için kullanılabilir. Service mesh veya ingress metric'leri üzerinden canary ilerlemesini yönetebilir. Success threshold tanımlanabilir. Failure durumunda trafik stable sürüme dönebilir. Monitoring entegrasyonu doğru metric üretmelidir.

Istio

Istio gelişmiş traffic routing sağlar. Weighted canary ve header routing uygulanabilir. Telemetry service-level gözlem sağlar. mTLS service iletişimini güvenli hale getirebilir. Platform maliyeti ve operasyon yükü kullanım kararında hesaba katılmalıdır.

Linkerd

Linkerd service mesh yaklaşımıyla servis iletişimini gözlemlemeye yardımcı olur. Traffic ve latency telemetry sağlayabilir. Progressive delivery entegrasyonlarında kullanılabilir. Proxy resource overhead ölçülmelidir. Mesh failure mode'ları operasyon ekibi tarafından anlaşılmalıdır.

NGINX

NGINX reverse proxy ve ingress katmanında kullanılabilir. Load balancing ve routing sağlar. Canary veya blue-green yönlendirme configuration ile uygulanabilir. Keep-alive ve timeout ayarları draining davranışını etkiler. Reload sırasında aktif connection davranışı production senaryolarıyla test edilmelidir.

Terraform

Terraform infrastructure resource'larını deklaratif tanımlar. Blue-green environment provisioning otomatikleştirilebilir. Plan çıktısı deployment öncesinde review edilir. State yönetimi güvenli olmalıdır. Infrastructure değişikliği application rollout'tan ayrı pipeline'a sahip olabilir.

Helm

Helm Kubernetes manifest'lerini paketlemeye yardımcı olur. Values ile environment configuration yönetilebilir. Chart version application release ile ilişkilendirilebilir. Upgrade sırasında strategy ve probe ayarları korunmalıdır. Template validation pipeline içinde çalıştırılabilir.

Prometheus

Prometheus metric toplama ve sorgulama için kullanılabilir. Canary success criteria PromQL üzerinden hesaplanabilir. Version label metric ayrımını sağlar. Alert rule automated rollback sinyaliyle entegre edilebilir. Cardinality ve retention planı production ölçeğine göre yapılmalıdır.

Grafana

Grafana deployment dashboard'ları oluşturmak için kullanılabilir. Release marker metric değişimini görünür kılar. Stable ve canary version aynı panelde karşılaştırılabilir. Business KPI ile teknik metric bir arada gösterilebilir. On-call ekibi için rollout odaklı dashboard hazırlanması faydalıdır.

Örnek Production-Ready Zero-Downtime Deployment Akışı

Production-ready akış code build ile başlayıp veri ve trafik geçişini ayrı aşamalarda yönetmelidir. Immutable image oluşturulur ve test ile security gate'lerden geçer. Additive migration sonrasında yeni version deploy edilir. Readiness ve smoke test doğrulandıktan sonra küçük canary trafiği gönderilir. Teknik ve business metric'ler başarılı kaldıkça trafik artırılır, eski sürüm drain edilir ve destructive migration daha sonraki release'e bırakılır.

1. Immutable Image Build

Source code'dan tek bir immutable container image üretilir. Git SHA ve image digest kaydedilir. Aynı image staging ve production'a taşınır. Build sonrası image içeriği değiştirilmez. Bu model reproducible deployment sağlar.

2. Test ve Security Gate

Unit ve integration testler çalıştırılır. Contract test compatibility'yi doğrular. Image vulnerability ve secret scan uygulanır. Kritik failure release'i durdurur. Sonuçlar artifact metadata ile saklanır.

3. Additive Database Migration

Yeni schema eski application'ı bozmayacak şekilde eklenir. Destructive change yapılmaz. Büyük backfill ayrı worker ile yürütülebilir. Database metric'leri gözlenir. Migration başarıyla tamamlanmadan bağımlı feature açılmaz.

4. Yeni Sürümü Deploy Et

Yeni replica'lar eski sürümün yanına başlatılır. Configuration doğrulanır. Startup probe gerekli initialization süresini yönetir. Version label telemetry'ye eklenir. Eski replica'lar hâlâ production trafiğini taşır.

5. Readiness Doğrula

Yeni pod trafik almadan readiness başarılı olmalıdır. Dependency ve initialization state kontrol edilir. False-positive readiness önlenmelidir. minReadySeconds kısa stabilizasyon süresi sağlayabilir. Readiness başarısızsa rollout ilerlememelidir.

6. Smoke Test Çalıştır

Critical endpoint'ler yeni version üzerinde test edilir. Database read/write ve authentication doğrulanır. Test data güvenli olmalıdır. Failure traffic promotion'ı engeller. Sonuç rollout metadata'ya kaydedilir.

7. %1 Canary Traffic Gönder

Yeni version ilk olarak düşük trafik oranı alır. Yüksek trafik servisinde yüzde 1 güçlü sample sağlayabilir. Routing gerçekten beklenen oranı üretiyor mu throughput üzerinden kontrol edilir. Stable version ana trafiği taşımaya devam eder. İlk observation window başlatılır.

8. Teknik ve Business Metrikleri Ölç

HTTP error rate ve latency izlenir. CPU, memory ve database metric'leri karşılaştırılır. Payment veya conversion gibi domain KPI eklenir. Canary stable baseline ile kıyaslanır. Threshold ihlalinde otomatik abort uygulanır.

9. Trafiği Kademeli Artır

Yüzde 5, 25, 50 ve 100 gibi adımlar kullanılabilir. Her aşama yeterli measurement window bekler. Sample count promotion koşuluna eklenir. Peak traffic davranışı gözlenir. Full promotion sonrasında da observation devam eder.

10. Eski Sürümü Connection Draining ile Trafikten Çıkar

Stable eski replica yeni request almaktan çıkarılır. Aktif connection'ların tamamlanması beklenir. WebSocket client'ları kontrollü reconnect yapar. SIGTERM handler resource cleanup uygular. Grace period sonrasında eski pod kapatılır.

11. Contract Migration'ı Daha Sonraki Release'te Uygula

Eski version kullanımının sıfırlandığı doğrulanır. Rollback penceresi kapatılır. Deprecated schema kullanım metric'i kontrol edilir. Ardından eski column veya table kaldırılabilir. Bu ayrım migration riskini application rollout'tan uzaklaştırır.

Deployment Öncesi Zero-Downtime Kontrol Listesi

Production deployment başlamadan önce teknik varsayımlar kısa bir checklist ile doğrulanmalıdır. Replica sayısı, health check, readiness ve graceful shutdown temel application lifecycle maddeleridir. API ve database compatibility version skew riskini azaltır. Session ve queue davranışı state kaybını önler. Rollback, metric ve abort threshold'ları ise sorun çıktığında hızlı ve kontrollü recovery sağlar.

En Az İki Instance Var mı?

Tek instance deployment sırasında kesinti riskini artırır. En az iki replica başlangıç noktası olabilir. Kalan replica'nın yeterli capacity taşıması gerekir. Autoscaling cold start süresi de hesaba katılmalıdır. Failure durumunda yalnızca sayı değil gerçek serving capacity önemlidir.

Load Balancer Health Check Çalışıyor mu?

Health check gerçekten backend durumunu yansıtmalıdır. Yanlış endpoint sürekli 200 dönmemelidir. Failure threshold çok agresif olmamalıdır. Draining sırasında backend yeni traffic almaktan çıkarılmalıdır. Production öncesi target removal testi yapılmalıdır.

Readiness Probe Doğru mu?

Pod gerçekten hazır olmadan Ready olmamalıdır. Geçici dependency problemi tüm pod'ları aynı anda NotReady yapmamalıdır. Probe hızlı cevap vermelidir. Startup behavior ile karıştırılmamalıdır. Deployment sırasında readiness transition metric olarak izlenebilir.

Graceful Shutdown Var mı?

SIGTERM handler uygulanmış olmalıdır. Yeni request kabulü durmalıdır. Active request'ler tamamlanmalıdır. Queue consumer yeni message almamalıdır. Gerçek termination testi CI veya staging'de yapılmalıdır.

maxUnavailable Doğru mu?

Kritik servislerde sıfır değeri güçlü başlangıçtır. Replica sayısı ve capacity ile birlikte değerlendirilmelidir. Cluster yeni surge pod için kaynak sağlayabilmelidir. PodDisruptionBudget ayrıca kontrol edilmelidir. Rollout testinde serving capacity grafiği izlenmelidir.

API Backward-Compatible mı?

Eski client yeni provider ile çalışabilmelidir. Required field değişiklikleri kontrol edilmelidir. Response field removal ertelenmelidir. Contract test başarılı olmalıdır. Deprecation policy izlenmelidir.

Database Migration Backward-Compatible mı?

Eski application yeni schema üzerinde çalışmalıdır. Destructive operation ayrı contract release'e bırakılmalıdır. Büyük DDL lock etkisi test edilmelidir. Backfill idempotent olmalıdır. Rollback sonrası schema behavior doğrulanmalıdır.

Session Paylaşımlı mı?

Session tek pod memory'sine bağlı olmamalıdır. Shared store veya stateless token kullanılabilir. Session serialization iki version ile uyumlu olmalıdır. Secret key rotation overlap sağlamalıdır. Blue-green switch sonrası login continuity test edilmelidir.

Queue Consumer Idempotent mı?

Message duplicate geldiğinde ikinci yan etki oluşmamalıdır. Ack policy doğru olmalıdır. Shutdown sırasında in-flight message güvenli kalmalıdır. Event schema iki version ile uyumlu olmalıdır. Retry ve dead-letter davranışı test edilmelidir.

Rollback Test Edildi mi?

Rollback yalnızca dokümanda yazılı olmamalıdır. Eski image'a gerçek dönüş denenmelidir. Yeni database schema üzerinde eski sürüm test edilmelidir. Traffic switch geri dönüş süresi ölçülmelidir. Runbook sonuçlara göre güncellenmelidir.

Deployment Metrikleri Tanımlandı mı?

Error rate ve latency minimum setin parçasıdır. Resource saturation ayrıca izlenmelidir. Business KPI service davranışını tamamlar. Version label tüm metric'lerde bulunmalıdır. Dashboard rollout başlamadan hazır olmalıdır.

Automated Abort Threshold Var mı?

Canary hangi koşulda duracak önceden belirlenmelidir. Minimum sample count eklenmelidir. Baseline comparison false alert'i azaltabilir. Business kritik hata doğrudan abort edebilir. Threshold'lar geçmiş deployment verisiyle kalibre edilmelidir.

Sık Yapılan Zero-Downtime Deployment Hataları

Kesintisiz deployment projelerinde en sık sorun araç seçimi değil yanlış varsayımdır. Kubernetes kullanmak tek başına zero-downtime sağlamaz. Readiness, graceful shutdown ve backward-compatible data modeli eksikse rollout sırasında hata oluşur. Canary yapıp metric izlememek yalnızca trafiği yavaşça hatalı sürüme taşımaktır. Başarılı deployment anlayışı teknik health ile business sonucunu birlikte değerlendirmelidir.

Sadece Kubernetes Kullanmanın Zero-Downtime Sağladığını Sanmak

Kubernetes orchestration sağlar ancak application behavior'ını düzeltemez. Tek replica kesinti yaratabilir. Breaking database migration tüm pod'ları bozabilir. Yanlış readiness traffic error üretir. Platform capability ile application design birlikte çalışmalıdır.

Readiness Probe Kullanmamak

Yeni pod startup tamamlanmadan traffic alabilir. İlk request'ler hata görebilir. Load balancer process alive bilgisini readiness sanabilir. Cache veya dependency initialization gecikmesi gizli kalır. Doğru readiness deployment safety'nin temelidir.

Pod'u Trafikten Çıkarmadan Kapatmak

Aktif request aniden kesilebilir. Client connection reset görür. Queue consumer in-flight message'ı yarıda bırakabilir. Önce traffic deregistration yapılmalıdır. Graceful shutdown bu geçişi güvenli hale getirir.

Database Column'ını Tek Adımda Rename Etmek

Eski version eski column adına erişir. Rename anında query hata verir. Rolling rollout version skew yaşadığı için kullanıcı etkilenir. Expand-and-contract güvenli alternatiftir. Cleanup sonraki release'e bırakılmalıdır.

Eski ve Yeni API Sürümlerini Uyumsuz Hale Getirmek

Microservice'ler aynı anda deploy edilmez. Yeni provider eski consumer'ı desteklemelidir. Required field veya response removal breaking change oluşturur. Contract test uyumsuzluğu erkenden yakalayabilir. API deprecation ölçümlü süreç olmalıdır.

In-Memory Session Kullanmak

Pod kapanınca session kaybolabilir. Kullanıcı logout olabilir. Sticky session yalnızca geçici çözüm sağlar. Shared session store instance bağımsızlığı oluşturur. Session formatı version compatibility açısından da test edilmelidir.

Queue Consumer'larda Graceful Shutdown Yapmamak

Worker kapanırken in-flight message yarıda kalabilir. Ack sonrası kapanma veri kaybı oluşturabilir. Ack öncesi kapanma duplicate delivery yaratır. Idempotent consumer riskleri azaltır. Consumer draining deployment lifecycle'ına eklenmelidir.

Blue-Green'de Database Problemini Görmezden Gelmek

İki application environment ayrı olsa da database çoğunlukla ortaktır. Breaking migration blue environment'ı da bozabilir. Rollback yeni schema üzerinde çalışmayabilir. Additive migration kullanılmalıdır. Data lifecycle environment switch'ten bağımsız tasarlanmalıdır.

Canary Yapıp Metrik İzlememek

Trafiği yüzde 5'e ayırmak tek başına risk yönetimi değildir. Başarı kriteri yoksa problem görülmeden promotion devam edebilir. Error rate ve latency minimum metriklerdir. Business KPI ek güven sağlar. Automated analysis canary'yi gerçek progressive delivery modeline dönüştürür.

Rollback'ı Test Etmemek

Runbook üzerinde kolay görünen rollback production'da çalışmayabilir. Eski image registry'de bulunmayabilir. Database schema değişmiş olabilir. Secret eski version ile uyumsuz olabilir. Düzenli rollback tatbikatı bu sürprizleri release öncesinde gösterir.

Tüm Trafiği DNS Değişikliğiyle Anında Taşıyabileceğini Varsaymak

DNS cache client ve resolver katmanlarında kalabilir. TTL sıfıra yakın olsa bile anlık convergence garanti edilmez. Eski endpoint trafik almaya devam edebilir. Environment overlap süresi buna göre planlanmalıdır. Daha hızlı cutover için proxy veya load balancer routing tercih edilebilir.

Deployment'ı Başarılı Sayıp Business KPI'ları İzlememek

Pod Ready olabilir ve HTTP 200 dönebilir. Ancak ödeme veya sipariş işlemi iş mantığı açısından başarısız olabilir. Teknik health gerçek business sonucu tek başına göstermez. Domain KPI rollout dashboard'una eklenmelidir. Release başarı tanımı kullanıcı sonucunu içermelidir.

Zero-Downtime Deployment Maturity Model

Zero-downtime yetkinliği tek deployment aracı kurulduğunda tamamlanan bir çalışma değildir. Ekipler manuel stop/start modelinden başlayıp rolling update, health automation ve canary gibi aşamalara ilerleyebilir. Daha ileri seviyede metric-driven progressive delivery ve backward-compatible data evolution standarda dönüşür. SLO ve risk tabanlı release yönetimi en olgun aşamada kararları otomatikleştirebilir. Maturity modeli ekiplerin bir sonraki yatırım alanını belirlemesine yardımcı olur.

Seviye 0: Manuel Stop/Start Deployment

Servis manuel olarak kapatılır. Yeni sürüm sunucuya yüklenir. Ardından uygulama tekrar başlatılır. Kesinti deployment süresine bağlıdır. İlk hedef çoklu instance ve immutable artifact modeline geçmektir.

Seviye 1: Çoklu Instance + Rolling Update

Servis birden fazla replica ile çalışır. Instance'lar kademeli değiştirilir. Load balancer traffic continuity sağlar. API ve database compatibility önem kazanır. Readiness henüz temel veya manuel olabilir.

Seviye 2: Automated Health Checks

Readiness ve liveness standartlaştırılır. Yeni instance hazır olmadan trafik almaz. Shutdown behavior test edilir. Pipeline health sonucu üzerinden ilerler. Kullanıcı kesintisi önemli ölçüde azalır.

Seviye 3: Blue-Green / Canary

Release riskine göre gelişmiş rollout strategy kullanılır. Traffic switch veya weighted routing uygulanır. Blast radius kontrol edilir. Rollback mekanizması otomatikleşir. Production validation daha sistematik hale gelir.

Seviye 4: Metric-Driven Progressive Delivery

Promotion kararları metric üzerinden verilir. Error rate ve latency otomatik analiz edilir. Business KPI release gate'e dahil edilir. Failure threshold rollout'u abort eder. İnsan gözlemi tek karar mekanizması olmaktan çıkar.

Seviye 5: Backward-Compatible Data ve API Evolution

Database migration expand-and-contract ile yürütülür. API ve event schema compatibility otomatik test edilir. Old ve new version overlap normal kabul edilir. Rollback data state üzerinde doğrulanır. Bağımsız microservice deployment güvenli hale gelir.

Seviye 6: SLO ve Automated Risk-Based Release

Release policy mevcut error budget durumuna göre değişebilir. Sağlıklı servis daha hızlı rollout yapabilir. Riskli durumda canary adımları yavaşlatılır veya deployment pause edilir. Technical ve business metric aynı karar modelinde kullanılır. Reliability ile release velocity ölçülebilir biçimde dengelenir.

Sık Sorulan Sorular

Zero-downtime deployment konusunda en sık sorulan sorular araç seçiminden çok mimari detaylara odaklanır. Rolling update kullanmak, Kubernetes'e geçmek veya blue-green environment oluşturmak tek başına yeterli değildir. Health check, graceful shutdown ve backward-compatible database tasarımı gerçek sonucu belirler. Aşağıdaki kısa yanıtlar production uygulamasında sık karşılaşılan temel karar noktalarını özetler. Daha büyük sistemlerde her yanıt workload karakteristiğine göre ayrıca doğrulanmalıdır.

Zero-downtime deployment nedir?

Zero-downtime deployment yeni sürüm yayınlanırken kullanıcıların hizmet almaya devam etmesini hedefler. Eski sürüm yeni sürüm hazır olana kadar trafik taşır. Yeni sürüm health check ve smoke test sonrasında production'a alınır. Traffic geçişi sırasında aktif connection'lar korunur. Database ve API değişiklikleri iki sürümle uyumlu tasarlanır.

Sıfır kesintili deployment nasıl yapılır?

Önce çoklu instance ve load balancer altyapısı gerekir. Readiness yeni instance'ın trafik almaya hazır olduğunu doğrular. Rolling, blue-green veya canary strategy seçilir. Graceful shutdown eski instance'ı güvenli biçimde kapatır. Metric ve automated rollback release sürecini tamamlar.

Rolling deployment zero-downtime sağlar mı?

Evet, doğru koşullarda sağlayabilir. En az iki replica ve uygun maxUnavailable değeri gerekir. Readiness probe doğru çalışmalıdır. Eski ve yeni sürüm backward-compatible olmalıdır. Graceful shutdown olmadan aktif request'ler yine kesilebilir.

Blue-green deployment nedir?

İki ayrı application environment kullanılır. Mevcut production bir ortamda çalışırken yeni sürüm diğerinde hazırlanır. Test sonrası trafik yeni ortama geçirilir. Eski ortam rollback için tutulabilir. Shared database compatibility ayrıca yönetilmelidir.

Canary deployment nedir?

Yeni sürüm önce küçük trafik grubuna açılır. Error ve latency metric'leri gözlenir. Başarılı olduğunda trafik oranı artırılır. Sorun görülürse rollout durdurulur. Bu yöntem blast radius'u sınırlamak için güçlüdür.

Blue-green mi canary mi daha iyidir?

Tek bir genel cevap yoktur. Blue-green hızlı cutover ve rollback sağlar. Canary küçük trafik oranıyla daha kontrollü risk yönetimi sunar. Blue-green daha fazla altyapı kapasitesi gerektirebilir. Uygulamanın trafik, maliyet ve risk profili seçimi belirler.

Kubernetes zero-downtime deployment nasıl yapılır?

Deployment replica sayısı yeterli olmalıdır. RollingUpdate strategy içinde maxUnavailable ve maxSurge doğru seçilmelidir. Readiness probe yeni pod'u erken trafikten korur. terminationGracePeriodSeconds ve SIGTERM handler graceful shutdown sağlar. Database ve session state Kubernetes dışındaki önemli tasarım noktalarıdır.

maxUnavailable kaç olmalıdır?

Kritik servislerde zero-downtime hedefi için sıklıkla 0 kullanılır. Bu değer yeni pod hazır olmadan mevcut capacity'nin azaltılmasını engeller. Ancak cluster surge pod için yeterli kaynağa sahip olmalıdır. Replica sayısı ve traffic capacity birlikte değerlendirilmelidir. Değer production load testleriyle doğrulanmalıdır.

Readiness probe neden önemlidir?

Readiness pod'un gerçekten trafik almaya hazır olup olmadığını gösterir. Port açılması tek başına yeterli değildir. Initialization tamamlanmadan gelen istek hata üretebilir. Kapanış sırasında readiness false olması yeni trafiği durdurur. Bu nedenle rollout ve graceful shutdown için merkezi öneme sahiptir.

Graceful shutdown nasıl yapılır?

Application SIGTERM sinyalini yakalamalıdır. Önce yeni request kabulü durdurulmalıdır. Active request ve in-flight işlerin bitmesi beklenmelidir. Resource cleanup uygulanmalıdır. Deadline sonunda process kontrollü biçimde sonlanmalıdır.

Database migration sırasında downtime nasıl önlenir?

Breaking schema change tek adımda uygulanmamalıdır. Additive migration ve expand-and-contract kullanılabilir. Büyük backfill batch halinde yürütülmelidir. Eski ve yeni application aynı schema üzerinde çalışabilmelidir. Destructive contract migration sonraki release'e bırakılmalıdır.

Expand-and-contract nedir?

Database değişikliğini üç aşamaya bölen bir modeldir. Expand yeni yapıyı ekler ve eski yapıyı korur. Migrate application ile veriyi yeni yapıya taşır. Contract eski yapıyı güvenli zamanda kaldırır. Bu yaklaşım rollback ve version skew için zaman kazandırır.

Column rename zero-downtime nasıl yapılır?

Doğrudan rename yerine yeni column eklenir. Application bir süre iki column'a yazabilir. Eski veri backfill edilir. Read path yeni column'a taşınır. Eski column sonraki release'te kaldırılır.

Blue-green deployment'ta database nasıl yönetilir?

İki environment çoğunlukla aynı database'i kullanır. Schema hem blue hem green application ile uyumlu olmalıdır. Additive migration traffic switch öncesinde uygulanabilir. Destructive change rollback penceresi kapanana kadar ertelenmelidir. Yeni sürümün yazdığı verinin eski sürüm tarafından okunabilmesi kontrol edilmelidir.

WebSocket bağlantıları deployment sırasında ne olur?

WebSocket uzun yaşayan connection olduğu için pod termination'ı geciktirebilir. Draining yeni bağlantıları başka instance'a yönlendirir. Server kontrollü reconnect isteyebilir. Client retry ve session resume desteklemelidir. Maximum connection lifetime deployment'ı daha öngörülebilir hale getirebilir.

Queue consumer'lar kesintisiz nasıl deploy edilir?

Consumer yeni message fetch etmeyi shutdown sırasında durdurmalıdır. In-flight mesaj tamamlanmalıdır. Ack işlemi doğru zamanda yapılmalıdır. Duplicate delivery için idempotency gerekir. Event schema eski ve yeni consumer ile uyumlu olmalıdır.

Feature flag zero-downtime deployment'a nasıl yardımcı olur?

Code deployment ile feature activation'ı ayırır. Yeni davranış production'da kapalı olarak bulunabilir. Küçük kullanıcı grubuyla açılabilir. Sorunda kill switch ile hızlı kapatma yapılabilir. Full application rollback ihtiyacı bazı durumlarda ortadan kalkar.

Canary deployment hangi metriklerle doğrulanmalıdır?

HTTP 5xx ve P95/P99 latency temel metric'lerdir. CPU ve memory capacity regression'ı gösterebilir. Database error rate ve queue lag dependency davranışını tamamlar. Payment success veya conversion gibi business KPI eklenmelidir. Minimum sample count olmadan tek başına yüzdesel threshold kullanılmamalıdır.

Otomatik rollback nasıl yapılır?

Önce failure threshold ve measurement window tanımlanır. Canary metric'leri stable baseline ile karşılaştırılır. Threshold ihlalinde traffic stable sürüme döner. Alert ve incident otomatik tetiklenebilir. Data migration rollback güvenliğini ayrıca sınırlayabilir.

Rollback yerine roll-forward ne zaman kullanılmalıdır?

Yeni schema eski application ile uyumsuz hale geldiyse roll-forward daha güvenli olabilir. Irreversible data migration rollback'ı riskli yapabilir. Security fix geri alınmamalıysa yeni düzeltme release'i tercih edilir. External side effect state'i eski code'a dönerek kaybolmaz. Karar failure sınıfına göre önceden runbook'ta tanımlanmalıdır.

Zero-Downtime Deployment Hakkında Ek Sorular

Sıfır kesintili release tasarımına başlanırken ekiplerin benzer operasyonel sorular sorması doğaldır. Aşağıdaki yanıtlar özellikle uygulama güncellemesi, migration, traffic management ve danışmanlık ihtiyacı gibi pratik başlıklara odaklanır. Kullanılacak strateji tek başına teknoloji adına göre seçilmemelidir. Mevcut uygulama state yönetimi, deployment sıklığı ve risk seviyesi değerlendirilmelidir. Kurumsal ölçekte standartlaştırılmış pipeline ve monitoring modeli uzun vadede manuel hataları belirgin biçimde azaltır.

Sıfır kesinti (Zero-Downtime) dağıtım nasıl yapılır?

Sıfır kesintili dağıtım için önce aynı servisin birden fazla sağlıklı instance ile çalışabilmesi gerekir. Load balancer yeni instance'ı readiness doğrulanmadan trafiğe almamalıdır. Eski ve yeni sürümün belirli süre beraber çalışabileceği kabul edilerek API, session ve database değişiklikleri backward-compatible hazırlanmalıdır. Rolling, blue-green veya canary gibi bir rollout yöntemi seçildikten sonra error rate, latency ve business KPI üzerinden promotion yapılmalıdır. Eski instance'lar da yeni trafik almaktan çıkarılıp aktif bağlantılarını tamamladıktan sonra graceful shutdown ile kapatılmalıdır.

Blue-Green, Canary ve Rolling Deployment stratejileri arasındaki farklar nelerdir?

Rolling deployment replica'ları kademeli biçimde değiştirir ve genellikle en az ek altyapı maliyetini gerektirir. Blue-green iki environment hazırlar ve traffic switch sayesinde çok hızlı cutover ile rollback sağlayabilir. Canary yeni sürümü önce küçük trafik grubuna açtığı için blast radius kontrolünde güçlüdür. Blue-green canary ve rolling deployment stratejileri karşılaştırması yapılırken yalnızca kesinti süresi değil, infrastructure cost, rollback hızı, compatibility gereksinimi ve metric automation da değerlendirilmelidir. Pratikte aynı şirket farklı servisler için bu stratejilerin birden fazlasını kullanabilir.

Zero-Downtime deployment sırasında veritabanı migration işlemleri nasıl güvenli şekilde gerçekleştirilir?

Database değişiklikleri mümkün olduğunca additive olarak başlamalıdır. Yeni column veya table eklenirken eski yapı korunmalı ve hem eski hem yeni uygulamanın aynı schema üzerinde çalışması doğrulanmalıdır. Büyük backfill işlemleri batch ve rate limit ile production trafiğine zarar vermeden yürütülmelidir. Column rename veya drop gibi destructive işlemler expand-and-contract modelinin contract aşamasına, yani eski sürüm tamamen kaldırıldıktan sonraki release'e bırakılmalıdır. Rollback testleri de yeni database state üzerinde eski application sürümüyle gerçekleştirilmelidir.

Sıfır kesintili dağıtımlarda health check, trafik yönlendirme ve otomatik rollback süreçleri nasıl yapılandırılmalıdır?

Readiness check bir instance'ın gerçekten trafik kabul edebileceği anı göstermelidir. Load balancer Ready olmayan yeni instance'a trafik göndermemeli ve kapanacak instance'ı önce draining state'e almalıdır. Canary rollout kullanılıyorsa trafik küçük yüzdeyle başlatılmalı ve belirli measurement window boyunca error rate, latency ve business KPI izlenmelidir. Minimum sample sayısı tamamlandıktan sonra success threshold karşılanırsa promotion yapılabilir. Failure threshold aşılırsa traffic stable sürüme dönmeli, alert oluşturulmalı ve data compatibility güvenliyse otomatik rollback uygulanmalıdır.

Zero-Downtime deployment ve DevOps süreçleri konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Zero-downtime deployment ve DevOps danışmanlığı yakınımda araması yaparken yalnızca deployment aracına değil, uygulama mimarisi ve operasyon süreçlerine birlikte yaklaşan bir çalışma modeli aramak daha doğru olur. Diyarbakır Yazılım Topluluğu'nun yaklaşımı, çalışmaları ve topluluk hakkında bilgi edinmek için https://www.diyarbakiryazilim.com.tr/about sayfasını inceleyebilirsiniz. Uygulama ve yazılım çalışmalarından örnekleri görmek için https://www.diyarbakiryazilim.com.tr/projects adresine göz atabilirsiniz. Özellikle monitoring ve alarm tasarımı, zero-downtime akışının release sonrası doğrulama kısmında kritik rol oynar. Bu konuda daha fazla teknik içerik için https://www.diyarbakiryazilim.com.tr/posts/sunucu-izleme-monitoring-ve-alarm-mekanizmalari sayfasından devam edebilirsiniz.

Sonuç: Gerçek Zero-Downtime Deployment Nasıl Tasarlanır?

Gerçek sıfır kesinti hedefi tek bir Kubernetes ayarı, tek bir load balancer veya tek bir CI/CD aracıyla tamamlanmaz. Sıfır Kesinti (Zero-Downtime) Dağıtım Stratejileri application lifecycle, traffic management, database evolution, observability ve recovery kararlarının birlikte tasarlanmasını gerektirir. Sistem eski ve yeni sürümün belirli süre yan yana çalışacağı varsayımıyla kurulmalıdır. Readiness yeni sürümü korurken graceful shutdown eski sürümün kullanıcı işlemlerini güvenli biçimde tamamlamasını sağlar. Database ve API backward compatibility ise deployment stratejisinin gerçekten kesintisiz çalışabilmesinin temelini oluşturur.

Yalnızca Deployment Aracına Odaklanmayın

Kubernetes veya başka bir orchestration platformu önemli altyapı sağlar. Ancak application session state veya breaking database change kullanıyorsa araç tek başına sorunu çözemez. Release tasarımı code, data ve traffic katmanlarını birlikte kapsamalıdır. Araç seçimi mimari gereksinimlerden sonra gelmelidir. Platform standardı ekiplerin aynı güvenlik ilkelerini tekrar kullanılabilir hale getirmesine yardımcı olur.

Eski ve Yeni Sürümün Bir Süre Birlikte Çalışacağını Varsayın

Rolling ve canary modellerinde bu durum zaten doğrudan oluşur. Blue-green rollback penceresinde de iki sürüm geçerliliğini korur. API ve database tasarımı overlap dönemini desteklemelidir. Shared session ve cache formatları da version skew'a dayanmalıdır. Bu varsayım birçok deployment problemini tasarım aşamasında görünür hale getirir.

API ve Database Değişikliklerini Backward-Compatible Tasarlayın

Additive API ve schema değişiklikleri güvenli geçiş sağlar. Field removal veya column drop ertelenmelidir. Expand-and-contract data evolution için uygulanabilir bir modeldir. Consumer contract test uyumluluğu otomatik kontrol edebilir. Compatibility bağımsız deployment yapabilmenin temel koşullarından biridir.

Readiness ve Graceful Shutdown'ı Zorunlu Hale Getirin

Yeni instance hazır olmadan production trafiği almamalıdır. Eski instance da aktif request tamamlamadan kapatılmamalıdır. Platform policy probe ve termination ayarlarını zorunlu kılabilir. Application framework ortak shutdown library kullanabilir. Bu standartlar servis ekiplerinin aynı hataları tekrar etmesini azaltır.

Stateful İşleri ve Queue Consumer'ları Ayrı Tasarlayın

HTTP API ile worker aynı lifecycle'a sahip olmayabilir. Queue consumer in-flight message ve acknowledgement yönetmelidir. Scheduler distributed lock veya leader election gerektirebilir. Database migration application release'ten ayrı çalıştırılabilir. Workload tipine göre deployment policy tanımlamak daha güvenli sonuç verir.

Küçük Trafikle Başlayıp Metriklerle Promotion Yapın

Canary rollout production davranışını düşük blast radius ile ölçer. İlk trafik oranı sistem hacmine göre seçilmelidir. Minimum sample ve measurement window tanımlanmalıdır. Teknik metric ile business KPI birlikte değerlendirilmelidir. Promotion ancak yeterli güven oluştuğunda ilerlemelidir.

Rollback'ı Deployment'tan Önce Tasarlayın

Rollback incident başladıktan sonra ilk kez düşünülmemelidir. Eski image'ın erişilebilir olduğu doğrulanmalıdır. Database ve event schema compatibility test edilmelidir. External side effect bulunan release'lerde roll-forward kriterleri belirlenmelidir. Recovery runbook düzenli tatbikatlarla güncel tutulmalıdır.

Teknik Metriklerle Birlikte Business KPI'ları İzleyin

HTTP 200 tek başına kullanıcı işleminin başarılı olduğunu kanıtlamaz. Ödeme, sipariş veya authentication başarısı ayrıca ölçülmelidir. Deployment marker business dashboard üzerinde de gösterilebilir. Canary yeni version ile stable version business sonucu karşılaştırılabilir. Böylece teknik olarak çalışan ancak işlevsel olarak bozuk release daha hızlı fark edilir.

Zero-Downtime'ı Tek Bir Deployment Tekniği Değil Uçtan Uca Bir Reliability Disiplini Olarak Ele Alın

Kesintisiz deployment gerçek anlamda uygulama kodundan database'e, load balancer'dan monitoring'e kadar uzanan bir süreçtir. Rolling, blue-green veya canary yalnızca traffic ve instance geçiş modelini belirler. Reliability ise bu modellerin sağlıklı data evolution, graceful shutdown, observability ve recovery mekanizmalarıyla birleşmesini gerektirir. Kendi sisteminizde bu yapıyı kurarken önce mevcut deployment akışınızı, state noktalarınızı ve failure mode'larınızı haritalandırmanız güçlü bir başlangıç olacaktır. Diyarbakır Yazılım Topluluğu ile iletişim ve çalışmalar hakkında daha fazla bilgi edinmek için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects sayfalarını inceleyebilirsiniz.