Hosting değiştiriyoruz, site ne kadar kapalı kalacak? Kesintisiz sunucu taşıma planı

Sunucu ya da hosting değiştirirken ziyaretçinin gördüğü kesinti, DNS'in "yayılma süresinden" çok, geçişten önce verilmemiş üç karardan doğuyor: kaydın TTL değeri ne zaman düşürüldü, eski ve yeni sunucu aynı anda trafik aldığında veriyi hangisi yazar, sertifika ile e-posta kayıtları cutover anında yerinde mi. Bu üçü planlandığında ziyaretçiye yansıyan kesinti saniyelerle ölçülür. Planlanmadığında site açık görünmeye devam eder, ama siparişlerin bir kısmı eski sunucuda birikir ve bunu genelde geçiş gününde değil, iki gün sonra müşteri telefonuyla fark edersiniz.

"DNS yayılması" bir süreç değil, eski TTL'in sayacı

DNS değişikliği internete yayılmaz. Çözücüler ellerindeki cevabı TTL süresi dolana kadar kullanır, süre dolunca yeniden sorar. Yani geçiş hızını belirleyen şey yeni kayıt değil, siz kaydı değiştirmeden önce yayında olan TTL. A kaydınızın TTL'i 86400 ise, değişiklikten sonraki 24 saat boyunca bir kısım ziyaretçi eski IP'ye gitmeye devam eder ve bu süre boyunca hiçbir şey yapamazsınız. Bu yüzden TTL, geçiş planının ilk maddesi, son maddesi değil.

Google'ın URL değişmeden site taşıma rehberi TTL'i "birkaç saat gibi muhafazakâr düşük bir değere" ve "taşımadan en az bir hafta önce" indirmeyi öneriyor. Pratikte iki kademe iyi çalışıyor: bir hafta önce 3600 saniye, geçişten 48 saat önce 300 saniye. Düşürdüğünüz TTL'in de eski TTL kadar beklemesi gerektiğini unutmayın; dün 86400 ile yayınlanmış bir kaydı bugün 300'e çekmeniz, önbellekteki kopyayı bugün geçersiz kılmaz. Geçiş oturduktan sonra TTL'i eski değerine geri çıkarın, aksi halde otoriter DNS'iniz gereksiz sorgu yükü taşır ve DNS sağlayıcınızda bir aksama olduğunda tampon süreniz kalmaz.

Nameserver değiştirmek, A kaydı değiştirmekten çok daha yavaş

Yeni hosting sağlayıcısının ilk isteği genelde şu olur: alan adının nameserver'larını bize çevirin. Bu, geçişi kontrol edilebilir bir işten iki günlük bir belirsizliğe dönüştürür. Delegasyon kayıtlarının TTL'i sizin elinizde değil, üst bölgenin elindedir. Bugün a.gtld-servers.net sunucusuna sorulduğunda .com bölgesindeki NS kayıtları 172800 saniyelik, yani iki günlük TTL ile dönüyor. Siz bunu 300'e düşüremezsiniz.

Doğru sıra şu: DNS'i mevcut sağlayıcınızda bırakın, geçişte yalnızca A ve AAAA kayıtlarını değiştirin. Nameserver değişikliği gerçekten gerekiyorsa taşımadan haftalar önce, iki tarafta birebir aynı bölge dosyasıyla yapın ve iki sağlayıcıyı bir süre paralel tutun. Bir de yeni alt alan adları için negatif önbelleği hesaba katın: olmayan bir kayda gelen sorgunun "yok" cevabı da önbelleğe girer. RFC 2308 bu süre için "bir ila üç saatlik değerler iyi çalışıyor, bir günü aşan değerler sorunlu bulundu" diyor. Geçiş gününde oluşturduğunuz yeni.sirket.com kaydının birkaç saat boyunca bazı ağlarda görünmemesinin sebebi budur.

Trafiğiniz bir CDN ya da proxy arkasındaysa cutover artık DNS işi değil

Siteniz Cloudflare benzeri bir proxy üzerinden yayınlanıyorsa, ziyaretçinin çözdüğü adres sizin sunucunuzun IP'si değil, proxy'nin anycast adresi. Origin IP'sini değiştirmek bu durumda bir DNS değişikliği değil, bir yapılandırma değişikliği olur: ziyaretçinin önbelleğindeki kayıt aynı kalır, trafik saniyeler içinde yeni sunucuya düşer, hata görürseniz aynı hızla geri alırsınız. Cloudflare dokümantasyonu proxy'li kayıtlar için TTL'in sabit biçimde "Auto", yani 300 saniye olduğunu ve değiştirilemediğini söylüyor.

Bunun iki şartı var. Yeni sunucunun güvenlik duvarı proxy'nin IP aralıklarına izin vermeli, yoksa geçiş anında 5xx alırsınız. İkincisi, origin IP'si hâlâ doğrudan erişilebilir durumdaysa geçiş sırasında eski sunucuya doğrudan gelen trafiği kesmiş olmazsınız; proxy'yi atlayan istekleri engellemek ayrı bir iş.

