%99.9 Uptime garantisi gerçekte ne kadar? Hesap ve kontrol

Uptime garantisi (SLA, Service Level Agreement) hosting seçiminde sık geçen bir ifadedir. Ancak kullanıcıların çoğu, “%99.9 doğruysa yılda neden hâlâ kesinti yaşıyorum?” sorusunun cevabını ararken gerçek ölçüm mantığını atlar. Bu yazıda %99.9 uptime garantisi ne kadar gerçekçidir, aylık/ yıllık karşılığı nasıl hesaplanır, SLA metninde hangi maddeler tazminatı fiilen etkiler ve bir sağlayıcıya teknik olarak nasıl doğrulama yaptırılır sorularını net şekilde yanıtlıyoruz.

%99.9 uptime garantisi pratikte ne demek?

Uptime genellikle sunucunun veya hizmetin “kullanılabilir” olduğu süreyi ifade eder. SLA metinlerinde ölçüm noktası değişkenlik gösterebilir (ör. yalnızca IP erişimi mi, uygulama katmanı mı, izleme aracının başarılı yanıtı mı).

Matematik: Aylık kesinti hakkı kaç dakikadır?

Uptime yüzdesini kesinti süresine çevirmek için şu yaklaşım kullanılır: - Kesinti = Toplam süre × (1 - uptime)

Aylık bazda (yaklaşık 30 gün): - 30 gün = 43.200 dakika - Kesinti = 43.200 × 0,001 = 43,2 dakika

Günlük bazda (yaklaşık 30 gün yerine 24 saat): - 24 saat = 1.440 dakika - Kesinti = 1.440 × 0,001 = 1,44 dakika/gün

Kritik nokta: Bu değer, “tek parça halinde” değil, SLA tanımı ve izleme metoduna göre gün içine yayılmış küçük arızalar şeklinde de görülebilir.

Yıllık karşılığı: Büyük resim

Yıllık 365 gün kabul edelim: - 365 gün = 525.600 dakika - Kesinti = 525.600 × 0,001 = 525,6 dakika - 525,6 dakika = 8,76 saat

Yani “%99.9” seviyesi, teorik olarak yılda yaklaşık 8 saat 45 dakika kesinti hakkı demektir. Bu rakam kulağa az gibi gelse de WordPress (WordPress siteleri), API servisleri veya ödeme akışları için “8 saat” genellikle kabul edilemez olabilir.

SLA metninde %99.9’u etkileyen 5 kritik madde

Bir sağlayıcı %99.9 yazsa bile SLA’nın uygulanma şekli sonucu değiştirir. SLA sözleşmelerinde genellikle şu maddeler belirleyicidir:

1) Ölçüm aracı ve ölçüm katmanı

SLA iki farklı şekilde ölçülebilir: - Ağ/istemci erişimi: Ping/port kontrol, TCP bağlantısı, basit HTTP 200 kontrolü - Uygulama erişimi: Belirli bir endpoint’ten başarılı yanıt alma (ör. /health), belirli response süresi ve içerik doğrulama

Örneğin VDS/VPS kullanan bir kullanıcı için web uygulaması “uyarı işaretleri olmadan 200 döner ama veri katmanı gecikmelidir” senaryosu yaşanabilir. Eğer ölçüm sadece TCP/HTTP erişimini kontrol ediyorsa, kullanıcı deneyimi düşerken SLA “up” görünebilir.

2) “Planlı bakım” (planned maintenance) istisnaları

SLA’larda planlı bakım kesintileri uptime’dan düşülmeyebilir. Burada kritik olan şudur: - Bakım süresi önceden bildiriliyor mu? - Bakım penceresi ve süre standardı net mi? - Bakım, izleme ile “otomatik tekrar deneme” sonrası hızlı toparlıyor mu?

Bu madde, özellikle yönetilen çözümlerde “normalde kesinti sayılmıyor” gibi görünse de pratikte kullanıcılar için servis duruşu yaratabilir.

3) Ölçümün başladığı an: “Şikayet/rapor” şartı

Bazı SLA’larda tazminat için: - Belirli bir süre içinde arıza kaydının açılması, - Sağlayıcının onayı, - İzleme ekranı ile eşleştirme şart koşulur.

