Saat 2 Sürprizi Olmadan Sunucu Taşıma Sürpriz
2 Eylül 2026 tarihinde yayımlandı
Bir sunucu taşıma işlemi, müşteriler yeni ortama hiç dokunmadan önce yeni ortamın zaten doğrulanmış olması durumunda en güvenli halini alır. Dosyaları kopyalamak işin yalnızca bir kısmıdır. Asıl iş, veri tutarlılığını, uygulama davranışını, e-posta teslimini, DNS kontrolünü, güvenlik kurallarını, zamanlanmış görevleri ve genellikle en uygunsuz saatte ortaya çıkan küçük yapılandırma ayrıntılarını korumaktır.
Bir işletme web sitesi, SaaS platformu, çevrimiçi mağaza veya ajans müşteri altyapısı için amaç sadece bir sunucuyu taşımak değildir. Amaç, temel altyapıyı kontrollü bir bakım penceresi, test edilmiş bir geri dönüş yolu ve ödeme, oturum açma veya veritabanı yazımları sırasında tatsız bir sürpriz olmadan değiştirmektir. Birinin neden sakin olmadığını sormasına gerek kalmadan önce hizmet yeniden sakinleşmiş olmalıdır.
Sunucu Taşımaya Eksiksiz Bir Envanterle Başlayın
Hedef sunucuyu hazırlamadan önce, mevcut sunucuda gerçekte nelerin çalıştığını belgelendirin. Bu, geçişten sonra ana web sitesinin çalıştığı ancak bir arka plan çalışanının, fatura e-posta hizmetinin veya unutulmuş bir müşteri alt alan adının çalışmadığı yaygın sorunu önler.
İşletim sistemi sürümünü, web sunucusu ile PHP veya çalışma zamanı sürümlerini, veritabanı motorunu ve sürümünü, uygulama bağımlılıklarını, SSL sertifikalarını, cron job'ları, güvenlik duvarı kurallarını, posta hizmetlerini, DNS kayıtlarını, depolama kullanımını ve etkin portları kaydedin. Konteynerleştirilmiş iş yükleri için compose dosyalarını, ortam değişkenlerini, volume'leri, imaj sürümlerini ve gizli bilgi yönetimini ekleyin. Sanal makineler için ağ ayarlarını ve bağlı disk bilgilerini kaydedin.
Ayrıca sunucu dışındaki her bağımlılığı da belirleyin. Örnekler arasında ödeme ağ geçitleri, işlemsel e-posta sağlayıcıları, nesne depolama, CDN ayarları, OAuth geri çağrıları, IP izin listeleri, üçüncü taraf API'ler ve lisans sunucuları yer alır. Genel IP adresindeki bir değişiklik bunların herhangi birini etkileyebilir. Bu, bazı ortamlarda en güzel DNS durumu olmayabilir, ancak yazıya döküldüğünde kontrol altındadır.
Envanter yalnızca teknik bileşenleri değil, iş önceliklerini de içermelidir. Bir mağaza bakım sırasında önbelleğe alınmış katalog sayfalarını gösterebilir, ancak envanter yazımları senkronize değilse siparişleri güvenle kabul edemez. Bir SaaS ürünü raporlama verilerinde kısa bir gecikmeyi tolere edebilir, ancak müşteri kimlik doğrulamasında edemez. Bu farklılıklar taşıma yöntemini belirler.
Doğru Taşıma Yöntemini Seçin
Tek bir doğru sunucu taşıma yaklaşımı yoktur. Doğru seçim, verinin ne sıklıkla değiştiğine, ne kadar kesintinin kabul edilebilir olduğuna ve mevcut yazılımın yeni platformda sorunsuz çalışıp çalışamayacağına bağlıdır.
Basit bir statik site genellikle çok az riskle kopyalanabilir, kontrol edilebilir ve yeni bir IP'ye yönlendirilebilir. Veritabanına sahip içerik yönetimli bir web sitesi, daha dikkatli bir veritabanı dışa aktarımı ve son senkronizasyon gerektirir. Etkin bir e-ticaret veritabanı veya çok kiracılı uygulama genellikle aşamalı bir geçiş gerektirir; burada dosyalar ve geçmiş veriler önce kopyalanır, ardından kısa bir yazma dondurması son veritabanı değişikliklerinin tutarlı şekilde taşınmasını sağlar.
Daha büyük sistemler için replikasyon, kurulum çabasına değebilir. Veritabanı replikasyonu, depolama senkronizasyonu ve blue-green deployment kalıpları son kesintiyi önemli ölçüde azaltabilir. Ancak bunlar operasyonel karmaşıklık da ekler, bu nedenle her küçük işletme için otomatik olarak en iyi yanıt değildir. Doğrulanmış bir yedekle birlikte temiz bir bakım penceresi, kimsenin test etmediği aşırı mühendislik ürünü bir süreçten çoğu zaman daha güvenlidir.
Mevcut sunucu eski bir işletim sistemi veya desteklenmeyen bir çalışma zamanı kullanıyorsa, bu taşıma işlemini doğrudan bir kopyalama yerine bir yükseltme projesi olarak ele alın. Eski paketler, kullanımdan kaldırılmış PHP işlevleri, veritabanı harmanlama değişiklikleri ve OpenSSL farklılıkları uygulama davranışını değiştirebilir. Bu sorunları DNS değişikliklerinden önce test etmek, müşteriler gelmeye başladıktan sonra fark etmekten çok daha ucuzdur.
Geçişten Önce Yeni Sunucuyu Hazırlayın
Hedefi, sadece sakin bir salı sabahına göre değil, gerçek iş yükü zirveleri için yeterli CPU, bellek, disk performansı ve ağ kapasitesiyle sağlayın. Mümkün olan yerlerde mevcut kaynak metriklerini gözden geçirin. Yüksek veritabanı I/O'su, bellek baskısı ve büyük yedekleme pencereleri, birebir aynı sunucu boyutunun çok küçük olabileceğine işaret eder.
Önce temel ortamı kurun: işletim sistemi güncellemeleri, SSH erişim kontrolleri, güvenlik duvarı kuralları, uygun olduğunda fail2ban veya eşdeğer koruma, izleme ajanları, yedekleme zamanlamaları ve en az ayrıcalık ilkesine sahip kullanıcı hesapları. Gerekli uygulama yığınını, iş yüküne karşı test edilmiş sürümlerle kurun.
Yeni sunucu, üretim trafiğini almadan önce izlemeye de sahip olmalıdır. CPU'yu, belleği, disk kullanımını, disk gecikmesini, ağ trafiğini, hizmet kullanılabilirliğini ve uygulama hatalarını izleyin. Daha teknik ekipler için Prometheus metriklerini Grafana'ya aktarmak, geçiş sırasında ve sonrasında faydalı görünürlük sağlar. Ping yanıtı veren bir sunucu mutlaka sağlıklı değildir. Sessizce veritabanı bağlantı havuzunun tükenmesini bekliyor olabilir.
Yedeklemeler özel dikkat gerektirir. Çalışma başlamadan önce kaynağın tam bir geri yüklenebilir yedeğini alın, ardından bunun geri yüklenebildiğini doğrulayın. Bir yedekleme dosyasının bir yerde mevcut olması cesaret vericidir, ancak bu henüz bir kurtarma planı değildir. Taşınan ortam üzerinde mutabık kalınan bir süre boyunca normal çalışana kadar bağımsız bir kopya saklayın.
Müşterileri Yeni Sunucuya Göndermeden Test Edin
Genel DNS değişikliklerinden önce yeni ortamı test etmek için geçici bir ana bilgisayar adı, hazırlık alt alan adı, özel ağ yolu veya yerel hosts dosyası geçersiz kılmasını kullanın. Bu, normal ziyaretçiler mevcut sunucuyu kullanmaya devam ederken ekibin hedef sunucuyu canlıymış gibi kontrol etmesini sağlar.
Para kazandıran veya operasyonların devam etmesini sağlayan kullanıcı yolculuklarını test edin. Bir e-ticaret sitesi için bu; ürün sayfaları, sepet işlemleri, ödeme, ödeme geri çağrıları, envanter güncellemeleri, hesap e-postaları ve sipariş yönetimi anlamına gelir. Bir SaaS uygulaması için oturum açmayı, parola sıfırlamaları, arka plan işlerini, dosya yüklemelerini, API endpoint'lerini, webhook'ları ve hesap düzeyi izinleri test edin.
Teknik davranışı da kontrol edin. Yönlendirmelerin doğru kaldığını, SSL sertifikalarının düzgün yüklendiğini, zamanlanmış görevlerin çalıştığını, giden e-postanın kimliği doğrulandığını, logların yazıldığını, önbelleklerin doğru temizlendiğini ve dosya sahipliğinin yüklemeleri veya güncellemeleri engellemediğini doğrulayın. Özellikle veritabanı ağırlıklı sayfalar için eski ve yeni sunucudaki yanıt sürelerini karşılaştırın.
Geri dönüş testini atlamayın. Kritik bir sorun ortaya çıkarsa trafiği kaynak sunucuya tam olarak nasıl geri döndüreceğinizi net olarak bilin. Bu, önceki DNS kaydını geri yüklemek, bir yük dengeleyici hedefini değiştirmek veya önceki uygulama ortamını salt okunur ama kullanılabilir durumda tutmak anlamına gelebilir. Geri dönüş, umut dolu bir ruh hali değil, belgelenmiş bir eylem olmalıdır.
DNS'i ve Son Veri Senkronizasyonunu Kontrol Edin
DNS, sunucu taşımanın genellikle görünen kısmıdır, ancak ilk değil son anahtar olmalıdır. Bölgeyi kontrol ediyorsanız DNS TTL değerlerini önceden, ideal olarak planlanan geçişten 24 ila 48 saat önce düşürün. Bu, çözümleyicilerin yeni adresi daha erken yenilemesine yardımcı olur, ancak bazı ağlar kayıtları yine de istenenden daha uzun süre tutabilir.
Geçişten hemen önce, uygulamanın izin verdiği yerlerde yazımları azaltın veya duraklatın. Siteyi bakım moduna alın, çalışanları duraklatın veya sipariş gönderimini geçici olarak devre dışı bırakın. Veritabanlarının, yüklenen dosyaların, kuyrukların ve değişen diğer verilerin son senkronizasyonunu gerçekleştirin. Ardından hedefte kayıt sayılarını, son işlemleri ve uygulama loglarını doğrulayın.
DNS'i veya trafik yönlendirme hedefini yalnızca son senkronizasyon tamamlandığında değiştirin. Yayılım sırasında eski sunucuyu çevrimiçi ve bozulmamış halde tutun. Bir referans noktası ve geri dönüş seçeneği olarak değerli olmaya devam eder. Ana sayfa tek bir ofis bağlantısından düzgün görünüyor diye onu hemen iptal etmeyin.
Geçişten sonra birden fazla ağdan test yapın ve logları izleyin. İsteklerin yeni sunucuya ulaştığını, arka plan işlerinin iki kez çalışmadığını, sertifikaların doğru sunulduğunu ve beklenmeyen 404, 500 veya izin hatalarının artmadığını doğrulayın. Özellikle e-postaya, webhook teslimine, ödeme bildirimlerine ve zamanlanmış süreçlere dikkat edin. Sessizce başarısız olma olasılığı en yüksek hizmetler bunlardır.
Taşıma Sonrasında İstikrarı Sağlayın
İlk 24 ila 72 saat hâlâ taşımanın bir parçasıdır. Daha yakın izleme sürdürün, kaynak kullanımını temel seviye ile karşılaştırın ve yavaş sorgulara, önbellek kaçırmalarına, depolama büyümesine ve uygulama istisnalarına dikkat edin. Yeni bir sunucu, eski kurulumun gizlediği kapasite veya yapılandırma sorunlarını ortaya çıkarabilir.
Trafik ve zamanlanmış işlemler kararlı hale geldiğinde, eğer düşürüldüyse DNS TTL değerlerini yeniden artırın. Yedeklemelerin yeni sistemden çalıştığını doğrulayın ve mümkün olan yerlerde pratik bir geri yükleme kontrolü gerçekleştirin. Belgeleri yeni IP adresleri, kimlik bilgileri, mimari notlar ve sağlayıcı izin listeleriyle güncelleyin.
Yönetilen altyapı desteği burada faydalıdır çünkü taşıma, dosyalar yeni bir diske ulaştığında bitmez. kodu.cloud'da operasyonel çalışma; sunucu hazırlığını, izlemeyi, yedekleme planlamasını ve geçiş penceresi sırasında yardımı içerebilir; böylece ekibiniz bir terminal istemi ve hızla soğuyan bir kahve fincanıyla baş başa kalmaz.
Dikkatli bir sunucu taşıması dramatik olmak zorunda değildir. Önce hedefi kurun, gerçek davranışı test edin, son veriyi bilinçli şekilde taşıyın ve loglar aynı hikâyeyi anlatana kadar bir geri dönüş rotasını koruyun. İşletmeyi ileri taşırken çalışma süresini böyle korursunuz.
Andres Saar Müşteri Hizmetleri Mühendisi