VDS Satın Alırken Kontrol Etmeniz Gereken 10 Madde

VDS (Virtual Dedicated Server) satın almak, doğru seçilmediğinde hem maliyeti artırır hem de beklenen performansı geciktirir. Bu yazıda, bir VDS siparişinden önce sağlayıcıyı teknik olarak “doğrulamanıza” yarayacak 10 kontrol maddesini adım adım anlatıyorum. Her başlık altında hangi detayı nasıl ölçeceğinizi ve kararınıza nasıl etki edeceğini net şekilde bulacaksınız.

1) CPU modeli ve “garantili” çekirdek performansı

VDS’lerde en sık hata, yalnızca “kaç vCPU var” diye bakmaktır. Bazı sağlayıcılar aynı sayıda vCPU sunduğunu iddia eder ama CPU sınırlaması (CPU quota) veya oversubscription (kaynakların paylaşılması) nedeniyle gerçek performans farklılaşır.

Kontrol listesi

• Teklifte CPU modeli belirtiliyor mu? (ör. Intel Xeon / AMD EPYC)
• “Burst” veya “ortalama” performans gibi şartlar yazıyor mu?
• CPU türü ve kapasitesi için açıklama var mı: ör. dedicated CPU bekleniyorsa “paylaşımlı” ibaresi geçiyor mu?
• En az bir örnek performans metriği (iowait, idle CPU, CPU throttling) paylaşılıyor mu?

Net karar

CPU modeli ve kaynak politikası açık değilse, benchmark talep edin. En azından sipariş öncesi “benzer profilde VM/Node performansı” örneği istemek doğrudur.

2) RAM miktarı kadar “RAM sınırı” ve OOM davranışı

RAM miktarı tek başına yeterli değildir. Bazı sistemlerde ek limitler, ballooning ya da RAM overcommit uygulanır. Bu da yoğun trafik anında servis çökmesine yol açabilir.

Kontrol listesi

• RAM’in tamamı kullanıcıya tahsisli mi, yoksa garanti yok mu?
• OOM (Out of Memory) durumunda ne olur? Yeniden başlatma otomatik mi?
• Sistem çekirdeği (kernel) ve bant genişliği limitleri dokümante edilmiş mi?

Net karar

Özellikle PHP-FPM, Node.js, Elasticsearch gibi bellek hassas işlerde “OOM planı” olmayan VDS yerine, otomatik kurtarma ve net limit açıklaması olan seçeneği tercih edin.

3) Disk tipi: NVMe mi SSD mi? IOPS / latency beklentisi

VDS performansı çoğu zaman CPU’dan değil diskten etkilenir. Veritabanı (MySQL/MariaDB/PostgreSQL), yoğun log yazan uygulamalar veya cache olmayan senaryolarda disk gecikmesi belirleyicidir.

Kontrol listesi

• “SSD” ifadesi tek başına yeterli değil. NVMe mi, SATA SSD mi?
• IOPS/throughput değerleri belirtiliyor mu?
• Disk boyutu arttıkça performans aynı mı değişiyor mu?
• RAID seviyesi ve disk dayanıklılığı (ör. enterprise SSD) yazıyor mu?

Net karar

Veritabanı çalıştıracaksanız, teklif ekranında IOPS/latency bilgisi ve disk türü net olmalıdır. Belirsizlik, ileride “neden yavaşladı?” tartışmasına dönüşür.

4) Ağ (network) kalitesi: bant genişliği, oversubscription ve lokasyon

Ağ tarafı VDS’lerde gecikme (latency) ve paket kaybıyla doğrudan ölçülür. Türkiye’de kullanıcı kitlesi hedefleniyorsa lokasyon seçimi önemlidir; ama tek kriter bu değildir.

Kontrol listesi

• Sunucu lokasyonu (şehir/ülke) net mi?
• Çıkış trafiği (egress) limiti var mı? “Unlimited” iddiası varsa gerçek politika nedir?
• Oversubscription oranı veya network sınırlaması var mı?
• Ping/route testi yapılabiliyor mu? (Sipariş öncesi destekle doğrulatın.)

Net karar

Uzak lokasyonda VDS, CPU/RAM iyi olsa bile uygulama gecikmesini büyütür. Özellikle API, oyun, real-time veya SEO bot trafiğinde ağ performansı fark yaratır.

5) Yönetim yöntemi: kontrol panel + root erişimi dengesi

VDS’de yönetim şekli, hem kurulum süresini hem de güvenlik pratiklerini etkiler.

Kontrol listesi

• Root (SSH) erişimi var mı? Yetkiler nasıl tanımlanmış?
• Sağlayıcı “kontrol paneli” sunuyor mu? (örn. ISPManager, cPanel, Plesk) veya sadece temel panel mi?
• Panel kullanıyorsanız lisans dahil mi?
• Güvenli yönetim için rol bazlı erişim (RBAC) var mı?

Net karar

Kendi stack’inizi (Nginx/Apache, Docker, Kubernetes değilse bile konteyner) yönetecekseniz root erişim şarttır. Panel gerekli ise lisans ve yetkilerin net olması gerekir.

6) Yedekleme (backup) stratejisi: periyot, tutma süresi ve geri dönüş doğrulama

Yedekleme en kritik kalemdir çünkü “var” demek yetmez; geri yükleme (restore) süreci garanti edilmelidir.

Kontrol listesi