Bu şartlar sağlanmazsa, teorik olarak “kesinti oldu” bile tazminata dönüşmeyebilir.

4) Uptime yüzdesi “tek bir bileşen” mi, tüm hizmet mi?

SLA şu ayrımlarla kırılabilir: - “Network uptime” %99.9 - “VM uptime” %99.9 - “Billing panel uptime” ayrıca

Sizin kritik olan ise çoğu zaman “uygulamanın erişilebilirliği”dir. Örneğin VDS’de disk I/O tıkanması uygulamayı yavaşlatır ama CPU/OS çalışır durumda kalırsa SLA nasıl sayılabilir? SLA metni burada belirleyici olur.

5) Tazminat limiti ve krediler

SLA tazminatı genellikle hizmet kredisi şeklindedir. Örneğin: - Uptime %99.9 altına düşerse kredi verilir - Krediler aylık ücretin belli yüzdesini aşamaz - Ödeme iadesi yapılmaz

Hatta bazı SLA’larda tazminat “seviye düşüşünde” başlar (ör. %99.9 → %99.8). Bu da “sık küçük kesintileri” maliyetli kılabilir.

%99.9 ne zaman yeterli, ne zaman yetmez?

Bu soruyu iki parametre belirler: hizmet tipi ve iş etkisi.

Uygulama tipi örnekleri

Aşağıdaki eşleştirme, kararınızı somutlaştırır: - Bilgilendirici site / blog / katalog: %99.9 çoğu durumda kabul edilebilir; yine de e-posta ve formlar için ayrı kritik var. - API servisleri (özellikle ödeme/entegrasyon): %99.9 yetersiz olabilir. Çünkü kesintiler “dakikalar” gibi görünse de çağrı zincirinde gecikme ve kuyruk biriktirebilir. - Kurumsal e-posta: Uptime garantisinden bağımsız, MX/relay erişimi ve gecikme senaryoları ayrı önem taşır. - Oyun/streaming: Küçük kesinti bile kullanıcı akışını keser. %99.9 burada genellikle yeterli olmaz.

Kullanıcı deneyimi “kesinti dakikaları”ndan farklıdır

SLA sadece “up”/“down” üzerinden gidebilir. Oysa pratikte: - 30 saniyelik paket kaybı bile yükleme süresini 5-10 kata çıkarabilir, - 1-2 dakikalık DB kilitlenmesi “sayfa çalışıyor gibi ama geç yanıt veriyor” şeklinde algılanır.

Bu yüzden SLA yanında şu metrikleri talep edin: - Ortalama ve p95/p99 yanıt süresi - Packet loss / latency tarihçesi - Uygulama katmanı health kontrolü

Net kontrol listesi: Karşılaştırırken SLA’yı nasıl doğrulayın?

Bir sağlayıcıyla görüşürken sadece “%99.9 var mı?” diye sormak yetmez. Aşağıdaki listeyle karşılaştırma yapın.

1) SLA kapsamını tek cümlede netleştirin

Şunları yazılı alın: - Ölçüm nerede yapılıyor? (IP mi, URL mi, endpoint mi?) - Uptime neyi kapsıyor? (VM/host/network katmanı) - Hangi durumlar istisna? (DDoS, hatalı yapılandırma, üçüncü taraf)

2) Tazminat kuralını sayısallaştırın

Şunu netleştirin: - Uptime %99.9 altına düşerse tazminat var mı? - Tazminat hangi oranda (ör. aylık ücret kredisi %X)? - Minimum düşüş eşiği var mı?

3) İzleme (monitoring) kanıtı isteyin

Sağlayıcıdan şunları talep edin: - Geçmiş uptime raporları (mümkünse günlük/haftalık) - İzleme sisteminin adı ve ölçüm yöntemi - “Kesinti raporu” ile sağlanan SLA eşleştirmesi

NetKıyas gibi hosting karşılaştırma platformlarında fiyat/konfigürasyon görünür olur; ama SLA doğrulaması için ayrıca konuşmanız gerekir.

4) Yedeklilik tasarımını SLA ile karıştırmayın

