%99.9 uptime garantisi ne kadar gerçekçi? Hesap + kontrol rehberi

Uptime garantisi, hosting alırken en çok pazarlanan ama en yanlış yorumlanan vaatlerden biridir. “%99.9” gibi bir oran kulağa net gelir; fakat kesintinin ne kadar, hangi durumlarda sayıldığı ve hangi sürenin hariç tutulduğu çoğu zaman belirsiz kalır. Bu yazıda %99.9’un matematiksel olarak ne anlama geldiğini hesaplayacak, SLA metinlerinde hangi maddelerin kritik olduğunu gösterecek ve pratik kontrol adımlarıyla “gerçekçi mi?” sorusunun cevabını ölçümle birlikte netleştireceğiz.

%99.9 uptime: Matematiksel karşılığı

“Uptime” genelde hizmetin erişilebilir olduğu zaman oranıdır. SLA’larda bu oran genellikle aylık veya yıllık bazda yazılır. Buradaki kritik nokta: Kesinti süresi hesabı doğrudan oranla ilgilidir.

Aylık ve yıllık kesinti hesabı

Aşağıdaki tabloda %99.9 uptime oranının pratik karşılığını görebilirsiniz. Hesaplarda 30 gün = 30×24 saat = 720 saat varsayılır.

Net sonuç: %99.9, aylık bazda teorik olarak yaklaşık 43 dakikalık kesinti payı demektir. Yıllık bazdaysa yaklaşık 8 saat 46 dakika downtime ile uyumlu bir vaat olur.

“Kesinti ne zaman sayılır?” sorusu

Burada matematik tek başına yetmez. SLA’larda ölçüm, çoğu zaman aşağıdaki gibi sınırlandırılır: - “Site tamamen kapalı mı?” yoksa “bazı sayfalar çalışmıyor mu?” sayılır mı? - HTTP 200 dönmeyen istekler mi downtime sayılır, DNS mi, TCP bağlantısı mı? - Sağlayıcı kendi ölçümünden mi bakar, yoksa müşteri raporları mı kabul edilir? - Bakım (maintenance) pencereleri otomatik olarak downtime dışı bırakılır mı?

Dolayısıyla aynı %99.9 oranı, farklı ölçüm tanımlarıyla kullanıcı deneyiminde ciddi farklılık yaratabilir.

SLA metninde asıl belirleyen 5 madde

“%99.9 yazıyor” demek yetmez. SLA dokümanındaki şu 5 başlık, gerçekçi sonucu belirler.

1) Ölçüm yöntemi (measurement)

SLA’da genellikle “erişilebilirlik” şu şekilde tanımlanır: - URL bazlı (ör. anasayfa) - IP bazlı (ör. TCP 443) - Ping/ICMP bazlı (hosting için çoğu zaman yanıltıcı) - Servis bileşeni bazlı (web, e-mail, API ayrı)

Özellikle yalnızca anasayfa kontrol ediliyorsa, WordPress paneli çalışmıyor veya ödeme sayfası hatalı dönüyor olsa bile SLA hedefini yakalayabilirsiniz. “Uptime” ölçümünün hangi uç noktayı kapsadığını doğrulayın.

2) Kapsam dışı durumlar (exclusions)

Sık görülen kapsam dışı durumlar şunlardır: - DNS değişiklikleri - Müşteri kaynaklı yanlış yapılandırma - Rate limit / WAF engelleri - DDoS saldırıları sırasında “mitigation” süreçleri - Bakım pencereleri

Bu maddeler, kağıt üzerinde %99.9’u “korur”. Gerçekte kullanıcı tarafında saatler süren etkiler olabilir.

3) Bakım pencereleri ve ön bildirim

Gerçekçi bir SLA’da bakım pencereleri nettir: - Haftalık/aylık plan - Bildirim süresi (ör. 24-48 saat) - Bakım sırasında neyin etkilendiği (web mi, API mı)

Örneğin “planlı bakım sırasında uptime hesaplanmaz” maddesi, sağlayıcının toplam uptime sayımını fiilen daha iyi gösterebilir.

4) Telafi (service credit) nasıl çalışır?

Birçok sağlayıcı uptime hedefi tutmazsa “iade” yerine service credit verir. Burada iki kritik kontrol vardır: - Kredinin hesaplama oranı: downtime ile orantılı mı, yoksa sınırlı bir tavan var mı? - Kredi gerçek nakit yerine sadece sonraki faturada mı geçerli?

Örnek mantık: Aylık SLA $100 fatura üzerinden düşünülürse, %99.9 hedefi kaçırıldığında verilecek kredi çok düşük kalabilir. Metinde “maksimum kredi” tavanı aranmalıdır.

5) İtiraz/kanıt süreci (claim process)

SLA ihlali talebi genellikle şunları ister: - Sağlayıcının ölçüm sistemine dayanmak - Belirli süre içinde bildirim - Log/rapor formatı

“E-postayla bildirmeniz yeterli” denmiyorsa, süreç karmaşıksa telafi alma ihtimali düşer. Bu noktayı özellikle yüksek erişilebilirlik bekleyen e-ticaret ve kurumsal işler için önemseyin.

%99.9 ne zaman “yeterli”, ne zaman “risk”?

Uptime hedefinin uygunluğu iş yüküne bağlıdır. Aşağıdaki karar çerçevesi pratik bir başlangıç verir.

Uygun olduğu senaryolar

