Mevcut VPS sunucusunu taşımadan önce hangi bilgiler hazırlanmalı?

VPS taşıma öncesinde hangi bilgiler hazırlanmalı?

VPS sunucusunu taşımadan önce işletim sistemi, uygulamalar, veri miktarı, ağ bağlantıları, alan adları, lisanslar ve yönetici erişimleri envantere alınmalıdır. Hedef ortamın bu ihtiyaçları karşılayabildiği doğrulanmalı; geçiş zamanı, veri güncelleme yöntemi, kabul kontrolleri ve geri dönüş kararı belirlenmelidir. Yalnız işlemci ve bellek miktarını aynı seçmek, uygulamanın yeni ortamda aynı şekilde çalışacağını göstermez.

Bu rehber, mevcut sunucusunu başka bir ortama taşımak isteyen işletmelerin teklif ve proje hazırlığına odaklanır. Canlı sisteme uygulanacak evrensel bir komut listesi sunmaz. Her uygulamanın bağımlılıkları farklı olabileceği için teknik inceleme gerekir. Amaç, taşıma gününde eksik bilgi aramak yerine çalışma başlamadan önce karar ve sorumlulukları belirlemektir.

Sunucunun üzerinde çalışan bütün işleri listeleyin

Sunucuda yalnızca bir web sitesi bulunduğunu düşünebilirsiniz; ancak arka planda zamanlanmış görevler, dosya aktarımları veya rapor üretimi çalışıyor olabilir. Uygulama geliştiricisinden ve mevcut sistem sorumlusundan çalışan servisleri açıklamasını isteyin. Sunucunun hangi dış hizmetlere bağlandığını da öğrenin. Bu bağlantılar, yeni IP veya yeni ortamla birlikte farklı ayar gerektirebilir.

Envanterde uygulama adı, teknik sorumlu, gerekli çalışma bileşenleri ve iş açısından önemi bulunsun. Bilinmeyen bir servis varsa bunu tespit edilmesi gereken konu olarak işaretleyin. Mevcut ortamın yalnızca ana ekranına bakarak bütün işlerin görüldüğü varsayılmamalıdır. Taşıma kapsamı, sistemdeki gerçek bağımlılıklar anlaşıldıkça kesinleştirilir.

İşletim sistemi ve sürüm uygunluğunu kontrol edin

Kaynak sunucunun işletim sistemi ve uygulama bileşenlerinin sürümleri kaydedilmelidir. Hedef ortamda aynı sürümün desteklenip desteklenmediği ayrıca incelenir. Eski bir uygulamanın yeni ortamda doğrudan çalışacağı varsayılmamalıdır. Taşıma projesiyle kapsamlı sürüm yükseltmesi aynı çalışma olmayabilir; gerekiyorsa bu iki iş ayrı planlanmalıdır.

Lisans ve aktivasyon koşullarını da başlangıçta sorun. Sunucu taşındığında farklı lisans yöntemi veya yeniden etkinleştirme gerekebilir. Hangi ürünün hangi kapsamda kullanılabileceği üretici ve sağlayıcı koşulları üzerinden doğrulanmalıdır. Teknik ekipten uygulama lisansını tahmin etmesini beklemek yerine, mevcut sözleşme ve kullanım bilgilerini yetkili kişilerle paylaşın.

Veri miktarı kadar değişim hızını da öğrenin

Diskte bulunan toplam veriyi bilmek yararlıdır; fakat taşıma sırasında hangi verinin değişmeye devam ettiğini anlamak da gerekir. Statik dosyalarla aktif işlemler alan bir veritabanı farklı hazırlık gerektirir. Sipariş, muhasebe veya kullanıcı işlemlerinin sürdüğü bir uygulamada eski ve yeni ortam arasındaki veri farkının nasıl yönetileceği belirlenmelidir.

Mevcut veri miktarını, büyüme düzenini ve uygulamanın yoğun çalıştığı saatleri yazın. Son eşitleme veya kabul sırasında işlemlerin durdurulup durdurulmayacağı teknik incelemeye bağlıdır. Bütün projelerde aynı aktarım süresi veya aynı kesinti yaklaşımı kullanılamaz. İşletmenin kabul edebileceği zaman aralığı açık olduğunda teknik plan daha gerçekçi hazırlanabilir.

Kaynak ölçümlerini ve yönetim beklentinizi paylaşın

