Hosting Sözleşmesindeki 5 Madde: Net Kontrol Rehberi

Doğru hosting sağlayıcısını seçmek, sadece fiyat ve teknik özelliklere bakmakla bitmiyor. Asıl farkı çoğu zaman sözleşmedeki maddeler yaratır: sorun yaşandığında kimin neyi yapacağı, hangi şartlarda kesinti olacağı ve verinizin nasıl korunacağı. Bu rehberde, hosting satın alırken sözleşmede mutlaka kontrol etmeniz gereken 5 maddeyi net bir kontrol listesine dönüştürüyorum. Sonunda, her maddeyi karşılaştırırken sağlayıcıdan isteyebileceğiniz somut kanıtları da göreceksiniz.

1) Hizmet kapsamı ve kaynak tanımı (kapsam + “adil kullanım”)

Sözleşmenin ilk kritik kısmı, hizmetin kapsamını ve sunucunun kaynaklarının nasıl tanımlandığını açık eder. Bu madde belirsiz kaldığında, “bizde sorun yoktu” tartışmasına girersiniz.

Ne aramalısınız?

“Kullanım hakkı” veya “adil kullanım” (fair usage policy) varsa hangi durumda uygulanacağı
CPU/RAM/IO (disk I/O) gibi kaynakların paylaşım mantığı: “garanti mi, bursting mi”
Bant genişliği için “sınırsız” deniyorsa bunun gerçekte ne anlama geldiği
Ölçüm metodolojisi: Trafik, bağlantı sayısı, istek oranı (requests per second) nasıl ölçülüyor?

Kontrol için pratik test soruları

Sağlayıcıya şu soruların yanıtını yazılı isteyin: - “Paylaşımlı veya VDS/VPS için CPU/RAM garantisi var mı? Bursting varsa sınır nedir?” - “Bant genişliği ‘sınırsız’ ise aylık eşiği kaç GB/kaç TB? Aşıldığında hız düşürme veya kota uygulanıyor mu?” - “Disk performansı için minimum IOPS/throughput taahhüdü var mı? Yoksa ‘best effort’ mi?”

Karşılaştırma ipucu (kısa rehber)

Aşağıdaki ifadeler, belirsizliği artırır: - “Sınırsız” (yanında net eşik yoksa) - “Best effort” (kritik uygulamalar için) - “Kaynaklar makul ölçüdedir” (sayısal karşılık yoksa)

2) SLA (Service Level Agreement) ve kesinti tanımı

SLA, pratikte “ne kadar kesinti olursa sorun sayılır ve nasıl telafi edilir?” sorusunun cevabıdır. SLA yoksa veya sadece iyi niyet metnine dönüşmüşse, sorun çıktığında hesabı siz ödersiniz.

Ne aramalısınız?

Sözleşme veya ekinde şunlar net yazmalı: - Aylık uygunluk (uptime) hedefi: örn. %99.9 - Ölçüm başlangıç/bitiş yöntemleri: Panel logları mı, sağlayıcı izleme mi? - “Planlı bakım”ın kesintiye nasıl dahil edildiği - DDoS/liṅk arızası/üçüncü taraf gibi istisnalar - SLA ihlali durumunda tazmin (service credit) olup olmadığı

Somut örnek: Telafi nasıl olmalı?

Sadece “tazmin edebiliriz” yazıyorsa pazarlık şansı düşer. Şöyle bir metin hedefleyin: - “SLA ihlali halinde hizmet kredisi X oranında uygulanır.” - Hizmet kredisi dışında ek adım: örn. ayarlama, süre uzatımı, destek önceliği.

Kontrol için kısa tablo

Aşağıdaki karşılaştırma, SLA kalitesini hızlı görmenizi sağlar:

Sözleşme/ek içerik	İyi işaret	Dikkat işareti
Uptime hedefi ve ölçüm yöntemi net	Uptime %99.9 gibi sayısal değer var	“Makul sürelerde” ifadesi var
Planlı bakım bildirimi şartı var	En az X saat önceden bildirim	Önceden bildirim yok
DDoS/istisna kapsamı sınırlı	“Sıradan saldırılar” ayrımı var	İstisnalar geniş ve belirsiz
SLA ihlalinde otomatik kredi	Hangi oranda kesinti kredisi net	“İncelemeye tabi” ve belirsiz

3) Veri güvenliği, yedekleme (backup) ve veri iadesi

Hosting sözleşmesinde en sık gözden kaçan madde budur: Yedekleme var mı, ne sıklıkta, nereye alınıyor ve abonelik bitince veriniz nasıl geri veriliyor?

Ne aramalısınız?

Şunlar net olmalı: - Yedekleme türü: dosya (files), veritabanı (DB), anlık görüntü (snapshot) - Frekans: günlük/saatlik - Saklama süresi: kaç gün/kaç hafta - Geri dönüş (restore) süresi hedefi - Kapsam: hangi içerikler yedekleniyor? (sadece web kökü mü, tam sistem mi?) - Abonelik iptalinde veri iadesi: panel export, indirme, teslim formatı

Sözleşmede arayacağınız kritik kelime çiftleri

“Yedekleme yapılır” yerine: “Yedek (backup) alınır ve restore edilebilir.”
“Sorumluluk müşteridedir” yerine: “Yedeklerin saklama süresi ve geri yükleme yöntemi tanımlıdır.”

