Hosting Sözleşmesinde 5 Kritik Madde: Seçimi Netleştirin

Giriş: Sözleşme, “hız” kadar belirleyicidir

Hosting satın almadan önce teknik özelliklere bakmak şart; fakat asıl risklerin önemli kısmı sözleşme maddelerinde saklıdır. Aynı CPU/RAM değerlerinde bile farklı sağlayıcılar, kesinti durumunda nasıl hareket edecekleri, iade süreci ve sorumluluk sınırları gibi konularda ayrışır. Bu rehberde hosting sağlayıcısı seçerken sözleşmedeki 5 kritik maddeyi nasıl okuyacağınızı, neyi netleştirmeniz gerektiğini ve örnek kontrol listesini bulacaksınız.

1) Hizmet Düzeyi Taahhüdü (SLA) ve kesinti tanımları

Sözleşmede “SLA var” ifadesi tek başına yeterli değildir. SLA metninde kesintinin nasıl ölçüldüğü ve hangi durumların kapsama girmediği netleşmelidir.

Kontrol etmeniz gereken alt başlıklar

• Uptime (erişilebilirlik) oranı: Örn. %99,9 gibi. Burada pratik karşılığı önemlidir. %99,9 uptime = aylık yaklaşık 43 dakika ölçülen kesinti riski.
• Ölçüm yöntemi: Sunucu erişilebilirliği nereden ölçülüyor? (sağlayıcının izleme noktası, müşterinin paneli, belirli IP aralığı vb.)
• Kapsam dışı durumlar: Bakım (maintenance), DDoS koruması, “hizmetin kötüye kullanımı”, üçüncü taraf altyapı arızaları, ağ sağlayıcı sorunları gibi maddeler genelde kapsam dışına alınır. Bu listeyi görünür şekilde okuyun.
• Mahsup/ceza koşulları: SLA ihlali olursa hizmet kesintisi telafisi nasıl veriliyor? İade mi, indirim mi, kredilendirme mi? Hangi koşulda hangi oran?

Hızla karar verdiren karşılaştırma noktası

Aynı uptime iddiasına sahip sağlayıcılar bile şu farkla ayrılır: - SLA ihlalinde otomatik telafi sunanlar - Telafiyi “talep şartı”na bağlayanlar - Telafiyi yalnızca belirli arıza türlerinde yapanlar

NetKıyas’ta VDS/VPS/Web Hosting kıyasında performans tablosu dışında, sözleşmede SLA’nın “ölçümü ve istisnaları” kısmına mutlaka bakın.

2) Band genişliği (trafik) ve adil kullanım politikası (AUP)

Bant genişliği genellikle “limitsiz” gibi pazarlansa da sözleşmede adil kullanım politikası (AUP) ve trafik limitleri yeniden tanımlanır. Bu maddeyi atlamak, ay sonunda sürpriz faturalara veya hız düşüşüne yol açabilir.

Sözleşmede arayın: şu ifadeler

• Transfer limitleri: Aylık GB/TB limit ve aşıma uygulanacak işlem
• Hız sınırlaması: “Aşımdan sonra 1 Mbps’e düşer” gibi net hız tanımları
• “Limitsiz” ifadesinin şartları: Sınırsız denirken “belirli kullanım profili” sınırı koyan sağlayıcılar
• Trafiğin türü: CDN kullanımı, yüklü istek (burst), bot trafiği, e-posta trafiği (varsa) ayrı kurallara tabi olabilir
• Paylaşımlı kaynaklar: Web hostingte komşu etki (noisy neighbor) politikası ve aşırı kullanım tespiti

Somut örnek: Ne tür şartlar risklidir?

Aşağıdaki kontrol, risk sinyalidir: - “Aşırı kullanım tespitinde otomatik hız kısıtlama veya plan yükseltme zorunluluğu” - “AUP’ye aykırılık tespiti sağlayıcının tek taraflı kararıyla yapılır”

Net risk, tek taraflı karar ve belirsiz ölçümle artar. Kullanım profili (ör. 301/302 ile sürekli tarama, yoğun API istekleri, yüksek bot oranı) belirli bir davranış döngüsüne sahipse AUP’yi erken inceleyin.

3) IP adresi, yönlendirme ve iade şartları

Özellikle VPS/VDS tarafında IP yönetimi, uygulamanın çalışması kadar operasyon maliyetini de etkiler.

Sözleşmede netleştirmeniz gerekenler

• Statik IP sağlanıyor mu? (özellikle SSL/whitelist/SFTP/kurumsal entegrasyonlar için)
• IP değişimi olursa iletişim/taşınma süresi: Sağlayıcı IP’yi değiştirdiğinde yeniden yapılandırma süresi var mı?
• Reverse DNS (rDNS) desteği: E-posta gönderimi, spam skorları ve bazı entegrasyonlar için kritik olabilir.
• Özel IP ücretleri: Ayrı ücret mi, kiralama mı, iade edilince ne olur?
• İptal/plan değişikliği sonrası IP’nin durumu: Kiralanan IP geri alınır mı, ne zaman askıya alınır?

Ne zaman IP maddesi kritik olur?

• WooCommerce/CRM entegrasyonu için IP whitelist kullanıyorsanız
• Kurumsal firewall kuralı IP bazında ise
• E-posta gönderimi (SMTP) tek IP ile güveniliyorsa

4) SLA dışı kesintiler, bakım penceresi ve olay yönetimi (incident)

