Bir hosting hizmetinin “yüksek erişilebilirlik” sunduğunu söylemek ile bu erişilebilirliğin hangi koşullarda, nasıl ölçüleceğini ve bir aksaklıkta ne yapılacağını yazılı biçimde tanımlamak aynı şey değildir. Service Level Agreement ifadesinin kısaltması olan SLA, sağlayıcı ile müşteri arasındaki hizmet seviyesi beklentilerini ölçülebilir maddelere dönüştürür. Böylece yalnızca genel bir kalite vaadi değil, kapsamı ve değerlendirme yöntemi belli bir çalışma çerçevesi oluşur.
Hosting SLA’sını değerlendirirken tek bir uptime yüzdesine odaklanmak yanıltıcı olabilir. Ölçüm noktası, planlı bakım, ağ ve donanım kapsamı, destek yanıt hedefi, istisnalar, raporlama yöntemi ve ihlal halinde uygulanacak hizmet kredisi birlikte okunmalıdır. Bu rehber, SLA’nın ne anlama geldiğini, uptime takibinin nasıl yapılacağını ve farklı sağlayıcıların tekliflerinin hangi sorularla karşılaştırılabileceğini açıklar.
SLA nedir?
SLA, bir hizmetin hangi seviyede sunulmasının hedeflendiğini ve bu seviyenin hangi ölçütlerle değerlendirileceğini açıklayan sözleşmesel bölümdür. Hosting bağlamında sunucuya veya hizmete erişilebilirlik, destek taleplerine ilk yanıt süresi, arıza bildirimi, yedekleme kapsamı ve olay sonrası raporlama gibi başlıkları içerebilir. Her SLA aynı kapsamı taşımaz; belgenin adı kadar, maddelerin ölçülebilir ve denetlenebilir olması önemlidir.
İyi hazırlanmış bir SLA, hizmeti, ölçüm dönemini, veri kaynağını ve tarafların sorumluluklarını açıkça belirtir. “Sorunlara hızlı müdahale edilir” gibi yoruma açık bir ifade yerine, hangi öncelik seviyesindeki talebe hangi kanal üzerinden ne zaman ilk yanıt verileceği tanımlanmalıdır. Benzer biçimde erişilebilirliğin web sitesi yanıtına mı, sunucu ağına mı yoksa fiziksel altyapıya mı ilişkin olduğu anlaşılmalıdır.
SLA, bütün kesintileri önleyen bir garanti değildir. Teknik arıza, bakım, güvenlik olayı veya müşterinin yapılandırmasından kaynaklanan problem yine yaşanabilir. Belge; olayın nasıl sınıflandırılacağını, hangi verilerle doğrulanacağını ve hedef karşılanmadığında hangi sürecin işleyeceğini önceden belirleyerek belirsizliği azaltır.
SLA ile uptime arasındaki fark nedir?
Uptime, hizmetin belirli bir ölçüm döneminde erişilebilir olduğu sürenin oranını ifade eden bir metriktir. SLA ise uptime dahil olmak üzere hizmete ilişkin birden fazla hedefi, ölçüm kuralını, istisnayı ve telafi yöntemini içerebilen daha geniş çerçevedir. Bu nedenle uptime değeri SLA’nın bir parçası olabilir, fakat tek başına SLA’nın tamamını temsil etmez.
Örneğin ağ bağlantısı çalışırken işletim sistemi yanlış yapılandırma nedeniyle yanıt vermeyebilir. Sağlayıcının SLA’sı yalnız ağ erişilebilirliğini kapsıyorsa bu olay müşteri açısından gerçek bir kesinti olsa da aynı SLA metriğine dahil edilmeyebilir. İşletim sistemi yönetimi, izleme ve müdahale kapsamının açıkça tanımlandığı bir yönetilen sunucu hizmeti değerlendirilirken, altyapı uptime’ı ile yönetim sorumluluğunun ayrı maddeler olduğunu kontrol etmek gerekir.
Uptime izleme “hizmet erişilebilir mi?” sorusuna veri üretir. SLA ise “hangi hizmet, kime göre erişilebilir sayılacak; hangi süreler hesap dışı kalacak ve hedef karşılanmazsa ne olacak?” sorularını yanıtlamalıdır. İki kavramı ayırmak, farklı kapsamları aynı yüzde üzerinden karşılaştırma hatasını önler.
Hosting SLA’sında hangi metrikler bulunmalıdır?
SLA metrikleri satın alınan hizmetin türüne göre seçilmelidir. Paylaşımlı hostingte web ve kontrol paneli erişimi önemliyken fiziksel sunucuda ağ, güç, donanım müdahalesi ve uzaktan erişim ayrı ayrı ele alınabilir. Ölçülemeyen veya veri kaynağı belirtilmeyen hedeflerin olay sonrasında doğrulanması zorlaşır.
- Hizmet veya ağ erişilebilirliği ve ölçüm dönemi
- Kesintinin başlangıç ve bitişinin nasıl belirleneceği
- Destek talebine ilk yanıt ve durum güncelleme hedefleri
- Öncelik seviyelerinin ve kritik olayın tanımı
- Planlı bakım bildirim yöntemi ve kapsamı
- Donanım arızasında inceleme veya değiştirme hedefleri
- Olay kaydı, raporlama ve hizmet kredisi süreci
Yedekleme SLA içinde yer alıyorsa yalnız “yedek alınır” ifadesi yeterli değildir. Yedeklenen veri, sıklık, saklama süresi, geri yükleme talebinin kapsamı ve geri dönüş sorumluluğu ayrı ayrı yazılmalıdır. Aynı şekilde destek hedefinin ilk yanıt mı, geçici çözüm mü yoksa kalıcı çözüm mü olduğu belirtilmelidir.
Ölçüm kapsamı neden açık olmalıdır?
Alan adı çözümlemesi, uygulama, veritabanı, işletim sistemi, sanallaştırma katmanı, ağ ve veri merkezi birbirinden farklı hata alanlarıdır. SLA bunların tamamını kapsamayabilir. Ölçüm kapsamı açık olduğunda müşteri kendi uygulama izlemesini sağlayıcının altyapı raporuyla birlikte değerlendirebilir ve sorunun hangi katmanda oluştuğunu daha doğru belirleyebilir.
Uptime yüzdesi nasıl hesaplanır?
Temel hesaplama, ölçüm dönemindeki toplam süreden SLA kapsamında doğrulanan kesinti süresinin çıkarılması ve kalan sürenin toplam süreye oranlanmasıdır. Formül, (toplam süre - kapsam dahilindeki kesinti) / toplam süre × 100 biçiminde ifade edilebilir. Buradaki kritik nokta matematikten çok hangi olayların “kapsam dahilindeki kesinti” sayıldığıdır.
Ölçüm dönemi aylık, üç aylık veya başka bir sözleşme dönemi olabilir. Farklı dönemler aynı olayın yüzdesel etkisini değiştirir. Ayrıca kısa süreli başarısız kontrollerin kaç kez tekrarlanması gerektiği, kısmi performans bozulmasının kesinti sayılıp sayılmadığı ve farklı lokasyonlardan alınan sonuçların nasıl birleştirileceği belirtilmelidir.
Tek bir monitör sonucu yeterli midir?
Tek bir lokasyondaki kontrol, o izleme noktasının internet bağlantısından veya DNS çözümleyicisinden etkilenebilir. Kesintiyi doğrulamak için farklı ağlardan tekrar kontrolü, hizmet portu testi, sunucu ve uygulama logları ile sağlayıcı durum kayıtları birlikte değerlendirilmelidir. Aksi halde yerel erişim sorunu genel hizmet kesintisi olarak kaydedilebilir.
Planlı bakım ve istisnalar nasıl ele alınır?
Planlı bakım çoğu SLA’da belirli koşullarla uptime hesabının dışında tutulabilir. Bunun kabul edilebilir olması için bakımın bildirim süresi, tahmini zaman aralığı, etkilenecek hizmetler ve değişiklik halinde uygulanacak iletişim yöntemi açıklanmalıdır. Sınırsız veya belirsiz bir bakım istisnası, açıklanan uptime hedefinin pratik değerini azaltır.
Doğal afet, büyük ölçekli dış ağ sorunu, müşterinin yaptığı hatalı yapılandırma, ödenmemiş hizmet nedeniyle askıya alma veya izin verilmeyen kullanım gibi durumlar da istisna listesinde bulunabilir. Ancak “üçüncü taraf kaynaklı bütün olaylar” gibi çok geniş ifadelerin altyapı bağımlılıklarını tamamen kapsam dışı bırakıp bırakmadığı dikkatle okunmalıdır.
Müşteri sorumlulukları da aynı açıklıkta yazılmalıdır. Güncel iletişim bilgisi sağlamak, destek talebini doğru kanaldan açmak, yönetilmeyen sistemde yazılım güncellemelerini yapmak veya gerekli logları paylaşmak müşteriye ait olabilir. Sorumluluk dağılımı belirsizse olay sırasında çözüm ve kredi değerlendirmesi uzar.
Uptime nasıl izlenir ve kesinti nasıl doğrulanır?
Uptime takibi, dışarıdan düzenli aralıklarla yapılan erişim kontrolleriyle başlar. Yalnız ana sayfanın yanıt vermesi yerine DNS çözümlemesi, TLS bağlantısı, HTTP durum kodu ve kritik bir uygulama uç noktası ayrı izlenebilir. Dinamik bir hizmet için veritabanına bağlı basit bir sağlık kontrolü, yalnız statik sayfa testinden daha anlamlı olabilir.
Alarm geldiğinde önce olayın tek bir kullanıcıyı mı, belirli bir lokasyonu mu yoksa tüm ziyaretçileri mi etkilediği belirlenmelidir. DNS sonucu, rota, port erişimi, HTTP yanıtı, zaman damgası ve hata metni kaydedilmelidir. Örneğin 503 Service Unavailable hatası, sunucuya bağlantı kurulabildiği halde uygulamanın isteği karşılayamadığını gösterebilir; bu durum ağ kesintisiyle aynı biçimde sınıflandırılmamalıdır.
Sağlayıcıya iletilen kayıtta başlangıç zamanı, etkilenen alan adı veya IP, test lokasyonları, alınan hata ve mümkünse olayın tekrarlandığı aralık bulunmalıdır. Sunucu loglarının saat dilimi ile izleme aracının saat dilimi eşleştirilmelidir. Hizmet yeniden geldiğinde de yalnız tek başarılı kontrolden sonra değil, art arda sağlıklı yanıtlar görüldüğünde bitiş zamanı belirlemek daha güvenilir olur.
Performans düşüşü kesinti sayılır mı?
Yüksek gecikme veya zaman aşımı, kullanıcı açısından hizmeti kullanılamaz hale getirebilir. Fakat SLA yalnız “port açık” kontrolüne dayanıyorsa performans bozulması kapsam dışında kalabilir. Kritik uygulamalarda yanıt süresi, hata oranı veya işlem başarısı gibi hizmet seviyesi göstergelerinin ayrıca tanımlanması bu boşluğu azaltır.
SLA ihlali ve hizmet kredisi süreci nasıl işler?
Hedefin karşılanmadığını düşünüyorsanız önce SLA’daki başvuru süresini ve gerekli kanıtları kontrol edin. Bazı sözleşmeler kredinin otomatik tanımlanmasını, bazıları ise müşterinin belirli bir süre içinde talep açmasını öngörür. Talepte olay numarası, doğrulanan kesinti aralığı, etkilenen hizmet ve hesaplama yöntemi açıkça yer almalıdır.
Hizmet kredisi çoğunlukla nakit tazminatla aynı şey değildir; gelecek fatura veya hizmet dönemi için uygulanabilecek sınırlı bir alacak olarak tanımlanabilir. Kredinin üst sınırı, hangi hizmet bedeli üzerinden hesaplandığı ve başka bir hesaba aktarılıp aktarılamadığı sözleşmede kontrol edilmelidir. İş kaybının tamamının krediyle karşılanacağı varsayılmamalıdır.
Kredi talebi, teknik kök neden analizinin yerine geçmez. Tekrarlayan olaylarda sağlayıcıdan zaman çizelgesi, etkilenen bileşen, uygulanan düzeltme ve tekrarını önleme adımları istenmelidir. Böylece değerlendirme yalnız geçmiş faturaya değil gelecekteki operasyon riskine de dayanır.
Destek hedefleri SLA’ya nasıl yazılır?
Destek SLA’sında öncelik seviyeleri somut etkiyle tanımlanmalıdır. Tam erişim kaybı ile tek kullanıcının yapılandırma sorunu aynı önceliğe sahip olmamalıdır. İlk yanıt, durum güncellemesi, geçici çözüm ve kalıcı çözüm birbirinden ayrılmalı; her hedefin yalnız mesai saatlerinde mi yoksa günün tamamında mı geçerli olduğu belirtilmelidir.
“Çözüm süresi” her arıza için kesin olarak taahhüt edilemeyebilir; üçüncü taraf müdahalesi veya karmaşık veri kurtarma farklı süre gerektirebilir. Bu durumda sağlayıcı, ilk müdahale ve düzenli bilgilendirme hedeflerini ölçülebilir biçimde tanımlayabilir. Müşterinin cevap vermesini bekleyen sürelerin sayaçta nasıl ele alındığı da açık olmalıdır.
Hosting SLA teklifleri nasıl karşılaştırılır?
Karşılaştırmaya açıklanan yüzdeyi sıralayarak değil, kapsam tablosu oluşturarak başlayın. Ölçüm noktası, dönem, bakım istisnası, ağ ve güç kapsamı, uygulama sorumluluğu, destek kanalı, kredi talep süresi ve kredi üst sınırını aynı satırlarda değerlendirin. Aynı görünen iki uptime hedefi, farklı istisnalar nedeniyle pratikte farklı koruma sunabilir.
- Hizmetin hangi bileşeni erişilebilir sayılıyor?
- Ölçümü sağlayıcı mı, bağımsız araç mı yapıyor?
- Planlı bakım ne kadar önce bildiriliyor?
- Kesinti ve performans bozulması nasıl ayrılıyor?
- Destek öncelikleri ve çalışma saatleri açık mı?
- Kredi otomatik mi, başvuruya bağlı mı?
- Olay sonrası rapor veya kök neden analizi sağlanıyor mu?
Son seçim iş yükünün önemine göre yapılmalıdır. Kritik olmayan bir tanıtım sitesi ile sürekli işlem alan bir uygulamanın kesinti toleransı aynı değildir. SLA’yı mimari yedeklilik, yedekleme, izleme ve kurtarma planının yerine koymak yerine bu önlemleri tamamlayan sözleşmesel katman olarak değerlendirin.
Sonuç
SLA, hosting hizmetinin ölçülebilir hedeflerini ve hedef karşılanmadığında izlenecek yolu tanımlar; uptime ise bu çerçevede kullanılan metriklerden yalnız biridir. Sağlıklı bir değerlendirme için ölçüm dönemi, kapsam, planlı bakım, istisnalar, destek seviyeleri ve hizmet kredisi aynı belge içinde birlikte okunmalıdır.
Kendi dış izlemenizi tutun, hata kayıtlarını zaman damgasıyla saklayın ve sağlayıcının raporuyla karşılaştırın. En yüksek yüzdeyi seçmek yerine, iş yükünüzün gerçek risklerini kapsayan, sorumlulukları açık ve doğrulanabilir bir SLA tercih edin.
Hosting SLA hakkında sık sorulan sorular
SLA bütün hosting kesintilerini kapsar mı?
Hayır. Kapsam hizmete ve sözleşmeye göre değişir. Planlı bakım, müşteri yapılandırması, alan adı veya belirli üçüncü taraf hizmetleri istisna olabilir. Hangi katmanın ve olay türünün kapsandığı SLA metninden doğrulanmalıdır.
Uptime değerini yalnız sağlayıcının panelinden izlemek yeterli midir?
Sağlayıcı verisi önemlidir fakat kullanıcı deneyimini görmek için farklı lokasyonlardan bağımsız dış izleme de yararlıdır. İki veri kaynağının ölçüm noktaları ve saat dilimleri aynı olmadığından sonuçlar olay kaydıyla birlikte değerlendirilmelidir.
SLA ihlalinde hizmet kredisi otomatik verilir mi?
Her zaman değil. Bazı sözleşmeler otomatik kredi tanımlarken bazıları belirli süre içinde kanıtlarla başvuru ister. Talep yöntemi, zaman sınırı ve kredi hesabı hizmet başlamadan önce okunmalıdır.
Uptime hedefi yedekleme ve veri kurtarmayı da kapsar mı?
Genellikle bunlar ayrı hizmet başlıklarıdır. Sunucunun erişilebilir olması yedeğin güncel veya geri yüklenebilir olduğunu göstermez. Yedek sıklığı, saklama ve geri yükleme hedefleri ayrıca tanımlanmalıdır.