Sertifikayı geçişten sonra değil, geçişten önce alın

Yeni sunucuda sertifika üretmenin en yaygın yolu olan HTTP-01 doğrulaması, alan adının o sunucuyu göstermesini şart koşar. Yani sıralama kilitlenir: sertifika için DNS'i çevirmeniz, DNS'i çevirmek için sertifikanın hazır olması gerekir. Çözüm DNS-01 doğrulaması. TXT kaydıyla doğrulama yaparak sertifikayı geçişten günler önce yeni sunucuya kurar, cutover'ı sertifikasız dakika geçirmeden yaparsınız.

Bu adımı atlamanın bedeli küçük değil. Sitenizde HSTS açıksa tarayıcı, sertifika hatasında kullanıcıya devam etme seçeneği sunmaz; RFC 6797 kullanıcı arayüzlerinin bu uyarıları tıklayıp geçilebilir hale getirmemesini açıkça ister. Yani "birkaç dakika sertifika uyarısı çıkar, sonra düzelir" senaryosu HSTS'li bir sitede tam kesinti demektir. İki kontrol daha: yeni sağlayıcı farklı bir sertifika otoritesi kullanıyorsa CAA kaydınız o otoriteye izin veriyor mu, ve yenileme otomasyonu yeni sunucuda gerçekten çalışıyor mu. Let's Encrypt, 10 Şubat 2027'de varsayılan sertifika ömrünü 64 güne indiriyor ve yenilemenin ömrün üçte ikisine denk gelecek şekilde tetiklenmesini öneriyor. Takvime gömülü eski yenileme betikleri taşıma sonrasında sessizce susar, bunu üç ay sonra öğrenirsiniz. Sertifika ömürlerindeki değişimi ayrıca ele almıştık.

Eski TTL penceresi boyunca iki sunucu da canlıdır

Geçişin asıl riski kesinti değil, bölünme. TTL süresi dolana kadar kullanıcıların bir kısmı eski sunucuya, bir kısmı yenisine düşer. İki sunucu da kendi veritabanına yazıyorsa elinizde iki farklı gerçeklik oluşur ve bunları sonradan birleştirmek, geçişi tekrar yapmaktan pahalıdır.

Çalışan üç yaklaşım var. En basiti, geçişten önce kısa bir yazma penceresi kapatmak: uygulamayı bakım kipine alın, son senkronu yapın, kaydı çevirin. İkincisi, eski sunucuyu uygulama olarak çalışır tutup veritabanını yeni tarafa alın; eski sunucu artık yeni veritabanına yazar, kimse veri kaybetmez. Üçüncüsü, eski sunucuyu cutover anında ters vekil sunucuya dönüştürüp tüm istekleri yeni adrese iletmek; önbelleğinde eski IP olan ziyaretçi farkında olmadan yeni sunucuya gider. Bu üçüncüsü, kontrolünüzdeki en temiz çözüm.

Hangisini seçerseniz seçin, eski sunucuda kapatılması gereken bir liste var: zamanlanmış görevler, kuyruk işçileri, e-posta gönderen betikler, webhook işleyicileri. İki sunucuda aynı anda çalışan bir fatura görevi faturayı iki kez keser, aynı hatırlatma e-postası müşteriye iki kez gider. Yüklenen dosyalar da aynı sorunun sessiz hali: ortak bir nesne depolaması yoksa geçiş penceresinde yüklenen dosyalar yanlış diskte kalır. Veritabanı tarafındaki şema ve senkron detayları için sıfır kesintili yayına alma ve eski sistemden veri taşıma yazılarındaki yaklaşım burada da geçerli.

E-posta hostingle birlikte taşınmaz, ayrıca taşınır

Web sunucusunu değiştirmek MX kaydınızı değiştirmez, ama posta kutularınız eski sağlayıcının sunucusundaysa hosting sözleşmesi bitince e-posta da biter. Geçiş planında e-postayı ayrı bir satır olarak tutun: posta kutuları nerede duracak, MX kaydı değişecek mi, eski kutulardaki arşiv nasıl taşınacak.

Uygulamanın gönderdiği e-postalar ayrı bir başlık. Yeni sunucudan gönderim yapacaksanız SPF kaydınız yeni IP'yi ya da yeni servis sağlayıcıyı içermeli, DKIM imzalama anahtarları yeni sunucuya taşınmalı ve seçici (selector) adları değişmemeli. Bu kayıtların mantığını SPF, DKIM ve DMARC yazısında ayrıntılı anlattık. Yeni ve geçmişi olmayan bir IP'den gönderime başlamanın teslim oranına etkisi de gerçek; parola sıfırlama ve sipariş e-postalarının birden spam kutusuna düşmesinin en sık sebeplerinden biri budur. İşlemsel e-posta tarafında bunu önlemenin yolu, gönderimi sunucudan bağımsız bir servis üzerinden yapmak.

Eski IP'niz sizin bilmediğiniz yerlerde kayıtlıdır

