Hizmet Seviyesi Anlaşması (SLA) Metinlerinde Nelere Dikkat Edilir?

Bir sunucu, veri merkezi veya bulut hizmeti satın alırken çoğu işletme sahibinin dikkatini fiyat, disk alanı veya bant genişliği gibi somut rakamlar çeker. Oysa hizmetin gerçek değerini belirleyen belge çoğu zaman gözden kaçırılan bir metindir: Hizmet Seviyesi Anlaşması, yani SLA (Service Level Agreement). Bu yazıda, teknik bir uzman olmasanız bile bir SLA'yı imzalamadan önce nasıl okumanız ve değerlendirmeniz gerektiğini pratik bir bakış açısıyla ele alıyoruz.

SLA Nedir, Neden Sıradan Bir Pazarlama Metni Değildir?

SLA, hizmet sağlayıcı ile müşteri arasında imzalanan, sunulan hizmetin hangi seviyede olacağını ve bu seviye sağlanamadığında ne olacağını tanımlayan hukuki ve teknik bir taahhüt belgesidir. Web sitesindeki "%99,9 kesintisiz hizmet" gibi ifadeler pazarlama amaçlı iken, SLA bu ifadenin sözleşmesel karşılığını, istisnalarını ve ihlal durumunda uygulanacak yaptırımları belirler.

Bu iki metin arasındaki fark önemlidir çünkü bir kesinti yaşandığında dayanak noktanız pazarlama sayfası değil, imzaladığınız SLA olacaktır. SLA, hizmet sağlayıcı ile aranızdaki sorumlulukları netleştiren referans bir dokümandır: kim, ne zaman, hangi koşullarda sorumlu tutulabilir sorusunun cevabı burada yazar.

İmzalamadan önce bu metni dikkatlice okumamak, işletmenizin bir kesinti anında beklediği korumadan yoksun kalmasına yol açabilir. Sorun yaşandığında "bu durum SLA kapsamı dışında" cevabıyla karşılaşmak, önceden yapılmış bir okuma eksikliğinin sonucu olabilir.

Uptime Yüzdesi Gerçekte Ne Anlama Gelir?

Sağlayıcıların öne çıkardığı %99,9, %99,95 veya %99,99 gibi oranlar kulağa birbirine yakın gelse de pratikte ciddi farklar yaratır. Bu yüzdeler, belirli bir zaman diliminde hizmetin ne kadar süre kesintisiz kalması gerektiğini ifade eder; geri kalan yüzde ise izin verilen kesinti süresidir.

Buradaki kritik nokta, hesaplamanın hangi periyoda göre yapıldığıdır. Aynı %99,9 oranı aylık hesaplanıyorsa izin verilen kesinti süresi, yıllık hesaplanan bir orana göre farklı bir dağılım gösterir. Bir SLA metninde bu periyodun açıkça belirtilip belirtilmediğini kontrol etmeniz gerekir; çünkü "%99,9 uptime" ifadesi tek başına yeterli bilgi vermez.

Ayrıca yüzdeler arasındaki küçük farklar göründüğünden daha büyük sonuçlar doğurur. %99,9 ile %99,99 arasındaki fark sayısal olarak küçük görünse de, izin verilen kesinti süresi açısından kat kat fark yaratabilir. Bu nedenle sadece yüzdeye değil, bu yüzdenin karşılık geldiği somut süreye bakmak gerekir.

Kesinti Tanımı: Metnin En Kritik Kısmı

Bir SLA'nın belki de en önemli, ama en çok atlanan bölümü "kesinti" kelimesinin nasıl tanımlandığıdır. Sağlayıcılar arasında bu tanım ciddi farklılıklar gösterebilir.

Öncelikle, planlı bakım çalışmalarının kesinti sayılıp sayılmadığına bakmak gerekir. Bazı sağlayıcılar önceden bildirilen bakım pencerelerini uptime hesabına dahil etmez; bu durumda ilan edilen yüksek uptime oranı, gerçek kullanılabilirlikten daha iyimser bir tablo çizebilir.

