Rollback (Geri Alma) Nedir?

Geri almak neden ayrı bir beceri?

Her deployment küçük bir risk taşır: testlerde görünmeyen bir hata, üretim verisinde patlayan bir sorgu ya da üçüncü taraf bir servisle beklenmedik bir uyumsuzluk. Böyle bir anda ekibin önünde iki yol vardır: sorunu canlı ortamda düzeltmek ya da önceki sürüme dönmek. Rollback ikincisidir ve asıl değeri kararı ertelemeden kullanıcıyı korumasıdır. Önce kanama durdurulur, kök neden sakin bir ortamda incelenir.

Ancak geri almak, “eski dosyaları geri kopyalamak” kadar basit değildir. Sürümler etiketlenmemişse, yapılandırma sürümle birlikte saklanmıyorsa veya veritabanı değişmişse, panik anında hangi duruma dönüleceği bile belirsizleşir.

Uygulama geri alma ile veritabanı geri alma aynı şey değildir

Uygulama kodu durumsuzdur (stateless): önceki sürümün paketi ya da container imajı hâlâ duruyorsa, onu yeniden çalıştırmak yeterlidir. Veritabanı ise durumu taşır. Yeni sürüm bir kolonu silmiş, tabloyu yeniden adlandırmış veya verileri yeni bir formatta yazmaya başlamışsa, eski kod bu şemayla çalışamaz. Şemayı geri almak da çoğu zaman o aradaki verinin kaybı demektir.

Bu yüzden olgun ekipler veritabanı migrasyonlarını “genişlet, sonra daralt” (expand/contract) mantığıyla yapar:

1. Genişlet: Yeni kolon veya tablo eklenir; eski kod bunu görmezden gelerek çalışmaya devam eder.
2. Geçiş: Yeni sürüm hem eski hem yeni yapıyla uyumlu biçimde yayına alınır, veriler arka planda taşınır.
3. Daralt: Eski kolon ancak birkaç sürüm sonra, geri dönülmeyeceği kesinleşince silinir.

Bu disiplinde kod her an bir önceki sürüme dönebilir, çünkü şema iki sürümle de uyumludur. Veri kaybına karşı son çare ise rollback değil, test edilmiş bir yedekten geri yüklemedir.

Geri dönüşü dakikalara indiren yayın alışkanlıkları

• Değişmez, etiketli paketler: Her sürüm commit kimliği veya sürüm numarasıyla etiketlenir ve sunucuda yeniden derlenmez. Geri almak, önceki etiketi tekrar yayına almaktan ibaret olur.
• Tek komutla dönüş: Sürüm klasörlerini yan yana tutup aktif olanı sembolik bağlantıyla göstermek veya orkestrasyon aracının kendi geri alma komutunu kullanmak, işlemi tahmin edilebilir kılar.
• Yapılandırma da sürümlenir: Ortam ayarları kodla birlikte değiştiyse, yalnızca kodu geri almak yeni bir hata üretebilir.
• Trafik düzeyinde geri alma: Blue-green deployment eski ortamı ayakta tuttuğu için dönüş tek bir trafik değişikliğidir; canary deployment ise sorunu kullanıcıların küçük bir kısmında yakalayıp geri çekmeyi sağlar.

# Sürüm klasörleri: geri almak = bağlantıyı önceki sürüme çevirmek
ln -sfn /srv/app/releases/2026-10-02_1412 /srv/app/current
systemctl reload app

# Kubernetes'te bir Deployment'ı önceki revizyona döndürmek
kubectl rollout undo deployment/web

Rollback mı, forward-fix mi?

Bazen geri dönmek yerine hızla yeni bir düzeltme yayınlamak (forward-fix, roll forward) daha doğrudur. Karar genellikle şu sorulara bağlıdır:

Forward-fix'i seçmek ancak CI/CD hattı hızlı ve güvenilirse mantıklıdır. Aceleyle, testleri atlayarak yapılan “düzeltme”, ilk hatanın üstüne ikincisini eklemenin en kısa yoludur.

Geri alma kararını kim, neye bakarak verir?

Rollback'in en pahalı kısmı çoğu zaman kararın gecikmesidir. Yayından önce hangi metriklerin geri dönüşü tetikleyeceği yazılı olmalıdır: hata oranındaki artış, yanıt süresindeki bozulma, ödeme veya kayıt gibi kritik akışlarda düşüş. Yayın sonrası ilk dakikalarda bu göstergeleri izleyen bir kişi ve “şüphedeysen geri al” kuralı, uzun süren bir arızayı kısa bir aksaklığa çevirebilir. Geri alma yolu da düzenli olarak denenmelidir; hiç çalıştırılmamış bir rollback prosedürü, ihtiyaç anında genellikle çalışmaz.