SLA (Service Level Agreement) nedir? Uptime garantisi nasıl okunur?

SLA (Service Level Agreement), bir hosting veya bulut hizmetinde sağlayıcının taahhütlerini yazılı hale getirir. Uptime (erişilebilirlik) garantisi kadar; ölçüm yöntemi, istisnalar, destek yanıt süreleri ve oluşan aksaklıkta nasıl telafi edileceği de bu doküman içinde yer alır. Bu yazıda SLA’nın hangi bölümleri kritik olduğunu, “%99.9” gibi sayıları nasıl hesapladığınızı ve satın alma kararı öncesi hangi maddeleri mutlaka kontrol etmeniz gerektiğini net şekilde öğreneceksiniz.

SLA neyi kapsar? (Uptime, destek, performans)

Bir SLA tek bir metrikten ibaret değildir. Hosting dünyasında SLA genellikle şu başlıklarda taahhüt verir:

Uptime/erişilebilirlik: Sunucunun veya servis bileşeninin (ör. web servis, API, kontrol paneli) belirli bir zaman diliminde çalışır durumda olması.
Yanıt süresi (response time) ve destek SLA’sı: Ticket açıldığında ilk yanıt, çözüme giden yol gibi hedefler.
Performans ölçümleri: Bazı planlarda CPU/RAM garantisi, ağ gecikmesi veya bant genişliği konusunda hedefler bulunabilir.
Bakım pencereleri (maintenance windows): Planlı kesintiler SLA’dan düşer mi düşmez mi açıkça yazılır.
Telafi/servis kredisi (service credits): SLA hedefi tutmazsa uygulanacak indirim veya kredi mekanizması.

Uptime SLA’sı neden tek başına yetmez?

Uptime hedefi tutsa bile site yavaş açılabilir, veri kaybı yaşanabilir veya belirli coğrafyalarda erişim sorunlu olabilir. Bu nedenle SLA okunurken aşağıdaki ayrımı yapın:

“Çalışır durumda olma” mı garanti ediliyor? (ör. “reachable”)
“Kullanıcının işlem yapabilmesi” mi garanti ediliyor? (ör. DB sorgusu, panel login)
Hangi katmanda? (fiziksel sunucu, sanallaştırma katmanı, ağ, DNS)

“%99.9” ne demek? Aylık kayıp nasıl hesaplanır?

SLA’lar çoğu zaman şu ifadelerle gelir: %99.9, %99.95, %99.99 gibi. Bu yüzdeler “planlanmamış kesinti” üzerinden hesaplanır. NetKıyas’ta karşılaştırdığınızda şu çerçeveyi her SLA için kurun: “Yüzde hangi zaman aralığına göre?” ve “Kesinti nasıl tanımlanıyor?”

Aylık pratik hesap için 30 günlük zaman aralığını kullanabilirsiniz:

Toplam süre: 30 gün = 720 saat
%99.9 uptime -> izin verilen kesinti: 720 saat x 0.001 = 0.72 saat = 43.2 dakika
%99.95 uptime -> izin verilen kesinti: 720 saat x 0.0005 = 0.36 saat = 21.6 dakika
%99.99 uptime -> izin verilen kesinti: 720 saat x 0.0001 = 0.072 saat = 4.32 dakika

Buradaki kritik nokta: Bu “dakika” miktarı genellikle planlanmamış kesintiler içindir. Planlı bakım, ağ yönlendirme değişimleri, DDoS koruması altında bazı durumlar veya sağlayıcının kontrolü dışındaki arızalar çoğu SLA’da istisna olabilir.

SLA metrikleri arasındaki en önemli 3 fark

Zaman penceresi: Aylık mı, yıllık mı? “Takvim ayı” mı “faturalandırma ayı” mı?
Kesinti tanımı: “Herhangi bir erişim kaybı” mı, “servisin tamamen down olması” mı?
Ölçüm kaynağı: Sağlayıcının kendi izleme sistemleri mi, sizin raporladığınız ölçümler mi?

Telafi (service credits) ne kadar değerli?

SLA tutmazsa verilen “kredi” veya indirim, çoğu kullanıcı için beklediği kadar hızlı ve tatmin edici olmayabilir. Bu yüzden krediyi şu sorularla değerlendirin:

Kredi oranı: Uptime hedefi her kaç saat aşılırsa/kaç puan düşerse kredi ne kadar?
Üst sınır: Aylık alabileceğiniz kredi maksimum kaç X aylık ücret? (sıklıkla tavan olur)
Otomatik mi, talep mi?: Sağlayıcı krediyi otomatik mi verir, yoksa ticket ile başvuru şart mı?
Kredi nakit mi?: Genelde “service credit” faturalara mahsup içindir; yeni ay için küçük bir indirim gibi kalabilir.

NetKıyas’ta karşılaştırırken kullanabileceğiniz değerlendirme modeli

Şu 4 adımlı kontrolle SLA kredisini anlamlandırın:

SLA hedefini bulun: “Aylık %99.x”
O hedefin izin verdiği kesintiyi hesaplayın (dakika cinsinden)
Hangi istisnalar kesintiyi “kesinti” saymıyor görün
Kredinin size gerçek değerini hesaplayın: Aylık ödemenizin kaçta kaçı?

Örnek (genel mantık): Aylık 300 TL ödüyorsanız ve SLA kredi tavanı 50 TL ise; beklenen telafi pratikte sınırlıdır. Bu, “SLA yazıyor ama risk yüksek” yorumunu destekler.

İstisnalar: SLA’nın çoğu kullanıcıyı etkileyen kısmı

