SLA Nedir? %99,9 Çalışma Garantisi Ne Anlama Gelir?

Hosting paketi seçerken karşınıza çıkan "%99,9 çalışma garantisi" gibi ifadeler, ilk bakışta hepsi aynı görünse de arkasındaki gerçek taahhüt sağlayıcıdan sağlayıcıya büyük farklılık gösterebilir. Bu yazıda SLA'nın ne olduğunu, rakamların gerçek hayattaki karşılığını, ihlal durumunda neler olduğunu ve satın almadan önce nelere dikkat etmeniz gerektiğini adım adım ele alıyoruz.

SLA nedir?

SLA (Service Level Agreement — hizmet seviyesi sözleşmesi), bir hizmet sağlayıcısının müşterisine karşı taahhüt ettiği hizmet kalitesini tanımlayan sözleşmedir. Hosting dünyasında en sık karşılaşılan SLA maddesi, sunucunun ne kadar süre kesintisiz çalışacağını belirten "çalışma garantisi" (uptime guarantee) rakamıdır.

%99,9 rakamı gerçekte ne demek?

%99,9 çalışma garantisi kulağa neredeyse mükemmel gelir, ama rakamı somutlaştırmak faydalıdır: bu oran, yılda toplam yaklaşık 8 saat 45 dakikaya kadar planlı ya da plansız kesintiye izin verildiği anlamına gelmektedir, ki bu hiç de küçük bir süre değildir. Karşılaştırma için: %99 garanti yılda ~3,65 gün, %99,99 garanti ise yılda sadece ~52 dakika kesintiye karşılık gelir.

Farklı yüzdelerin karşılığı: tam tablo

Yüzde işaretinden sonraki her "9" rakamı, izin verilen kesinti süresini yaklaşık 10'a böler. Bu artış kulağa küçük gelse de, gerçek sürelere döküldüğünde aradaki fark çok büyüktür:

Garanti	Yıllık izinli kesinti	Aylık izinli kesinti
%99 (iki dokuz)	~3 gün 15 saat	~7 saat 18 dakika
%99,5	~1 gün 19 saat	~3 saat 39 dakika
%99,9 (üç dokuz)	~8 saat 45 dakika	~43 dakika
%99,95	~4 saat 22 dakika	~22 dakika
%99,99 (dört dokuz)	~52 dakika	~4 dakika
%99,999 (beş dokuz)	~5 dakika	~26 saniye

Sektörde "üç dokuz" (%99,9) yaygın bir standarttır ve çoğu kurumsal site, blog ya da küçük-orta ölçekli e-ticaret için fazlasıyla yeterlidir. "Dört dokuz" ve üzeri garantiler genelde çok daha pahalı, özel altyapı gerektirir ve gerçek hayatta nadiren tam olarak tutturulabilir — bu seviyedeki bir vaadi gördüğünüzde temkinli yaklaşmakta fayda var.

SLA ihlali olursa ne olur?

Ciddi bir SLA metninde, garanti edilen sürenin altına düşülmesi durumunda müşteriye ne sağlanacağı açıkça yazar — genelde bu, o ayın faturasından belirli bir oranda indirim şeklinde olur. SLA'sı olmayan ya da ihlal durumunu tanımlamayan bir sağlayıcı, rakamı yalnızca pazarlama amacıyla kullanıyor olabilir.

Satın almadan önce SLA'yı nasıl kontrol edersiniz?

Bir hosting sağlayıcısının çalışma garantisi vaadinin gerçek mi yoksa yalnızca pazarlama mı olduğunu anlamak için şu adımları izleyebilirsiniz:

1. SLA metnini bulun. Sağlayıcının kullanım şartları veya hizmet sözleşmesi sayfasında "çalışma garantisi", "uptime" veya "SLA" başlığını arayın. Bu bilgi yalnızca reklam sayfasında, küçük bir rozet olarak duruyorsa ve ayrıntılı bir sözleşme metni yoksa bu bir uyarı işaretidir.
2. İhlal durumunda ne olduğunu okuyun. Metinde "garanti tutturulamazsa müşteriye X uygulanır" gibi somut bir madde var mı? Bu madde yoksa, rakamın arkasında bir yaptırım da yoktur.
3. Talep sürecini sorun. Tazminat/indirim otomatik mi uygulanıyor, yoksa siz mi talep etmeniz gerekiyor? Talep süresi (kesintiden sonra kaç gün içinde bildirmeniz gerektiği) var mı?
4. Geçmiş performansı araştırın. Bağımsız durum izleme siteleri veya sağlayıcının kendi durum sayfası geçmişi, vaat edilen rakamın gerçekte tutturulup tutturulmadığı hakkında fikir verir.
5. Hangi hizmetlerin kapsandığını netleştirin. Garanti yalnızca sunucu erişilebilirliğini mi kapsıyor, yoksa e-posta ve veritabanı gibi diğer hizmetleri de mi?

Bu beş adımı uyguladığınızda genelde iki tür sağlayıcıyla karşılaşırsınız: birincisi, sorularınıza net, yazılı ve tutarlı cevaplar veren; ikincisi ise "genelde çok iyi çalışıyoruz" gibi belirsiz ifadelerle geçiştiren sağlayıcı. İkinci tür bir yanıt aldığınızda, bu sağlayıcının SLA'yı gerçek bir taahhüt olarak değil, yalnızca bir pazarlama cümlesi olarak kullandığını varsaymanız makul bir yaklaşımdır. Yazılı ve net cevap veren sağlayıcılar, genelde arka planda gerçekten bu taahhüdü karşılayacak bir izleme ve operasyon süreci kurmuş olan sağlayıcılardır — çünkü belirsiz bir sürecin yazılı hale getirilmesi zaten zordur.

Örnek senaryo: bir e-ticaret sitesinde kesinti

Diyelim ki bir e-ticaret sitesi işletiyorsunuz ve sunucunuz bir ay içinde toplam 90 dakika erişilemez durumda kaldı. Sağlayıcınızın SLA'sı %99,9 (aylık ~43 dakika izin verilen kesinti) ise, bu 90 dakikalık kesinti garantiyi ihlal etmiş demektir — çünkü izin verilen sürenin yaklaşık iki katı kadar kesinti yaşanmıştır. Şeffaf bir SLA metninde bu durumda ne olacağı nettir: örneğin o ayki faturanızın belirli bir yüzdesi iade/indirim olarak yansıtılır. SLA'sı belirsiz bir sağlayıcıda ise aynı kesintiyi yaşadığınızda elinizde hiçbir somut talep hakkı olmayabilir — tek yapabileceğiniz destek ekibine yazıp "iyi niyetli" bir jest beklemek olur. Bu örnek, SLA'nın sadece kâğıt üzerinde bir rakam değil, gerçek bir olay anında işinize yarayan bir güvence olduğunu gösterir.

SLA konusunda sık yapılan hatalar

