Geri Alma Planı Olmayan Dağıtım, Dağıtım Değildir

Geri alma planı olmadan yapılan dağıtım, aslında tek yönlü bir bahistir. Yayın sonrası bir sorun çıktığında ekibin ilk refleksi genellikle "hemen bir düzeltme yazıp yayınlayalım" olur. Bu refleks, kesintiyi çözmez; uzatır. Çünkü baskı altında yazılan düzeltme test edilmemiştir, ikinci bir hata riski taşır ve her deneme yeni bir dağıtım süresi kadar zaman yer. Sağlıklı olan, bilinen çalışan duruma dönüp sorunu sakin kafayla incelemektir — ama bu ancak dönüş yolu önceden kurulmuşsa mümkündür.

Geri almayı imkânsız kılan üç şey

1. Geriye uyumsuz veritabanı göçleri

En sık karşılaşılan engel budur. Yeni sürümle birlikte bir sütun silindiyse veya tipi değiştiyse, eski sürüme dönmek artık mümkün değildir: eski kod, artık var olmayan bir alanı arar. Bu yüzden altın kural şudur: şema değişiklikleri kod değişikliklerinden ayrı ve daha önce yayınlanır, yıkıcı adımlar ise en sona bırakılır. Uygulamasının ayrıntıları için sıfır kesintili göç yazımıza bakabilirsiniz.

2. Tek yönlü veri dönüşümleri

Yeni sürüm, mevcut kayıtları yeni bir formatta yazmaya başladıysa, geri döndüğünüzde eski kod bu kayıtları okuyamaz. Bu durumda geri alma teknik olarak mümkün ama pratikte veri kaybına yol açar. Çözüm, geçiş döneminde her iki formatı da okuyabilen kod yazmaktır.

3. Dış sistemlere yayılmış değişiklikler

Yeni sürüm bir ödeme sağlayıcısına farklı formatta istek göndermeye başladıysa veya bir webhook sözleşmesini değiştirdiyse, geri dönüş yalnızca sizin kontrolünüzde değildir. Bu tür değişiklikleri kademeli yayınlamak ayrıca önemlidir.

Geri dönüşü ucuzlatan dört pratik

Özellik bayrakları

Riskli davranışı kodla birlikte değil, bir anahtarın arkasında yayınlamak, geri almayı dağıtım işlemi olmaktan çıkarıp bir yapılandırma değişikliğine indirger. Yeni sürüm zaten yayındadır; sorun çıkarsa yalnızca bayrağı kapatırsınız. Bu, saniyeler içinde ve yeni bir dağıtım riski almadan gerçekleşir.

Bayrakların gizli maliyeti, temizlenmediklerinde kod tabanında birikmeleridir. Her bayrağa bir sahip ve bir kaldırılma tarihi atamak, bu borcun büyümesini engeller.

Kademeli yayın

Yeni sürümü tüm trafiğe aynı anda açmak, hatayı da tüm kullanıcılara aynı anda göstermek demektir. Trafiğin önce %1'ine, sonra %10'una açmak, sorunun etkisini küçük tutar ve genellikle sorunu üretim ölçeğinde ilk kez görmenizi sağlar. Kademeli yayın sırasında hata oranı ve yanıt süresi otomatik izleniyorsa, geri alma da otomatikleştirilebilir.

Değişmez sürümler

Geri alınacak sürümün elinizde hazır durması gerekir. Her yayında oluşturulan yapı (build) artefaktının saklanması ve önceki sürüme tek komutla dönülebilmesi şarttır. "Eski commit'i çekip yeniden derleyelim" yaklaşımı, geri alma süresini dakikalardan yarım saate çıkarır — üstelik bağımlılıklar değiştiği için aynı çıktıyı üretme garantisi de yoktur.

Provası yapılmış geri alma

Hiç denenmemiş bir geri alma prosedürü, olmayan bir prosedürdür. Bu, yedeklemede de aynen geçerlidir; geri dönüşü denenmemiş yedeğin durumu için yedek geri dönüş testi yazımıza bakın. Geri almayı üç ayda bir, gerçek üretim ortamında ve zaman tutarak deneyin. Ölçtüğünüz süre, olay anındaki en kritik bilgidir.

Ne zaman geri almalı, ne zaman ileri gitmeli?

Her sorun geri alma gerektirmez. Pratik bir karar kuralı şudur:

• Geri alın: Sorunun sebebi belirsizse, etkisi yayılıyorsa veya çözüm süresi tahmin edilemiyorsa. Belirsizlik, geri almanın en güçlü gerekçesidir.
• İleri gidin: Sebep kesin biliniyorsa, düzeltme tek satırlıksa ve geri alma daha riskliyse (örneğin şema zaten değişmişse).

Karar anında en çok yapılan hata, sebebi bulmaya çalışırken kesintiyi uzatmaktır. Doğru sıra: önce etkiyi durdur, sonra araştır.

Dağıtım hattına neler eklenmeli?

Geri alma yeteneği bir kültür meselesi olduğu kadar bir otomasyon meselesidir. Dağıtım hattınızda şunlar bulunmalıdır: her yayın için sürüm etiketi ve saklanan artefakt, yayın sonrası otomatik sağlık kontrolü, hata oranı eşiği aşıldığında uyarı, ve tek komutla önceki sürüme dönüş. Bu yapıyı sıfırdan kurmak için CI/CD kurulum yazımız, hattın kendi güvenliği için ise pipeline güvenliği yazımız tamamlayıcıdır. Yayın stratejilerinin karşılaştırmalı bir özeti için Martin Fowler — Blue Green Deployment yazısı iyi bir başlangıçtır.

Sonuç

Dağıtımın başarısı, doğru gittiğinde ne kadar hızlı olduğuyla değil, yanlış gittiğinde ne kadar çabuk dönebildiğinizle ölçülür. Geri alma yeteneği sonradan eklenen bir acil durum planı değil, göçlerin sırasından özellik bayraklarına kadar dağıtım tasarımının içine örülmesi gereken bir özelliktir. Ekibinize sorulacak tek bir soru bu yeteneğin var olup olmadığını hemen gösterir: "Şu an yayındaki sürümden bir öncekine dönmemiz kaç dakika sürer?" Kimse net bir sayı veremiyorsa, bir sonraki dağıtımdan önce yapılacak iş bellidir.