İkinci önemli husus, kısmi kesinti ve performans düşüşü durumlarının nasıl ele alındığıdır. Sunucunuz tamamen çökmese bile ciddi şekilde yavaşlamışsa, bu durum bazı sözleşmelerde "kesinti" sayılmayabilir. Oysa işletmeniz açısından yavaş çalışan bir sistem, tam kesintiyle benzer zararlar doğurabilir.

Sonuç olarak, dar ve sıkı tutulmuş bir kesinti tanımı, sağlayıcının gerçek yaşanan sorunları SLA kapsamı dışında bırakmasına imkan tanıyabilir. Bu bölümü satır satır okumak, sözleşmenin geri kalanından daha fazla önem taşıyabilir.

Telafi ve İade Politikaları Gerçek Zararı Karşılıyor mu?

SLA ihlali durumunda sunulan telafi genellikle "kredi" adı verilen bir indirim veya kısmi iade şeklindedir. Ancak bu sürecin işleyişi kritik detaylar içerir.

İlk olarak, çoğu sağlayıcıda bu kredi otomatik olarak uygulanmaz; müşterinin kesintiyi fark edip belirli bir süre içinde resmi olarak talep etmesi gerekir. Bu talep süresi kaçırıldığında hak kaybı yaşanabilir.

İkinci olarak, telafi tutarlarına genellikle bir üst sınır konur; bu sınır çoğunlukla o ay ödenen hizmet bedelinin küçük bir yüzdesiyle sınırlıdır. Bir kesinti nedeniyle işletmenizin yaşadığı gerçek ticari kayıp (kaçan satışlar, itibar kaybı, müşteri memnuniyetsizliği) bu üst sınırın çok üzerinde olabilir; SLA bu farkı telafi etmeyi amaçlamaz, sadece sınırlı bir jest sunar.

Bu nedenle SLA'yı bir "sigorta" gibi değil, sağlayıcının hizmet kalitesine dair sınırlı bir güvence olarak görmek daha gerçekçi bir yaklaşımdır.

Kesinti Nasıl Ölçülüyor ve Raporlanıyor?

Bir kesinti yaşandığında bunu kim, hangi yöntemle tespit ediyor sorusu, anlaşmazlıkların en sık yaşandığı alanlardan biridir. Bazı SLA'larda kesintinin tespiti tamamen sağlayıcının kendi izleme sistemlerine dayanır; bu da sağlayıcının hem hakem hem taraf konumunda olması anlamına gelebilir.

Müşterinin kendi bağımsız izleme araçlarıyla topladığı kayıtların kanıt olarak kabul edilip edilmeyeceği de sözleşmede netleşmesi gereken bir konudur. Eğer SLA yalnızca sağlayıcının kendi ölçümlerini geçerli sayıyorsa, sizin farklı bir izleme aracıyla tespit ettiğiniz kesinti süresi resmi kayıtlarla örtüşmeyebilir.

Ölçüm yönteminin şeffaf olmaması, ileride yaşanabilecek bir anlaşmazlıkta müşteriyi dezavantajlı konuma düşürür. Bu nedenle mümkünse hangi araçların, hangi aralıklarla kontrol yaptığının ve sonuçların nasıl raporlandığının sözleşmede açıkça yer alıp almadığını kontrol etmek faydalı olur.

Sorumluluk Sınırlamaları ve İstisnalar

Neredeyse tüm SLA'larda sağlayıcıyı belirli durumlardan sorumlu tutmayan istisna maddeleri bulunur. Bunlar arasında mücbir sebepler (doğal afetler, savaş gibi kontrol dışı olaylar), üçüncü taraf hizmetlerdeki kesintiler (örneğin internet servis sağlayıcısı veya bulut altyapı ortağı kaynaklı sorunlar) ve güvenlik olayları (siber saldırılar) sayılabilir.

