Mavi/Yeşil ile Kanarya dağıtımları ne zaman kullanılmalı, trafik kaydırma nasıl çalışır, neler izlenir ve daha güvenli yayınlar için uygulamalı adımlar öğrenin.

Yeni kod göndermek tek bir nedenle risklidir: gerçek kullanıcılar erişene kadar nasıl davrandığını gerçekten bilemezsiniz. Mavi/Yeşil ve Kanarya, kesintiyi neredeyse sıfıra yakın tutarken bu riski azaltmanın iki yaygın yoludur.
Bir mavi/yeşil dağıtım, birbirine benzeyen iki ayrı ortam kullanır:
Yeşil ortamı arka planda hazırlarsınız—yeni yapıyı dağıtırsınız, kontrolleri çalıştırırsınız, ısıtırsınız—ve emin olduğunuzda trafiği Mavi'den Yeşil'e geçirirsiniz. Bir şey ters giderse hızlıca geri dönebilirsiniz.
Ana fikir iki renk değil, temiz, geri alınabilir bir geçiş yapmaktır.
Bir kanarya sürümü kademeli bir yayındır. Herkesi bir kerede değiştirmek yerine, yeni sürümü önce küçük bir kullanıcı dilimine gönderirsiniz (örneğin %1–5). Her şey sağlamsa, aşama aşama genişletirsiniz ta ki trafik %100 yeni sürüme geçene kadar.
Ana fikir, tam olarak karar vermeden önce gerçek trafikten öğrenmektir.
Her iki yaklaşım da şu hedeflere yöneliktir:
Bunu farklı yollarla yaparlar: Mavi/Yeşil, ortamlar arasında hızlı bir geçişe odaklanırken, Kanarya, trafik kaydırma yoluyla kontrollü maruz kalma sağlar.
Hiçbir yaklaşım otomatik olarak üstün değildir. Doğru seçim, ürününüzün nasıl kullanıldığına, testlere ne kadar güvendiğinize, ne kadar hızlı geri bildirim istediğinize ve hangi arıza türlerinden kaçınmak istediğinize bağlıdır.
Birçok ekip her ikisini de karıştırır—altyapı basitliği için Mavi/Yeşil kullanıp yüksek riskli hizmetler için Kanarya tekniklerini eklemek gibi.
Aşağıdaki bölümlerde bunları doğrudan karşılaştıracağız ve her birinin ne zaman daha uygun olduğunu göstereceğiz.
Mavi/Yeşil ve Kanarya, değişiklikleri kullanıcıları kesintiye uğratmadan yayınlamanın yollarıdır—ama yeni sürüme trafiğin nasıl aktığı konusunda farklılık gösterirler.
Mavi/Yeşil iki tam ortam çalıştırır: “Mavi” (mevcut) ve “Yeşil” (yeni). Yeşili doğrularsınız, sonra tüm trafiği bir kerede değiştirirsiniz—tek, kontrollü bir anahtarı çevirir gibi.
Kanarya yeni sürümü önce küçük bir kullanıcı dilimine gönderir (örneğin %1–5), sonra gerçek dünya performansını izlerken trafiği kademeli olarak kaydırır.
| Faktör | Mavi/Yeşil | Kanarya |
|---|---|---|
| Hız | Doğrulamadan sonra çok hızlı geçiş | Tasarım gereği daha yavaş (kademeli yayılma) |
| Risk | Orta: kötü bir sürüm geçişten sonra herkesi etkiler | Daha düşük: sorunlar genellikle tam yayılmadan önce ortaya çıkar |
| Karmaşıklık | Orta (iki ortam, temiz geçiş) | Daha yüksek (trafik bölme, analiz, kademeli adımlar) |
| Maliyet | Daha yüksek (yayın sırasında kapasiteyi fiilen iki katına çıkarırsınız) | Genellikle daha düşük (mevcut kapasiteyle kademeli artırma yapılabilir) |
| En uygun | Büyük, koordine değişiklikler | Sık, küçük iyileştirmeler |
Büyük değişiklikler, geçişler veya eski/yeniyi net ayırmanız gereken sürümler için Mavi/Yeşil seçin; temiz, öngörülebilir bir geçiş anı istiyorsanız uygundur.
Sık yayın yapıyorsanız, gerçek kullanımdan güvenli şekilde öğrenmek istiyorsanız ve metriklere göre adım atarak patlama etkisini azaltmak istiyorsanız Kanarya tercih edin.
Emin değilseniz, operasyonel sadelik için Mavi/Yeşil ile başlayın; izleme ve geri alma alışkanlıkları oturunca daha riskli hizmetler için Kanarya'yı ekleyin.
Mavi/Yeşil, yayınların “bir anahtar çevirir gibi” hissetmesini istediğinizde güçlü bir tercihtir. İki üretim-benzeri ortam çalıştırırsınız: Mavi (mevcut) ve Yeşil (yeni). Yeşil doğrulandığında kullanıcıları ona yönlendirirsiniz.
Ürününüz gözle görülür bakım pencerelerine tahammül edemiyorsa—ödeme işlemleri, rezervasyon sistemleri, giriş yapılmış paneller—Mavi/Yeşil uygundur çünkü yeni sürüm kullanıcılara gönderilmeden önce başlatılır, ısıtılır ve kontrol edilir. Dağıtım süresinin çoğu müşterilerin önünde değil, kenarda gerçekleşir.
Geri alma genellikle trafiği tekrar Mavi'ye yönlendirmek kadar basittir. Bu, şu durumlarda değerlidir:
Ana fayda geri almanın yeniden derlemeyi veya yeniden dağıtmayı gerektirmemesidir—sadece trafik anahtarıdır.
Mavi/Yeşil, veritabanı göçleri geriye dönük uyumlu olduğunda en kolay haldedir; çünkü kısa bir süre Blue ve Green birlikte var olabilir (ve her ikisi de okuma/yazma yapabilir, yönlendirme ve iş kurulumunuza bağlı olarak).
Uygun örnekler:
Riskli örnekler sütun kaldırma, alan yeniden adlandırma veya anlam değiştirme gibidir—bunlar çok adımlı göç planı yapmadan “geri dönme” vaadini bozabilir.
Mavi/Yeşil ek kapasite (iki yığın) ve trafiği yönlendirecek bir yol (load balancer, ingress veya platform yönlendirmesi) gerektirir. Ortamları otomatik oluşturan ve temiz bir yönlendirme kolu olan bir altyapınız varsa, Mavi/Yeşil yüksek güvenle, düşük drama için pratik bir varsayılan olur.
Kanarya sürümü, değişikliği önce küçük bir gerçek kullanıcı dilimine açıp olup biteni gözlemleyerek genişlettiğiniz bir stratejidir. Bütün dünyayı durdurmadan riski azaltmak istediğinizde en iyi seçenektir.
Kanarya, yüksek trafikli uygulamalarda en iyi çalışır çünkü %1–5 bile anlamlı veri üretebilir. Eğer hata oranı, gecikme, dönüşüm, ödeme tamamlama, API zaman aşımı gibi net metrikleri zaten izliyorsanız, dağıtımı gerçek kullanım desenleri üzerinde doğrulayabilirsiniz.
Bazı sorunlar sadece gerçek yük altında ortaya çıkar: yavaş DB sorguları, önbellek kaçırmaları, bölgesel gecikme, nadir cihazlar veya seyrek kullanıcı akışları. Kanarya ile hata oranını veya performans bozulmasını tüm kullanıcılara ulaşmadan önce doğrularsınız.
Ürününüz sık gönderim yapıyorsa, birden çok ekip katkıda bulunuyorsa veya aşamalı tanıtılabilecek değişiklikler varsa (UI değişiklikleri, fiyat deneyleri, öneri mantığı), kanarya doğaldır. %1 → %10 → %50 → %100 gibi genişletebilirsiniz.
Kanarya, özellik bayraklarıyla özellikle iyi eşleşir: kodu güvenle dağıtıp işlevi bir kullanıcı alt kümesi, bölge veya hesaba açabilirsiniz. Bu da geri almayı dramatik bir yeniden dağıtmadan ziyade bayrağı kapatmak kadar basit yapar.
Kademeli teslimata doğru ilerliyorsanız, kanarya genellikle en esnek başlangıç noktasıdır.
Ayrıca bakınız: /blog/feature-flags-and-progressive-delivery
Trafik kaydırma, yeni sürümü kimlerin ve ne zaman aldığını kontrol etmek demektir. Herkesi bir kerede çevirmek yerine, istekleri eski sürümden yeni sürüme kademeli (veya seçici) olarak taşırsınız. Bu, hem mavi/yeşil dağıtımin hem de kanarya sürümünün pratik kalbidir—ve ayrıca sıfır kesinti dağıtımını gerçekçi kılar.
Trafiği yığındaki birkaç ortak noktadan kaydırabilirsiniz. Doğru seçim, kullandıklarınıza ve ne kadar ince kontrol istediğinize bağlıdır.
Her katmana ihtiyacınız yok. Yönlendirme kararları için bir “tek gerçek kaynağı” seçin ki sürüm yönetimi varsayıma dönüşmesin.
Çoğu ekip şu yaklaşımlardan birini (veya karışımını) kullanır:
Yüzde en kolay açıklanandır, ama kohortlar genellikle daha güvenlidir çünkü hangi kullanıcıların değişikliği gördüğünü kontrol edebilirsiniz (ilk saatte en büyük müşterilerinizi şaşırtmamak için).
İki şey sağlam dağıtım planlarını genellikle bozar:
Sticky sessions (oturum bağımlılığı). Sisteminiz bir kullanıcıyı bir sunucu/sürüme bağlıyorsa, %10 trafik bölmesi %10 gibi davranmayabilir. Ayrıca kullanıcılar sürümler arasında gidip geldiğinde kafa karıştırıcı hatalar oluşabilir. Mümkünse paylaşılan oturum depolaması kullanın veya yönlendirmenin bir kullanıcıyı tutarlı olarak aynı sürüme yönlendirdiğinden emin olun.
Önbellek ısıtma. Yeni sürümler genellikle soğuk önbelleklere (CDN, uygulama önbelleği, DB sorgu önbelleği) çarpar. Bu, kod doğru olsa bile performans gerilemesi gibi görünebilir. Trafiği artırmadan önce özellikle yüksek trafikli sayfalar ve pahalı uç noktalar için önbellekleri ısıtmaya zaman ayırın.
Yönlendirme değişikliklerini rastgele bir düğme tıklaması yerine bir üretim değişikliği gibi ele alın.
Belgeleyin:
Bu küçük yönetişim, iyi niyetli kişilerin "sadece %50'ye iteyim" diye yaparken hâlâ canary sağlığını inceliyor olmanızı önler.
Bir yayın sadece "dağıtım başarılı mı?" değildir. Asıl soru "gerçek kullanıcılar daha kötü bir deneyim yaşıyor mu?" Mavi/Yeşil veya Kanarya sırasında sakin kalmanın en kolay yolu, size söyleyen küçük bir sinyal setini izlemektir: sistem sağlıklı mı ve değişiklik müşterilere zarar veriyor mu?
Hata oranı: HTTP 5xx, istek hataları, zaman aşımı ve bağımlılık hatalarını izleyin (DB, ödemeler, üçüncü taraf API'ler). Kanarya hataları küçük görünse bile büyük destek yükü yaratabilir.
Gecikme: p50 ve p95'i (ve varsa p99) izleyin. Ortalama gecikme sabit kalsa bile uzun kuyruklardaki yavaşlamalar kullanıcıların hissettiği farkı yaratabilir.
Doluluk (saturation): Sisteminizin ne kadar "dolduğunu" izleyin—CPU, bellek, disk IO, DB bağlantıları, kuyruk derinliği, iş parçacığı havuzları. Doluluk problemleri genellikle tam kesintiden önce görünür.
Kullanıcı-etkisi sinyalleri: Kullanıcıların gerçekten ne yaşadığını ölçün—ödeme hataları, giriş başarı oranı, arama sonuçları, uygulama çökme oranı, önemli sayfa yükleme süreleri. Bunlar genellikle sadece altyapı istatistiklerinden daha anlamlıdır.
Bir ekranı dolduran, sürüm kanalınızda paylaşılan küçük bir pano oluşturun. Her yayında tutarlı olsun ki insanlar grafik aramakla zaman kaybetmesin.
İçerik:
Eğer kanarya sürümü yapıyorsanız, metrikleri sürüm/örnek grup bazında ayırın ki kanarya ile baseline'ı doğrudan karşılaştırabilesiniz. Mavi/Yeşil içinse geçiş penceresinde yeni ortamla eskiyi karşılaştırın.
Trafiği kaydırmadan önce kuralları kararlaştırın. Örnek eşikler:
Sayılar servisinize bağlıdır; önemli olan üzerinde anlaşılmış olmalarıdır. Herkes geri alma planını ve tetikleyicileri bilirse, müşteri etkilenirken tartışma olmaz.
Yayın penceresi sırasında (veya geçişlerde) özel alarmlar ekleyin veya eşikleri sıkılaştırın:
Alarmları eyleme geçirilebilir tutun: “ne değişti, nerede ve sonraki adım ne?” Eğer alarmlar gürültülüysa, trafik kaydırma sırasında önemli sinyali kaçırırsınız.
Çoğu rollout hatası büyük hatalardan değil; küçük uyumsuzluklardan kaynaklanır: eksik bir yapılandırma, hatalı DB göçü, süresi geçen sertifika veya yeni ortamda farklı davranan bir entegrasyon. Yayın öncesi kontroller, bu sorunları patlama etkisi küçükken yakalama şansınızdır.
Trafiği kaydırmadan önce (mavi/yeşil veya küçük bir kanarya olsun) yeni sürümün temel olarak canlı ve istekleri karşılayabildiğini doğrulayın.
Unit testleri harikadır ama dağıtılmış sistemde konuşmayı kanıtlamazlar. Yeni ortamda birkaç dakikada biten kısa, otomatik uçtan uca testler çalıştırın.
Hizmetler arası akışları (web → API → DB → üçüncü taraf) kapsayan akışlara odaklanın ve her kritik entegrasyon için en az bir “gerçek” isteği dahil edin.
Otomatik testler bazen gözü kaçırır. Temel iş akışlarınızı hedef alan insana uygun doğrulamalar yapın:
Birden fazla rol destekliyorsanız (admin vs müşteri), her rol için en az bir yolculuk örnekleyin.
Check listi esas bilgiyi tekrar edilebilir bir stratejiye çevirir. Kısa ve uygulanabilir tutun:
Bu kontroller rutin hale geldiğinde trafik kaydırma kontrollü bir adım olur—bir inanç sıçraması değil.
Mavi/Yeşil yayını, adım adım bir kontrol listesi gibi ele alındığında en kolay çalışır: hazırla, dağıt, doğrula, geçir, gözle, sonra temizle.
Yeni sürümü Yeşil ortama dağıtın; Mavi gerçek trafiğe hizmet vermeye devam etsin. Konfigürasyonlar ve sırlar uyumlu olsun ki Yeşil gerçek bir ayna olsun.
Kısa, yüksek sinyalli kontroller yapın: uygulama temiz başlıyor mu, önemli sayfalar yükleniyor mu, ödemeler/giriş çalışıyor mu ve loglar normal görünüyor mu. Otomatik smoke testleriniz varsa şimdi çalıştırın. Bu aynı zamanda Yeşil için izleme panoları ve alarmların aktif olduğunu doğrulama anıdır.