Bir yazılım projesinin en kritik anı çoğu zaman geliştirme değil, üretim ortamına geçiştir. Test ortamında sorunsuz görünen bir sürüm, canlıda farklı ağ kuralları, gerçek kullanıcı yükü, entegrasyon bağımlılıkları ya da veri tutarsızlıkları nedeniyle beklenmedik sorunlar yaratabilir. İyi hazırlanmış bir canlıya geçiş planı, yalnızca teknik ekip için değil; operasyon, müşteri hizmetleri, finans ve saha ekipleri için de riskleri görünür kılar.

Canlıya geçişi tek bir işlem gibi ele almak hatalı olur. Bu süreç; kapsam dondurma, veri taşıma, erişim yönetimi, performans doğrulama, rollback senaryosu ve geçiş sonrası izleme gibi parçaların birlikte çalıştığı kontrollü bir operasyondur. Özellikle ERP, CRM, B2B portal, mobil uygulama backend’i veya dış sistemlerle API üzerinden konuşan platformlarda 30 dakikalık plansız bir kesinti bile sipariş akışını, çağrı merkezi yükünü ya da saha operasyonunu doğrudan etkileyebilir.

Bu yazıda, kesinti süresini kısaltan, veri kaybı riskini düşüren ve ekipler arası koordinasyonu netleştiren pratik bir geçiş çerçevesi bulacaksınız. Amaç, teorik bir liste sunmak değil; uygulanabilir, denetlenebilir ve gerçek projelerde karşılığı olan bir plan ortaya koymak.

Canlıya geçiş planı neden ayrı bir doküman olmalı?

Proje planı ile canlıya geçiş planı aynı şey değildir. Proje planı aylar sürebilir; canlıya geçiş ise çoğu ekipte 2 ila 8 saatlik kritik bir pencereye sıkışır. Bu kısa aralıkta yapılacak her adımın sırası, sorumlusu ve geri dönüş yöntemi önceden tanımlanmış olmalıdır.

Ayrı bir doküman kullanılmasının temel nedeni, sürecin kontrol edilebilir olmasıdır. Örneğin cuma gecesi saat 22:00’de başlayan bir geçişte, “önce veritabanı şeması uygulanacak, sonra kuyruk servisleri durdurulacak, ardından DNS veya load balancer yönlendirmesi yapılacak” gibi sıralamalar yorumla değil, açık talimatlarla yönetilmelidir. Dakika bazlı planlama burada gerçekten fark yaratır.

Hangi bilgileri içermeli?

  • Geçiş tarihi, başlangıç ve hedef bitiş saati. Örnek: 14 Eylül 2026, 23:00–01:00.
  • Sistem kapsamı. Hangi modüller, API’ler, mobil backend’ler veya entegrasyonlar etkilenecek?
  • İş etkisi. Sipariş alma duracak mı, sadece raporlama mı etkilenecek?
  • Sorumlu kişiler ve yedekleri. En az 1 birincil, 1 yedek kişi kritik adımlarda tanımlanmalı.
  • İleri alma ve geri alma adımları. Her iki taraf da komut, süre ve onay kriteriyle yazılmalı.

Tek satırlık “deployment yapılacak” notu yeterli değildir. Üretim ortamında güven, detayla sağlanır.

Geçiş öncesi hazırlık: 7 günlük kontrol penceresi

Başarılı geçişlerin önemli bir bölümü, canlıya çıkmadan önce kazanılır. Son 7 gün içinde yapılan hazırlıklar, geçiş gecesindeki belirsizliği ciddi ölçüde azaltır. Buradaki amaç işleri uzatmak değil, sürprizleri en aza indirmektir.

1. Kapsamı dondurun

Geçişten 3 ila 5 gün önce yeni özellik eklemeyi durdurmak, çoğu projede iyi bir pratiktir. Bu pencere içinde yalnızca kritik hata düzeltmeleri alınır. Özellikle veri modeli değişmişse, son anda eklenen küçük bir alan bile entegrasyonları bozabilir.