• Sağlayıcı otomatik yedekleme yapıyor mu?
• Sıklık nedir? (ör. 1 saat / günlük) ve hangi bileşenler yedekleniyor: disk imajı mı, sadece dosya mı?
• Tutma süresi kaç gün? (7/14/30)
• Restore işlemi ne kadar sürer? SLA var mı?
• Yedekler şifreli mi? (at-rest) Anahtar yönetimi kimde?

Net karar

“Backup var” yerine “backup restore edilir mi, dokümante edilmiş mi, şifreli mi” sorusunu net yanıtlayın. Mümkünse test restore isteyin.

7) SLA, kesinti bildirimi ve kaynak limitleri

SLA (Service Level Agreement) sadece pazarlama metni değil; ölçülebilir taahhüt içermelidir.

Kontrol listesi

• Uptime hedefi (ör. %99.9) açık mı?
• Planlı bakım için bildirim süresi var mı?
• Donanım arızasında yeniden kurulum/taşıma politikası nedir?
• Bant genişliği aşımında uygulanan kesme mi var, hız düşürme mi?

Net karar

Uptime taahhüdü yoksa veya kesinti tanımı belirsizse, kritik sistemlerde (ödeme altyapısı, üretim CRM) risk almış olursunuz.

8) Ölçekleme (scaling) ve yedek planıyla birlikte büyüme yolu

İş büyüdükçe VDS’in kaynakları yetmez. Sağlayıcının ölçekleme yaklaşımı “işi kesmeden yükseltme” üzerine kurulu olmalıdır.

Kontrol listesi

• CPU/RAM/disk artırımı panelden mi, ticket ile mi?
• Artış sonrası servis kesintisi oluyor mu? (live resize / downtime)
• Otomatik ölçekleme sunuluyor mu? (Auto-scaling) Sunuluyorsa hangi bileşene uygulanır?
• Yeni kapasiteye geçiş sonrası veri tutarlılığı nasıl sağlanıyor?

Net karar

İlk günden “büyüme planı” yoksa, daha sonra yükseltme sırasında saatlerce kesinti görebilirsiniz. Sipariş öncesi “resize sırasında downtime kaç dakika” bilgisini isteyin.

9) Güvenlik: DDoS yaklaşımı, firewall ve anahtar yönetimi

VDS güvenliği, sadece “Linux kurduk” ile bitmez. Sağlayıcının altyapı koruması ve sizin ayarlarınız birlikte çalışmalıdır.

Kontrol listesi

• Sağlayıcı katman 3/4 DDoS koruması sunuyor mu?
• İsteğe bağlı firewall var mı, yoksa sadece OS firewall mı?
• SSH için yetkisiz erişimi azaltan kontroller var mı? (örn. brute-force throttle)
• Veri taşınıyor mu: yedekler farklı ortamda mı, şifreli mi?
• Varsayılan parola yok; SSH key ile erişim destekleniyor mu?

Net karar

DDoS koruması metinle değil kapsama açıklamasıyla anlaşılır. “%100 korur” söylemi yerine, hangi seviyede hangi yaklaşım olduğu yazılmalıdır.

10) Teknik konumlandırma ve işletim sistemi uyumluluğu

Son kullanıcı için basit gibi görünen bu madde, pratikte kurulum süresini belirler. Ubuntu, Debian veya dağıtım seçimi kadar, çekirdek güncellemeleri ve sürüm uyumu da önemlidir.

Kontrol listesi

• Hangi işletim sistemleri hazır geliyor? Ubuntu/Debian/AlmaLinux/Rocky gibi.
• Kernel güncelleme politikası var mı? (kendi kernelinizi kullanacaksanız etki eder)
• Özel modüller gerekiyorsa destek var mı? (örn. WireGuard, eBPF gerektiren akışlar)
• Docker/Nginx kurulumunda kernel/overlay uyumsuzluğu çıkar mı?

Net karar

Kullandığınız yazılımın dokümantasyonundaki gereksinimleri baz alın. Örneğin belirli PHP sürümü, glibc veya kernel versiyonu gerekiyorsa dağıtım uyumu net olmalıdır.

Hızlı doğrulama: 10 maddeyi sipariş öncesi soruya çevirin

Aşağıdaki tabloyu sağlayıcıyla görüşmede kullanabilirsiniz. Amaç, “yanıtları yazılı alınca” karar vermektir.

Karar verirken en sık yapılan 3 hata

1. Sadece fiyat üzerinden seçim: Disk ve network parametreleri net değilse düşük maliyet “yavaşlık” olarak geri döner.
2. “Unlimited” bant genişliği ifadesine kör güven: Çıkış trafiğinde gerçek limit ve hız düşürme koşulu sorulmalıdır.
3. Backup var sanmak: Restore süresi, şifreleme ve tutma süresi netleşmeden “yedek” değeri oluşmaz.

Sonuç: 10 maddeyi tamamlayın, riskinizi düşürün

VDS satın alırken kontrol edeceğiniz 10 maddeyi tek tek yanıtlayın: CPU/RAM sınırları, disk tipi ve IOPS, ağ politikası ve lokasyon, root erişimi ve kontrol panel uyumu, yedekleme/restore doğruluğu, SLA ve ölçekleme süreci, güvenlik yaklaşımı ve işletim sistemi uyumu. Aksiyon olarak bugün sağlayıcılarla görüşmelerinizi bu listeye göre planlayın; yanıtları yazılı alın ve en az iki seçenek arasında aynı kriterlerle kıyaslayın. Bu şekilde, VDS’inizin “kâğıt üzerinde hızlı” değil, gerçekte kararlı çalışmasını garanti altına alırsınız.