CPU, RAM ve depolama kullanımına ilişkin mevcut ölçümler varsa bunları paylaşın. Yalnız satın alınmış kapasiteyi bilmek, gerçekten hangi kaynağın kullanıldığını açıklamayabilir. Uygulamanın yavaşladığı dönemler veya belirli görevlerde oluşan yoğunluklar değerlendirmeye yardımcı olur. Ölçüm bulunmuyorsa hangi verinin toplanması gerektiği başlangıç incelemesinde belirlenebilir.

Red Hat'in sanallaştırma açıklaması, sanal makinenin kaynaklarının fiziksel altyapıdan düzenlendiğini anlatır. Bunun satın alma açısından karşılığı, sadece VPS adını değil teslim edilen kaynak ve kullanım koşullarını incelemektir. Hedef sunucuda yönetim desteği isteniyorsa işletim sistemi, uygulama ve veri sorumlulukları da ayrıca yazılmalıdır.

IP adresi ve dış bağlantı bağımlılıklarını ayırın

Bazı uygulamalar yalnızca belirli IP adreslerinden gelen bağlantıları kabul eder. Dış servislerde izin listesi, şirket içindeki firewall kuralları veya karşı sistem bağlantıları bulunabilir. Yeni sunucunun IP düzeni değiştiğinde bu bağımlılıklar da kontrol edilmelidir. Gerekli değişiklikleri kimin yapacağı, hangi erişimlerin gerektiği ve karşı tarafın çalışma saatleri proje planına eklenmelidir.

Alan adı ve DNS yönetiminin kimde olduğunu öğrenin. Web sitesi, uygulama ve e-posta kayıtları aynı panelde bulunabilir; bu durum hepsinin aynı anda değiştirileceği anlamına gelmez. Hangi kaydın hangi amaçla düzenleneceği belirlenmelidir. Geçiş sırasında ilgisiz bir hizmetin ayarını değiştirmek yerine, etkilenen bağlantılar üzerinden kontrollü ilerlenmelidir.

Yedekleme ile taşıma kopyasını birbirine karıştırmayın

Taşıma için alınan bir kopya, işletmenin devam eden yedekleme planının yerine geçmez. Çalışma öncesi hangi verilerin korunacağı ve gerektiğinde nasıl geri alınacağı belirlenmelidir. Kopyanın nerede tutulduğu, erişimin kimde olduğu ve geri yüklemenin hangi kapsamda denendiği sorulmalıdır. Sunucuya erişimin bulunması tek başına yeterli kurtarma hazırlığı değildir.

Veritabanı kullanan uygulamalarda dosyaların yanında verinin tutarlılığı da değerlendirilir. Teknik ekibin uygulama sorumlusuyla birlikte çalışması gerekebilir. Yedekleme sıklığı ve saklama süresi için her işletmeye aynı öneri verilmemelidir. Beklenen veri kaybı ve kesinti toleransı iş tarafından açıklanmalı; uygun yöntem bu ihtiyaca göre seçilmelidir.

Test ortamında kabul edilecek işlevleri belirleyin

Yeni sunucunun açılması, taşımanın tamamlandığını göstermeye yetmez. Uygulama oturumu, veri okuma ve yazma, dosya işlemleri, zamanlanmış görevler ve dış servis bağlantıları ayrı kontroller olabilir. Bunların hangilerinin projeye dahil olduğu önceden belirlenmelidir. Kullanıcı kabulünü yapacak kişilerin çalışma zamanı da planın parçasıdır.

Örneğin iş uygulamasında örnek bir kaydın oluşturulması ve ilgili raporda görünmesi test edilebilir. Bu yalnız bir kabul senaryosu örneğidir; bütün uygulamalarda aynı işlem uygulanmaz. Testin gerçek müşteriye bildirim veya sipariş üretmesi gibi yan etkileri varsa bunlar kontrol edilmelidir. Kabul, rastgele sayfa gezmekten daha belirli bir işlem listesine dayanmalıdır.

Geçiş penceresi ve geri dönüş kararı

İşletmenin yoğun çalışma dönemi, vardiya düzeni ve kritik kapanış tarihleri teknik ekiple paylaşılmalıdır. Taşımanın yalnız sağlayıcının uygun olduğu saate göre planlanması yeterli değildir. Kullanıcı bilgilendirmesi, işlem dondurma ihtiyacı ve destek iletişim kanalı önceden belirlenmelidir. Geçiş sırasında müşteri tarafında karar verecek kişi erişilebilir olmalıdır.