Taşımanın en çok sürpriz çıkaran kalemi bu. Yıllar içinde sunucunuzun IP adresi başka tarafların izin listelerine girmiş olur: bankanın sanal POS paneli, e-fatura entegratörü, kargo firmasının API'si, bir müşterinin kurumsal güvenlik duvarı, tedarikçinin SFTP sunucusu, iş ortağına kurulmuş VPN tüneli. Bu tarafların çoğunda IP güncellemesi bir form, bir onay ve bazen bir hafta demektir.

Geçiş tarihinden en az iki hafta önce dışarıya açılan ve dışarıdan gelen bağlantıların envanterini çıkarın. Sadece gelen trafiği değil, giden trafiği de yazın: sizin çağırdığınız servislerden hangileri kaynak IP'nize göre doğruluyor? Mümkünse geçiş öncesinde iki IP'yi birden izin listesine ekletin, böylece cutover sırasında kesişim penceresi oluşur. Dış servis kesintilerine dayanıklılık tarafındaki devre kesici ve yeniden deneme mantığı, bu kalemlerden biri gözden kaçtığında kesintinin sipariş kaybına dönüşmesini de engeller.

Geçiş günü: sıra, doğrulama ve geri dönüş penceresi

Geçiş günü doğaçlama kaldırmaz. Adımları önceden yazın, her adımın yanına kimin yapacağını ve başarı kriterini koyun. Çalışan bir sıralama şöyle: yedek ve anlık görüntü alın, eski sunucuda yazmayı durdurun, son veri senkronunu yapın, yeni sunucuyu hosts dosyası üzerinden gerçek alan adıyla test edin, A kaydını değiştirin, dış dünyadan doğrulayın, eski sunucuyu vekil moduna alın.

hosts dosyası testi burada en ucuz sigorta: DNS'e dokunmadan, kendi makinenizden alan adını yeni IP'ye yönlendirip giriş, ödeme, dosya yükleme, e-posta gönderimi ve arama gibi gerçek akışları koşarsınız. Geçiş sonrası doğrulama listesi de aynı şekilde önceden hazır olmalı. İzleme tarafında hata oranı ve yanıt süresi grafiklerine bakmıyorsanız geçişin başarılı olup olmadığını müşteri söyler; SLO ve hata bütçesi kurulumu olan ekipler bu kararı dakikalar içinde verebiliyor. Geri dönüş planınızın süresi de TTL'inize eşittir: 300 saniyelik TTL ile yanlış giden bir geçişten beş dakikada dönersiniz, yeter ki eski sunucu hâlâ ayakta ve verisi tutarlı olsun. Yedeklerin gerçekten geri dönebildiğini geçişten önce test edin, geçiş gününde değil.

Eski sunucuyu ne zaman kapatacağınızı log dosyası söyler

Taşıma, DNS kaydını değiştirdiğinizde bitmiyor. Google'ın rehberi eski sağlayıcıyı "ona giden trafik sıfırlanana kadar" açık tutmayı söylüyor ve bu iyi bir ölçüt: eski sunucunun erişim loglarını izleyin, günlerce süren bir kuyruk görürsünüz. Uzun TTL'i önbelleğinde tutan kurumsal çözücüler, elle hosts kaydı girmiş bir iş ortağı, eski IP'yi sabitlemiş bir entegrasyon. Log sıfırlanmadan sunucuyu kapatmak, bu trafiği sessizce düşürmek demek.

Aynı rehberin bir uyarısı daha var ve sık ihlal ediliyor: geçişten önce yeni sunucuya koyduğunuz geçici tarama engellerini kaldırın. Test ortamından kopyalanan bir robots.txt ya da sayfalarda unutulmuş noindex etiketi, taşımanın ertesi günü trafiğin düşmesinin en bilinen sebebi. Search Console doğrulama dosyanızın yeni kopyada bulunduğundan emin olun. Googlebot'un tarama hızında geçişten hemen sonra geçici bir düşüş görmek normal; birkaç gün içinde toparlar. URL yapısı da değişiyorsa iş büyür, o senaryoyu site yenileme ve taşımada SEO yazısında ayrıca ele aldık.

Bu hafta atılacak ilk adım

Üç şeyi bugün kontrol edebilirsiniz. Alan adınızın A kaydındaki mevcut TTL değerini öğrenin (dig +noall +answer sirket.com A bir saniye sürer), DNS'inizin nerede yönetildiğini ve nameserver'ların kimde olduğunu yazın, son olarak sunucunuzun IP adresinin kayıtlı olabileceği dış tarafların listesini çıkarın. Bu üç bilgi, geçişin bir akşam işi mi yoksa iki haftalık bir hazırlık mı olduğunu büyük ölçüde belirler.

Taşımayı yakında yapacaksanız mevcut DNS kayıtlarınızı, sertifika yönetiminizi ve dışarıya bağlanan entegrasyonların listesini çıkarıp bizimle paylaşın; geçiş planını adım sırası ve geri dönüş penceresiyle birlikte çıkaralım.