SLA nedir? Hostingte hedefler, cezalar ve pratik kontrol listesi

SLA (Service Level Agreement), bir barındırma hizmetinde “ne kadar süre çalışır” hedefini ve bu hedef tutmadığında ne olacağını yazılı hale getirir. Hosting seçiminde SLA, yalnızca pazarlama ifadesi değil; ölçüm mantığı ve istisnalar net olmadığında pratikte tazminatın çalışmamasına yol açabilir. Bu rehberde SLA’nın ne olduğunu, hostingte nasıl okunacağını ve VDS/VPS/dedicated gibi servislerde hangi maddelere özellikle bakmanız gerektiğini net bir kontrol listesiyle öğreneceksiniz.

SLA hostingte neyi ifade eder?

SLA; sağlayıcının hizmet seviyesine dair taahhüdünü, ölçüm yöntemini ve çoğu zaman “hizmetin hedefe ulaşmaması halinde uygulanacak telafi/indirim” mekanizmasını tanımlar. Genellikle SLA; “erişilebilirlik (availability)”, “performans (performance)” ve bazı durumlarda “destek yanıt süreleri (support response)” başlıklarını kapsar.

SLA metinlerinde şu üç parça birlikte okunur:

• Hedef (target): Örn. %99.9 uptime (çalışma süresi) gibi.
• Ölçüm (measurement): Uptime nasıl hesaplanıyor? Hangi sistemler dahil, hangi zaman aralığı dahil?
• Telafi (remedy): Hedef tutmazsa ne oluyor? Otomatik kredi mi, indirim mi, yoksa yalnızca başvuru şart mı?

Uptime hedefi ne kadar zaman kaybına denk gelir?

SLA’da belirtilen yüzde hedefi, pratikte “yılda kaç saat” veya “ayda kaç dakika” kesinti yapabileceğinizi matematiksel olarak verir. Bu hesap, sağlayıcılar arasında kıyas yapmanızı kolaylaştırır.

Aşağıdaki tablo, yıllık kesinti toleransını gösterir (basitleştirilmiş hesap):

Önemli nokta: Sağlayıcı “uptime” hesabını yaparken hangi bileşenlerin dahil edildiği değişebilir. Bazı SLA’lar sadece “network erişilebilirlik” ölçer; uygulama katmanındaki hataları hariç tutabilir.

SLA’da ölçüm yöntemi: En kritik bölüm burası

SLA’nın en fazla “anlaşmazlık” yarattığı alan ölçüm yöntemidir. Aynı “%99.9” hedefini görüp farklı sonuçlar almak mümkündür.

Ölçüm nasıl yapılır?

SLA metninde tipik olarak şu sorulara yanıt arayın:

• Hangi ölçüm aracı? (İzleme aracı, heartbeat, HTTP kontrolü vb.)
• Hangi endpoint? (site URL, API endpoint, port kontrolü)
• Hangi bölge/konum? (tüm bölgeler mi, tek veri merkezi mi?)
• Hangi durumlar downtime sayılır?
• Hangi durumlar hariç tutulur?

Örnek senaryo: Sağlayıcının izleme sistemi yalnızca “ICMP ping” veya basit bir port kontrolü yapıyorsa, uygulama katmanı bozuk olsa bile SLA “tutuyor” görünebilir. Buna karşılık izleme HTTP üzerinden “başarılı yanıt (2xx/3xx)” kontrol ediyorsa aynı sorun farklı sonuç doğurur.

Tekil bileşen mi, tüm hizmet mi?

SLA’da “hizmet kapsamı” net değilse, telafi hakkı daralır. Şunu özellikle istemeniz gereken netlik sağlar:

• VPS/VDS için: hypervisor host mu, VM network mi, storage mu?
• Dedicated için: switch/port arızası downtime sayılıyor mu?
• Web hosting için: sadece kontrol paneli mi, web sunucusu mu, DNS mi?

Telafi (remedy) gerçekte neye dönüşür?

Birçok kullanıcı SLA’yı yalnızca uptime yüzdesi sanır. Oysa pratik değer, telafi mekanizmasının “gerçekten kullanılabilir” olup olmamasında yatar.

