Uptime garantisi %99.9 ne kadar gerçekçi? Hesap ve kontrol listesi
%99.9 uptime garantisi aylık kaç dakika kesinti demek? SLA dışı durumlar, ölçüm yöntemi ve kanıt isteyerek gerçekliği nasıl doğrularsınız?
Uptime garantisi (SLA kapsamında), hosting alırken en çok verilen sözlerden biridir; ancak rakam tek başına doğru kararı verdirmez. Çünkü %99.9 gibi oranlar hem ölçüm yöntemine hem de SLA’nın dışarıda bıraktığı durumlara bağlıdır. Bu yazıda, %99.9’un teknik olarak aylık/ yıllık “izin verilen” kesinti süresini net hesaplayacak, ardından sağlayıcıların nasıl ölçüm tuttuğunu ve hangi kanıtları isteyebileceğinizi kontrol listesiyle çıkaracağız.
%99.9 uptime tam olarak ne demek?
Uptime yüzdesi, belirli bir zaman aralığında hizmetin “erişilebilir” olduğu süreyi ifade eder. Pratikte SLA’larda şu iki konu kritik olur:
- Aritmetik karşılık: %99.9, “toplam sürenin %0.1’i kadar” kesinti anlamına gelir.
- Kesinti tanımı: Kesinti “sunucu erişilemez” olarak mı ölçülür, yoksa uygulama katmanı (HTTP/ uygulama hatası) da dahil mi?
Aylık ve yıllık kesinti hesabı
SLA’larda tipik yaklaşım, ayı 30 gün ve yılı 365 gün almak olur. Hesapları bu kabul üzerinden görelim.
- Aylık izin verilen kesinti: 30 gün × 24 saat × 60 dk = 43.200 dk
- %99.9 kesinti payı: 43.200 × 0.001 = 43.2 dk
-
Yani yaklaşık 43 dakika 12 saniye.
-
Yıllık izin verilen kesinti: 365 gün × 24 saat × 60 dk = 525.600 dk
- %99.9 kesinti payı: 525.600 × 0.001 = 525.6 dk
- Bu da yaklaşık 8 saat 45 dakika.
Önemli detay: SLA’lar genellikle “tek seferde uzun kesinti”yi değil, dönem içindeki toplam kesinti süresini baz alır. Örneğin 43 dakikanın 10 dakikada bir 4 parçaya bölünmesi mümkündür. Bu, kullanıcı deneyimini etkiler.
Dakika yeterli mi? Uygulama senaryosu fark yaratır
%99.9 kulağa yüksek gelir; ancak senaryoya göre fark büyür:
- API/checkout: 30-60 saniyelik tekrar eden kesintiler, sipariş kaybına dönüşebilir.
- SEO ağırlıklı blog: Tek seferlik kısa erişim sorunları daha yönetilebilir olabilir.
- Düzenli job çalışan sistemler: Erişim kesilse de arka plan işlerinin yeniden denemesi kritik olur.
Bu yüzden uptime oranını, “kesinti başına etki” ile birlikte değerlendirmeniz gerekir.
SLA’larda %99.9 neden bazen “gerçekçilikten uzak” görünür?
%99.9’un tutarlılığı; ölçümün nasıl yapıldığı, kesinti istatistiğinin neyi kapsadığı ve SLA’nın dışladığı durumlar nedeniyle değişir.
1) Ölçüm noktası: IP/port mu, sayfa mı?
Bir sağlayıcının “ulaşılabilirlik” ölçümü şu şekillerde olabilir:
- Sunucu erişimi (ICMP ping): Ping bazen servis aksasa bile cevap verebilir.
- Port erişimi (TCP): Port açık olabilir ama uygulama çökmüş olabilir.
- HTTP/HTTPS kontrolü: En anlamlısı genellikle belirli bir URL’nin (ör.
/health) dönmesiyle ölçülür.
Kritik soru: SLA’da ölçümün hangi katmanda yapıldığı yazıyor mu? Yazmıyorsa, gerçekliği doğrulamak için siz teknik test yapmalısınız.
2) SLA dışı durumlar: “Sıfır kesinti sayılabilir” boşluklar
SLA’lar çoğu zaman şu başlıkları kesinti saymayabilir:
- DNS değişiklikleri ve bakım pencereleri
- Müşteri tarafı yapılandırma hataları
- DDoS koruması sırasında “hizmetin sınırlanması”
- Üçüncü parti bağımlılıklar (CDN, upstream, ödeme sağlayıcıları)
- Yazılım güncellemeleri (sağlayıcının kendi kontrolündeki bakım işleri dahil edilip edilmediği belirsizse)
SLA metninde “excluded” (hariç tutulan) maddeler net değilse, %99.9 pratikte daha iyi veya daha kötü çıkabilir. Bu nedenle sadece yüzdeye değil, kapsam maddelerine bakın.
3) “Planlı bakım”ın kesintiye etkisi
Bazı sağlayıcılar planlı bakımda SLA’ı durdurur. Örneğin ay içinde 1-2 saat planlı bakım oluyorsa, bu süre “uçuşta” olabilir. Uptime garantisinin “gerçek” karşılığı, planlı bakımın dahil edilip edilmediğiyle belirlenir.
4) Tek lokasyon mu, çoklu lokasyon mu?
Veri merkezinde tek nokta arızası (switch, güç, uplink) yaşandığında kurtarma hızını lokasyon ve mimari belirler. Multi-AZ/HA mimarisi olanlar genellikle daha stabil performans verir. VDS/VPS tarafında “aynı fiziksel host” üzerinde yoğunluk da önemli olabilir.
%99.9’u doğrulamak için sağlayıcıdan isteyeceğiniz kanıtlar
SLA belgesi almak tek başına yeterli değildir. Aşağıdaki maddeler, “söz mü, ölçüm mü?” sorusunu netleştirir.
Hangi belgeleri yazılı isteyin?
- SLA kapsamı ve hariç tutulan durumlar listesi (tam metin)
- Uptime ölçüm metodolojisi: Nereden ve hangi protokolle ölçüm yapılıyor?
- Raporlama sıklığı: Aylık rapor var mı, yoksa yalnızca talep edilince mi veriliyor?
- Geçmiş dönem performansı: Mümkünse son 6-12 ayın uptime raporu.
- Kredi/ tazminat mekanizması: Kesinti olursa “hizmet kredisi” nasıl hesaplanıyor?
Sağlayıcı bunu hangi metrikle ölçüyor? (net kontrol soruları)
Aşağıdaki sorulara net cevap almanız gerekir:
- Kesintiyi kaç dakika altına düşerse saymıyorlar mı? (örn. 1 dakikadan kısa kesintiler)
- Ölçümde kullanılan URL/endpoint sabit mi?
- Ölçüm konumu (ülke/ISP) neresi?
- CDN varsa origin mi ölçülüyor, edge mi?
Gerçekçi değerlendirme: %99.9 kimin için yeterli?
Aşağıdaki karar matrisi, oranı “yeterlilik” açısından netleştirir.
- %99.9 yeterli olabilir:
- Düşük trafikli, esnek içerik siteleri
- Tek kullanıcı kitlesi küçük olan projeler
-
Uygulama tarafında otomatik yeniden deneme (retry) ve kuyruk (queue) mimarisi olanlar
-
%99.9 genellikle yetersiz kalabilir:
- Tekrarlayan hatalarda gelir kaybı yaşayan e-ticaret ödeme akışı
- Gerçek zamanlı kullanıcı deneyimi gerektiren uygulamalar (chat, canlı yayın)
- SLA dışında kalan bağımlılıklar olmadan çalışan mimariler kuramayanlar
Bu noktada hedefi “%99.9 olsun” yerine, kendi iş etkilerinize göre belirleyin. Aksi halde sağlayıcı SLA’ı tutsa bile “sizin gördüğünüz” kesinti deneyimi farklı olabilir.
Uptime performansını artıran teknik tercihler (VDS/VPS ve web hosting)
SLA tek başına çözüm değildir. Uptime’i etkileyen uygulama ve mimari kararları vardır.
1) Yedekleme (backup) ve geri dönüş süresi
“Erişilebilirlik yoksa” bile sistemin geri dönüşü önem kazanır. Yedekleme stratejisini şu şekilde planlayın:
- Günlük tam yedek (backup) + saatlik artımlı (incremental) yedek
- Yedeklerin test edilmesi: geri dönüş doğrulaması (restore drill)
- Yedeklerin farklı lokasyonda tutulması
2) İzleme ve otomatik iyileştirme (health check + restart)
Uptime’inizi, kendi tarafta da ölçün. Dışarıdan izleme (Uptime monitoring) şu metrikleri takip etmelidir:
- HTTP 200/ 3xx oranı
- Response time (TTFB ve toplam)
- Uygulama health endpoint
- 5xx hata sayısı
Uygulama katmanı “hizmet var” görünse bile hata veriyorsa, bu SLA’nızdan görünmeyebilir.
3) CDN ve origin ayırımı
CDN, istemci ile origin arasındaki mesafeyi kısaltır; ani trafik darbelerinde de tampon etkisi sağlar. Ancak CDN kullanıyorsanız:
- SLA ölçümü origin’den mi, edge’den mi yapılıyor?
- CDN cache dolu olduğunda “origin down” görünse de kullanıcı kesintiyi hisseder mi?
Bu farkı sözleşmede ve teknik testte netleştirin.
4) Stateless tasarım ve yeniden başlatma
VDS/VPS üzerinde uygulama yönetiyorsanız:
- Uygulamanın stateless olması (oturumları dış depoya almak)
- Service yeniden başlatma politikaları
- DB bağlantı retry ve connection pool ayarları
Uptime’i sözleşme kadar, mimari de belirler.
HTTP/3, lokasyon ve ölçüm: SLA ile “sizinkinin” aynı mı olduğunu test edin
Uptime ölçümünüz SLA ile aynı bakış açısında değilse, iki taraf “çelişkili” veri üretir.
Kısa test akışı
Aşağıdaki yaklaşım, sağlayıcıya göre net bir kıyas çıkarır:
- Aynı endpoint’i iki farklı ülkeden izleyin
- HTTP/1.1 ve HTTP/2/HTTP/3 (varsa) durum kodlarını kaydedin
- Lokasyon değişkenliğini yorumlamak için DNS TTL davranışını gözlemleyin
Bu çalışma, örneğin sağlayıcının ölçüm noktasında her şey “up” iken sizin lokasyonunuzda süreklilik sorunu yaşandığını ortaya çıkarır.
%99.9 SLA aldım: Peki kesinti olursa ne beklemelisiniz?
SLA’ların çoğu “kesinti olursa tazminat” mekanizması içerir; ancak bu mekanizmalar pratikte her zaman beklendiği gibi çalışmaz.
Aşağıdaki başlıkları sözleşmeden kontrol edin:
- Kesinti başladıktan sonra kaç dakika geçince SLA kredisi devreye girer?
- Hizmet kredisi, faturaya otomatik yansır mı yoksa talep gerekir mi?
- Kredi tutarı “kesinti süresi oranıyla” mı hesaplanır, yoksa sabit bir band mı var?
- Kesintiler “toplam” mı toplanır, yoksa tek seferde mi bakılır?
Net bir karşılaştırma için mini tablo
Aşağıdaki tablo, SLA metni okurken hızlı tarama sağlar:
| Kriter | %99.9’un gerçekliği nasıl etkilenir? | Ne aramalısınız? |
|---|---|---|
| Ölçüm katmanı | Uygulama hatası gizlenebilir | HTTP/health endpoint |
| Hariç tutulanlar | Kesinti “sayılmayabilir” | excluded listesi net mi? |
| Planlı bakım | SLA durabilir | bakım pencereleri ve dahil/ hariç |
| Raporlama | Kanıt sunulmazsa tartışma çıkar | aylık rapor / geçmiş kayıt |
| Tazminat | Kesintiyi telafi etmeyebilir | kredi hesap formülü |
Sonuç: %99.9’u “körlemesine” değil, ölçüm kapsamıyla birlikte değerlendirin
%99.9, teknik olarak aylık yaklaşık 43 dakikalık toplam kesinti hakkı demektir; yıllıkta ise yaklaşık 8 saat 45 dakika. Ancak bu rakamın sizin yaşantınıza karşılık gelip gelmediğini, SLA’nın ölçüm metodolojisi ve hariç tuttuğu durumlar belirler. İade/tazminat formülünü, ölçüm endpoint’ini ve raporlama kanıtlarını yazılı isteyin; ayrıca kendi tarafınızda health check ve HTTP izleme ile doğrulama yapın. Bu adımları uygularsanız, %99.9’un sizin senaryonuz için gerçekçi olup olmadığını net biçimde anlayıp doğru hosting türü ve mimariyi seçebilirsiniz.
Hosting karşılaştırması yapmaya hazır mısın?
100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.
Hosting Karşılaştır →İlgili Yazılar
VDS/VPS Performans Düşüşünde Net Sorun Giderme Rehberi
VDS/VPS performansı düştüğünde adım adım tanılama ve çözüm: CPU/RAM disk, ağ, kernel, loglar ve ölçümle kalıcı iyileştirme.
SSH key ile şifre girişini devre dışı bırakma rehberi
SSH key tabanlı giriş kurup parola (password) doğrulamayı kapatın. Güvenli yapılandırma, hatasız test adımları ve geri dönüş planı.
Hreflang Tag’leri Çoklu Lokasyon Hosting’de Nasıl Kurulur?
Çoklu lokasyon hosting kullanan sitelerde hreflang etiketleri nasıl doğru yönetilir? CDN, önbellek ve yönlendirme kurallarıyla hatasız kurulum adımları.
Bot Trading için VDS’de düşük gecikme nasıl sağlanır?
Bot trading’de düşük gecikme için VDS konum, ağ, kernel, zaman senkronu, DNS, bağlantı ayarları ve ölçüm adımlarını net biçimde görün.