• Yalnızca yüzdeye bakıp ihlal maddesini okumamak: %99,9 yazan iki sağlayıcıdan biri ihlal durumunda tazminat öngörürken diğeri hiçbir şey öngörmeyebilir — rakam aynı, güvence çok farklı.
• Planlı bakımın garanti hesabına dahil olup olmadığını sormamak: Bazı sağlayıcılar önceden duyurulan bakımları SLA hesabının dışında tutar; bu, gerçek kesinti toleransını etkiler.
• Kesintiyi fark edip bildirmemek: Tazminat süreci talebe bağlıysa, sessiz kalmak hakkınızı kullanmamak anlamına gelir.
• "%100 garanti" vaadini sorgulamadan kabul etmek: Teknik olarak imkânsıza yakın bir vaat, ya abartıdır ya da küçük yazıda başka koşullara bağlanmıştır.
• SLA'yı yalnızca büyük/pahalı paketlerde aramak: Çalışma garantisi, paket fiyatından bağımsız bir taahhüt olmalıdır; ucuz bir pakette garanti yoksa bu, sağlayıcının genel şeffaflık anlayışı hakkında da fikir verir.
• Garantiyi yalnızca "reklam metninden" öğrenmeye çalışmak: Pazarlama sayfasındaki büyük puntolu "%99,9 garanti" ifadesi ile hizmet sözleşmesindeki gerçek madde bazen birbirinden farklı koşullar taşıyabilir; ikisini karşılaştırmadan karar vermek risklidir.
• Kendi ölçümünüzü hiç yapmamak: Sağlayıcının kendi rakamlarına tamamen güvenmek yerine, bağımsız bir izleme aracıyla kendi sitenizin gerçek erişilebilirliğini takip etmek, olası bir anlaşmazlıkta elinizi güçlendirir.
• Sözleşme güncellemelerini takip etmemek: SLA maddesi zaman içinde değişmiş olabilir; uzun süredir müşteri olduğunuz bir sağlayıcıda bunu ara sıra kontrol etmemek, fark etmeden daha zayıf bir garantiyle devam etmenize yol açabilir.

Bu hataların ortak noktası, SLA'yı "satın alma anında bir kez okunup unutulan" bir belge olarak görmektir. Oysa SLA, hizmetiniz boyunca zaman zaman geri dönüp bakmanız gereken, aktif bir referans belgesi olarak ele alınmalıdır.

Terim sözlüğü

SLA metinlerini okurken karşınıza çıkabilecek teknik terimlerin düz Türkçe karşılıklarını aşağıda topladık; bu terimleri bilmek, farklı sağlayıcıların sözleşmelerini birebir karşılaştırmanızı ve satın almadan önce doğru soruları sormanızı kolaylaştırır:

Terim	Anlamı
Uptime (çalışma süresi)	Sunucunun erişilebilir olduğu toplam süre yüzdesi
Downtime (kesinti süresi)	Sunucunun erişilemez olduğu süre
SLA (hizmet seviyesi sözleşmesi)	Taahhüt edilen hizmet kalitesini ve ihlal durumunda uygulanacak yaptırımı tanımlayan belge
Planlı bakım	Önceden duyurulan, genelde gece saatlerinde yapılan kısa süreli kesinti
Plansız kesinti (outage)	Beklenmedik bir arıza ya da saldırı sonucu oluşan erişilemezlik
İzleme (monitoring)	Sunucunun çalışır durumda olup olmadığının 7/24 otomatik olarak kontrol edilmesi
Yedeklilik (redundancy)	Bir bileşen arızalandığında devreye giren, aynı işi yapabilen ikinci bir bileşenin bulunması (örn. N+1 güç sistemi)
Failover	Bir sistemin arızalanması durumunda otomatik olarak yedek sisteme geçiş yapılması
Kredi/tazminat (SLA credit)	Garanti ihlal edildiğinde müşteriye tanınan fatura indirimi veya hizmet süresi uzatımı
Bağımsız izleme (third-party monitoring)	Sağlayıcıdan bağımsız bir dış servisin sunucu erişilebilirliğini ayrıca ölçmesi
Sorumluluk sınırlaması (limitation of liability)	Sağlayıcının ödeyeceği azami tazminatı sınırlayan sözleşme maddesi

Kontrol listesi

• Sağlayıcının SLA metni yayında ve kolayca bulunabiliyor mu?
• İhlal durumunda ne olacağı (tazminat/indirim oranı) açıkça yazıyor mu?
• Tazminat otomatik mi uygulanıyor, yoksa talep mi gerekiyor?
• Planlı bakımların garanti hesabına dahil olup olmadığı belirtilmiş mi?
• Hangi hizmetlerin (sunucu, e-posta, veritabanı) garanti kapsamında olduğu net mi?
• Sağlayıcının geçmiş kesinti kayıtlarına (durum sayfası, bağımsız izleme) ulaşılabiliyor mu?
• Sözleşme koşulları zaman içinde değişirse size nasıl bildirim yapılacağı belirtilmiş mi?

