SLA Nedir? Yazılım ve Web Projelerinde Hizmet Seviyesi Sözleşmesi

SLA (Service Level Agreement, Hizmet Seviyesi Sözleşmesi), bir hizmet sağlayıcının sunduğu hizmetin hangi kalitede, hangi sürelerle ve hangi ölçütlerle verileceğini; bu sözler tutulmadığında ne olacağını yazılı olarak tanımlayan anlaşmadır.

Bir web sitesi, mobil uygulama ya da kurumsal yazılım canlıya alındığında iş bitmez; asıl soru, o sistemin her gün ne kadar güvenilir çalışacağıdır. "Site çökerse ne olacak?", "Bir hata bildirdiğimde kaç saat içinde dönüş alırım?" gibi soruların cevabı SLA'da yazar. Bu yazıda SLA'nın temel kavramlarını, yüzdelerin gerçekte ne anlama geldiğini ve iyi bir sözleşmede bulunması gereken maddeleri ele alıyoruz.

SLA, SLO ve SLI arasındaki fark nedir?

Bu üç kısaltma sık sık birbirinin yerine kullanılır, ancak farklı şeyleri anlatır:

• SLI (Service Level Indicator, Hizmet Seviyesi Göstergesi): Ölçtüğünüz metriktir. Örneğin başarılı isteklerin oranı, sayfanın yanıt süresi ya da sistemin erişilebilir olduğu dakikaların oranı.
• SLO (Service Level Objective, Hizmet Seviyesi Hedefi): O metrik için belirlediğiniz iç hedeftir. "İsteklerin %99,9'u başarılı olsun" ya da "sayfaların %95'i 500 milisaniyenin altında yanıt versin" gibi.
• SLA (Service Level Agreement): Bu hedeflerin müşteriye verilen, yaptırımı olan sözleşme hâlidir. Hedef tutturulamazsa hizmet kredisi, ücret indirimi ya da fesih hakkı gibi sonuçlar doğar.

Sağlıklı bir yapıda iç hedef (SLO), sözleşmede taahhüt edilen değerden (SLA) daha sıkı tutulur. Böylece ekip, müşteriye verilen söz çiğnenmeden önce sorunu fark edip müdahale edebilir.

%99,9 erişilebilirlik gerçekte ne kadar kesinti demek?

Erişilebilirlik (uptime) yüzdeleri kâğıt üzerinde birbirine çok yakın görünür, ama aradaki farklar ciddi kesinti sürelerine karşılık gelir:

• %99: Yılda yaklaşık 3,65 gün, ayda yaklaşık 7 saat 18 dakika kesinti.
• %99,5: Yılda yaklaşık 1,8 gün, ayda yaklaşık 3 saat 39 dakika.
• %99,9: Yılda yaklaşık 8 saat 46 dakika, ayda yaklaşık 44 dakika.
• %99,95: Yılda yaklaşık 4 saat 23 dakika, ayda yaklaşık 22 dakika.
• %99,99: Yılda yaklaşık 53 dakika, ayda yaklaşık 4 dakika.

Her ek "dokuz", altyapıda, izlemede ve operasyonda belirgin biçimde daha fazla yatırım gerektirir. Bu nedenle doğru soru "en yüksek yüzde hangisi?" değil, "bu sistem bir saat kapalı kalırsa işimize maliyeti ne olur?" sorusudur. Bir kurumsal tanıtım sitesi için %99,5 çoğu zaman yeterliyken, ödeme alan bir e-ticaret altyapısı ya da operasyonu yöneten bir panel için %99,9 ve üzeri hedeflenir.

Yanıt süresi ve çözüm süresi neden ayrı tanımlanmalı?

SLA'larda en sık yaşanan yanlış anlaşılma, yanıt süresiyle çözüm süresinin karıştırılmasıdır. Yanıt süresi, bildiriminize bir uzmanın ilk dönüş yapmasına kadar geçen süredir. Çözüm süresi ise sorunun giderilmesine ya da kalıcı olmasa bile işi yürütmeye yetecek bir geçici çözümün devreye alınmasına kadar geçen süredir.

Bu sürelerin anlamlı olması için talepler öncelik seviyelerine ayrılır. Örnek bir yapı şöyle olabilir:

1. Kritik (P1): Sistem tamamen erişilemez ya da ödeme gibi temel bir işlev durmuş. Yanıt 30 dakika, geçici çözüm 4 saat içinde.
2. Yüksek (P2): Önemli bir işlev bozuk ama sistem çalışıyor. Yanıt 2 saat, çözüm 1 iş günü içinde.
3. Orta (P3): Kullanıcıları etkileyen ama çevresinden dolaşılabilen bir hata. Yanıt 1 iş günü, çözüm planlanan bir sonraki sürümde.
4. Düşük (P4): Görsel kusurlar, metin düzeltmeleri, küçük iyileştirme talepleri. Yanıt 2 iş günü, çözüm iş planına göre.

Buradaki süreler yalnızca örnektir; her projenin kritiklik düzeyine göre yeniden belirlenmelidir. Önemli olan, her seviyenin tanımının açık olması ve hangi talebin hangi seviyeye girdiğine kimin karar verdiğinin önceden yazılmasıdır. Ayrıca sürelerin "7/24" mü yoksa "iş saatleri içinde" mi işlediği net olmalıdır; hafta sonu açılan kritik bir talep ile pazartesi sabahı açılan bir talep arasındaki fark, sözleşmede bu ayrıntıya bağlıdır.

İyi bir SLA'da hangi maddeler bulunur?

Tek sayfalık bir taahhüt listesi yerine, aşağıdaki başlıkları kapsayan bir sözleşme hem müşteriyi hem hizmet sağlayıcıyı korur:

• Hizmetin kapsamı: Hangi sistemler, hangi ortamlar (canlı, test) ve hangi bileşenler sözleşmeye dahil?
• Ölçüm yöntemi: Erişilebilirlik nasıl ve nereden ölçülüyor, ölçüm dönemi aylık mı, yıllık mı?
• Hedef değerler: Erişilebilirlik yüzdesi, yanıt ve çözüm süreleri, gerekiyorsa performans hedefleri.
• Destek kanalları ve saatleri: Talepler hangi kanaldan açılır, kritik durumlarda kime ulaşılır?
• Planlı bakım: Bakım pencereleri ne zaman yapılır, ne kadar önceden duyurulur ve erişilebilirlik hesabına dahil midir?
• İstisnalar: Mücbir sebepler, müşterinin kendi değişikliklerinden kaynaklanan sorunlar ve sözleşme dışındaki üçüncü taraf hizmetleri.
• Yaptırımlar: Hedef tutturulamazsa hangi oranda hizmet kredisi verilir, tekrarlayan ihlallerde fesih hakkı doğar mı?
• Raporlama: Aylık erişilebilirlik raporu, olay sonrası değerlendirme (post-mortem) ve düzenli gözden geçirme toplantıları.

İyi bir SLA, işler yolunda gittiğinde değil, ters gittiğinde kimin ne yapacağını anlatır.

Hizmet kredisi nasıl çalışır?

Hizmet kredisi, taahhüt edilen seviye tutturulamadığında müşteriye bir sonraki faturadan düşülen indirimdir. Genellikle kademeli kurgulanır: Örneğin aylık erişilebilirlik %99,9'un altına düşerse aylık ücretin %10'u, %99'un altına düşerse %25'i gibi. Hizmet kredisi kesintinin işletmeye verdiği zararın tamamını karşılamaz; asıl amacı hizmet sağlayıcıyı güvenilirliğe yatırım yapmaya teşvik etmektir. Bu yüzden kredilerin nasıl talep edileceği, örneğin ay bitiminden sonra kaç gün içinde başvurulması gerektiği de sözleşmede yer almalıdır.

Bağımlılıklar SLA'yı nasıl etkiler?

Modern bir web sistemi tek parçadan oluşmaz: bulut sunucusu, veritabanı, e-posta servisi, ödeme altyapısı, harita ya da kimlik doğrulama hizmetleri. Her bağımlılığın kendi SLA'sı vardır ve zincirin toplam güvenilirliği, en zayıf halkadan bile düşük olabilir. %99,9 erişilebilirlik sunan iki bağımsız servise birlikte ihtiyaç duyan bir sistemin teorik erişilebilirliği yaklaşık %99,8'dir.

