SLA (Service Level Agreement) nedir, ne kadar önemli?

SLA (Service Level Agreement), hosting ve sunucu hizmetlerinde “hangi koşullarda ne kadar hizmet” verileceğini yazılı hale getirir. Uptime (erişilebilirlik), yanıt süreleri ve destek kapsamı gibi metrikler; sorun çıktığında hangi sürede müdahale edileceğini ve hangi durumda tazminat/iyileştirme bekleyebileceğinizi belirler. Bu yazıda SLA’nın terimlerini net biçimde çözecek, yüzde 99.9 gibi ifadelerin pratikte kaç dakikaya karşılık geldiğini hesaplayacak ve SLA’yı gerçekten nasıl test edeceğinizi öğreneceksiniz.

SLA’da en sık geçen kavramlar: Sadece “% uptime” değil

SLA dokümanları genellikle tek bir cümleden oluşmaz; birden fazla ölçüm ve kapsam maddesi içerir. Hosting alırken asıl farkı yaratan kısım, “nerede ölçülür, ne sayılır, hangi koşullar hariçtir” kısmıdır.

Uptime / Availability (erişilebilirlik)

Uptime genelde saat/gün bazında hesaplanır. Önemli noktalar: - Ölçüm periyodu: Aylık mı yıllık mı hesaplanıyor? - Ölçüm lokasyonu: Nereden ölçülüyor (Türkiye mi, Avrupa mı, tek noktadan mı)? - Ölçüm yöntemi: ICMP ping mi, HTTP kontrolü mü, uygulama endpoint’i mi? - Hariç tutulanlar: Planlı bakım, DDoS, üçüncü parti ağ sorunları, müşteri kaynaklı kesintiler.

RTO / RPO (opsiyonel ama kritik)

Bazı sağlayıcılar SLA yanında DR/İş sürekliliği hedefleri verir: - RTO (Recovery Time Objective): Sistemin ne kadar sürede geri döneceği. - RPO (Recovery Point Objective): Ne kadar veri kaybına izin verildiği.

Her hosting SLA’sında RTO/RPO olmayabilir; ancak dedicated sunucu veya kritik iş yükleri için bunlar sözleşmede açık yazılmadığında beklenti yönetimi zorlaşır.

Destek SLA’sı: Yanıt süresi ve çözüm hedefi

Uptime yanında sık görülen metrikler şunlardır: - İlk yanıt (First Response): Talep açıldıktan sonra kaç dakika içinde dönüş yapılacağı. - Çözüm süresi (Resolution Time): Sorunun kalıcı giderilmesi için hedef. - Öncelik seviyeleri: P1/P2/P3 gibi sınıflar ve hangi arızaya hangi sınıf verileceği.

Burada pratik hedef şudur: Uptime kaç olursa olsun, destek SLA’sı belirleyicidir. Çünkü kesinti anında ilk dakikalarda doğru teşhis konmazsa kayıp uzar.

Süreç tanımı: “Planlı bakım” ve “Maintenance Window”

Bir sağlayıcı yüzde 99.9 uptime taahhüdünde bulunabilir; ancak ay içinde uzun planlı bakım pencereleri varsa, ölçümün nasıl etkilendiğini bilmek gerekir.

SLA dokümanında şu sorular net olmalıdır: - Planlı bakım uptime hesaplamasına dâhil mi hariç mi? - Bakım tarih/saat aralığı ve bildirim süresi (ör. 48 saat önceden). - Bakımın türü (reboot mi, kernel update mi, veri merkezi müdahalesi mi) ve etkisi.

%99.9, %99.99 gibi rakamlar: Gerçekte kaç dakika kesinti?

SLA’daki yüzde uptime rakamları tek başına anlaşılır değildir; pratikte “kaç dakikalık kesinti” demek gerektiği hesaplanmalıdır. Aşağıdaki hesaplar günlük 24 saat bazına göre düşünülmüştür.

Aylık yaklaşık kesinti (30 gün = 720 saat): - %99.9 uptime: 720 × 0.001 = 0.72 saat ≈ 43 dk - %99.95 uptime: 720 × 0.0005 = 0.36 saat ≈ 22 dk - %99.99 uptime: 720 × 0.0001 = 0.072 saat ≈ 4.3 dk - %99.999 uptime: 720 × 0.00001 = 0.0072 saat ≈ 26 sn

