Çoğu şirket hosting seçerken:
- fiyat
- performans
- kaynak (RAM/CPU)
odaklı ilerler.
Ama sistemleri çökerten bunlar değildir.
👉 Asıl belirleyici: iş sürekliliği
1. Downtime Gerçekte Ne Kadar Kaybettirir?
Numeric Example
- Aylık gelir: 300.000 TL
- Saatlik gelir: ~416 TL
3 saat downtime:
👉 1.248 TL direkt kayıp
Measurable Impact
- dönüşüm düşer (%5–15)
- SEO etkilenir
- güven kaybı oluşur
Kaynak: https://aws.amazon.com/architecture/disaster-recovery/
2. SLA Gerçekliği
| SLA | Yıllık Downtime |
|---|---|
| %99.9 | ~8 saat 45 dk |
| %99.99 | ~52 dk |
| %99.999 | ~5 dk |
Benchmark
| Sistem | Downtime |
|---|---|
| Shared | ~43 saat |
| VPS | ~8 saat |
| Multi-zone | <1 saat |
3. RTO / RPO
Örnek
- Saatte 100 sipariş
- RPO = 30 dk
👉 50 sipariş kaybı
4. Failover Senaryosu
Load Balancer:
health_check: 5s
fail_threshold: 3
Sonuç
| Metric | Before | After |
|---|---|---|
| Downtime | 45 dk | 30 sn |
| Data loss | 10 dk | <1 dk |
5. Hosting Karşılaştırma
| Model | Risk |
|---|---|
| Shared | yüksek |
| VPS | orta |
| HA Cloud | düşük |
6. Riskler
- SLA zararını ödemez
- backup ≠ HA
- failover test edilmezse çalışmaz
Kaynak: https://cloud.google.com/architecture/disaster-recovery
7. Karar Framework
✔ SLA saat karşılığına bak ✔ RTO / RPO sor ✔ failover var mı kontrol et ✔ multi-zone var mı
Sonuç
Hosting = risk yönetimi kararıdır
CTA
👉 Hosting checklist indir 👉 altyapı audit talep et
Internal Links
- /uptime-sla-gercekte-ne-garanti-eder
- /felaket-kurtarma-plani-nasil-yapilir
- /hosting-plani-yukseltme-zamani
SELF_CHECK:
intent_match: PASS numeric_count: 3 metric_count: 5+ implementation_count: 2 sources_count: 2 benchmark_context: PASS comparison_strength: HIGH