SLA Nedir? Hizmet Seviyesi Anlaşması ve Önemi Hakkında Rehber

Bir hosting, sunucu ya da bulut hizmeti satın aldığınızda yalnızca teknik özellikleri değil, sağlayıcının size verdiği sözleşmesel taahhütleri de satın alırsınız. Bu taahhütlerin yazılı hâli SLA‘dır. SLA, “sunucum çökerse ne olur, yanıt süresi nedir, zarar ettiğimde ne tazminat alırım?” sorularının cevaplarını içerir. Pazarlama broşürlerindeki “%99.9 uptime” ifadesinin gerçekten ne anlama geldiğini ancak SLA’yı okuyarak anlarsınız. Bu yazıda SLA nedir, hangi bileşenlerden oluşur, neden bu kadar önemlidir ve bir hizmet alırken SLA’yı nasıl değerlendirmeniz gerektiğini ayrıntılı biçimde inceleyeceğiz.

SLA Nedir?

SLA, İngilizce Service Level Agreement ifadesinin kısaltmasıdır; Türkçe karşılığı Hizmet Seviyesi Anlaşması‘dır. Bir hizmet sağlayıcı ile müşteri arasında imzalanan, hizmetin hangi kalitede sunulacağını sayısal ve ölçülebilir biçimde tanımlayan resmi sözleşmedir.

SLA yalnızca “hizmet sunulacaktır” gibi belirsiz bir vaat değildir; aksine somut metriklerle desteklenir:

• Hizmetin yıllık çalışır kalma süresi (uptime)
• Kesinti durumunda müdahale ve çözüm süreleri
• Destek taleplerine yanıt süreleri
• Taahhütlerin karşılanmaması hâlinde uygulanacak yaptırımlar (kredi, iade, ceza)

SLA hem hosting/bulut/sunucu hizmetlerinde hem de yazılım geliştirme, bakım, çağrı merkezi gibi alanlarda kullanılır. Bu yazıda ağırlıklı olarak hosting ve sunucu hizmetleri açısından inceleyeceğiz.

SLA Neden Önemlidir?

SLA’nın önemi, hizmet alımının görünmeyen tarafını yazılı hâle getirmesinden gelir. Net bir SLA’nın size kazandırdıkları:

• Belirsizliği ortadan kaldırır: Sağlayıcının size ne taahhüt ettiği, hangi şartlarda ne yapacağı yazılıdır; sözlü vaatlere bağımlı kalmazsınız.
• Beklentileri hizalar: “7/24 destek” ifadesinin “anında yanıt” mı, “4 saat içinde yanıt” mı olduğunu netleştirir.
• Hesap verebilirlik sağlar: Sağlayıcı taahhüdünü tutmadığında somut bir yaptırım (kredi, iade) devreye girer.
• Risk yönetimini kolaylaştırır: Sitenizin/uygulamanızın hangi sıklıkta ve hangi sürede aşağıda olabileceğini önceden bilirsiniz; iş sürekliliği planınızı buna göre yaparsınız.
• Sağlayıcılar arasında karşılaştırma yapmanızı sağlar: Aynı fiyata farklı SLA sunan iki sağlayıcıdan hangisinin gerçekten avantajlı olduğunu objektif değerlendirebilirsiniz.
• Hukuki dayanak oluşturur: Anlaşmazlık durumunda referans alınacak temel belge SLA’dır.

Kısacası SLA, bir “iyi niyet metni” değildir; ölçülebilir taahhüt + yaptırım içerir ve hizmetin temel kalite garantisidir.

Bir SLA’da Bulunması Gereken Temel Maddeler

Güçlü bir SLA, en azından aşağıdaki başlıkları net biçimde tanımlamalıdır:

1. Hizmet Tanımı ve Kapsamı

Sözleşmenin hangi hizmeti kapsadığı açık olmalıdır: web hosting mi, VDS mi, e-posta servisi mi, yedekleme mi? Kapsama girmeyen unsurlar (örneğin “üçüncü taraf yazılımlar SLA dışındadır”) da yazılı belirtilmelidir.

2. Çalışma Süresi (Uptime) Garantisi

SLA’nın en bilinen maddesidir. Yıllık ya da aylık olarak hizmetin minimum hangi oranda çalışacağı belirtilir. Örneğin “%99.9 uptime” gibi.