SLA ile sorumluluk sınırlaması arasındaki ilişki

Çoğu hizmet sözleşmesinde SLA maddesinin hemen yanında ya da altında bir "sorumluluk sınırlaması" (limitation of liability) maddesi de bulunur. Bu madde genelde, sağlayıcının bir kesinti nedeniyle ödeyeceği azami tazminatın, o ayki (veya o dönemki) fatura tutarıyla sınırlı olduğunu belirtir. Başka bir deyişle, kesinti sizin işinize dolaylı olarak çok daha büyük bir maliyet çıkarmış olsa bile (örneğin kaybedilen satışlar), sağlayıcıdan talep edebileceğiniz tazminat genelde yalnızca o hizmete ödediğiniz ücretle sınırlıdır. Bu, sektörün neredeyse tamamında standart bir uygulamadır ve tek bir sağlayıcıya özgü bir dezavantaj değildir; büyük bulut sağlayıcılarından küçük yerel hosting firmalarına kadar hemen hemen her hizmet sözleşmesinde benzer bir sınırlama maddesine rastlanır ve bu genelde tüketici/ticari sözleşme hukukunun genel bir uygulamasıdır. Bunu bilmek, SLA'dan beklentinizi gerçekçi tutmanıza yardımcı olur: SLA, olası bir dolaylı zararı tam olarak karşılayan bir sigorta değil, sağlayıcıyı hizmet kalitesi konusunda sorumlu tutan ve küçük bir tazminat sağlayan bir mekanizmadır. Gerçekten kritik, kesintiye tahammülü olmayan bir iş yürütüyorsanız, SLA'ya ek olarak kendi tarafınızda da (yedekleme, felaket kurtarma planı gibi) önlemler almanız gerekir.

Hosting türüne göre SLA farkları

SLA taahhüdü, hangi tür hosting hizmeti aldığınıza göre de farklılık gösterebilir. Paylaşımlı hostingde, sunucu kaynağı birden fazla müşteri arasında paylaşıldığı için garanti genelde tüm müşterilere eşit ve standart şekilde uygulanır — tek bir müşterinin özel bir talebi üzerine SLA şartları değiştirilmez. VDS (sanal özel sunucu) hizmetlerinde ise kaynaklar size ayrıldığı için bazı sağlayıcılar daha yüksek ya da daha esnek SLA seçenekleri sunabilir; ancak bu genelde ek bir maliyetle gelir. Bayilik (reseller) hizmetlerinde ise durum biraz farklıdır: bayi, sağlayıcıdan aldığı SLA'yı kendi müşterilerine aktarır ya da kendi ek taahhüdünü üstüne koyar — bu yüzden bir bayiden hizmet alıyorsanız, hem bayinin hem de bayinin bağlı olduğu asıl sağlayıcının SLA'sını sorgulamanız faydalı olur.

Bulut (cloud) tabanlı hizmetlerde ise durum biraz daha karmaşıktır: SLA genelde katmanlı çalışır: alt yapı sağlayıcısının kendi veri merkezi/ağ garantisi, bunun üzerine kurulu hosting sağlayıcısının kendi garantisiyle birleşir. Bu durumda "zincirin en zayıf halkası" prensibi geçerlidir — alt katmandaki bir sağlayıcının garantisi ne kadar yüksek olursa olsun, üstteki hosting sağlayıcısının kendi operasyonel hataları (yanlış yapılandırma, gecikmeli müdahale gibi) yine de kesintiye yol açabilir. Bu yüzden SLA değerlendirirken yalnızca "hangi büyük bulut sağlayıcısının altyapısını kullanıyorlar" sorusuna değil, hosting sağlayıcısının kendi operasyon kalitesine de bakmak gerekir.

