Mavi/Yeşil ve Kanarya Dağıtımları: Açık Bir Yayın Stratejisi

Mavi/Yeşil ve Kanarya Dağıtımlarının Anlamı

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.

Basitçe Mavi/Yeşil

Bir mavi/yeşil dağıtım, birbirine benzeyen iki ayrı ortam kullanır:

• Mavi: şu anda kullanıcılara hizmet veren sürüm ("canlı" düzen).
• Yeşil: yeni sürümü dağıttığınız ve hazır bekleyen ikinci düzen.

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.

Basitçe Kanarya

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.

Paylaşılan amaç: daha az kesintiyle daha güvenli yayınlar

Her iki yaklaşım da şu hedeflere yöneliktir:

• bir şey bozulduğunda kullanıcı etkisini azaltmak
• bir sıfır kesinti dağıtımı (veya sisteminizin izin verdiği kadar yakın) desteklemek
• geri almaları daha az stresli ve öngörülebilir kılmak

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.

Tek bir “en iyi” seçenek yok

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 vs Kanarya: Hızlı Karşılaştırma

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.

Trafik nasıl değişir

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.

Önemli artılar ve eksiler

Basit bir karar rehberi

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 Hangi Durumda Uygundur

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.

Neredeyse sıfır kesintiye ihtiyacınız varsa

Ü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.

En basit geri alma yöntemini istiyorsunuz

Geri alma genellikle trafiği tekrar Mavi'ye yönlendirmek kadar basittir. Bu, şu durumlarda değerlidir:

• bir sürümü dakikalar içinde geri almak zorundaysanız
• baskı altında acil düzeltmelerden kaçınmak istiyorsanız
• net, tekrar edilebilir bir hata yanıtı istiyorsanız

Ana fayda geri almanın yeniden derlemeyi veya yeniden dağıtmayı gerektirmemesidir—sadece trafik anahtarıdır.

Veritabanı değişiklikleriniz uyumlu tutulabiliyorsa

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:

• eklenen nullable sütunlar, yeni tablolar
• eski kodun yok sayabileceği genişletilmiş veri formatları

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.

Çift ortam ve yönlendirme kontrolünü karşılayabiliyorsanız

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ümleri Hangi Durumda Daha Uygun

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.

Yüksek trafiniz ve net sinyalleriniz varsa

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.

Performans ve uç durumlar sizi endişelendiriyorsa

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.

Tek seferlik bir geçiş değil, kademeli yayınlar gerekiyorsa

Ü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.

Özellik bayrakları araç setinizin parçasıysa

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 Temelleri (Jargonsuz)

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.

"Direksiyon": trafik nereye yönlendiriliyor

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.

• Load balancer: gelen istekleri iki ortam veya iki sunucu kümesi arasında bölür.
• Ingress controller (Kubernetes): kurallara göre trafiği farklı Servislere yönlendirir.
• Service mesh: hizmetler arası trafiği hassas kurallarla ve daha iyi görünürlükle kontrol eder.
• CDN / edge yönlendirme: yönlendirme kararlarını kullanıcılara yakın yapmak istediğinizde, genellikle web trafiği için faydalı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.

Trafiği bölmenin yaygın yolları

Çoğu ekip şu yaklaşımlardan birini (veya karışımını) kullanır:

• Yüzde bazlı: %1 → %5 → %25 → %50 → %100. Klasik kanarya deseni.
• Header bazlı: belirli bir başlığa sahip istekleri (ör. QA araçlarından veya dahili testlerden) yeni sürüme yönlendirme.
• Kullanıcı kohortları: önce çalışanlar, beta kullanıcıları, bir bölge veya müşteri kademesi gibi belirli grupları kaydırma.

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).

Oturumlar ve önbellekler: iki sık takılma noktası

İ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.

Trafik değişikliklerini kontrollü bir operasyon haline getirin

Yönlendirme değişikliklerini rastgele bir düğme tıklaması yerine bir üretim değişikliği gibi ele alın.

Belgeleyin:

• kimlerin trafik oranlarını değiştirmeye yetkisi olduğu
• nasıl onaylandığı (on-call? sürüm yöneticisi? değişiklik bileti?)
• nerede yapıldığı (load balancer yapılandırması, ingress kuralları, mesh politikası)
• "dur"un ne demek olduğu (yayını durdurma ve geri alma planını uygulama tetikleyicisi)

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.

Yayın Sırasında Neler İzlenmeli

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?

Dört temel sinyal: hata, gecikme, doluluk, kullanıcı etkisi

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.

Herkesin okuyabileceği bir "sürüm panosu" oluşturun

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:

• hata oranı (genel + kritik uç noktalar)
• gecikme (kritik yollar için p50/p95)
• doluluk (yığının en önemli 3 kısıtı, örn. uygulama CPU, DB bağlantıları, kuyruk derinliği)
• kullanıcı-etkisi KPI'ları (en önemli 1–3 iş akışı)

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.

Duraklatma/geri alma kararları için net eşikler koyun

Trafiği kaydırmadan önce kuralları kararlaştırın. Örnek eşikler:

• hata oranı baseline'a göre X% artarsa Y dakika boyunca devam etmesi
• p95 gecikme sabit bir limiti aşarsa (veya baseline'a göre X% artarsa)
• bir kullanıcı-etkisi KPI'sı kabul edilemez seviyenin altına düşerse

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 penceresine odaklı alarmlar

Yayın penceresi sırasında (veya geçişlerde) özel alarmlar ekleyin veya eşikleri sıkılaştırın:

• beklenmeyen 5xx/zaman aşımı artışları
• kritik rotalarda ani gecikme gerilemeleri
• doluluk sinyallerinde hızlı yükseliş (bağlantı havuzları, kuyruklar)

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.

Yayın Öncesi Kontrolleri (Sorunları Erken Yakalar)

Ç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.

Sağlık kontrolleri ve smoke testleri ile başlayın

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.

• uygulama health endpoint'lerinin OK döndürdüğünden emin olun (sadece “süreç çalışıyor” değil)
• bağımlılıkları doğrulayın: veritabanı, önbellek, kuyruk, obje depolama, e-posta/SMS sağlayıcıları
• sırların ve ortam değişkenlerinin mevcut ve doğru kapsamlı olduğundan emin olun

Yeni ortama karşı kısa uçtan uca testler çalıştırı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.

Kritik kullanıcı yolculuklarını doğrulayın

Otomatik testler bazen gözü kaçırır. Temel iş akışlarınızı hedef alan insana uygun doğrulamalar yapın:

• giriş ve şifre sıfırlama
• ödeme/checkout akışı (hata yolları dahil)
• kullanıcıların her gün yaptığı temel "oluştur/güncelle/sil" işlemleri

Birden fazla rol destekliyorsanız (admin vs müşteri), her rol için en az bir yolculuk örnekleyin.

Ön-yayın hazır olma kontrol listesi tutun

Check listi esas bilgiyi tekrar edilebilir bir stratejiye çevirir. Kısa ve uygulanabilir tutun:

• veritabanı göçleri uygulandı ve geri alınabilir (veya açıkça güvenli)
• gözlemlenebilirlik hazır: loglar, panolar, kritik metrikler için alarmlar
• geri alma planı gözden geçirildi (kim, nasıl ve "dur" ne demek)

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ı: Pratik Oyun Kitabı

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.

1) Yeşil'e dağıt (kullanıcıları etkilemeden)

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.

2) Trafik değişmeden önce Yeşil'i doğrulayın

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.

3) Veritabanı göçlerini güvenli şekilde planlayın (genişlet/sözleş)