Sözleşme sadece uptime oranı değil; aynı zamanda kesinti türlerini nasıl yöneteceğini de anlatır. Bakım penceresi, DDoS sürecinin kapsamı ve olay bildirimi (incident notification) bu bölümde görünür olur.

Bakım penceresi (maintenance window) maddesini okuyun

• Bildirim süresi: Bakım için kaç saat/dakika önce haber verilecek?
• Bakım türü: Planlı mı, plansız mı? Plansızlarda kapsam dışı mı?
• İşlem etkisi: Yeniden başlatma (reboot) gerekecek mi? IP değişimi olacak mı?

Olay yönetimi: “Ne zaman haber veriyorlar?”

• Kesinti olunca otomatik bildirim var mı? E-posta/teleticket/SMS
• İlerleme paylaşımı: Kayıt açıldıktan sonra status güncellemeleri hangi sıklıkla
• DDoS veya güvenlik olaylarında: Kapsam dışı mı sayılıyor? Hız kesme/filtreleme nasıl tanımlanıyor?

Pratik değerlendirme

Bir sağlayıcının iyi olması, yalnızca “kesinti olmaz” demesiyle anlaşılmaz. Aksine, kesinti olunca: - bildirim süreleri - durum güncellemeleri - bakımın planlanma şekli net yazılıysa operasyon planınız daha doğru olur.

5) Sorumluluk sınırı, veri güvenliği ve yedek (backup) yükümlülüğü

Hosting sözleşmelerinde en çok tartışma yaratan kısım “sorumluluk” bölümüdür. Bu bölümde veri kaybı, yedekleme ve geri yükleme (restore) koşulları net olmalıdır.

Aşağıdaki alt başlıkları sözleşmede arayın

• Yedekleme sıklığı: Otomatik yedek alınıyor mu? (günlük/saatlik gibi)
• Yedeklerin saklama süresi: 7 gün mü, 30 gün mü? Saklama süresi azsa veri geri dönüş planı zayıflar.
• Geri yükleme politikası: Restore işlemi kaç gün/kaç deneme? Ek ücret var mı?
• Yedekleme kapsamı: Sadece dosyalar mı, veritabanı (DB) da dahil mi, yapılandırmalar var mı?
• Şifreleme ve erişim: Yedekler şifreli mi? Erişim yetkisi kimlerde?
• Sorumluluk sınırı: Sağlayıcı hangi zarar türlerinde sorumlu değil? Örn. “kâr kaybı” gibi kalemler dışında, “doğrudan zararlar” bile sınırlanabiliyor.

En kritik fark: “Yedekleme var” değil, “geri yükleme erişilebilirliği”

Bazı sağlayıcılar “yedek alınır” der, fakat restore talebinde süreç zor ve ücretlidir. Bu yüzden şu iki soruyu sözleşmede net arayın: 1) Restore talebi teknik olarak ne kadar sürede sonuçlanır? 2) Restore, kullanıcı tarafında veri kaybı yaşandıktan sonra pratikte erişilebilir mi?

Kararınızı hızlandıran 1 sayfalık kontrol listesi

Aşağıdaki listeyi, sözleşme PDF’ini inceledikten sonra tek tek işaretleyin: - SLA uptime oranı ve ölçüm yöntemi açık mı? - SLA kapsam dışı durumlar sınırlı mı, yoksa geniş mi? - AUP ve trafik aşımı sonrası işlem net mi (hız düşürme/ek ücret/plan yükseltme)? - Statik IP, rDNS ve IP değişimi varsa süreç yazılı mı? - Bakım için bildirim süresi ve plansız bakım istisnası net mi? - Yedekleme sıklığı + saklama süresi + restore koşulları açık mı? - Sağlayıcının sorumluluk sınırı, veri kaybı senaryosunda pratikte sizi koruyor mu?

Hosting türüne göre sözleşme maddelerini önceliklendirme

Her madde her kullanıcı için aynı önemde değildir. Uygulamanıza göre öncelik sıralaması yapın.

Hangi hosting türünde hangi madde daha kritik?

Sık yapılan hata: Teknik tabloda iyi olup sözleşmede zayıf kalmak

Birçok kullanıcı CPU, RAM ve disk değerlerine bakıp sözleşmeyi hızlıca geçer. Oysa pratikte şu durumlar sözleşme yüzünden yaşanır: - SLA ihlalinde telafi yerine “talep koşulu” - AUP nedeniyle beklenmedik hız düşmesi - IP değişimlerinde whitelist/SSL sorunları - Bakım penceresinin dar ya da bildirimsiz olması - Yedek var ama restore sürecinin uzun/ücretli olması

Bu nedenle satın alma kararı “teknik özellik + sözleşme maddelerinin birlikte anlamı” ile netleşir.

Sonuç: Satın almadan önce sözleşmeyi 10 dakikada netleştirin

Hosting seçimini hızlandırmak için sözleşmeyi teknik özellik sayfasıyla birlikte düşünün. Önce SLA ve ölçüm, ardından AUP/bant genişliği, sonra IP ve yönlendirme, ardından bakım/incident yönetimi, en sonda da yedek ve sorumluluk kısmını kontrol edin. Bu 5 madde netleşince sağlayıcı karşılaştırması “sayıdan” çıkıp “risk yönetimine” dönüşür; böylece yanlış tercih ihtimali belirgin şekilde azalır. Karar vermeden önce emin olmadığınız maddeleri sağlayıcıya yazılı olarak sorun ve cevapları aynı sayfaya not edin.