--- title: "Geri Alma Planı Olmayan Dağıtım, Dağıtım Değildir" url: "https://cilginyazilim.com/blog/geri-alma-plani-olmayan-dagitim-dagitim-degildir" description: "Dağıtımdan geri dönüş nasıl planlanır? İleriye uyumlu göçler, özellik bayrakları, kademeli yayın ve geri alma süresini ölçmek için pratik bir rehber." published: "2026-10-06T10:00:00+03:00" modified: "2026-10-06T10:00:03+03:00" author: "Çılgın Yazılım" category: "DevOps ve Sistem Yönetimi" tags: ["izleme", "devops", "ci/cd", "risk yönetimi", "veritabanı göçü", "dağıtım", "geri alma planı", "özellik bayrağı", "kademeli yayın", "canary", "sürüm yönetimi", "olay müdahalesi", "kesinti"] site: "Çılgın Yazılım" language: "tr" --- # Geri Alma Planı Olmayan Dağıtım, Dağıtım Değildir Sorun çıktığında "düzeltip yeniden yayınlayalım" demek, kesintiyi uzatan en pahalı reflekstir. Geri dönüş yolu önceden kurulur. **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. ![Güvenli dağıtım kuralları listesi](https://cilginyazilim.com/uploads/blog/2026/07/geri-alma-plani-olmayan-dagitim-dagitim-degildir-ozet.png) *Geri alma bir acil durum prosedürü değil, dağıtım tasarımının parçasıdı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](https://cilginyazilim.com/blog/veritabani-gocleri-sifir-kesintiyle-nasil-uygulanir) 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](https://cilginyazilim.com/blog/yedekleme-var-ama-geri-donus-denenmemis) 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](https://cilginyazilim.com/blog/ci-cd-nedir-kucuk-ekipler-icin-otomatik-dagitim), 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](https://martinfowler.com/bliki/BlueGreenDeployment.html) 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. ## Sıkça Sorulan Sorular ### Küçük ekipler için geri alma altyapısı fazla mı karmaşık? Aksine, küçük ekipler için daha kritiktir çünkü olay anında müdahale edecek kişi sayısı azdır. Basit bir sürüm etiketi ve önceki artefakta dönen tek komut, en küçük kurulumda bile büyük fark yaratır. ### Özellik bayrakları kodu karmaşıklaştırmıyor mu? Kalıcı hâle gelirlerse evet. Bayrağı geçici bir yayın aracı olarak görüp kaldırma tarihini baştan belirlemek bu karmaşıklığı önler. ### Veritabanı göçünü geri almak neden bu kadar zor? Kod geri alınabilir çünkü değişmez bir artefakttır; veri ise geri alınamaz çünkü bu sırada değişmeye devam etmiştir. Bu yüzden yıkıcı şema adımları koddan ayrı ve en sona bırakılır. ### Kademeli yayın için özel bir altyapı şart mı? Gelişmiş trafik yönlendirme faydalıdır ama şart değildir. Sunucuların bir kısmını yeni sürüme alıp yük dengeleyici üzerinden kademeli açmak da aynı korumayı büyük ölçüde sağlar. --- Kaynak: [Geri Alma Planı Olmayan Dağıtım, Dağıtım Değildir](https://cilginyazilim.com/blog/geri-alma-plani-olmayan-dagitim-dagitim-degildir)