2. Üretime yakın ortamda prova yapın

Staging ortamı gerçekten üretime benzemiyorsa testlerin değeri sınırlı kalır. En azından şu unsurlar benzer olmalıdır: veritabanı motoru sürümü, cache katmanı, kuyruk sistemi, environment variable seti, üçüncü parti API anahtarlarının test karşılıkları. Mümkünse geçiş adımlarının kuru koşusu bir kez zaman tutularak yapılmalı. Örnek: migration 11 dakika, indeks oluşturma 4 dakika, cache warm-up 6 dakika.

3. Veri yedeğini doğrulayın

Yedek almak tek başına güvence değildir; asıl önemli olan geri dönülebilir olmasıdır. Geçişten önce alınan yedeğin tarih-saat bilgisi, boyutu ve geri yükleme testi kayıt altına alınmalı. 80 GB’lık veritabanının restore süresi 45 dakika ise rollback penceresi buna göre planlanmalıdır. “Gerekirse döneriz” ifadesi, süre hesabı yoksa eksik kalır.

4. Bağımlılık haritasını çıkarın

Canlıya geçişte sorun çoğu zaman ana uygulamada değil, çevresindeki bağımlılıklarda ortaya çıkar. Ödeme sistemi, e-fatura servisi, LDAP/SSO, SMS sağlayıcısı, ETL job’ları, webhook tüketicileri… Her entegrasyon için “geçiş sırasında ne olacak?” sorusu yanıtlanmalı. Gerekirse belirli job’lar 1 saatliğine durdurulur.

Kesintiyi azaltan geçiş stratejileri

Her proje aynı yöntemle canlıya alınmaz. Uygulamanın mimarisi, trafik seviyesi ve veri tutarlılığı ihtiyacı hangi stratejinin seçileceğini belirler. Burada sihirli tek bir model yok; doğru strateji, sistemin gerçeklerine göre seçilir.

Big bang geçiş

Tüm kullanıcıların tek anda yeni sürüme geçtiği modeldir. Küçük ölçekli iç uygulamalarda uygulanabilir. En büyük artısı basit olmasıdır. En büyük eksisi ise hata çıktığında etkisinin geniş bir alana yayılmasıdır. 200 kullanıcıya hizmet veren kapalı bir intranet uygulamasıyla 20 bin günlük oturuma sahip bir B2B platform aynı risk profiline sahip değildir.

Blue-green dağıtım

İki ayrı üretim ortamı kullanılır. Mevcut sürüm “blue”, yeni sürüm “green” olarak hazır bekler. Trafik, doğrulama sonrası yeni ortama yönlendirilir. Sorun çıkarsa geri dönüş genellikle daha hızlıdır; çünkü eski ortam korunur. Bu modelin maliyeti daha yüksektir. Aynı anda 2 ortamı ayakta tutmak gerekir.

Canary geçiş

Trafiğin önce küçük bir bölümü yeni sürüme verilir. Örnek: ilk 15 dakika %5 trafik, sonra %25, ardından tamamı. Uygulama gözlemlenebilirliği güçlü ekipler için etkili bir yöntemdir. Hata oranı, yanıt süresi ve iş metrikleri kabul eşiğini aşarsa dağıtım durdurulur.

Feature flag yaklaşımı

Kod canlıdadır ama özellik kapalıdır. Özellikle yüksek riskli modüllerde etkilidir. Kullanıcı segmentine göre açma imkânı verdiği için kontrol seviyesi yüksektir. Ancak feature flag yönetimi disiplinsiz yapılırsa zamanla teknik borç üretir.

Seçim yaparken en az 3 ölçüte bakın: kabul edilebilir kesinti süresi, rollback süresi, veri uyumluluğu. Örneğin şema değişikliği geri uyumsuzsa, yalnızca trafik yönlendirmesiyle güvenli dönüş mümkün olmayabilir.

Veri kaybını önlemek için migration planı nasıl yazılır?