Yıllık yaklaşık kesinti (365 gün ≈ 8760 saat): - %99.9: 8760 × 0.001 = 8.76 saat - %99.99: 8760 × 0.0001 = 0.876 saat ≈ 52 dk

NetKıyas’ta karşılaştırma yaparken tek bakılacak şey “yüzde” değildir. Sağlayıcının: 1) hangi ölçümü yaptığı, 2) hangi kesintileri hariç tuttuğu, 3) destek SLA’sını, 4) tazminat/iyileştirme mekanizmasını bir arada incelemeniz gerekir.

SLA neden kritik? Çünkü kesinti maliyeti dakikalarla büyür

SLA’nın önemi yalnızca “iyi görünmesi” değil; kesintinin finansal/operasyonel etkisini azaltmasıdır.

Örnek 1: E-ticaret ve ödeme akışı

Uptime hedefi tutsa bile, destek SLA’sı yavaşsa ödeme akışı toparlanması uzar. Bu durumda asıl kayıp yalnızca erişilebilirlik değil; ödeme başarısızlıkları, sepet terk oranı ve destek yüküdür.

Örnek 2: SEO ve crawl bütçesi

Siteniz arada kısa süreli dönmezlik yaşarsa arama botları sayfayı daha geç tekrar tarayabilir. Ayrıca kontrol paneli/uygulama endpoint’leri farklı davranıyorsa (örn. ana domain dönerken API dönmüyorsa), kullanıcı deneyimi de etkilenir.

Örnek 3: Uptime’ın “tanım” farkı

Bazı sağlayıcılar uptime’ı ICMP ping ile ölçer. Web uygulaması ise sağlık kontrolünde sorun yaşayabilir. Bu yüzden SLA metriklerini hangi endpoint üzerinden ölçtüklerini sorgulamak gerekir.

SLA’yı değerlendirme: Net kontrol listesi (satın almadan)

Aşağıdaki listeyi, sağlayıcı SLA dokümanını okurken tek tek ilerleyin.

1) Ölçüm yöntemi net mi?

Şunlar yazılı mı? - Uptime ölçümü HTTP/HTTPS endpoint mi yoksa ping mi? - Ölçüm noktası (region/ülke) belirtilmiş mi? - Ölçüm sıklığı ve yöntem dokümante mi?

Kontrol sorusu: “SLA ihlali hesaplaması hangi URL/port üzerinden yapılıyor?”

2) Hariç tutulan durumlar gerçekçi mi?

Sık hariçler: - Müşteri hatası / yanlış yapılandırma - Kullanıcı trafiği kaynaklı aşırı yük - DDoS saldırı türleri ve mitigation süreci - Planlı bakım

Hariçlerin sayısı değil, kapsamı önemlidir. Örneğin DDoS hariç tutuluyorsa, sağlayıcı DDoS koruma için ne garanti veriyor? Yoksa sadece “hariç” mi diyor?

3) Destek SLA’sı hangi arızaları kapsıyor?

Aşağıdaki ayrım net değilse, “SLA var” demek çoğu zaman yetersiz kalır: - Ağ kesintisi mi, disk doluluğu mu, kernel panic mi? - Donanım arızasında iade/yenileme hedefi var mı? - Destek kanalları: e-posta, bilet, çağrı hattı; çalışma saatleri.

Kontrol sorusu: “P1 arıza tanımı ve ilk yanıt süresi kaç dakika?”

4) Tazminat/credit mekanizması var mı ve nasıl çalışıyor?

Bazı sağlayıcılar SLA ihlalinde sadece küçük bir indirim verir; bazısı ise krediyi “ücretin yüzdesi” olarak tanımlar.

İhlal durumunda: - Tazminat ne kadar? - Tazminat hangi şartla? - Ölçüm dönemi ve başvuru süresi var mı?

Net hedef: Tazminatın “olaydan sonra” bile anlamlı olması.

5) Bakım pencereleri SLA’dan düşüyor mu?