Dördüncü örnek: kurumsal e-posta kesintisi

SLA yalnızca "site açılıyor mu açılmıyor mu" sorusuyla sınırlı değildir. Diyelim ki siteniz sorunsuz çalışıyor ama kurumsal e-posta hizmetiniz bir gün boyunca gönderim/alım yapamadı. Sözleşmenizde çalışma garantisi yalnızca "web sunucusu erişilebilirliği" şeklinde dar bir şekilde tanımlanmışsa, bu tür bir e-posta kesintisi SLA kapsamına hiç girmeyebilir — çünkü e-posta ayrı bir hizmet olarak değerlendirilmiş olabilir. Bu, önceki bölümlerde bahsettiğimiz "hangi hizmetlerin kapsandığını netleştirin" adımının neden satın almadan önce mutlaka sorulması gereken bir soru olduğunu somutlaştıran bir örnektir: sunucu erişilebilirliği mükemmel olsa bile, günlük iş akışınızı doğrudan etkileyen bir hizmet (e-posta, veritabanı, API) SLA'nın dışında kalmış olabilir.

Üçüncü örnek: birden fazla kısa kesintinin toplamı

SLA ihlalleri her zaman tek bir uzun kesintiden kaynaklanmaz; bazen birbirinden bağımsız görünen birkaç kısa kesinti toplamda garantiyi aşabilir. Diyelim ki bir ayda sırasıyla 10 dakika, 15 dakika ve 25 dakika olmak üzere üç ayrı, birbiriyle ilgisiz kesinti yaşadınız — toplam 50 dakika eder. Sağlayıcınızın aylık garantisi %99,9 (yaklaşık 43 dakika) ise, bu üç küçük kesinti tek başına fark edilmeyecek kadar kısa görünse de toplamda garantiyi ihlal etmiştir. Bu senaryo, kullanıcıların sık yaptığı bir hatayı gösterir: yalnızca "büyük" kesintileri hatırlayıp küçük, birkaç dakikalık kesintileri önemsememek. Oysa SLA hesaplaması genelde dönem içindeki TÜM kesinti sürelerinin toplamına bakar; bu yüzden küçük kesintileri de not almak ve gerektiğinde biriktirip toplu olarak sağlayıcınıza bildirmek, hakkınızı tam olarak kullanmanızı sağlar.

İkinci örnek: planlı bakım ile plansız kesintinin farkı

Bir başka örnek üzerinden ilerleyelim. Sağlayıcınız size bir hafta önceden e-posta göndererek pazar gecesi saat 03:00-04:00 arası bir bakım çalışması yapacağını bildiriyor. Bu bir saatlik kesinti, sözleşmede "planlı bakım SLA hesabının dışındadır" maddesi varsa garanti hesabınıza dahil edilmez — yani o ay yaşadığınız başka, planlanmamış 20 dakikalık bir kesinti bile garantiyi ihlal ediyor olabilir, ama planlı bakım saati ihlal sayılmaz. Bu ayrımı bilmemek, kullanıcıların "bu ay toplam kaç dakika kesinti yaşadım" hesabını yanlış yapmasına ve sağlayıcıyla gereksiz bir anlaşmazlığa girmesine yol açabilir. Bu yüzden SLA metnini okurken planlı bakımın ayrı tutulup tutulmadığı, tutuluyorsa hangi koşullarda (örneğin en az kaç gün önceden bildirim yapılması gerektiği) net şekilde tanımlanmış olması, gerçek kesinti toleransınızı doğru hesaplamanız için kritik bir detaydır.

SLA, sözleşme yenilendiğinde değişebilir mi?