Canlıya geçişte en hassas alan veridir. Uygulama birkaç dakikalığına yavaşlayabilir; ancak veri kaybı, sipariş çakışması veya finansal kayıt bozulması çok daha ağır sonuçlar doğurur. Bu nedenle veri taşıma adımları ayrı bir başlıkta ele alınmalıdır.

İyi bir migration planında bulunması gerekenler

  • Etkilenen tablolar, koleksiyonlar veya dosya depoları
  • Şema değişikliklerinin ileri ve geri uyumluluk durumu
  • DDL ve DML adımlarının ayrı yazılması
  • Beklenen kayıt sayısı. Örnek: 1,2 milyon müşteri kaydı, 9 milyon sipariş satırı
  • Doğrulama sorguları ve kabul eşikleri

Basit bir örnek verelim. Eski sistemde full_name alanı varken yeni sistemde first_name ve last_name alanları kullanılacaksa, yalnızca kolon eklemek yetmez. Boş kayıt oranı, çok parçalı isimler, entegrasyonların beklediği format ve eski API yanıtları da hesaba katılmalıdır.

SELECT COUNT(*) FROM customers WHERE first_name IS NULL;
SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '1 hour';

Bu tür doğrulama sorguları geçiş planında açıkça yer almalı. “Veriler kontrol edildi” ifadesi yerine hangi sorgunun çalıştırıldığı yazılmalı. Ayrıca yazma trafiğinin dondurulacağı pencere de net olmalıdır. Örneğin 23:10–23:25 arasında yeni sipariş oluşturma kapatılacak, yalnızca mevcut sipariş görüntüleme açık kalacak gibi.

Operasyon aksamasını azaltan geçiş kontrol listesi

Teknik başarı, her zaman operasyonel başarı anlamına gelmez. Sistem açılmış olsa bile kullanıcıların giriş yapamaması, çağrı merkezinin yeni ekranı tanımaması veya depo sürecinin geçici olarak durması gerçek hayatta ciddi aksamalara yol açar. Bu nedenle geçiş kontrol listesi, teknik ve operasyonel maddeleri birlikte içermelidir.

Canlıya geçiş gecesi için örnek kontrol listesi

  • Geçiş komuta kanalı açıldı mı? Örnek: tek bir Teams/Slack kanalı ve tek karar verici.
  • Bakım modu mesajı hazır mı? Kullanıcıya gösterilecek metin onaylandı mı?
  • Son tam yedek alındı mı? Saat ve checksum kaydı var mı?
  • Batch job, cron ve queue consumer süreçleri durduruldu mu?
  • Migration adımları beklenen sürede tamamlandı mı? Planlanan 12 dakika, gerçekleşen 14 dakika gibi not düşüldü mü?
  • Uygulama sağlık kontrolleri geçti mi? HTTP 200 dönmesi tek başına yeterli olmayabilir.
  • Login, sipariş oluşturma, ödeme, rapor görüntüleme gibi kritik senaryolar manuel test edildi mi?
  • İzleme panelleri açık mı? CPU, bellek, hata oranı, kuyruk derinliği, 95. persentil yanıt süresi takip ediliyor mu?
  • İş birimlerinden onay alındı mı? Sadece teknik ekip “tamam” dememeli.
  • Rollback tetikleme eşiği tanımlı mı? Örnek: 10 dakika boyunca hata oranı %3 üstünde kalırsa geri dönüş.

Bu liste her projede birebir aynı kalmaz. Yine de iskelet olarak son derece işlevseldir. Özellikle çok paydaşlı projelerde adım adım işaretlenen kontrol listeleri, sözlü koordinasyona kıyasla çok daha güvenilirdir.

Rollback planı: hiç kullanılmasa bile yazılmalı

Geçiş planlarının en zayıf halkası çoğu zaman geri dönüş kısmıdır. Pek çok ekip ileri alma adımlarını ayrıntılı biçimde yazar, rollback bölümünü ise tek cümleyle geçer. Oysa başarısız bir geçişte, zaman baskısı altında en çok ihtiyaç duyulan belge rollback planıdır.