• Planlı bakım bildirim süresi kaç gün/saat?
• Uptime hesabına etkisi “dâhil/hariç” açık mı?

SLA ile ilgili sık yapılan hatalar (karşılaştırırken kaçının)

1) Sadece yüzde uptime’a bakmak: Örneğin %99.9 iyi görünebilir ama ölçüm ping ile yapılır ve web endpoint’i farklıdır. 2) Destek SLA’sını göz ardı etmek: İlk yanıt süresi uzarsa kesinti uzar. 3) Hariçleri okumamak: “Her şey hariç” gibi geniş hariçler, SLA’nın pratik değerini düşürür. 4) Tazminatın nasıl verildiğini sormamak: İndirim varsa bile işlem süreci zor ise pratikte kullanılmayabilir. 5) Uptime hedefi ile performansı karıştırmak: SLA genellikle erişilebilirliği tanımlar; hız/IOPS gibi performans değerleri ayrı hükümlerde olabilir.

VDS/VPS/dedicated için SLA farklılaşır: Hangi beklentiye hangi madde bakılır?

SLA’yı ürün türüne göre değerlendirmek gerekir. Aşağıdaki tablo, “hangi beklenti hangi doküman maddesiyle ilişkili”yi hızlı görmenizi sağlar.

Not: Her sağlayıcı aynı terminolojiyi kullanmaz. “Availability” yerine “Uptime”, “Support response” yerine “Ticket response” görebilirsiniz; içerik aynı mı diye metni karşılaştırın.

H3: SLA’nın performansla ilişkisi (yanlış beklentiyi düzeltin)

Bir barındırma hizmeti “yüksek uptime” vaat edebilir; ancak CPU throttle, disk IOPS limiti veya bant darboğazı performansı düşürür. Bu yüzden SLA metni yanında şu dokümanlar da önem taşır: - Kaynak limitleri (CPU burst, memory garanti, disk türü) - Bant/Trafik politikası (“adil kullanım” maddeleri) - Ağ gecikmesi ölçümü (latency) ve bakım prosedürleri

NetKıyas’ta VDS/VPS karşılaştırması yaparken performans testleri ve kaynak tanımlarıyla birlikte SLA’yı birlikte okumak, hatalı karar riskini azaltır.

Pratik test: SLA’yı “kâğıt üstünden” doğrulama

Sözleşme tek başına yetmez. Kendi ölçümünüz, SLA metriklerinin pratikte nasıl karşılık geldiğini görmenizi sağlar.

1) Uptime izleme (uptime monitoring)

• HTTP/HTTPS endpoint izleme kurun (ör. /health gibi uygulama seviyesinde).
• Farklı lokasyonlardan izleme yapın.
• Kesinti anlarını loglarınızla eşleştirin (web server log, uygulama log).

2) Yanıt süresi ve kesinti kayıtları

SLA destek yanıt sürelerini doğrulamak için: - Bilet açma saatini yazın. - İlk yanıt saatini kaydedin. - Aynı sınıftaki arızalarda tekrarlayın.

3) Değişiklik yönetimi

Planlı bakımda ne olacağını anlamak için: - Bildirim geldiğinde uygulamanızın beklenen şekilde davranıp davranmadığını kontrol edin. - Güncelleme/reboot sonrası otomatik servis ayağa kalkışını test edin.

Sonuç: SLA’yı “yüzde” olarak değil, “ölçüm + kapsam + destek” olarak değerlendirin

NetKıyas’ta bir hizmeti değerlendirirken SLA dokümanını sadece “%99.9” gibi rakamlarla okumayın. Ölçüm yöntemi (hangi endpoint), hariç tutulan durumlar, destek yanıt süresi ve tazminat mekanizmasını birlikte kontrol edin; ardından kendi izleme sisteminizle bunu doğrulayın. Aksiyon olarak, satın alma kararından önce SLA metninden bu 5 başlığı işaretleyin: ölçüm yöntemi, planlı bakım, hariçler, destek SLA’sı (P1/P2), tazminat/credit koşulları. Bu yaklaşım, kesinti yaşandığında kimin neyi hangi sürede yapacağını netleştirir.