Bir diğer önemli ama sıkça gözden kaçan nokta, SLA'nın sabit kalıp kalmadığıdır. Bazı sağlayıcılar, hizmet şartlarını zaman içinde güncelleyebilir ve bu güncelleme SLA maddesini de kapsayabilir. Genelde bu tür değişiklikler önceden duyurulur, ama duyurunun ne kadar göze çarpar şekilde yapıldığı sağlayıcıdan sağlayıcıya değişir. Uzun vadeli bir müşteriyseniz, ara sıra güncel hizmet şartlarını tekrar gözden geçirmeniz, ilk satın aldığınızda kabul ettiğiniz SLA'nın hâlâ aynı şekilde geçerli olup olmadığını teyit etmenizi sağlar. Şeffaf bir sağlayıcı, SLA'da olumsuz bir değişiklik yaptığında bunu mevcut müşterilerine e-posta ile ayrıca bildirir; böyle bir bildirim almadıysanız ve şüpheniz varsa, doğrudan destek ekibine sorup güncel taahhüdü teyit edebilirsiniz.

Sağlayıcınıza sorabileceğiniz doğru sorular

Bir hosting sağlayıcısıyla görüşürken SLA hakkında sorabileceğiniz somut sorular şunlar olabilir: "Yıllık kaç dakika/saat kesinti garantisi veriyorsunuz?", "Planlı bakımlar bu hesaba dahil mi?", "İhlal durumunda tazminatı ben mi talep etmeliyim yoksa otomatik mi uygulanır?", "Son bir yılda bu garantiyi kaç kez tutturamadınız?" gibi doğrudan sorular olabilir. Son soru özellikle öğreticidir: dürüst bir sağlayıcı bu soruya net bir cevap verebilir ya da geçmiş durum kayıtlarına yönlendirebilir; kaçamak bir cevap, o sağlayıcının performans geçmişi konusunda şeffaf olmak istemediğinin bir işareti olabilir. Bu soruları satın almadan önce canlı destek üzerinden sormak, hem sağlayıcının bilgi düzeyini hem de yanıt hızını aynı anda test etmenizi sağlar.

SLA rakamının daha az önemli olduğu durumlar

Her proje için SLA rakamı aynı ağırlıkta değildir. Örneğin kişisel bir blog ya da hâlâ geliştirme aşamasında olan bir test sitesi için birkaç dakikalık/saatlik bir kesinti, gelir kaybı ya da müşteri güveni açısından ciddi bir sonuç doğurmaz — bu durumda SLA rakamı, hosting seçiminde belirleyici bir kriter olmaktan çok "iyi olsun" düzeyinde bir faktördür. Buna karşılık canlı sipariş alan bir e-ticaret sitesi, kurumsal bir müşteri portalı ya da gelir getiren herhangi bir uygulama için SLA'nın somut ve yazılı olması önceliklidir. Kendi projeniz için SLA'ya ne kadar ağırlık vermeniz gerektiğine karar verirken, kısa bir kesintinin sizi gerçekte ne kadar etkileyeceğini dürüstçe değerlendirmeniz en sağlıklı yoldur.

Benzer şekilde, henüz kullanıcısı olmayan bir MVP (minimum uygulanabilir ürün) ya da bir iç ekip aracı için de çok yüksek bir SLA rakamı peşinde koşmak, o aşamada bütçenizi gereksiz yere daha pahalı bir pakete yönlendirebilir. Bu tür projelerde standart bir %99,9 garantisi genelde fazlasıyla yeterlidir; kaynaklarınızı SLA'yı yükseltmek yerine ürünün kendisini geliştirmeye ayırmak daha doğru bir önceliklendirme olur.

SLA ihlali sürecinde maliyet ve zaman

