Kurumsal hosting hizmeti satın alırken teknik özellikler kadar, hatta çoğu durumda onlardan daha kritik olan unsur SLA sözleşmesidir. SLA, sağlayıcının hangi hizmet seviyesini hangi koşullarda sunacağını yazılı ve ölçülebilir şekilde tanımlar. Bu doküman doğru okunmadığında, kesinti anında beklentiler ile gerçek sonuçlar arasında ciddi farklar oluşur; BT ekipleri operasyonel baskı yaşar, iş birimleri gelir kaybı ve itibar riskiyle karşılaşır. Bu nedenle SLA incelemesi, yalnızca hukuk veya satın alma ekiplerine bırakılmamalı; BT operasyon, güvenlik, uygulama sahipleri ve finans birimleri birlikte değerlendirme yapmalıdır. Amaç, “yüksek uptime” gibi genel vaatler değil, gerçek hayatta denetlenebilir taahhütler üzerinden riskleri yönetmektir.
SLA dokümanının kapsamını ve tanımlarını netleştirin
İyi bir SLA incelemesi, önce tanımlar bölümünden başlamalıdır. “Hizmet kesintisi”, “planlı bakım”, “acil bakım”, “kritik olay”, “yanıt süresi” ve “çözüm süresi” gibi terimler belirsiz bırakılmışsa, aynı olay için farklı yorumlar oluşur. Örneğin bazı sağlayıcılar yalnızca altyapı erişilebilirliğini kapsarken, bazıları işletim sistemi, yönetilen servisler ve güvenlik katmanını da SLA kapsamına alır. Bu fark, olay anında hangi ekibin sorumlu olacağını doğrudan etkiler. Bu nedenle sözleşme metninde hizmetin teknik sınırlarını, müşteri sorumluluklarını ve üçüncü taraf bağımlılıklarını satır satır doğrulamak gerekir.
Bir diğer kritik nokta, hizmetin hangi lokasyon ve ortamları kapsadığıdır. Üretim ortamı için verilen SLA’nın test, felaket kurtarma veya yedekleme ortamlarında aynı olup olmadığı mutlaka kontrol edilmelidir. Ayrıca “çoklu bölge”, “çoklu veri merkezi” veya “yedekli mimari” gibi ifadelerin SLA metninde sadece pazarlama söylemi olarak mı yer aldığı, yoksa ölçülebilir taahhütlere bağlanıp bağlanmadığı incelenmelidir. Kurumsal tarafta en doğru yaklaşım, SLA kapsamını şirketin kritik uygulama envanteriyle eşleştirmek ve hangi uygulamanın hangi hizmet seviyesiyle korunacağını önceden yazılı hale getirmektir.
Erişilebilirlik, performans ve bakım pencerelerini teknik gerçeklikle değerlendirin
SLA’daki erişilebilirlik yüzdesi tek başına yeterli değildir; nasıl ölçüldüğü en az rakam kadar önemlidir. Aylık yüzde 99,9 ile yüzde 99,95 arasında küçük görünen fark, yıl bazında saatlerce ek kesinti anlamına gelebilir. Ölçümün sağlayıcının iç izleme sistemine mi, tarafsız dış ölçüme mi dayandığı net olmalıdır. Ayrıca ölçüm noktası da kritiktir: veri merkezi ağından ölçülen erişilebilirlik, son kullanıcı deneyimini yansıtmayabilir. Kurumsal ekipler için doğru yöntem, SLA metriğini iş uygulamasının gerçek erişim senaryolarıyla karşılaştırmak ve tutarsızlık varsa müzakere etmektir.
Planlı bakım pencereleri, sözleşmede en sık gözden kaçırılan bölümlerden biridir. Birçok sağlayıcı bakım dönemlerini kesinti hesabı dışında tutar; ancak bakım sıklığı, süresi ve duyuru süresi sınırsız bırakılmışsa pratikte ciddi operasyonel etki oluşur. Bu nedenle bakım bildiriminin kaç gün önce yapılacağı, bakımın hangi saat dilimlerinde uygulanacağı ve kritik dönemlerde bakımın ertelenip ertelenemeyeceği açık yazılmalıdır. Özellikle e-ticaret, finans veya 7/24 müşteri hizmeti sunan kurumlarda bakım penceresi politikası, iş takvimiyle uyumlu olacak şekilde sözleşmeye bağlanmalıdır.
- Erişilebilirlik metriğinin aylık mı yıllık mı hesaplandığını doğrulayın; hesap periyodu tazmin hesaplamasını etkiler.
- Bakım kesintilerinin toplam süre limiti olup olmadığını isteyin; sınırsız istisna operasyon riskini artırır.
- Performans kriterlerinde yalnızca altyapı metrikleri değil, uygulama katmanını etkileyen gecikme ve I/O sınırlarını da değerlendirin.
- SLA raporlarının formatını, paylaşım sıklığını ve geriye dönük denetlenebilirliğini sözleşmeye dahil edin.
İhlal yönetimi, tazmin mekanizması ve destek süreçlerinde uygulanabilirlik arayın
SLA ihlal edildiğinde ne olacağı, sözleşmenin en kritik operasyonel bölümüdür. Birçok metinde tazmin “hizmet kredisi” olarak tanımlanır; bu kredi çoğu zaman doğrudan mali kaybı karşılamaz, sadece sonraki faturalarda indirim sağlar. Bu nedenle kurumunuz için kabul edilebilir tazmin modelini önceden belirlemek önemlidir. Kritik sistemler için sadece kredi değil, tekrar eden ihlallerde fesih hakkı, iyileştirme planı zorunluluğu veya üst yönetim seviyesinde olay inceleme toplantısı gibi mekanizmalar da düşünülmelidir. Amaç cezalandırmak değil, hizmet seviyesini sürdürülebilir şekilde güvence altına almaktır.
Destek süreçlerinde ise “yanıt süresi” ile “çözüm süresi” arasındaki fark net olmalıdır. Dakikalar içinde yanıt vermek, olayın kısa sürede çözüleceği anlamına gelmez. Bu nedenle farklı olay öncelikleri için hem ilk geri dönüş hem de hedef çözüm süreleri yazılı olmalıdır. Ayrıca eskalasyon adımları, iletişim kanalları, 7/24 erişim modeli ve olay sonrası kök neden analizi teslim süresi açıkça belirtilmelidir. Kurumsal ekipler, sözleşme imzalanmadan önce bir masa başı tatbikat yaparak olası kesinti senaryosunda kimin ne zaman devreye gireceğini prova ederse, gerçek olay anındaki belirsizlikler ciddi ölçüde azalır.
- İhlal bildiriminin otomatik mi manuel mi olacağını netleştirin; yalnızca müşteri başvurusuna bağlı modellerde hak kaybı yaşanabilir.
- Tazmin talebi için süre sınırı ve gerekli kanıt setini önceden öğrenin; kaçırılan süreler kredi hakkını düşürebilir.
- Tekrarlayan ihlallerde zorunlu düzeltici faaliyet planı ve takip toplantısı şartı ekleyin.
Müzakere ve uygulama için kurum içi kontrol adımları oluşturun
SLA incelemesinin etkili olması için teknik ekiplerin hukuki metinlere aktif katkı vermesi gerekir. Pratikte en iyi yöntem, kurum içinde kısa bir “SLA değerlendirme matrisi” hazırlamaktır. Bu matriste kritik uygulamalar, kabul edilebilir kesinti süresi, hedef kurtarma süresi, sorumlu iş birimi ve sağlayıcı taahhütleri yan yana yazılır. Böylece sözleşmedeki her madde iş etkisiyle ilişkilendirilebilir. Satın alma sürecinde düşük maliyet avantajı sağlayan teklif, zayıf SLA koşulları nedeniyle toplam sahip olma maliyetini yükseltebilir; bu yüzden karar sadece fiyatla verilmemelidir.
- Öncelikle iş kritikliği yüksek sistemleri sınıflandırın ve her sınıf için minimum SLA eşiği belirleyin.
- Sağlayıcıdan örnek aylık SLA raporu talep edin; ölçüm ve raporlama yaklaşımını imza öncesinde görün.
- Planlı bakım, acil bakım ve istisna maddeleri için üst sınırlar ve bildirim süreleri üzerinde net uzlaşma sağlayın.
- Destek modeli için iletişim zinciri, eskalasyon seviyeleri ve olay kapatma kriterlerini kurum prosedürleriyle hizalayın.
- İhlal durumunda kredi, düzeltici faaliyet ve fesih hakkı maddelerini birbirini tamamlayacak şekilde yapılandırın.
Sonuç olarak kurumsal hostingte güçlü bir SLA, sadece hukuki güvence değil, aynı zamanda operasyonel süreklilik aracıdır. Doğru hazırlanmış bir sözleşme kesintileri tamamen ortadan kaldırmaz; ancak etkisini öngörülebilir hale getirir, sorumlulukları netleştirir ve iyileştirme kültürü oluşturur. Kurumlar için en sağlıklı yaklaşım, SLA’yı imza anında bırakılan statik bir belge olarak değil, düzenli gözden geçirilen yaşayan bir yönetim çerçevesi olarak ele almaktır. Bu disiplin, hem hizmet kalitesini hem de iş birimlerinin teknolojiye duyduğu güveni uzun vadede güçlendirir.