İçindekiler
Hosting şirketi seçimi, bir web projesinin hayatta kalma ve büyüme kapasitesini doğrudan belirler. Yanlış seçimlerin sonuçları görünenden çok daha derindir: müşteri kaybı, SEO düşüşü, veri kaybı, itibar zedelenmesi ve beklenmedik maliyetler olarak geri döner. Bu makale, en sık yapılan hataları sadece listelemekle kalmıyor; gerçek dünyadan örnekler, sayısal yaklaşımlar, karar matrisleri ve uygulanabilir kontrol listeleriyle “hangi senaryoda hangi altyapıyı seçmeliyim” sorusuna net cevaplar veriyor. Az başlık—derin analiz prensibiyle yazıldı: her H2 altında uygulamaya geçirilebilir, somut bilgi ve ölçülebilir kriterler bulacaksınız.
Hata 1 — İhtiyaç Analizi Yapmadan, “En Ucuz Paket”i Seçmek (Detaylı Maliyet ve Risk Analizi)
Çoğu kuruluş hosting firmasını seçerken sadece aylık ücret etrafında döner. Oysa hosting, maliyetin ötesinde operasyonel risk ve fırsat maliyetidir. Bir hesaplama örneğiyle başlayalım: e-ticaret sitesi günlük 2.000 ziyaretçi, ort. 1.5 sayfa/ziyaret, ort. yük 2 RPS (request per second) ve kritik satış anlarında ani %200 trafik patlaması bekleniyor. Bu senaryoda paylaşımlı ucuz paket (aylık 30–50 TL) ile karşılaşacağınız gerçek maliyetleri şöyle modelleyebilirsiniz:
- Performans kaybı: Sayfa yüklenme süresi 300ms’den 1.2s’ye çıkarsa dönüşüm oranında %7–12 düşüş beklenir. Aylık 10.000 ziyaretçi ve ort. 0,5% dönüşüm ile 50 siparişten 4–6 sipariş kaybı; bu satış başına ort. 500 TL ise aylık 2.000–3.000 TL kayıp.
- Seo maliyeti: Sürekli yüksek TTFB ve Core Web Vitals sorunları organik trafik kaybı yaratır. Bir anahtar kelimede ilk 10’dan çıkmanın geri dönüşü aylar hatta yıllar alabilir.
- Taşıma ve downtime maliyeti: Kesinti başına ort. 1–4 saat arası downtime; teknik destek gecikiyorsa günlük fırsat maliyeti büyür. Taşıma maliyeti (veri transfer, DNS, testler, üçüncü taraf entegrasyon testi) tek seferlik 3.000–10.000 TL aralığına rahat çıkabilir.
Bu hesap gösteriyor ki, aylık 30 TL tasarruf etmek, aylık gelirinize oranla çok daha büyük kayıplara neden olabilir. Doğru yaklaşım: ihtiyaçları nicel hale getirip (RPS, ort. sayfa büyüklüğü, beklenen maksimum trafik, veritabanı sorgu yoğunluğu, eşzamanlı kullanıcı sayısı) uygun sınıflandırmaya göre (paylaşımlı, VPS, bulut, dedicated) karar verin. Karar matrisinde aşağıdaki parametreleri ağırlıklandırın: performans (%30), güvenlik (%20), ölçeklenebilirlik (%20), destek kalitesi (%15), maliyet (%15).
Hata 2 — Sunucu Lokasyonu, Ağ ve Veri Merkezi Kalitesini Görmezden Gelmek
Sunucu lokasyonu ve veri merkezi kalitesi teknik ancak son derece pratik bir etkendir. Hedef kitleniz Türkiye ise Avrupa’da (ör. Almanya) veya ABD’de host edilmek düşük gecikme, mobil kullanıcı deneyimi ve lokal SEO açısından dezavantaj yaratır. Teknik etkileri sayısal olarak düşünün: 40ms vs 120ms ping farkı, TCP el sıkışma sürelerini uzatır; TLS el sıkışmaları ve paket kayıpları sayfa açılış sürelerini artırır. Özellikle mobilde 3G/4G kullanıcı deneyimi bozulur.
Değerlendirme kriterleri:
- Data center Tier seviyesi: Tier III+ tercih edin; çift besleme, N+1 yedekliliği, UPS ve jeneratör altyapısı olmalı.
- Peering ve transit: Veri merkezinin backbone sağlayıcıları (IXP, Tier1) ve BGP politikaları erişim performansını etkiler.
- DDoS koruması ve scrubbing: Özellikle yüksek riskli sektörler için otomatik DDoS mitigasyonu şarttır.
- Co-location vs cloud: Fiziksel kontrol mü yoksa ölçeklenebilirlik mi öncelikli? Co-location düşük gecikme ve kontrol sunar; bulut hızlı ölçeklenebilirlik sağlar.
Pratik kontrol: sağlayıcıdan traceroute ve peering bilgisi isteyin; latency map talep edin. Hedef kitlenize göre en yakın PoP (Point of Presence) ve CDN entegrasyonunu önceden planlayın.
Hata 3 — SLA, Destek ve Operasyonel Sözleşmeleri Detaylandırmamak
Birçok müşteri “%99.9 uptime” reklamını görüp sözleşme okumadan onay verir. Gerçekte SLA maddeleri sadece uptime yüzdesi değil, RTO/RPO (recovery time objective, recovery point objective), kredi hesaplama, destek tepki (response) ve çözüm (resolution) süreleri, bakım pencereleri ve istisnaları içermelidir.
SLA kontrol listesi (zorunlu maddeler):
- Uptime tanımı: Hangi seviyedeki arızalar uptime dışı sayılır? (network vs host vs uygulama)
- Tepki süreleri: Seviyelendirilmiş (Severity 1: 15dk response, 2: 1saat, 3: 24saat)
- Çözüm süreleri: Kritik problemler için hedeflenen maksimum çözüm süresi veya geçici çözüm sağlanma süresi
- SLA kredileri: Uptime altındaki süre için geri ödeme veya kredi mekanizması (örn. %99.9’dan düşükse aylık ücretin %10’u kadar kredi)
- Bakım bildirimleri: Planlı bakım penceresi ve kullanıcıya bildirim süresi (ör. en az 72 saat önceden)
- Taşıma ve veri çıkarma: Sözleşme feshi halinde veri taşıma süreci ve maliyeti
Destek değerlendirmesi için test edin: satın almadan önce ön satış destek taleplerine gerçek sorunlarla (ör. yüksek CPU kullanım senaryosu) ticket açın; yanıt süresi ve çözüm kalitesini ölçün. Telefon, canlı chat, 24/7 NOC ve Slack/Telegram gibi iletişim kanallarının mevcudiyeti avantajdır.
Hata 4 — Yedekleme, Felaket Kurtarma ve Veri Yönetişimini Hafife Almak
Yedekleme “var mı?” sorusu yeterli değildir; nasıl, nerede, hangi sıklıkta ve ne kadar zamanda geri yüklenebildiği kritiktir. Sık yapılan hatalar: tek lokasyonda yedekleme, günlük yedekleme ama uzun RTO, test edilmemiş geri yükleme süreçleri, yedeklerin bütünlüğünün doğrulanmaması.
En iyi uygulamalar:
- 3-2-1 prensibi: En az 3 kopya, 2 farklı medya, 1 kopya off-site
- Farklı coğrafi yedekleme: Primary veri merkezi + farklı bölgede (farklı ülke/PoP) yedek
- Snapshot vs tam yedek: Veritabanları için anlık snapshot + günlük tam yedek kombinasyonu
- Geri yükleme testi: Her 3 ayda bir veya sürüm değişikliklerinde test geri yükleme yapılmalı
- RPO/RTO hedefleri: Ticari iş ihtiyaçlarına göre örn. RPO = 15 dk, RTO = 1 saat gibi hedefleri sözleşmeye koyun
Örnek senaryo: bir ödeme sağlayıcısı günlük 1 milyon işlem yapıyor. Ödenmemiş RTO 2 saat ise, iş kaybı ve itibar riski çok yüksek; buraya uygun asgari RPO=0–15dk mimarisi gerekir: realtime replication, hot-standby ve otomatik failover gerektirir. Bu çözümler paylaşımlı hostingde mümkün değildir.
Hata 5 — Ölçeklenebilirlik ve Performans Mimarisi Planı Yapmamak
Başlangıçta küçük, sonra büyük düşünmek sık yapılan ama yanlış uygulanan yaklaşımdır. Ölçeklenebilirlik yalnızca daha güçlü sunucuya geçmek değil; yatay ölçek, cache stratejileri, CDN, asenkron işlem mimarileri, queue sistemleri ve veritabanı sharding’i düşünmektir.
Kontrol adımları:
- Benchmark: Gerçek trafik verisi üzerinden yük testleri (ab test yerine gerçekçi senaryo)
- Cache stratejisi: Edge caching (CDN), application cache (Redis/Memcached), DB query cache
- Auto-scaling politikaları: CPU/RAM/Latency bazlı threshold’larla otomatik kaynak açma
- Storage I/O değerlendirmesi: Disk IOPS, NVMe vs HDD, RAID konfigürasyonları
- Network bandwidth: Burst capacity, 95th percentile billing, egress maliyetleri
Örnek maliyet hesabı: Auto-scaling ile ani %300 trafik artışı yaşandığında, anlık cloud maliyetin 5x artabilir. Ancak planlanmamış downtime maliyeti (kaybedilen satışlar, müşteri kaybı) çok daha yüksektir. Yatırım kararlarında peak-capacity vs average-cost analizini yapın ve SLA ile koruyun.
Hata 6 — Güvenlik Yaklaşımlarını ve Uyumluluğu Göz Ardı Etmek
Hosting seçiminde GDPR, KVKK, PCI-DSS, ISO27001 gibi uyumluluk ihtiyaçlarını en başta değerlendirmelisiniz. Basit bir blog için bu gerekmeyebilir; ancak e-ticaret, sağlık, finans gibi sektörlerde uyumluluk zorunludur. Sık yapılan hatalar: SSL sadece sunucu tarafında, uygulama katmanında zafiyet taraması yapılmaması, WAF (Web Application Firewall) eksikliği, log yönetiminin yetersiz olması.
Kontrol listesi:
- WAF ve IPS/IDS: OWASP Top10’a karşı koruma
- Güncelleme ve patch politikası: Kernel ve uygulama katmanındaki yamaların ne kadar hızlı uygulandığı
- SIEM ve log retention: Olay zaman çizelgesi ve adli inceleme için en az 90–365 gün log saklama
- Şifreleme: Data-at-rest ve data-in-transit şifreleme
- Penetrasyon testi: Yıllık veya dağıtım sonrası testler
Örnek: PCI-DSS gereksinimi olan bir ödeme portalı paylaşımlı SMTP veya paylaşımlı sunucu üzerinde barındırılmamalıdır. Hosting seçimi PCI uyumlu altyapı gerektirir ve sağlayıcıdan sertifikasyon belgeleri istenmelidir.
Hata 7 — Taşıma (Migration) Sürecini ve SEO Risklerini Planlamamak
Hosting değişimi SEO için potansiyel risk taşır: DNS TTL yanlış ayarı, IP değişimi nedeniyle geçici SERP düşüşü, SSL hataları, robots.txt veya .htaccess yanlışları. Taşıma planı gereklilikleri:
- DNS TTL azaltma: Taşıma öncesi 48–72 saat TTL=300s gibi ayar
- Canary test: Kısa süreli A/B ile yeni sunucuda test etme
- Robots ve canonical kontrolü: Yeni ortamda indekslenmeyi engelleyen hataların önlenmesi
- SSL ve HSTS: HTTPS zorunluluk ve preload planı
- Search Console ve Analytics: Hemen izleme, crawl errors ve 5xx hatalarına anında müdahale
Taşıma örneği: 10.000 sayfalık bir içerik sitesinde hatalı robots.txt yüzünden 90% sayfa indeks dışı kalmış; organik trafik %70 düşmüş. Bu tarz senaryolar aylar alır düzelmesi; planlama ve test süreçleriyle önlenir.
Hata 8 — “Sınırsız” ve “Limitsiz” Pazarlama Söylemlerine Körü Körüne İnanmak
“Limitsiz trafik” pazarlama söylemlerinin arkasında genelde adil kullanım politikası (AUP) ve “resource throttling” bulunur. Teknik açıdan, CPU ve I/O kısıtlamaları ile karşılaşılmadığından emin olmak için sağlayıcıdan multi-metric kullanım sınırlarını (CPU%, RAMMB, IOPS, concurrent processes, number of inodes) talep edin. Ayrıca egress (çıkış) maliyetleri, backup retrieval ücretleri ve API rate limitleri gibi gizli maliyetleri sözleşmede netleştirin.
Hata 9 — Referans ve Uzun Süreli Müşteri Deneyimlerini İncelememek
Reklam metinleri yanıltıcı olabilir. Gerçek güvenilirlikte veri için şu kaynaklara bakın:
- Kurumun 2+ yıllık müşteri portföyü ve case study’leri
- Bağımsız uptime izleme (uptimerobot, pingdom) verileri
- Şikayet platformları ve çözüm oranları
- Uzun dönemli SLA ihlallerinin geçmişi
İdeal olarak, sağlayıcıyla pilot proje yapın veya 1–3 aylık deneme ile gerçek yük testleri uygulayın.
Hata 10 — Operasyonel İzleme, Alarm ve Metrik Planı Kurmamak
Bir hosting sağlayıcısı sunucu verilerini verir ama hangi metriklerin kritik olduğunu siz belirlemelisiniz. Örnek olarak izlenmesi gereken temel metrikler:
- CPU% (core bazlı yüksek kullanımlar)
- Memory usage ve swap kullanım
- Disk I/O (IOPS ve latency)
- Network throughput ve packet loss
- Database query latency ve slow query count
- Application error rate (5xx, timeouts)
Alarm eşikleri ve escalation prosedürleri açık olmalı; örneğin CPU>85% 5 dakika için alarm, otomatik ölçeklendirme ya da öncelikli destek çağrısı tetiklenmeli. Bu düzenlemeler yoksa hosting pasif altyapı sunar; proaktif değil reaktif olursunuz.
Pratik Kontrol Listesi: Satın Almadan Önce Sormanız Gereken 22 Soruluk Kısa Test
- Sunucu lokasyonu neresi? Hedef kitlenizle uyumlu mu?
- Data center Tier seviyesi nedir?
- Peering ve backbone sağlayıcıları kimler?
- SLA detayları nelerdir (uptime, RTO, RPO, kredi mekanizması)?
- Destek kanalları ve ortalama tepki süreleri nedir?
- Hangi güvenlik sertifikasyonlarına sahipler (ISO27001, SOC2)?
- WAF, DDoS koruması, IPS/IDS var mı?
- Yedekleme politikası nedir? Coğrafi yedek var mı?
- Restore testleri ne sıklıkta yapılır?
- Taşıma desteği sunuyorlar mı?
- Gerçek kullanıcı referansları ve uptime geçmişi mevcut mu?
- CPU/RAM/IO limitleri nelerdir? Adil kullanım nasıl tanımlanmış?
- CDN ve cache entegrasyonu sağlanıyor mu?
- SSL yönetimi otomatik mi? HSTS uygulanıyor mu?
- Audit log ve SIEM entegrasyonu sağlanıyor mu?
- Veri silme ve veri taşıma süreçleri sözleşmede nasıl düzenlenmiş?
- Fatura ve maliyet kalemleri (egress, backup retrieval) net mi?
- Ölçeklenebilirlik yolları nelerdir (vertical/horizontal, autoscale)?
- Test ortamı/ staging sunucusu sağlanıyor mu?
- Uygulama katmanı performans tuning desteği veriyorlar mı?
- SLA ihlali geçmişi ve çözüm kanıtları sunabilirler mi?
- Deneme süresi veya pilot proje opsiyonu var mı?
Örnek Karar Matriksi (Basit Ağırlıklı Skorlama)
Seçimi nicelleştirmek için aşağıdaki örnek ağırlıklandırmayı kullanabilirsiniz (0–10 puanlama):
- Performans: %30
- Güvenlik/Uyumluluk: %20
- Ölçeklenebilirlik: %15
- Destek Kalitesi: %15
- Maliyet: %10
- Yedekleme & Recovery: %10
Her kategori 0–10 arası puanlanır; ağırlıklarla çarpılarak toplam skor elde edilir. En yüksek toplam skor güvenli tercihtir. Bu yaklaşım subjektif seçimleri sayısal hale getirir ve takım içi tartışmayı nesnelleştirir.
Sonuç: Hosting Seçimi Stratejik Karardır — Teknik ve İşsel Perspektif Birlikte Değerlendirilmelidir
Hosting seçimi, yalnızca teknik bir satın alma değildir; iş sürekliliği, müşteri deneyimi ve uzun vadeli maliyet yönetiminin merkezidir. En sık yapılan hatalar—ucuz paket, lokasyon ihmal, SLA ve destek sorgulamamak, yedekleme ve güvenlik eksikleri, ölçeklenebilirlik planlamamak—hepsi kolayca önlenebilir. Yapılacak doğru hazırlık: nicel ihtiyaç analizi, pilot testler, SLA müzakere, yedekleme doğrulama ve somut taşıma planıdır. Bu süreç profesyonelce yönetildiğinde hosting altyapısı rekabet avantajı yaratır; ihmal edildiğinde ise maliyetli krizlerin kaynağı olur.