Bu nedenle bir yazılım ekibinin müşterisine verdiği söz, kullandığı servislerin sözlerinden daha yüksek olamaz. Kritik bağımlılıklar için yedekli yapı, otomatik yeniden deneme, kuyruk ve önbellek gibi teknikler bu açığı kapatmaya yardım eder. Yedekleme tarafında ise iki kavram önemlidir: RTO (bir kesintiden sonra sistemin en geç ne kadar sürede ayağa kalkacağı) ve RPO (en fazla ne kadarlık veri kaybının kabul edilebileceği). Bu iki değer de SLA'da açıkça yazmalıdır.

SLA nasıl ölçülür ve takip edilir?

Ölçülmeyen bir SLA yalnızca iyi niyet beyanıdır. Güvenilir bir takip için şu adımlar işe yarar:

1. Dışarıdan izleme kurun. Sistemin erişilebilirliğini farklı konumlardan, dakikada bir kontrol eden bağımsız bir izleme aracı kullanın.
2. Gerçek kullanıcı deneyimini ölçün. Yalnızca "site açılıyor mu?" değil, giriş, arama, ödeme gibi kritik akışların çalışıp çalışmadığını da test edin.
3. Alarm ve nöbet düzeni oluşturun. Kritik bir sorun gece yarısı yaşandığında kimin uyarılacağı ve nasıl müdahale edeceği belli olsun.
4. Her olayı kayda geçirin. Başlangıç ve bitiş saati, etki alanı, kök neden ve alınan önlemler bir olay raporunda toplansın.
5. Aylık raporlayın. Erişilebilirlik oranını, açılan talepleri ve sürelere uyumu her ay paylaşın.

Bu disiplin, hataların hızlı fark edildiği ve küçük adımlarla güvenle yayına alındığı bir geliştirme kültürüyle birlikte en iyi sonucu verir. Bu konuyu Dramsız DevOps yazımızda ayrıntılı olarak ele aldık. Güvenlik olayları için ayrı bir müdahale planı da hazırlamak gerekir; siber güvenlik kontrol listemiz bu konuda iyi bir başlangıç noktasıdır.

Sık sorulan sorular

SLA ile bakım sözleşmesi aynı şey mi?

Hayır. Bakım sözleşmesi hangi işlerin yapılacağını (güncellemeler, yedekleme, küçük geliştirmeler) tanımlar; SLA ise bu hizmetlerin hangi kalite ve sürelerle verileceğini ve nasıl ölçüleceğini. Çoğu projede ikisi aynı sözleşmenin farklı bölümleri olarak yer alır.

%100 erişilebilirlik taahhüt edilebilir mi?

Gerçekçi değildir. Donanım, ağ, bulut sağlayıcısı ve yazılım katmanlarının hiçbiri kusursuz değildir. %100 vaat eden bir sözleşme genellikle ya ölçüm yöntemini belirsiz bırakır ya da istisnaları geniş tutar. Ölçülebilir ve dürüst bir hedef her zaman daha değerlidir.

Küçük bir kurumsal web sitesi için SLA gerekli mi?

Ayrıntılı bir sözleşme gerekmeyebilir, ama temel taahhütlerin yazılı olması yine de önemlidir: erişilebilirlik hedefi, yedekleme sıklığı, güvenlik güncellemeleri ve bir sorun olduğunda kime, nasıl ulaşılacağı.

SLA'yı kim ölçmeli?

İdeal olarak her iki taraf da aynı verilere erişebilmelidir. Hizmet sağlayıcının izleme raporlarına ek olarak müşterinin de görebildiği bağımsız bir durum sayfası ya da izleme aracı, anlaşmazlıkları en baştan önler.

Nereden başlamalı?

Önce sisteminizin hangi parçalarının işinize doğrudan para ya da itibar kaybettirdiğini listeleyin. Ardından bu parçalar için gerçekçi erişilebilirlik hedefleri, öncelik seviyeleri ve yanıt süreleri belirleyin, sonra da bunları ölçecek izleme düzenini kurun. SLA'yı yazılımla birlikte tasarlamak, sonradan eklemeye çalışmaktan her zaman daha kolaydır; bu yüzden yazılım geliştirme sürecinin ilk haftalarında konuşulması gereken bir konudur.

Projeniz için doğru hizmet seviyesini birlikte belirlemek isterseniz Geleceğe dokunun.