Bir SLA ihlali yaşandığında sürecin nasıl işlediğini bilmek, beklentinizi doğru yönetmenize yardımcı olur. Öncelikle kesintinin ne zaman başlayıp ne zaman bittiğinin kaydı tutulur — bu genelde sağlayıcının kendi izleme sisteminden veya bağımsız bir izleme aracından alınır. Ardından siz (ya da otomatik sistem) bu kesintiyi SLA talebi olarak bildirir; sağlayıcı kaydı doğrular ve ihlal gerçekten yaşanmışsa tazminatı (genelde bir sonraki faturaya yansıyan indirim şeklinde) uygular. Bu sürecin tamamı, sağlayıcının sürece ne kadar hazırlıklı olduğuna bağlı olarak birkaç günden birkaç haftaya kadar sürebilir. Talebinizi kesintiden sonra ne kadar makul bir sürede bildirdiğiniz de önemlidir — bazı sözleşmelerde belirli bir süre (örneğin birkaç gün ile birkaç hafta arası) içinde bildirim şartı olabilir; bu süreyi kaçırmamak için kesinti yaşadığınızda mümkün olan en kısa sürede destek ekibinize yazmanız önerilir. Tazminatın kendisi neredeyse her zaman parasal değil, hizmet süresi/fatura indirimi şeklinde uygulanır; SLA'nın amacı zaten maddi bir tazminat mekanizması değil, sağlayıcıyı hizmet kalitesini korumaya teşvik eden bir sorumluluk aracıdır.

SLA ve uluslararası kalite standartları

Bazı hosting sağlayıcıları, SLA taahhütlerini desteklemek için bağımsız kalite standartlarına da atıfta bulunur. Örneğin bir veri merkezinin ISO 27001 (bilgi güvenliği yönetimi) veya benzeri bir sertifikaya sahip olması, o tesisin süreçlerinin bağımsız bir denetimden geçtiği anlamına gelir — bu, tek başına bir SLA taahhüdü değildir ama sağlayıcının operasyonel olgunluğu hakkında ek bir güven sinyali verir. Benzer şekilde TIER sınıflandırması (veri merkezlerinin yedeklilik seviyesini gösteren bir standart), bir sağlayıcının fiziksel altyapısının SLA'yı destekleyip desteklemediğine dair dolaylı bir ipucu sunar. Bu sertifikaları görmek, tek başına bir garanti anlamına gelmez ama SLA metniyle birlikte değerlendirildiğinde sağlayıcının iddialarının arkasında gerçek bir altyapı olup olmadığı konusunda ek bir doğrulama sağlar. Kendi altyapımız hakkında ayrıntılı bilgiye ilgili sayfamızdan ulaşabilirsiniz.

SLA, SLO ve SLI arasındaki fark

SLA'yı araştırırken karşınıza bazen SLO ve SLI kısaltmaları da çıkabilir; bu üçü birbiriyle ilişkili ama farklı kavramlardır. SLI (Service Level Indicator), gerçekten ölçülen sayısal bir değerdir — örneğin "bu ay sunucu %99,95 oranında erişilebilirdi" bir SLI'dır. SLO (Service Level Objective), sağlayıcının kendi içinde hedeflediği performans seviyesidir — örneğin "hedefimiz %99,95 erişilebilirlik" bir SLO'dur; bu, müşteriye karşı hukuki bir taahhüt değil, içsel bir hedeftir. SLA (Service Level Agreement) ise bu hedefin müşteriyle yazılı olarak taahhüt edilmiş, ihlali durumunda yaptırımı olan resmi halidir. Yani SLI "ne oldu", SLO "ne hedefliyoruz", SLA ise "ne taahhüt ediyoruz ve tutmazsak ne olur" sorularına cevap verir. Bir sağlayıcı size yalnızca bir SLO'dan bahsedip bunu SLA gibi sunuyorsa, bu ayrımı fark etmeniz ve gerçek bir taahhüt olup olmadığını sorgulamanız önemlidir.

Kendi sitenizin çalışma süresini nasıl izlersiniz?

