Cloud migration’da “downtime sıfır” iddiası, her baytın anında taşındığı anlamına gelmez. Anlamı: kullanıcıya görünür kesinti olmadan (veya saniyeler mertebesinde kontrollü cutover ile) production’ı yeni altyapıya geçirmektir. Bu rehber, EuroVDC bulut sunucu / KVM hedefiyle blue-green, fazlı taşıma ve DNS cutover pratiklerini anlatır.
Hedef Sofya (AB) ise hem GDPR hem gecikme için Bulgaristan KVM VPS rehberine de bakın. Plan boyutu için KVM kiralama rehberi yardımcı olur. Burada odak: kesintiyi nasıl yöneteceğiniz.
“Sıfır downtime” gerçekte ne demek?
- Okuma ağırlıklı siteler: Eski ve yeni sunucu bir süre paralel; DNS veya load balancer yeniye kayar; yazma kısa bir dondurma penceresiyle senkronlanır.
- Yazma ağırlıklı uygulamalar: Kısa maintenance (dakikalar) veya replication lag’i kapatacak freeze şarttır; “hiçbir saniye yok” vaadi genelde pazarlamadır.
- Ölçüt: HTTP 5xx, başarısız ödeme ve “site yok” süresi — sizin SLA’nız bunları tanımlar.
Taşımadan önce envanter
- Uygulama stack’i (PHP, Node, Docker…), web sunucusu, reverse proxy.
- Veritabanı boyutu, motor (MySQL/PostgreSQL), replication var mı.
- Dosya depolama (uploads, media); object storage’a ayrılabilir mi.
- Cron, kuyruk, websocket, e-posta gönderimi.
- SSL sertifikaları, DNS TTL, bağımlı alt domainler.
- Gizli anahtarlar, .env, API anahtarları — repoda değil, hedefte hazır.
Envanter eksikse cutover günü sürpriz çıkar. Bir staging VM’de aynı imajı önce ayağa kaldırın.
Strateji A: Blue-green (paralel ortam)
Eski ortam “blue”, yeni EuroVDC cloud “green” olarak hazırlanır. Green’de uygulama + DB snapshot/replica çalışır; smoke test geçer; trafik green’e alınır. Sorun olursa DNS/LB tekrar blue’ya döner.
- Hedef planda VM açın (Sofya), OS ve güvenlik sertleştirme.
- Kodu deploy edin; config’i production sırlarına bağlayın.
- DB’yi replica veya son dump + binlog/WAL ile yaklaştırın.
- Green’de health check (login, sepet, kritik API).
- TTL’yi önceden düşürün; cutover’da A/AAAA veya LB backend değiştirin.
- 48 saat blue’yu kapatmayın (rollback).
Strateji B: Fazlı (phased) taşıma
Önce statik/CDN, sonra okuma replica, sonra yazma master. E-ticaret ve büyük DB’lerde riski böler. Her fazın geri alma adımı yazılı olmalı.
- Faz 1: Medya/object storage veya CDN origin güncellemesi.
- Faz 2: Okuma trafiğinin bir kısmı yeni app sunucusuna.
- Faz 3: DB promote / final sync + kısa yazma freeze.
- Faz 4: Eski sunucuyu monitoring’de tutup kapatma.
DNS, SSL ve cutover penceresi
TTL’yi cutover’dan 24–48 saat önce 300’e (veya daha aşağı) indirin. SSL’i yeni IP’de Let’s Encrypt veya mevcut sertifika ile önceden doğrulayın. Cutover’ı trafik düşükken (gece / pazar yerel saati) planlayın; ödeme sağlayıcı webhook’larını yeni IP allowlist’e ekleyin.
Domain EuroVDC’deyse domain sorgulama / panel DNS ile A kaydını güncellemek tek panelden yönetilir; harici registrar’da da aynı kayıt mantığı geçerlidir.
Veritabanı senkronu: pratik seçenekler
- Küçük DB (<5–10 GB): Bakım penceresinde dump/restore + uygulama dondurma.
- Orta/büyük: Replication kur, lag ≈ 0 olunca promote; kısa freeze.
- Dosya ağırlıklı: rsync --delete dry-run; cutover’da son delta.
Cutover sonrası integrity: satır sayıları, son sipariş ID, kritik cron’ların çalıştığı.
Sık yapılan migration hataları
- TTL düşürmeden cutover; saatlerce split-brain.
- Staging’de test etmeden production DNS çevirmek.
- Cron’ların hem eski hem yeni sunucuda çift çalışması (çift fatura / çift e-posta).
- Yalnızca dosyayı taşıyıp .env ve queue worker’ı unutmak.
- Rollback planı olmadan blue’yu hemen silmek.
- “Sıfır downtime” diye yazma freeze’i reddedip veri kaybı riski.
Örnek zaman çizelgesi (orta boy SaaS)
- T-7 gün: Envanter, hedef VM, staging prova.
- T-2 gün: TTL düşür, SSL hazır, replication başlat.
- T-0 (60–90 dk pencere): Freeze yazma → final sync → DNS/LB → smoke → freeze kaldır.
- T+2 gün: Metrikler stabilse blue’yu kapatma kararı.
EuroVDC tarafında pratik notlar
Sofya KVM’de root ile kendi reverse proxy’nizi (Nginx/Caddy) kurarsınız; panelden gelen IP’yi DNS’te kullanın. Aynı hesapta domain + SSL yönetmek cutover checklist’ini kısaltır. Taşıma günü destek için ticket açmak yerine önce staging smoke’u kaydedin (ekran görüntüsü + curl çıktısı); sorun ayrıştırması hızlanır.
Ödeme ve e-posta IP allowlist’lerini yeni sunucu IP’sine T-1 günde ekleyin. Cutover sonrası 24 saat 5xx ve kuyruk uzunluğunu izleyin; sessiz hatalar genelde cron ve webhook’ta çıkar, ana sayfada değil.
Sıkça sorulan sorular
Gerçekten downtime sıfır mümkün mü?
Okuma ağırlıklı sistemlerde kullanıcıya görünür kesinti çoğu zaman önlenebilir. Yoğun yazma ve tek master DB’de kısa, planlı bir freeze penceresi daha güvenlidir; “hiçbir saniye yok” iddiası genelde abartıdır.
EuroVDC’ye taşırken hedef nedir?
Tipik hedef Sofya’daki KVM bulut sunucudur: root, NVMe ve AB lokasyonu. Planı iş yüküne göre seçip staging’de aynı imajla prova edin.
Blue-green mi fazlı taşıma mı?
Küçük/orta uygulamalarda blue-green hızlıdır. Çok büyük DB veya çok bileşenli sistemlerde fazlı taşıma riski böler. İkisini birleştirmek de yaygındır (önce green hazırla, DB’yi fazlı senkronla).
DNS TTL ne zaman düşürülmeli?
Cutover’dan en az 24–48 saat önce. Aksi halde resolver’lar eski IP’yi uzun süre cache’ler; trafik iki sunucuya bölünür.
Rollback nasıl olur?
Eski (blue) ortamı en az 48 saat açık tutun. DNS/LB’yi geri alın; cutover sonrası yazılan veriyi blue’ya geri almak için senkron planınız önceden yazılı olmalı.
Migration sırasında e-posta ve cron ne olmalı?
Cutover anında cron’u tek tarafta çalışacak şekilde kilitleyin. SMTP/webhook IP allowlist’lerini yeni sunucuya ekleyin; aksi halde sessiz gönderim hataları oluşur.
Hemen planlayın
Hedef VM için Sofya planlarına bakın: Bulut Sunucu. Yoğun tek kiracı için fiziksel sunucu; lokasyon kararı için Sofya VPS rehberi.