Fiziksel sunucu barındırma seçerken yalnızca işlemci, bellek veya disk kapasitesine bakmak yeterli değildir. Asıl karar, arıza anında kimin hangi işlemi yapacağı, işletim sistemi ve güvenlik güncellemelerini kimin yöneteceği, yedeklerin nerede tutulacağı ve erişim sınırlarının nasıl belirleneceği netleştiğinde verilir. Bu sorumluluklar yazılı olarak açıklanmıyorsa teknik olarak güçlü bir sunucu bile operasyonel risk oluşturabilir.
Fiziksel sunucu barındırma, bir sunucunun veri merkezinde çalıştırılması anlamına gelir; ancak barındırma ile yönetim aynı hizmeti ifade etmeyebilir. Sağlayıcı fiziksel alan, enerji, ağ bağlantısı ve donanım erişimi sunarken işletim sistemi, uygulamalar, kullanıcı hesapları ve güncellemeler müşterinin sorumluluğunda kalabilir. Bazı modellerde izleme, işletim sistemi yönetimi veya arıza müdahalesi ayrıca tanımlanır.
Bu nedenle teklif veya hizmet sözleşmesinde “yönetim dahil” gibi genel ifadeler yerine her katmanın karşılığını arayın. Donanım arızasında parça değişimini sağlayıcı yapıyor olabilir; fakat bozuk disk sonrasında işletim sisteminin yeniden kurulması, uygulama ayarlarının geri yüklenmesi veya verinin yedekten döndürülmesi farklı sorumluluklara ait olabilir.
Uygulama güncellemelerini ve güvenlik kontrollerini kendi ekibiniz yürütüyorsa, fiziksel erişim ve donanım müdahalesinin tanımlı olması önceliklidir. Buna karşılık ekipte sürekli sistem yönetimi kapasitesi yoksa, yalnızca güçlü donanım seçmek sorunu çözmez; yönetim kapsamı, müdahale yöntemi ve erişilebilir destek koşulları ayrıca değerlendirilmelidir. Yönetilen ve yönetilmeyen hizmet arasındaki farkın sağlayıcıya göre değişebileceğini unutmayın.
Donanım ve arıza müdahalesi: Disk, güç kaynağı veya bellek arızasında arızalı parçayı kimin teşhis edeceğini ve değiştireceğini öğrenin. Sunucunun tamamen durması halinde yalnızca parça değişimi mi yapılacak, yoksa açılış ve temel sağlık kontrolü de gerçekleştirilecek mi? Arıza giderildikten sonra uygulamanın çalışır duruma getirilmesi ayrıca sizin ekibinize bırakılıyorsa bunu planınıza dahil edin.
İşletim sistemi ve erişim: Yönetici erişiminin kimde bulunduğu, işletim sistemi kurulumunu kimin yaptığı ve güncellemeler öncesinde geri dönüş planının nasıl hazırlanacağı açık olmalıdır. Kendi ekibiniz değişiklik yapacaksa, sağlayıcının yalnızca fiziksel müdahale sunması yeterli olabilir. Kritik güncellemeleri sağlayıcının yapmasını bekliyorsanız, bu işlemin kapsamını ve onay akışını yazılı olarak isteyin.
Yedekleme ve geri dönüş: RAID, yedekleme değildir. RAID bazı disk arızalarında çalışmayı sürdürebilir; ancak yanlış silme, bozuk uygulama verisi veya fidye yazılımı gibi durumlarda ayrı ve geri döndürülebilir yedek gerekir. Yedeklerin kapsamını, saklama süresini, farklı bir konumda tutulup tutulmadığını ve geri yükleme sorumluluğunu kontrol edin. Sağlayıcı yedekleme seçeneği sunsa bile, geri yüklemenin neyi kapsadığını doğrulamadan bunu tam felaket kurtarma planı saymayın.
Ağ ve güvenlik: Dış erişim, güvenlik duvarı kuralları, saldırı bildirimleri ve IP değişikliği gibi konuların kim tarafından yönetileceğini ayırın. Sağlayıcının ağ seviyesindeki önlemleri, uygulamadaki zayıf parola veya güncel olmayan eklenti riskini ortadan kaldırmaz. İnternete açık bir yönetim arayüzünüz varsa erişimi sınırlama, çok faktörlü kimlik doğrulama ve düzenli güncelleme gibi kontroller yine işletim sorumluluğuna göre planlanmalıdır.
Sunucuda özel bir işletim sistemi kurulumu ve sık uygulama değişikliği gerekiyorsa, tam yönetim yerine kontrollü yönetici erişimi ve net bir donanım müdahale süreci daha uygun olabilir. Bu durumda karar zinciri şöyledir: değişiklikleri kendi ekibiniz yapabiliyorsa erişim ve kurtarma prosedürünü doğrulayın; ekip bu işlemleri düzenli yürütemiyorsa yönetim kapsamı ve bakım penceresi tanımlı bir model arayın.
Öte yandan kesinti sırasında kurum içi ekip müdahale edemiyorsa, yalnızca düşük maliyetli fiziksel alan ve ağ bağlantısına göre seçim yapmak uygun değildir. Sağlayıcı arızayı algılayıp fiziksel müdahale edebiliyor, fakat veriyi geri yüklemiyorsa yedeklerin geri dönüşünü sizin üstlenmeniz gerekir. Bu yük kabul edilemiyorsa, geri yükleme prosedürü ve sorumlusu açıkça tanımlanmış bir hizmet seçin; ancak uygulamanın kendi tutarlılık kontrollerini yine ayrıca planlayın.
Örneğin bir şirket, özel bir lisans sunucusunu fiziksel sunucuda çalıştırmak istesin. Donanım değişikliği sağlayıcıya, lisans yapılandırması ve işletim sistemi güncellemeleri şirkete ait olsun. Şirketin yöneticisi arızalı diski değiştirecek ekipmana erişemiyorsa donanım müdahalesi tanımlı bir hizmet gerekir; fakat disk değiştiğinde lisans sunucusunun otomatik olarak çalışacağı varsayılamaz. Bu nedenle seçim, donanım desteğinin yanında yapılandırma yedeği ve yeniden çalıştırma prosedürünü de içermelidir.
İlk kullanım öncesinde sağlayıcıdan tek sayfalık bir sorumluluk matrisi isteyin. Satırlara donanım arızası, işletim sistemi kurulumu, güvenlik güncellemesi, ağ kuralı değişikliği, yedek alma, geri yükleme ve acil erişim gibi işlemleri yazın; her satırda sorumlu tarafı, gerekli erişimi ve beklenen kanıtı belirtin. “Dahil” ifadesi tek başına yeterli değildir; işlemin hangi koşulda başlatılacağı ve tamamlandığının nasıl anlaşılacağı da belirtilmelidir.
Ardından küçük bir kabul senaryosu yürütün: yönetici erişiminin gerçekten çalıştığını, izleme bildirimlerinin hangi kanaldan geldiğini ve örnek bir yedekten dosya geri dönüşünün kapsamını doğrulayın. Uygun sonuç, yalnızca panele girebilmek değil; sorumlu kişinin, kayıt numarasının veya işlem çıktısının bulunabilmesidir. Bu kontrol hizmetin tüm arızaları çözeceğini kanıtlamaz, fakat belirsiz sorumlulukları erken görünür kılar.
İhtiyaçları ve hizmet kapsamlarını karşılaştırmak için fiziksel sunucu seçenekleri sayfasını inceleyebilirsiniz. Son karar öncesinde donanım özelliklerini bu sorumluluk matrisiyle birlikte değerlendirin; kapasite uygun olsa bile yedek, erişim veya müdahale sınırı belirsizse sağlayıcıdan yazılı açıklama almadan ilerlemeyin.
Copyright © 2026 Tüm Hakları Saklıdır.