Bu istisnaların varlığı normal karşılanabilir, ancak önemli olan bu maddelerin ne kadar geniş tanımlandığıdır. Bazı sözleşmelerde istisna listesi o kadar kapsamlı yazılır ki, pratikte sağlayıcıyı neredeyse her türlü kesintiden sorumsuz kılar. Bu durumda SLA'nın taahhüt ettiği koruma, kağıt üzerinde kalan bir formaliteye dönüşür.

Bu bölümü okurken kendinize şu soruyu sormanız faydalı olur: "Bu istisnalar çıkarıldığında, sağlayıcının gerçekten sorumlu tutulabileceği bir durum kalıyor mu?"

Destek Yanıt Süresi ile Çözüm Süresi Farkı

SLA metinlerinde sıkça karşılaşılan bir karışıklık, "yanıt süresi" ile "çözüm süresi" kavramlarının birbirine karıştırılmasıdır. Yanıt süresi, destek talebinizin alındığının size bildirilmesi için geçen süredir; bu, sorunun çözüldüğü anlamına gelmez, sadece talebinizin sisteme düştüğünü gösterir.

Çözüm süresi ise sorunun fiilen giderilmesi için geçen zamanı ifade eder ve genellikle ayrı bir taahhüt olarak belirtilir (bazen hiç belirtilmeyebilir). Bir sağlayıcının "15 dakikada yanıt" vaadi, sorununuzun 15 dakikada çözüleceği anlamına gelmez; bu iki metriği karıştırmak, kesinti anında beklenti yönetimi açısından hayal kırıklığına yol açabilir.

SLA'yı incelerken her iki süre için de ayrı taahhütlerin var olup olmadığına, varsa bu sürelerin öncelik seviyesine (kritik, orta, düşük gibi) göre nasıl değiştiğine bakmak gerekir.

Yedekleme ve Veri Kurtarma Taahhütleri SLA'da mı?

Uptime kadar önemli olan ama sıklıkla ihmal edilen bir konu, yedekleme ve veri kurtarma taahhütleridir. Bazı sağlayıcılarda bu konu ana SLA'nın parçası değildir; ayrı bir yedekleme politikası belgesinde ele alınır ya da hiç yazılı bir taahhüt yoktur.

Kontrol edilmesi gereken noktalar arasında yedekleme sıklığı (günlük, haftalık), yedeklerin ne kadar süreyle saklandığı ve bir veri kaybı durumunda geri yükleme için ne kadar sürenin taahhüt edildiği yer alır. Ayrıca veri kaybı yaşandığında sorumluluğun sağlayıcı ile müşteri arasında nasıl paylaşıldığı da netleşmelidir; çoğu zaman müşterinin de kendi yedeklerini tutması beklenir.

Yedekleme taahhüdü içermeyen bir SLA, sunucunuzun "ayakta kalması" konusunda güvence verse bile, veri kaybı riskine karşı sizi savunmasız bırakabilir. Bu, uptime garantisi kadar ciddiye alınması gereken bir boşluktur.

Veri Merkezi Tier Seviyesi ve Ağ Altyapısı Garantileri

Veri merkezlerinin sınıflandırılmasında kullanılan Tier I'den Tier IV'e kadar olan seviyeler, fiziksel altyapının yedeklilik ve dayanıklılık düzeyini gösterir. Daha yüksek tier seviyesi genellikle daha fazla yedekli güç kaynağı, soğutma sistemi ve bakım esnekliği anlamına gelir.

Ancak tier seviyesinin tek başına bir uptime garantisi olmadığını hatırlamak önemlidir. Tier seviyesi, altyapının teorik dayanıklılığını gösterir; SLA'da yer alan somut uptime taahhüdü ise ayrı bir konudur ve bu ikisi mutlaka birebir örtüşmeyebilir.