Net kontrol listesi (restore kısmı)

Yalnızca yedek olduğuna güvenmeyin. Şu soruları isteyin: - “Yedek geri yükleme talebi kaç saat içinde işlenir?” - “Restore sırasında oluşabilecek veri kaybı için SLA veya hedef süre var mı?” - “Yedekler sadece sağlayıcı tarafında mı, yoksa müşteriye export imkanı var mı?”

4) İptal, askıya alma (suspension) ve limit aşımı prosedürü

Birçok kullanıcı yalnızca “parayı ödeyince hizmet alırım” yaklaşımıyla hareket eder. Oysa sözleşmeler, belirli şartlarda askıya alma ve otomatik kısıtlama mekanizmaları içerir. Bu madde net değilse, kritik anlarda erişimi kaybedebilirsiniz.

Ne aramalısınız?

Limit aşımı türleri: CPU yoğunluğu, bağlantı sayısı, bant genişliği, disk kullanım eşiği
Askıya alma adımı: uyarı var mı, kaç saat/dakika sonra aksiyon geliyor?
İletişim kanalı: bildirim e-postası, panel uyarısı, bilet sistemi
İtiraz/itiraz süreci: itiraz ettikten sonra hizmet tekrar açılıyor mu?
“Kötüye kullanım” tanımı: spam, brute force, anormal trafik gibi durumlar hangi ölçüte göre değerlendiriliyor?

Karşılaştırma için pratik şablon

Sağlayıcıdan şu formatta net yanıt isteyin: - “Limit aşımında önce uyarı gönderilir (X saat). Uyarıdan sonra otomatik throttle olur (Y). Hala devam ederse askıya alma uygulanır (Z).”

Bu şema netse, kesinti yönetilebilir olur.

5) Fesih (termination), ücret iadesi ve sorumluluk sınırları

Sözleşmenin en “hassas” bölümü genellikle ücret iadesi ve sorumluluk maddeleridir. Burada amaç, sorun çıktığında nasıl bir finansal denge kurulduğunu görmek ve “her şey tamamen müşterinin sorumluluğunda” tuzağını fark etmektir.

Ne aramalısınız?

Fesih bildirim süresi: kaç gün önce haber verilmeli?
İade politikası: kurulum ücreti, aylık ücret, indirimli kampanya bedeli iade ediliyor mu?
Orantılı iade (pro-rata) var mı?
Sözleşme ihlali olunca sağlayıcının kesme hakkı ne zaman devreye girer?
Sorumluluk sınırı (limitation of liability): Sağlayıcı hangi zarar türlerinden sorumlu değil? (ör. kâr kaybı, dolaylı zarar)
Uygulanabilir ceza/geri ödeme: servis kredisi dışında bir karşılık var mı?

Somut kıyas: Sözleşme dili nasıl okunur?

Aşağıdaki örüntüler farklı risk seviyeleri yaratır: - “Ödemeler iade edilmez” + “hizmet kapsamı belirsiz” kombinasyonu: risk artar. - “Orantılı iade var” + “fesih ön bildirimi net” kombinasyonu: plan yapmayı kolaylaştırır.

Kontrol için kısa liste

Sözleşmeyi imzalamadan önce şunları not alın: - Ücret iadesi var mı? Varsa hangi durumlarda? - Fesihte veri nasıl teslim ediliyor? Export/indirme yöntemi var mı? - Sağlayıcının sorumluluk sınırı ne kadar geniş? (özellikle veri kaybı iddialarında)

Tüm maddeleri aynı sayfada değerlendirme: 10 dakikalık puanlama

Beş maddeyi okuduktan sonra tek bir karar tablosu yapın. Aşağıdaki puanlama, sağlayıcılar arasında net fark görmenizi sağlar.

Puanlama tablosu

Her madde için 0-2 arası puan verin:
2: Sayısal ve ölçülebilir netlik
1: Kısmen net, ek/ekler gerekebilir
0: Belirsiz veya “takdir” ağırlıklı

Madde	0	1	2
Kaynak tanımı & kapsam	—	kısmi	sayısal ve ölçülebilir
SLA & kesinti	istisna çok	kısmi	sayısal + telafi net
Yedek & restore & iade	yok/bulanık	kısmi	frekans + restore hedefi net
Askıya alma & limit aşımı	belirsiz	süreç var	adım adım prosedür var
Fesih & iade & sorumluluk	riskli	kısmi	pro-rata/rota net + sınır makul

En azından toplamda 8/10 seviyesini hedefleyin. 6/10 altı puan alan sağlayıcılar, teknik olarak iyi olsalar bile operasyonel risk yaratır.

Sonuç: Aksiyon planı (hemen uygulayın)

Hosting sözleşmesini “metin okuma” gibi değil, operasyonel riski yönetme aracı gibi düşünün. Yukarıdaki 5 maddeyi sırayla kontrol edin; belirsiz kalan her noktada sağlayıcıdan yazılı yanıt talep edin. Kararınızı hızlandırmak için NetKıyas’ta aradığınız özelliklerle birlikte sözleşme eklerini (SLA, backup, suspension, termination) karşılaştırın. Son adım olarak da seçim yapmadan önce yedek (backup) ve fesih/restore süreçlerini netleştirin; böylece erişim kaybı veya veri iadesi konusunda sürpriz yaşamazsınız.