Bir sağlayıcı “%99.9 garanti” diyebilir ama yedeklilik tasarımı şu sorulara bağlıdır: - Tek servis mi çalışıyor, yoksa failover var mı? - Storage (depolama) tek noktadan mı? - DNS (domain isim sistemi) TTL değerleri kesinti anında toparlanmayı nasıl etkiliyor?

Bu noktalar, SLA ile aynı şey değildir. SLA, “olursa” kapsamı; mimari ise “olmayacağını” hedefler.

Hangi alternatifler %99.9’un riskini düşürür?

%99.9’un “yılda yaklaşık 8,8 saat” gibi bir kesinti hakkı olduğunu hesapladık. Bu riski azaltmak için iki yaklaşım var: daha yüksek SLA talep etmek ve tasarımla kesintiyi yönetmek.

SLA seviyesini yükseltmek (ör. %99.95 / %99.99)

Genel mantık: - %99.95 ≈ yıllık 2,63 saat - %99.99 ≈ yıllık 0,88 saat

Not: Bu hesaplar uptime tanımına göre değişir, ancak karar mekanizmanızı kurmak için yeterince öğreticidir. Burada esas olan, daha yüksek SLA talep ederken tazminat ve ölçüm katmanını da aynı netlikte istemektir.

Tasarım: tek noktayı azaltın

Aşağıdaki uygulamalar, “SLA ne olursa olsun” servis sürekliliğini artırır: - Uygulama katmanında health check ve otomatik yeniden deneme - Veritabanı için düzenli yedek (backup) ve geri dönüş testi - Statik içerik için CDN (içerik dağıtım ağı) kullanımı - DNS TTL değerlerini planlı şekilde düşük tutma - Gerektiğinde birden fazla lokasyon/instance (özellikle kritik işlerde)

Yedekleme ve geri dönüş testi birlikte ele alınmalı

“Yedek var” ile “yedekten gerçekten geri dönebiliyorum” aynı değildir. Küçük bir kesintide yedekten dönmek gerekmez; ancak büyük kesintide geri dönüş süresi (RTO) ve veri kaybı (RPO) SLA’dan daha somut etkidir.

Pratik senaryolar: %99.9 ile karşılaşacağınız tipik durumlar

Senaryo A: Gün içinde kısa düşüşler

%99.9 yaklaşımında kesinti süreleri gün içine yayılabilir. Örneğin: - 20-30 saniyelik kısa kopuşlar - Dosya indirmelerinde veya dashboard erişiminde “aralıklı hata”

Bu tür durumlar loglarda görünür, kullanıcılar ise “site açılmadı” diye kısa kısa şikayet eder.

Senaryo B: Uygulama yavaşlar ama SLA up görünür

Özellikle ölçüm katmanı basitse, uygulama yavaşlığı SLA’ya yansımayabilir. Örneğin: - CPU/IO kilitlenmesi - DB bağlantı havuzu tükenmesi

Bu senaryoda metrik olarak yanıt süresi ve hata oranı kritik hale gelir.

Senaryo C: Planlı bakım “up” sayılır

Sağlayıcı bakım penceresi açar, izleme “up” sayabilir. Kullanıcı ise sayfa boş ekran/timeout görebilir. Bu yüzden bakım bildirimlerinin içeriğini (tarih-saat, etkilenecek servisler) yazılı isteyin.

Sonuç: %99.9’u doğru okuma ve aksiyon planı

%99.9 uptime garantisi, teorik olarak aylık yaklaşık 43 dakika, yıllık yaklaşık 8,8 saat kesinti demektir. Bu rakam bazı blog/servis türlerinde yönetilebilir, ödeme ve entegrasyon gibi kritik işlerde ise genellikle risklidir. Aksiyon olarak, SLA metninde ölçüm katmanı, planlı bakım istisnaları ve tazminat şartlarını yazılı alın; ardından izleme kanıtı ve tazminat eşiğini sayısallaştırın. Eğer servisiniz kritikse sadece SLA’ya güvenmeyin; yedekleme (backup) + geri dönüş testi, CDN kullanımı ve mümkünse yedeklilik mimarisiyle kesintinin iş etkisini azaltın.