Ağ altyapısı tarafında ise yedekli internet çıkışlarının varlığı, birden fazla operatörle bağlantı sağlanıp sağlanmadığı ve gecikme (latency) konusunda herhangi bir taahhüt olup olmadığı incelenmelidir. Bir SLA'nın sadece sunucu çalışma süresine odaklanıp ağ performansına hiç değinmemesi, hizmetin gerçek kalitesi hakkında eksik bilgi vermeniz anlamına gelir.

Fesih, Değişiklik Bildirimi ve Sözleşme Sonlandırma Koşulları

SLA'lar statik belgeler değildir; sağlayıcılar zaman içinde şartları güncelleyebilir. Burada önemli olan, bu değişikliklerin tek taraflı olarak yapılıp yapılamayacağı ve size ne kadar önceden bildirim yapılacağıdır. Bildirim süresi çok kısa tutulmuşsa, kabul etmediğiniz yeni şartlarla karşı karşıya kalma riskiniz artar.

Ayrıca sağlayıcının SLA'yı tekrarlayan şekilde ihlal etmesi durumunda sizin sözleşmeyi feshetme hakkınızın olup olmadığı da kontrol edilmelidir. Bazı sözleşmelerde bu hak açıkça tanınırken, bazılarında böyle bir çıkış maddesi bulunmayabilir.

Son olarak, sözleşme sonlandığında verilerinizin nasıl ve ne kadar süre içinde size teslim edileceğine veya taşınacağına dair maddelerin varlığı da göz ardı edilmemelidir. Bu madde eksikse, sağlayıcı değişikliği yapmak istediğinizde beklenmedik zorluklarla karşılaşabilirsiniz.

Kapasite Planlama ve Ölçeklenebilirlik Taahhütleri

İşletmeniz büyüdükçe sunucu ihtiyaçlarınız da değişir. Bir SLA'nın bu büyümeye karşı herhangi bir kapasite garantisi içerip içermediğini kontrol etmek uzun vadeli planlama açısından önemlidir.

Özellikle ani trafik artışları yaşandığında (örneğin bir kampanya veya haber sonrası), performans taahhüdünün geçerliliğini koruyup korumadığı sorgulanmalıdır. Bazı sözleşmelerde "normal kullanım koşulları" gibi belirsiz ifadeler yer alır ve bu, olağandışı yük durumlarında sağlayıcıya sorumluluktan kaçma imkanı tanıyabilir.

Ölçeklenebilirlik maddelerinin hiç bulunmaması, kısa vadede fark edilmese de işletmeniz büyüdükçe sizi ciddi şekilde sınırlayabilir; bu nedenle SLA'yı sadece bugünkü ihtiyaçlarınıza göre değil, gelecekteki büyüme senaryolarına göre de değerlendirmek gerekir.

SLA Karşılaştırırken Sorulması Gereken Kontrol Listesi

Farklı sağlayıcıların SLA metinlerini karşılaştırırken aşağıdaki soruları kendinize sorabilirsiniz:

• Uptime yüzdesi hangi periyotla (aylık mı, yıllık mı) hesaplanıyor ve kesinti tanımı planlı bakımı, kısmi kesintiyi kapsıyor mu?
• Telafi süreci nasıl işliyor; talep için son tarih, üst sınır ve ödeme şekli nedir?
• Kesinti tespiti kim tarafından yapılıyor; bağımsız kayıtlarla itiraz etme imkanı var mı?
• Yedekleme, destek yanıt/çözüm süreleri, fesih koşulları ve kapasite garantileri ayrı ayrı ve açık şekilde ele alınmış mı?

Bu soruların net cevaplarını bulamadığınız bir SLA metni, muhtemelen sizi ileride belirsizliklerle baş başa bırakacaktır. İmzadan önce zaman ayırıp bu maddeleri sorgulamak, kesinti anında yaşanacak hayal kırıklıklarının önüne geçmenin en pratik yoludur.