İyi bir rollback planı şu 4 soruya yanıt verir: hangi koşulda geri dönülecek, kararı kim verecek, teknik adımlar neler olacak, geri dönüş sonrası doğrulama nasıl yapılacak? Burada “gerekirse eski sürüm deploy edilir” demek yeterli değildir. Veritabanı şema değişiklikleri geri uyumlu değilse, eski sürümü ayağa kaldırmak tek başına çözüm olmaz.

Somut bir rollback örneği

Diyelim ki yeni sürümde sipariş tablosuna zorunlu bir kolon eklendi ve eski sürüm bu alanı bilmiyor. Bu durumda rollback için ya geri uyumlu bir migration tasarlanmalı ya da veri yazımı dondurulduktan sonra kontrollü geri dönüş yapılmalı. Aksi halde uygulama açılır; ancak yeni dönemde oluşan kayıtlar eski sürüm tarafından işlenemez.

Karar eşiğini de yazın. Örnek: “İlk 20 dakikada ödeme başarısızlık oranı baz değerin 2 katını aşarsa rollback başlatılır.” Bu yaklaşım, duygusal kararların önüne geçer.

Geçiş sonrası ilk 24 saat: izleme, doğrulama, iletişim

Canlıya geçiş, deploy tamamlandığında bitmez. Özellikle ilk 1 saat ve ilk 24 saat, gizli sorunların ortaya çıktığı dönemdir. Bellek sızıntıları, kuyruk birikmesi, gecikmeli webhook’lar ya da gece çalışan rapor job’ları çoğu zaman bu pencerede kendini gösterir.

İlk 60 dakikada bakılması gereken sinyaller

  • 5xx hata oranı ve uygulama log’larında artış
  • Ortalama ve p95 yanıt süreleri
  • Veritabanı bağlantı sayısı, kilitlenme ve yavaş sorgular
  • Kritik iş metrikleri: sipariş adedi, başarılı ödeme, yeni kullanıcı kaydı

İlk 24 saatte ise daha geniş bir doğrulama gerekir. Örnek olarak sabaha karşı çalışan mutabakat job’ları, entegrasyon retry kuyrukları ve raporlama ekranlarındaki toplamlar kontrol edilmelidir. Teknik izleme kadar kullanıcı geri bildirimi de değerlidir. Destek ekibine gelecek ilk 10 çağrı, çoğu zaman gözden kaçan UX veya yetkilendirme sorunlarını görünür hale getirir.

İletişim tarafını da ihmal etmeyin. Geçiş tamamlandığında ilgili paydaşlara kısa bir durum özeti gönderin: başlangıç saati, bitiş saati, yaşanan sapmalar, açık kalan düşük öncelikli maddeler. Bu yaklaşım kurumsal hafıza oluşturur ve sonraki geçişleri iyileştirir.

Sonuç: iyi canlıya geçiş planı sürprizi azaltır

Etkili bir canlıya geçiş planı, yalnızca teknik adımların listesi değildir. İş etkisini, veri güvenliğini, kullanıcı deneyimini ve geri dönüş senaryosunu aynı çerçevede yönetir. Dakika bazlı zamanlama, doğrulanmış yedek, test edilmiş migration, net rollback eşiği ve geçiş sonrası izleme bir araya geldiğinde kesinti ve operasyon aksaması belirgin biçimde azalır.

Her sistemin riski farklıdır. İç kullanımda olan bir workflow uygulaması ile çok kanallı sipariş alan bir B2B platform aynı yöntemle yönetilmemelidir. Yine de temel prensip değişmez: belirsizliği azalt, sorumluluğu netleştir, doğrulamayı ölçülebilir hale getir. Canlıya geçiş gecesinin rahat geçmesini istiyorsanız, hazırlık masasında daha fazla düşünmek gerekir.