SLA’nın en problemli bölümü genellikle “limitations / exclusions / service not covered” başlığıdır. Aşağıdaki maddeler sık görülür ve “kesinti oldu” diyebilmenizi engelleyebilir:

Planlı bakım: Önceden bildirilen bakım pencereleri (maintenance windows) SLA dışı olabilir.
Müşteri kaynaklı problemler: Yanlış yapılandırma, hatalı uygulama değişiklikleri, kontrol paneli kullanıcı eylemleri.
Üçüncü taraflar: Domain/DNS sağlayıcısı, upstream internet sağlayıcıları, CDN katmanı.
DDoS olayları: Koruma sistemleri bazı durumlarda SLA kapsamı dışında değerlendirilir.
Aşırı kullanım (fair usage): Bant genişliği/CPU limitlerinin aşılması veya throttling (hız kısıtlama).
Karşılanmayan koşullar: Sizden istenen log, erişim testi veya takip araçlarını sağlayamıyorsanız telafi talebi reddedilebilir.

İnce okuma için SLA kontrol listesi

Satın alma öncesi şu ifadeleri metinden arayın:

“Service Credits” (kredi mekanizması)
“Exclusions / Not covered” (hariç tutulanlar)
“Measurement period” (ölçüm dönemi)
“Planned maintenance” (planlı bakım)
“Notification” (bildirim şartı)
“How to claim” (telafi başvurusu nasıl yapılır)

Destek SLA’sı neden kullanıcı deneyimi için kritiktir?

Uptime kadar önemli bir başka metrik destek SLA’sıdır. Çünkü bir kesinti başladığında ilk dakikalar belirleyicidir: Uygulama çöktüyse veri kaybı riski doğar, trafik kaybı hızlanır.

Destek SLA’sında bakmanız gerekenler

İlk yanıt süresi (örn. “kritik olayda 15 dk içinde ilk yanıt”)
Çözüm/ilerleme güncellemeleri (örn. “her 1 saatte durum güncellemesi”)
Seviye tanımı: “Seviye 1/Seviye 2” ne demek? Kritik kesinti nasıl belirleniyor?
Ekip erişimi: Sadece otomatik bot mu, yoksa sistem mühendisleri devreye giriyor mu?

Bu alanlar özellikle VDS/VPS ve yönetilmeyen (unmanaged) senaryolarda önemlidir. Yönetilen servislerde, sağlayıcının sizin müdahaleniz olmadan sorunu sınırlaması beklenir.

SLA metnini teknik gereksinimle eşleştirme

SLA’yı okuduktan sonra kendi uygulamanızı şu katmanlara ayırın:

Uygulama erişilebilirliği: Web/API çalışıyor mu?
Veri katmanı: DB erişimi var mı, replikasyon var mı?
İletim katmanı: Ağ gecikmesi, packet loss, routing.
Dış bağımlılıklar: CDN, DNS, e-posta, üçüncü taraf ödeme sağlayıcıları.

Sağlayıcı SLA’sı çoğu zaman “sunucu ayağa kalktı”yı garanti eder; veri bütünlüğü veya uygulama sağlığı için ayrı dokümanlar gerekebilir. Bu yüzden SLA ile birlikte şu dokümanları da isteyin/inceleyin:

Yedekleme (backup) politikası: Sıklık (günlük/saatsel), saklama süresi, geri dönüş (restore) zamanı hedefi.
Felaket kurtarma (disaster recovery) / replikasyon: Hedef RPO/RTO değerleri varsa önemlidir.
Bant genişliği ve throttling: Trafik limitleri SLA kapsamına dahil mi değil mi?

Pratik senaryolar: Hangi SLA seviyesi kimi korur?

Aşağıdaki örnekler, SLA seviyelerinin gerçek hayatta nasıl karşılık bulduğunu göstermek içindir:

Kurumsal web sitesi (düşük-orta trafik): %99.9 çoğu zaman yeterli görünse de; destek yanıt süresi ve planlı bakım hariçlerinin kapsamı belirleyicidir.
E-ticaret (ödeme akışı): Sadece uptime değil; DB/önbellek (cache) erişimi ve geri dönüş süresi kritik. “Çalışıyor gibi” ama işlem yapılamıyorsa SLA metrikleri yine de karşılamayabilir.
API servisleri / entegrasyonlar: Yanıt süresi ve ölçüm yöntemi (servis availability mi, endpoint availability mi) net yazılmalıdır.
Canlı yayın / video: Uptime yanında bant genişliği planlaması ve ağ kalitesi gerekir; SLA’da sadece CPU uptime yazıyorsa beklentiyi yanlış kurabilirsiniz.

Satın alma kararı için net aksiyon önerisi

SLA’yı “en yüksek rakam yazıyor” diye seçmeyin. Kararı şu sırayla verin:

Uptime hedefini bulun ve aylık izin verilen kesintiyi dakika olarak hesaplayın.
SLA’nın planlı bakım ve istisna maddelerini kontrol edin; sizin kullanım senaryonuza denk geliyor mu bakın.
Telafi service credit mekanizmasının otomatik olup olmadığını ve tavanını öğrenin.
Destek SLA’sı (ilk yanıt ve güncelleme) kritik olaylar için yeterli mi kontrol edin.
SLA’ya ek olarak yedekleme ve (varsa) RPO/RTO hedeflerini değerlendirin.

Bu adımları tamamladıktan sonra sağlayıcı seçiminiz “kulağa iyi geliyor” yerine “ölçülebilir ve yönetilebilir” hale gelir. NetKıyas karşılaştırmalarında SLA metninin bu bölümlerini özellikle kıyaslayın; seçiminizi dakika, kredi ve istisnalar üzerinden netleştirerek riski somut şekilde yönetin.