Beklenmedik sonuçta hangi koşulda durulacağı ve geri dönüşe kimin onay vereceği yazılmalıdır. Eski ortama dönmek, o sırada yeni ortamda oluşan veriyi de değerlendirmeyi gerektirebilir. Bu nedenle geri dönüş yalnız bir DNS kaydını değiştirmek olarak anlatılmamalıdır. Plan, uygulama ve veri davranışına göre teknik ekip tarafından hazırlanmalıdır.

Teslim sonrası hangi bilgiler alınmalı?

Yeni ortamın erişim ve sorumluluk bilgileri şirkete teslim edilmelidir. Uygulanan değişikliklerin özeti, tamamlanan kontroller ve açık kalan işler kaydedilmelidir. Eski sunucunun ne zaman kapatılacağı da belirli olmalıdır. Kabul tamamlanmadan veya gerekli veri korunmadan eski hizmetin sonlandırılması istenmemelidir.

İlk dönem desteğinin hangi olayları kapsadığını öğrenin. Taşıma sırasında oluşan eksikle daha sonra istenen yeni özellik aynı iş değildir. Güncelleme, izleme ve devam eden bakım hizmeti alınacaksa bunların sorumlusu ayrıca belirlenmelidir. Teknik devir tamamlandığında şirket, hangi sistem için kime başvuracağını anlayabilmelidir.

Devir erişimlerini ve ekipler arası iletişimi planlayın

Kaynak sağlayıcı, hedef sağlayıcı ve uygulama geliştiricisi farklı taraflar olabilir. Hangi bilgiyi kimin sağlayacağı ve geçiş sırasında kimin karar vereceği yazılmalıdır. Bir ekibin başka bir ekipten yetki beklediği durumlar çalışma takvimini etkileyebilir. Bu nedenle iletişim kişileri, erişilebilir zamanlar ve onay sırası hazırlık dosyasının parçası olmalıdır. Tek bir kişinin bütün teknik ayrıntıları bilmesi şart değildir; doğru kişilere ulaşılabilmesi gerekir.

Erişim devrinde yetkilerin iş için gereken sınırda verilmesi ve işlem sonrasında gözden geçirilmesi planlanabilir. Yönetici parolalarını herkese açık bir mesajda toplamak yerine uygun paylaşım yöntemi belirlenmelidir. Eski sağlayıcıdaki erişimin kapatılması da veri ve kabul kontrolleriyle birlikte değerlendirilir. Başlangıçta hangi erişimin kime ait olduğunun bilinmesi, proje sonunda gereksiz yetkilerin unutulmasını azaltır.

Teslim görüşmesinde yalnız yeni sunucuyu değil, ekiplerin sorumluluklarını da doğrulayın. Bir hata oluştuğunda kimin ilk incelemeyi yapacağı ve uygulama geliştiricisine hangi bulguyla dönüleceği belirli olmalıdır. Bu düzen, taşıma tamamlandıktan sonra ortaya çıkan her sorunun belirsiz biçimde taraflar arasında dolaşmasını önlemeye yardımcı olur.

VPS taşıma teklifi için hazırlayabileceğiniz dosya

Sunucu ve uygulama envanteri, yaklaşık veri miktarı, kaynak ölçümleri, alan adları, dış bağlantılar ve hedef çalışma takvimi başlangıç dosyanızı oluşturabilir. Eksik bilgiler için “bilinmiyor” yazmanız, hatalı bir varsayımdan daha yararlıdır. Sağlayıcıdan hangi konuların ön incelemede doğrulanacağını ve fiyatın hangi kapsam üzerinden hesaplandığını açıklamasını isteyin.

İz Medya VPS sunucu kiralama hizmeti, kendi bulut ortamında talebe özel değerlendirilir. Taşıma yanında günlük işletim desteği gerekiyorsa sunucu yönetim kapsamını da belirtin. İlk iletişimde parola paylaşmadan mevcut sisteminizi anlatabilirsiniz. İnceleme yöntemi, aktarılacak işler ve teslim kontrolü netleştiğinde yazılı kapsam ve teklif hazırlanır.

Sık Sorulan Sorular