Sağlayıcınızın SLA rakamına güvenmek yerine, kendi sitenizin gerçek erişilebilirliğini bağımsız olarak izlemek isterseniz, birkaç yöntem vardır. En basit yöntem, ücretsiz veya düşük maliyetli bağımsız izleme servislerini kullanmaktır; bu servisler sitenizi belirli aralıklarla (örneğin her birkaç dakikada bir) dışarıdan ziyaret eder, erişilemediğinde size e-posta veya bildirim gönderir ve zaman içinde bir "gerçek uptime" raporu üretir. Bu rapor, sağlayıcınızın kendi beyan ettiği rakamla karşılaştırıldığında, olası bir anlaşmazlıkta size somut bir kanıt sağlar.

Daha teknik bir yaklaşım isteyenler için, sunucu günlük kayıtlarını (log dosyalarını) düzenli incelemek de bir seçenektir; bu kayıtlar hangi isteklerin başarısız olduğunu, hangi saatlerde sorun yaşandığını ayrıntılı şekilde gösterir. Çoğu kullanıcı için bağımsız bir izleme servisi kurmak, log incelemekten çok daha pratik ve yeterlidir. Önemli olan, izlemeyi "bir kere kurup unutmak" değil, ara sıra raporları gözden geçirip sağlayıcınızın performansının zamanla değişip değişmediğini takip etmektir.

Kendi müşterilerinize SLA sunmak: bayi ve ajanslar için

Bir hosting bayiliği yürütüyorsanız ya da müşterilerinize web sitesi/hosting hizmeti veren bir ajanssanız, kendi müşterilerinize de bir SLA sunmanız gündeme gelebilir. Bu durumda dikkat edilmesi gereken temel nokta, kendi müşterinize verdiğiniz garantinin, sizin aldığınız hizmetin garantisinden daha yüksek olmamasıdır — aksi halde sağlayıcınızdan aldığınızdan daha fazlasını taahhüt etmiş olursunuz ve bir ihlal durumunda kendi cebinizden karşılamanız gereken bir fark ortaya çıkabilir. Sağlıklı bir yaklaşım, sağlayıcınızın size verdiği garantiyi olduğu gibi ya da küçük bir güvenlik payıyla (örneğin sağlayıcı %99,9 veriyorsa siz müşterinize %99,8 gibi) kendi müşterinize yansıtmaktır. Ayrıca müşterinize sunduğunuz SLA metninde, ihlal durumunda tazminatın nasıl hesaplanacağını ve nasıl talep edileceğini de en az sizin sağlayıcınızdan aldığınız kadar net yazmanız, hem müşteri güveni hem de olası anlaşmazlıkların önlenmesi açısından önemlidir.

LivHosting'in taahhüdü

%99,9 çalışma garantisi veriyoruz ve bunu sadece bir rakam olarak bırakmıyoruz: söz verdiğimiz sürede sunucunuz ayakta kalmazsa, bu durumu faturanıza yansıtırız. Sunucularımız 7/24 izlenir; bir sorun oluştuğunda ekibimiz anında müdahale eder. Bu taahhüdü tüm web hosting ve VDS paketlerimizde, paket büyüklüğünden bağımsız olarak aynı şekilde uyguluyoruz. Yenileme fiyatlarımızın neden artmadığını merak ediyorsanız ilgili yazımıza da göz atabilirsiniz — şeffaflık ilkemiz sadece SLA'da değil, fiyatlandırmamızda da geçerlidir. Bu yazıda anlattığımız kontrol listesini kendi sözleşmemize uyguladığınızda, ihlal maddesinin, kapsanan hizmetlerin ve talep sürecinin hepsinin açıkça yazılı olduğunu göreceksiniz; SLA'yı bizim için de yalnızca bir pazarlama rakamı değil, gerçek bir taahhüt olarak ele alıyoruz. Bu yazıda geçen kontrol listesini, terim sözlüğünü ve örnek senaryoları kendi karar sürecinizde bir referans olarak kullanabilir, hangi sağlayıcıyı seçerseniz seçin daha bilinçli bir karar vermiş olursunuz.