Telafi türleri

SLA’larda genellikle şu telafi yöntemleri görülür:

• Hizmet kredisi (service credit): Ay bazında indirim/credit.
• Fatura indirimi: Bazı durumlarda bir sonraki fatura tutarına yansır.
• Olağanüstü iptal hakkı: Sık ihlal olursa sözleşmeyi fesih.

Burada kritik olan şu noktadır: Telafi çoğu zaman otomatik değildir. SLA ihlali olsa bile “başvuru açmak” gerekebilir.

Telafi nasıl hesaplanıyor?

Bazı sağlayıcılar “SLA her ihlalde tam telafi” mantığı yerine “eşik (threshold) sonrası kredi” yaklaşımı kullanır. Örneğin:

• Ay içinde belirli bir kesinti süresi aşılmadan kredi verilmez.
• Kredi oranı sınırlıdır (örn. maksimum %X).
• Performans düşüşleri “downtime” sayılmaz.

Bu yüzden SLA’yı okurken “telafi yüzdesi” ve “maksimum cap” kısmını kontrol edin.

İhlal durumunda zaman aralığı

SLA ihlali için hesap penceresi önemlidir. Bazı SLA’lar takvim ayı içinde ölçer; bazıları tüm dönem ortalaması alır. Bu da “tek seferlik büyük arıza” ile “parça parça küçük arızaların” telafiye etkisini değiştirir.

SLA’da sık görülen istisnalar (downtime sayılmayan durumlar)

SLA’lar genellikle istisnalar içerir. İstisna maddeleri, SLA’nın pratikte uygulanabilirliğini belirler.

Hosting SLA metinlerinde en sık görülen istisnalar:

• Müşteri kaynaklı sorunlar: yanlış yapılandırma, uygulama hataları
• Planlı bakım (scheduled maintenance): önceden bildirimle
• Üçüncü taraf bağımlılıklar: CDN, upstream, internet sağlayıcı
• DDoS olayları ve mitigasyon: bazı sağlayıcılar tamamen hariç tutar
• DNS kaynaklı erişim sorunları: bazı SLA’lar DNS’i ayrı kapsar
• Yasal/uygulama gereklilikleri: güvenlik, erişim kısıtları

“Daha iyi SLA” her zaman daha iyi telafi demek değildir

%99.9 hedefi görece yüksek bir seviye gibi görünür. Ancak telafi kısmı zayıf ve istisnalar genişse, SLA pratikte düşük değer taşıyabilir. Bu nedenle SLA’yı uptime hedefiyle birlikte “dahil/hariç” kapsamı ve telafi koşullarıyla birlikte değerlendirin.

VDS, VPS ve dedicated için SLA okuma: Ne beklemelisiniz?

Servis türü, SLA kapsamını değiştirir.

VDS/VPS: VM erişilebilirliği nasıl ölçülür?

VDS/VPS SLA’larında genellikle şunlar kritik olur:

• VM’in network erişilebilirliği uptime sayılıyor mu?
• VM içi servis çökse bile (ör. web server down) downtime sayılıyor mu?
• Storage performans dalgalanmaları downtime sayılır mı?
• KVM gibi sanallaştırma altyapısında “host arızası” telafiye dahil mi?

Net kontrol: SLA’da “uptime” tanımının hangi katmanı kapsadığını arayın. VM içindeki uygulama hatalarını kapsayan SLA nadirdir; çoğu sağlayıcı altyapı erişilebilirliği üzerinden ölçüm yapar.

Dedicated: Donanım arızası ve bakım pencereleri

Dedicated sunucuda SLA genellikle şu riskleri hedefler:

• Donanım arızası durumunda “reaksiyon süresi” (ör. parça değiştirme)
• Veri merkezi bakım pencereleri
• RMA süreçleri

Dedicated SLA’da “uptime” kadar düzeltme/aksiyon süresi de önemlidir. Çünkü bazı senaryolarda sunucu kısa süreli düşer ama tam yerine koyma süresi uzayabilir.

Web hosting: DNS ve uygulama katmanı ayrımı

Paylaşımlı hosting veya yönetimli web hostingte SLA çoğu zaman birden fazla bileşene ayrılır:

• Web sunucusu erişilebilirliği
• DNS erişilebilirliği (domain DNS)
• Kontrol paneli (panel) erişimi

Özellikle site trafiği için, “DNS yavaşlığı” yaşandığında SLA’nın devreye girip girmeyeceği kritik olur. Bu yüzden hosting SLA metninde “DNS downtime” ifadesini arayın.

NetKıyas’ta SLA kıyasını daha hızlı yapmanız için kontrol listesi

Aşağıdaki maddeler, sağlayıcılar arasında hızlı ve anlaşılır bir kıyas yapmanızı sağlar. SLA okurken her maddeye net cevap arayın.

1) SLA kapsamı

• Hedef yalnızca network erişilebilirliği mi, yoksa uygulama endpoint mi?
• VPS/VDS tarafında ölçüm VM mi yoksa altyapı mı?

2) Uptime hedefi

• Hedef yüzdesi kaç? (%99.9, %99.95 gibi)
• Hesap dönemi ne? (aylık/yıllık)

3) Ölçüm yöntemi

• Sağlayıcı izlemeyi nasıl yapıyor?
• HTTP başarı kriteri var mı (ör. 2xx)?
• Hangi endpoint kontrol ediliyor?

4) İstisnalar

• DDoS hariç tutuluyor mu?
• Planlı bakım nasıl bildiriliyor?
• DNS sorunları dahil mi hariç mi?
• Müşteri hataları dışında kalan “altyapı” sorunları dahil mi?

5) Telafi (remedy)

• Telafi türü ne: service credit mi, fatura indirimi mi?
• Otomatik mi, talep gerekiyor mu?
• Maksimum kredi sınırı var mı?
• Kesinti süresi eşik aşmadan kredi verilmiyor mu?

6) Destek SLA’sı var mı?

• İlk yanıt süresi (initial response) var mı?
• Kritik arızada eskalasyon (escalation) mekanizması nasıl çalışıyor?

Aşağıdaki tablo, aynı hedef yüzdesini görseniz bile “pratikte” farkı yakalamak için kıyas formatı sağlar. Siz kendi notunuzu bu şablona göre tutabilirsiniz.

SLA tek başına karar değildir: Neden tek başına yetmez?

SLA, ölçüme ve telafiye ilişkin çerçeveyi verir; ancak “yüksek performans” ile “stabil çalışma” her zaman aynı şey değildir.

Aşağıdaki faktörler SLA hedefini tamamlar, eksik bıraktığı yerleri kapatır:

• Gizli performans kriterleri: CPU throttling, storage IOPS limitleri
• Gerçek zamanlı izleme: sizin uygulama bazlı takip (APM/log)
• Yedekleme (backup) stratejisi: sadece erişilebilirlik değil veri kaybı riski
• Failover/replication: kesinti sonrası toparlanma hızı

Bir örnek: SLA “uptime” hedefini tutsa bile uygulama yavaş yanıt verebilir. Bu durumda kullanıcı deneyimi etkilenir; SLA telafisi genellikle devreye girmez. Bu yüzden SLA ile birlikte kaynak limitleri, storage sınıfı ve throttling politikaları da değerlendirilmelidir.

Sonuç: SLA’yı puanlayın, ardından servis tasarımını tamamlayın

Hosting seçerken SLA’yı sadece yüzdesine bakarak değerlendirmeyin. Önce SLA kapsamı (hangi katman ölçülüyor), sonra istisnalar (hangi kesintiler downtime sayılmıyor) ve en son telafi koşulları (otomatik mi, talep gerekiyor mu, cap var mı) üzerinden net bir puanlama yapın. Daha sonra da kendi tarafınızda yedekleme (backup), izleme ve uygulama kurtarma adımlarını (log/alert/restore akışı) SLA’nın yakalayamadığı senaryolar için devreye alın.

Aksiyon önerisi: İncelediğiniz her sağlayıcı için yukarıdaki kontrol listesi tablosunu doldurun; ardından “ölçüm yöntemi ve telafi” tarafı daha net ve daha uygulanabilir olan seçeneği önceliklendirin.