3. Yanıt ve Çözüm Süreleri

Destek talebine ne kadar sürede yanıt verileceği ve sorunun ne kadar sürede çözüleceği ayrı ayrı tanımlanır. Genelde öncelik seviyelerine (kritik / yüksek / orta / düşük) göre farklı süreler belirlenir.

4. Performans Metrikleri

Yalnızca “çalışıyor olması” yetmeyebilir; bazı SLA’lar yanıt süresi (latency), işlem gecikmesi (throughput), disk IOPS, ağ kapasitesi gibi performans metrikleri de tanımlar.

5. Bakım Pencereleri

Planlı bakım çalışmalarının ne zaman, hangi sıklıkta ve ne kadar süreyle yapılacağı yazılır. Planlı bakım çoğunlukla uptime hesabının dışında tutulur; bu nüans önemlidir.

6. SLA İhlali ve Kredi Politikası

Taahhüt edilen seviyeye ulaşılamadığında ne olacağı net biçimde belirtilir. Genelde “hizmet kredisi” şeklindedir: yıllık ücretin belirli bir yüzdesi bir sonraki faturadan düşülür.

7. Sorumluluk Sınırları (Liability) ve İstisnalar

Doğal afet, mücbir sebep, DDoS, müşteri kaynaklı yapılandırma hataları gibi durumların SLA dışında tutulduğu istisna maddeleri yer alır. Bu kısım SLA’nın en dikkatli okunması gereken bölümüdür.

8. Raporlama ve Şeffaflık

Uptime ölçümünün hangi araçla yapıldığı, müşterinin bu verilere nasıl erişeceği (status sayfası, aylık rapor) belirtilir.

9. Sözleşme Süresi ve Sonlandırma

SLA’nın geçerlilik süresi, yenileme şartları ve fesih hakkı tanımlanır.

Uptime Yüzdelerinin Gerçekte Ne Anlama Geldiği

“%99 uptime” ile “%99.999 uptime” birbirine çok benzer görünür; oysa pratikteki kesinti süreleri arasında büyük fark vardır. Aşağıdaki tablo yıllık kesinti karşılığını gösterir:

• %99 (iki dokuz): Yıllık yaklaşık 3 gün 15 saat 36 dakika kesinti
• %99.5: Yıllık yaklaşık 1 gün 19 saat 48 dakika kesinti
• %99.9 (üç dokuz): Yıllık yaklaşık 8 saat 46 dakika kesinti
• %99.95: Yıllık yaklaşık 4 saat 23 dakika kesinti
• %99.99 (dört dokuz): Yıllık yaklaşık 52 dakika 36 saniye kesinti
• %99.999 (beş dokuz): Yıllık yaklaşık 5 dakika 15 saniye kesinti

Görüldüğü gibi her “ek dokuz” hem operasyonel maliyeti hem de altyapı yatırımını ciddi şekilde artırır. Kurumsal e-ticaret ya da finans uygulamaları için %99.99 ve üzeri bir SLA aranırken, küçük bir blog için %99.9 çoğunlukla yeterlidir.

SLA Hangi Şekillerde Karşımıza Çıkar?

SLA’lar tek bir kalıpta değil, ilişki türüne göre farklı şekillerde sunulur:

• Müşteri tabanlı SLA: Tek bir müşteri için özel olarak hazırlanır. Genelde kurumsal sözleşmelerde görülür.
• Hizmet tabanlı SLA: Aynı hizmeti alan tüm müşterilere uygulanan standart sözleşme. Hosting paketlerinde en yaygın olanıdır.
• Çok seviyeli (multi-level) SLA: Hem kurumsal hem hizmet bazlı maddeleri birleştirir. Örneğin sağlayıcı seviyesinde genel uptime, müşteri seviyesinde özel destek süresi içerir.
• İç (internal) SLA: Şirket içinde bir bölümün (örneğin IT departmanının) diğer bölümlere verdiği taahhüt. Dış müşteri içermez.

SLA, SLO ve SLI Arasındaki Fark

Modern operasyon (SRE / DevOps) ekipleri SLA’yı tek başına değil, iki kardeş kavramla birlikte konuşur:

• SLI (Service Level Indicator): Ölçtüğünüz somut metriktir. Örneğin: “HTTP isteklerinin %99’unun 300 ms altında yanıtlanma oranı.”
• SLO (Service Level Objective): İç hedefinizdir. Ekibin kendine koyduğu, müşteriye söz vermediği seviyedir. Örneğin: “Aylık uptime %99.95 olmalı.”
• SLA (Service Level Agreement): SLO’nun müşteriye sözleşmeyle taahhüt edilmiş ve cezası tanımlanmış hâlidir. Örneğin: “%99.9 uptime sağlanmazsa aylık ücretin %10’u kredi olarak iade edilir.”

Pratikte sağlayıcılar SLO’larını SLA’larından bir tık daha yüksek tutar; böylece SLA ihlali olmadan önce iç alarmları devreye girer.

SLA Kredisi Nasıl Hesaplanır?

SLA ihlali yaşandığında verilen tazminat çoğunlukla “hizmet kredisi” şeklindedir, yani parasal iade değil bir sonraki faturadan indirimdir. Tipik bir hosting SLA tablosu şuna benzer:

• Uptime %99.9 ile %99.0 arası: aylık ücretin %10’u kredi
• Uptime %99.0 ile %95.0 arası: aylık ücretin %25’i kredi
• Uptime %95.0 altı: aylık ücretin %50’si veya tamamı kredi

Kredi alabilmek için genelde müşterinin resmi olarak başvuru yapması, kesinti süresini kendi izleme araçlarıyla belgelemesi ve belirli bir süre içinde (genelde 30 gün) talebi iletmesi gerekir. Otomatik iade nadir görülür; bu yüzden uptime takibini kendi tarafınızdan da yapmak önemlidir.

SLA’da Sık Görülen “Küçük Yazılarla” Yazılmış İstisnalar

SLA’yı imzalamadan önce dikkat edilmesi gereken bölüm istisnalardır. En sık karşılaşılanlar:

• Planlı bakım kesintileri uptime hesabına dahil edilmez.
• DDoS saldırıları çoğu standart SLA’nın dışındadır. Koruma için ayrı bir DDoS SLA’sı gerekebilir.
• Müşteri kaynaklı hatalar (yanlış DNS, yanlış kod, yetersiz kaynak) sağlayıcıyı sorumlu tutmaz.
• Üçüncü taraf servisleri (CDN sağlayıcısı, ödeme entegrasyonu) çoğunlukla kapsam dışıdır.
• Mücbir sebepler (deprem, savaş, ulusal kesintiler) standart bir istisnadır.
• Beta veya deneysel hizmetler çoğu zaman SLA dışında tutulur.

Bu istisnaların kapsamı sağlayıcıdan sağlayıcıya çok değişir; aynı “%99.9” yazısının altında çok farklı taahhütler bulunabilir.

İyi Bir SLA Nasıl Değerlendirilir?

Bir hizmet alırken SLA’nın gerçekten ne kadar değerli olduğunu anlamak için şu soruları sorun:

1. Uptime nasıl ölçülüyor? Sağlayıcının kendi izleme aracı mı, bağımsız üçüncü taraf mı?
2. Planlı bakımlar uptime’a dahil mi? Değilse, yılda kaç saat planlı bakım yapılabilir?
3. Kredi yüzdeleri makul mü? %0.1’lik bir düşüş için %10 kredi mantıklı bir taahhüttür; %0.5 düşüş için yalnızca %5 kredi zayıftır.
4. Kredi otomatik mi, başvuru gerektiriyor mu? Otomatik kredi büyük artıdır.
5. Destek SLA’sı net mi? Yanıt süreleri sınıflandırılmış mı (kritik / yüksek / düşük)?
6. İstisna listesi ne kadar geniş? İstisnalar uzadıkça SLA’nın değeri düşer.
7. SLA müşteri görüşmesinde değiştirilebilir mi? Kurumsal müşteriler için bu pazarlık alanı vardır.

SLA Hangi Sektörlerde Daha Kritiktir?

Her hizmet için SLA önemlidir, ancak bazı sektörlerde kritiklik çok daha yüksektir:

• E-ticaret: Dakikalık kesinti doğrudan ciro kaybıdır; en az %99.95 hedeflenmelidir.
• Finans ve ödeme sistemleri: Yasal düzenlemeler %99.99+ SLA gerektirebilir.
• Sağlık ve kamu uygulamaları: Hizmet erişilebilirliği zorunluluktur.
• SaaS ürünler: Müşteriniz size SLA dayatabilir; sizin de altyapı SLA’nız buna eşdeğer olmalıdır.
• Medya ve canlı yayın: Yoğun trafik anlarında ağ ve CDN SLA’sı belirleyicidir.
• Bireysel blog ve tanıtım siteleri: %99.9 düzeyi genelde yeterlidir.

SLA’yı Müşteri Olarak Nasıl Takip Etmelisiniz?

SLA, yalnızca sağlayıcının imzasıyla değil, sizin aktif takibinizle anlam kazanır:

• Bağımsız uptime izleme servislerinden birini (örn. UptimeRobot, StatusCake, Better Stack) kullanın.
• Kesinti gördüğünüzde ekran görüntüsü, zaman damgası ve log ile kayıt altına alın.
• Sağlayıcının status sayfasını takip edin; bildirilen kesintilerin SLA hesabına dahil edilip edilmediğini sorgulayın.
• Aylık ya da çeyrek dönemlik olarak gerçek uptime’ı taahhüt ile karşılaştırın.
• SLA ihlali tespit ederseniz, kredi talebinizi yazılı olarak ve süresi içinde iletin.

Sıkça Sorulan Sorular

SLA ile sözleşme aynı şey midir?

Hayır. Genel sözleşme (Master Service Agreement) hizmetin hukuki çerçevesini çizer; SLA ise hizmetin ölçülebilir kalite seviyelerini ve ihlal sonuçlarını tanımlar. SLA çoğu zaman ana sözleşmenin bir ekidir.

%100 uptime garantisi mümkün müdür?

Pratikte değildir. Bazı sağlayıcılar pazarlama amaçlı %100 ifadesi kullanır; ancak küçük yazıda planlı bakım, mücbir sebep gibi istisnalar bunu fiilen %99.9x seviyesine indirir.

SLA ihlali olduğunda otomatik para iadesi alır mıyım?

Genelde hayır. Çoğu SLA “hizmet kredisi” verir, parasal iade değil. Ayrıca krediyi almak için resmi başvuru yapmanız gerekir; otomatik kredi nadir görülür ama varsa büyük artıdır.

Paylaşımlı hosting hizmetlerinde SLA gerçek anlamda işletilir mi?

Standart paylaşımlı hosting paketlerinde SLA genelde temel düzeydedir ve uptime taahhütleri sınırlıdır. Kritik uygulamalar için VDS, adanmış sunucu veya bulut çözümlerinin daha güçlü SLA’larını tercih etmek gerekir.

SLA, DDoS saldırılarını kapsar mı?

Standart SLA’ların büyük çoğunluğu DDoS’u istisna olarak tutar. DDoS koruması için sağlayıcının ayrıca DDoS Protection SLA‘sı olup olmadığını kontrol etmelisiniz.

Kendi müşterilerime SLA vermeli miyim?

Eğer kurumsal müşterilere hizmet veriyorsanız (ajans, SaaS, bayi hosting) evet. Ancak müşterinize verdiğiniz SLA, altyapı sağlayıcınızın size verdiği SLA’dan daha güçlü olamaz. Önce alt SLA’nızı netleştirin, üst SLA’nızı ona göre kurgulayın.

Sonuç

SLA, bir hizmetin pazarlama vaatlerinin ötesinde gerçek kalite taahhüdünü tanımlayan resmi belgedir. Uptime yüzdeleri, yanıt süreleri, kredi politikaları ve istisnalar; satın aldığınız hizmetin pratikteki güvencesini belirler. Doğru okunmuş bir SLA, hem beklentilerinizi gerçekçi tutar hem de bir sorun yaşandığında elinizdeki en güçlü dayanak olur. Hosting, sunucu ya da bulut hizmeti seçerken yalnızca fiyat ve özellik listesine değil, mutlaka SLA’nın somut maddelerine bakmalısınız.

Kolan’ın güçlü uptime taahhüdü ve şeffaf SLA politikasıyla sunduğu hosting ve sunucu çözümlerini kolan.net.tr/hosting adresinden inceleyebilir, ihtiyacınıza uygun paketi güvenle seçebilirsiniz.