SLA ve destek beklentileri: sözleşmede neye bakmalı?

Yazılım sözleşmelerindeki hizmet seviyesi taahhüdü (SLA), çoğu zaman okunmadan imzalanan bölüm. Oysa sistem çöktüğünde ya da kritik bir hata çıktığında elinizdeki tek araç o metin.

"%99,9 erişilebilirlik" ne demek?

Yüzdeler kulağa benzer geliyor ama aradaki fark büyük:

| Taahhüt | Aylık izin verilen kesinti | | --- | --- | | %99 | ~7 saat | | %99,5 | ~3,5 saat | | %99,9 | ~43 dakika | | %99,95 | ~22 dakika |

Asıl sorulması gereken üç soru:

1. Neyin erişilebilirliği ölçülüyor? Tüm sistem mi, yalnızca ana giriş sayfası mı? Bazı sözleşmelerde "sistem ayakta ama arama çalışmıyor" durumu kesinti sayılmıyor.

2. Nasıl ölçülüyor? Sağlayıcının kendi izleme aracıyla mı? Ölçümün şeffaf ve doğrulanabilir olması gerekiyor.

3. Planlı bakım hariç mi? Çoğu sözleşmede planlı bakım kesinti sayılmıyor. O hâlde bakım penceresinin ne kadar önce duyurulacağı ve hangi saatlerde yapılabileceği yazılı olmalı — mesai saatinde yapılan "planlı bakım", pratikte kesintidir.

Yanıt süresi ≠ çözüm süresi

En sık karıştırılan iki kavram:

• Yanıt süresi (response time): talebin alındığının bildirilmesi. Otomatik bir e-posta bile bu şartı karşılayabiliyor.
• Çözüm süresi (resolution time): sorunun giderilmesi.

Yalnızca yanıt süresi taahhüt eden bir SLA, pratikte az şey vaat ediyor. Kritik seviye için çözüm süresi ya da en azından geçici çözüm (workaround) süresi de tanımlı olmalı.

Önem seviyeleri

İyi bir SLA sorunları seviyelere ayırıyor ve her seviye için ayrı süre tanımlıyor. Tipik yapı:

• Kritik: sistem tamamen erişilemez ya da veri kaybı riski. En kısa süreler.
• Yüksek: temel bir işlev çalışmıyor, geçici çözüm yok.
• Orta: işlev kısmen etkileniyor, geçici çözüm var.
• Düşük: görsel hata, iyileştirme talebi.

Kritik noktası: seviyeyi kim belirliyor? Sağlayıcı belirliyorsa, sizin kritik dediğiniz sorun "orta" olarak sınıflanabiliyor. Sözleşmede itiraz mekanizması olmalı.

İhlal hâlinde ne oluyor?

Çoğu SLA'da yaptırım, hizmet kredisi (bir sonraki fatura döneminde indirim) biçiminde. Bu genellikle sembolik: bir günlük kesintinin iş kaybı, aylık ücretin küçük bir yüzdesi kadar krediyle karşılanmıyor.

Gerçek koruma, tekrarlayan ihlal hâlinde cezasız fesih hakkı. Sözleşmede bu madde varsa, sağlayıcının teşviki de doğru hizalanıyor.

Örnek: bordro günü kesintisi

Bir şirkette intranet üzerinden bordro görüntüleniyor. Ayın 15'i, bordro yayın günü ve sistem üç saat erişilemiyor.

Sözleşmeye göre aylık %99,5 taahhüdü var; üç saatlik kesinti bu sınırı aşıyor ve hizmet kredisi hakkı doğuyor. Kredi tutarı aylık ücretin küçük bir kısmı.

Gerçek maliyet ise bu değil: İK'ya gelen yüzlerce telefon, "bordrom yatmadı mı" paniği ve çalışanların sisteme güveninin sarsılması.

Bu örnek, SLA pazarlığında asıl bakılması gereken şeyi gösteriyor: tazminat tutarı değil, kritik günlerde bakım yasağı. Bordro, zam duyurusu ve yıl sonu gibi tarihlerde planlı bakım yapılamayacağının sözleşmeye yazılması, hizmet kredisinden çok daha değerli.

Destek kanalları ve kapsam

Sorulacaklar: Destek hangi saatlerde veriliyor (7/24 mi, mesai saatleri mi, hangi saat dilimi)? Hangi kanallardan (e-posta, telefon, portal)? Türkçe destek var mı? Kimler talep açabiliyor — herkes mi yoksa tanımlı yöneticiler mi?

Son madde önemli: yalnızca iki kişinin talep açabildiği bir yapıda, o iki kişi izindeyken süreç duruyor.

Kendi tarafınızdaki hazırlık

SLA tek taraflı bir vaat değil; sizin de yükümlülükleriniz var. Genellikle: sorunu yeterli bilgiyle bildirmek, erişim sağlamak, test ortamında doğrulamak.

Ayrıca iç tarafta bir olay müdahale planı gerekiyor: sistem çöktüğünde çalışanlara kim, nereden haber verecek? İntranet çalışmıyorsa duyuru intranetten yapılamaz — yedek kanal tanımlı olmalı. Kanal iş bölümünü iç iletişim kanal matrisi, kriz iletişimini kriz iletişimi yazısında ele aldık.

Çok kiracılı yapılarda ek sorular

Hizmet birden fazla şirketin aynı altyapıyı paylaştığı bir yapıda sunuluyorsa (çoğu bulut intranet böyle çalışıyor), SLA'ya birkaç soru daha eklemek gerekiyor.

Birincisi komşu etkisi: başka bir müşterinin yoğunluğu sizin performansınızı etkileyebiliyor mu, kaynak sınırlaması nasıl yapılıyor? İkincisi veri izolasyonu: verilerinizin başka müşterilerin verisinden nasıl ayrıldığı teknik olarak açıklanabiliyor mu? Mimariyi çok kiracılı mimari ve veri izolasyonu yazısında ele aldık.

Üçüncüsü güncelleme takvimi: yeni sürümler herkese aynı anda mı geliyor, erteleyebiliyor musunuz? Ortak altyapıda genellikle erteleme mümkün değil; bu, güncellemenin sizin için sürpriz olmaması adına önceden duyurulma süresini önemli kılıyor.

Dördüncüsü denetim erişimi: bağımsız güvenlik denetimi raporları paylaşılıyor mu? Kurumsal alıcıların giderek daha sık sorduğu bir madde; kapsamını ISO 27001 ve intranet yazısında ele aldık.

Sık sorulan sorular

Küçük şirkette SLA pazarlığı mümkün mü? Standart sözleşmelerde esneklik sınırlı; ancak bakım penceresi ve destek saatleri gibi maddeler çoğu zaman görüşülebiliyor.

Yedekleme SLA kapsamında mı? Ayrı bir konu ve mutlaka sorulmalı: yedek sıklığı, saklama süresi ve geri dönüş süresi. Ayrıntısını veri saklama ve yedekleme yazısında ele aldık.

Felaket senaryosu kapsanıyor mu? Bölgesel bir kesintide ne oluyor? Yaklaşımı felaket kurtarma planı yazısında ele aldık.

Fiyatla SLA arasında ilişki var mı? Genellikle var: daha yüksek taahhüt daha pahalı katmanda sunuluyor. Fiyatlandırma modellerini intranet fiyatlandırma modelleri yazısında karşılaştırdık.