• Blog, içerik odaklı site (tekil sayfa arızaları gelir kaybını sınırlı etkiliyorsa)
• İçerik yayıncılığı ve SEO ağırlıklı projeler (kısa kesintiler genellikle toparlanabilir)
• Test/QA ortamları

Riskli olduğu senaryolar

• E-ticaret ödeme akışı (checkout) veya kritik sipariş API’leri
• Lead toplama ve form gönderiminin gelir etkisi yüksek olduğu sektörler
• SLA ihlali olduğunda müşteri güveni ciddi sarsılan kurumsal sistemler

Buradaki temel mantık: 43 dakikalık aylık downtime, e-ticarette tek seferde toplu satış kaybı yaratabilir. Ayrıca bu “tek blok” halinde gerçekleşmeyebilir; 5-6 dakikalık çoklu parçalı kesintiler kullanıcı deneyimini daha da kötüleştirir.

“Uptime”yi kendi ölçün: 10 dakikada net doğrulama

SLA sadece sağlayıcı beyanıdır. Gerçekçi değerlendirme için kendi tarafınızda ölçüm kurun. Amaç, sağlayıcının ölçümüyle değil; sizin kullanıcı deneyiminizle uyumu yakalamaktır.

Basit ölçüm checklist’i

• Hangi URL/endpoint? Ödeme değilse bile kritik sayfayı seçin: / veya /login yerine iş akışına yakın bir uç nokta.
• Protokol: Sadece HTTP değil, mümkünse HTTPS yanıtını da ölçün.
• Konum: Ölçümü farklı coğrafyalarda yapın (Türkiye + Avrupa gibi). Yüksek gecikme ve routing sorunları farklı sonuç verebilir.
• Arıza türü ayrımı: DNS hatası mı, TLS/sertifika mı, uygulama hatası mı?

Hangi veriler toplanmalı?

• Kesinti başlangıç/bitiş zamanı
• HTTP durum kodu (örn. 502, 503)
• TLS sertifika hatası varsa kaç dakikada düzeldi
• Ortalama yanıt süresi (latency) kesintiyle birlikte artıyor mu?

Not: Uptime ölçümü kesintiyi yakalar ama performans düşüşünü (özellikle CPU %100, disk IO tıkanması) her zaman downtime saymaz. Bu yüzden “erişilebilirlik” ile “hız”ı ayrı düşünün.

NetKıyas perspektifi: Karşılaştırmada 4 teknik soru

Hosting karşılaştırırken şu sorulara net yanıt alın. Bu sorular doğrudan %99.9’un gerçeğe dönüşüp dönüşmeyeceğini etkiler.

1) Sağlayıcı hangi servis bileşenleri için SLA veriyor?

Bazı sağlayıcılar yalnızca web tarafını garanti ederken e-mail veya API’yi ayrı ele alır. “Sitede sorun yaşadığımda SLA geçer mi?” netleşmelidir.

2) Altyapı: Single point of failure var mı?

%99.9 hedefi bile altyapı tasarımına bağlıdır. Örnek: Tek bir hypervisor hatası, tek bir switch problemi veya tek lokasyon gibi durumlar kesintiyi uzatabilir.

3) Yedeklilik (redundancy) hangi katmanda?

• Donanım yedekliği (RAID/disk)
• Güç (UPS/jeneratör)
• Ağ (switch/routing)
• Uygulama katmanı (cluster)

4) DDoS ve network throttling nasıl davranıyor?

DDoS koruması “erişimi sürdürme” hedefindedir ama ağır trafiği sınırlayan throttling bazı durumlarda kullanıcı deneyimini downtime benzeri hale getirir. SLA metni bu tür durumları nasıl sayıyor?

%99.9’u destekleyen altyapı beklentisi

%99.9 seviyesinde bile gerçekçi bir beklenti için sağlayıcının şu yetenekleri sunması gerekir: - Otomatik izleme (monitoring) ve hızlı failover prosedürleri - Bir arıza olduğunda hizmetin başka bir bileşenden devreye alınması - Planlı bakım için önceden bildirim ve kesintiyi sınırlayan süreç - Üst düzey loglama ve incident yönetimi

Bu başlıkların hiçbiri SLA metninde detaylı anlatılmasa bile, “telafi almak için uğraşmadan” hizmetin istikrarlı kalması için kritiktir.

Sonuç: Kararı SLA’dan önce ölçümle tamamlayın

%99.9 uptime garantisi matematiksel olarak aylık yaklaşık 43 dakikalık, yıllık yaklaşık 8 saat 46 dakikalık downtime ile uyumludur. Bu nedenle e-ticaret, ödeme akışı ve kritik API’ler için %99.9 tek başına “güvenli” bir hedef değildir; ölçüm yöntemi, kapsam dışı maddeler ve telafi (service credit) koşulları netleşmeden karar vermek risktir.

Aksiyon önerisi: SLA metninde ölçüm yöntemi, kapsam dışı durumlar, bakım pencereleri ve telafi maddelerini çıkarın; ardından kendi tarafınızda farklı konumlardan kritik endpoint’inizi izleyin. SLA ile ölçüm sonuçları uyumlu değilse, hedefi bir üst sınıfa (ör. %99.95 veya %99.99 gibi) ya da daha güçlü altyapı garantisi olan plana taşıyın. Böylece “kağıt üzerinde uptime” yerine gerçek kullanıcı erişimini esas alırsınız.