İmzalanan Bilişim Anlaşmalarında Hizmet Seviyesi (SLA) Belirleme

Bir bilişim sözleşmesinde “hizmet kesintisiz sunulacaktır” yazması ilk bakışta güven verici görünebilir. Fakat hangi hizmetin, hangi saatlerde, hangi ölçüm yöntemiyle ve hangi hata payıyla kesintisiz sayılacağı yazılmamışsa bu ifade uyuşmazlık anında beklenen korumayı sağlamayabilir. 10 yıllık uzmanlık perspektifiyle değerlendirildiğinde, İmzalanan Bilişim Anlaşmalarında Hizmet Seviyesi (SLA) Belirleme sürecinde en kritik konu yüksek oranlar yazmak değil, teknik beklentileri ölçülebilir ve uygulanabilir sözleşme mekanizmalarına dönüştürmektir. Bu rehberde bilişim sözleşmelerinde SLA hizmet seviyesi nasıl belirlenir, yazılım ve BT hizmet sözleşmelerinde SLA maddeleri nasıl hazırlanır, SLA sözleşmesinde uptime yanıt süresi ve çözüm süresi nasıl belirlenir ve bilişim sözleşmelerinde SLA ihlali cezai şart ve hizmet kredisi nasıl ele alınır sorularını birlikte inceleyeceğiz. Buradaki açıklamalar genel bilgilendirme amaçlıdır ve somut sözleşmelerde güncel mevzuat, sektör düzenlemeleri, veri koruma yükümlülükleri ve tarafların özel riskleri ayrıca değerlendirilmelidir.

Hizmet Seviyesi Anlaşması (SLA) Nedir?

SLA, hizmet sağlayıcının sunacağı bilişim hizmetinin ölçülebilir performans seviyelerini ve bu seviyelerin nasıl takip edileceğini belirleyen sözleşmesel çerçevedir. Uptime, ilk yanıt süresi, müdahale süresi, çözüm hedefi, veri yedekleme, güvenlik olay bildirimi veya destek saatleri gibi konular SLA içinde düzenlenebilir. İyi hazırlanmış bir SLA yalnız müşteriye hak veren metin değildir, aynı zamanda sağlayıcının hangi koşullarda hangi performansı taahhüt ettiğini açıkça gösterir. Böylece tarafların farklı teknik beklentilerle hareket etmesi önlenir. SLA'nın değeri, anlaşılabilir tanımlar ile doğrulanabilir ölçüm sistemlerinin bir araya gelmesinden doğar.

SLA Ne Anlama Gelir?

SLA, Service Level Agreement ifadesinin kısaltmasıdır ve Türkçede Hizmet Seviyesi Anlaşması olarak kullanılır. Belge, hizmetin hangi kalite seviyesinde sunulacağını ölçülebilir kriterlere bağlar. Örneğin “yüksek erişilebilirlik” yerine aylık yüzde 99,9 availability hedefi yazılabilir. Benzer biçimde “hızlı destek” yerine P1 olaylarında 15 dakika içinde ilk insan yanıtı gibi net bir süre kullanılabilir. Böylece hizmet kalitesi yorumdan çıkar ve tarafların üzerinde anlaşabileceği verilere bağlanır.

Bilişim Sözleşmelerinde SLA Neden Kullanılır?

Bilişim hizmetlerinin önemli bölümü devamlılık ve ölçülebilir performans gerektirir. SaaS uygulaması, veri tabanı, bulut altyapısı veya yönetilen ağ hizmeti kesildiğinde iş süreçleri doğrudan etkilenebilir. SLA bu riskin hangi seviyede kabul edildiğini önceden belirler. Müşteri hangi performansı satın aldığını, sağlayıcı da hangi seviyeyi sağlamakla yükümlü olduğunu bilir. Bu nedenle SLA yalnız operasyon belgesi değil, ticari fiyatlandırma ve risk paylaşımı aracıdır.

SLA Bir Sözleşme midir, Sözleşme Eki midir?

SLA bağımsız sözleşme olarak imzalanabilir veya ana bilişim sözleşmesinin eki haline getirilebilir. Uygulamada çoğu kurum SLA'yı ana sözleşmeye bağlı teknik ve operasyonel ek olarak kullanır. Önemli olan belgenin hukuki bağının ve öncelik sırasının açıkça yazılmasıdır. Ana sözleşme başka şey söylerken SLA farklı düzenleme içeriyorsa hangi hükmün uygulanacağı belirsiz kalmamalıdır. Bu nedenle belge mimarisi imza aşamasında netleştirilmelidir.

Hizmet Sağlayıcı ve Hizmet Alan Açısından SLA'nın İşlevi

Hizmet alan SLA sayesinde satın aldığı performansın ölçülebilir sınırlarını görür. Hizmet sağlayıcı ise sınırsız ve yoruma açık beklentiler yerine belirli taahhütlerle çalışır. İki taraf için de raporlama, eskalasyon ve iyileştirme mekanizması oluşur. İhlal halinde uygulanacak servis kredisi veya başka sonuçlar önceden bilinir. Böylece teknik operasyon ile sözleşmesel sorumluluk aynı çerçevede yönetilir.

İyi Bir SLA Hangi Sorunları Önler?

İyi bir SLA öncelikle “kesinti ne zaman başladı?” veya “yanıt sayılan şey nedir?” gibi temel tartışmaları azaltır. Ticket saatinin hangi anda çalışmaya başladığı ve hangi koşullarda durduğu tanımlanır. Planlı bakım, üçüncü taraf arızası ve müşteri kaynaklı sorunlar için sınırlar belirlenir. Kronik ihlal ve çıkış süreci önceden düzenlenebilir. Böylece taraflar sorun çıktığında sözleşmeyi yorumlamak yerine önceden kabul edilen mekanizmayı uygular.

İmzalanmış Bilişim Sözleşmesinde SLA Neden Kritik Öneme Sahiptir?

İmzalanmış bir bilişim sözleşmesinde SLA, teknik hizmet beklentisinin hukuken takip edilebilir hale gelmesini sağlar. Özellikle kritik sistemlerde sözleşme bedeli kadar hizmetin devamlılığı da ticari değerin parçasıdır. Ölçüm yöntemi bulunmayan genel taahhütler tarafların aynı olayı farklı biçimde yorumlamasına yol açabilir. Müşteri yüzde 100 hizmet beklerken sağlayıcı belirli kesintileri olağan kabul edebilir. Bu nedenle SLA, sözleşmenin teknik gerçeklik ile ticari beklenti arasında kurduğu en önemli köprülerden biridir.

Teknik Beklentilerin Hukuki Yükümlülüğe Dönüştürülmesi

Teknik ekip “P1 olayına 15 dakikada müdahale” beklentisine sahip olabilir. Bu beklenti yalnız operasyon dokümanında kalırsa ticari bağlayıcılığı zayıf olabilir. SLA içinde açık tanım, başlangıç anı ve ölçüm yöntemiyle yazıldığında sözleşmesel yükümlülüğe dönüşür. İhlal halinde uygulanacak sonuç da aynı metinde veya ana sözleşmede ilişkilendirilebilir. Bu yaklaşım teknik gereksinim ile hukuk metni arasında daha güçlü uyum sağlar.

Soyut "Kesintisiz Hizmet" İfadesinin Sakıncaları

Kesintisiz hizmet ifadesi ölçüm yöntemi olmadan çok geniş anlam taşıyabilir. Planlı bakımın dahil olup olmadığı bilinmez. Tek kullanıcı etkilenirse kesinti sayılıp sayılmayacağı da belirsiz kalabilir. Bölgesel arıza veya performans düşüşü aynı tartışmayı doğurur. Bu yüzden soyut ifadeler yerine kapsamı ve ölçümü açık availability hedefleri kullanılmalıdır.

Ölçülemeyen Hizmet Taahhüdünün Yarattığı Uyuşmazlıklar

Ölçüm yapılmayan taahhütlerde taraflar kendi kayıtlarına dayanabilir. Sağlayıcının monitoring sistemi yüzde 99,95 gösterirken müşterinin sistemi yüzde 99,70 gösterebilir. Hangi kaydın esas alınacağı yazılmamışsa uyuşmazlık büyür. Log saklama süresi kısa ise geçmiş olayı doğrulamak daha da zorlaşır. Bu nedenle veri kaynağı ve hesaplama formülü SLA'nın temel bileşenidir.

SLA'nın İş Sürekliliğine Etkisi

İş sürekliliği yalnız felaket kurtarma planından ibaret değildir. Günlük operasyonlarda hizmet seviyelerinin izlenmesi de sürekliliğin parçasıdır. P1 olayları, RTO, RPO ve availability hedefleri birlikte değerlendirilebilir. İş birimleri hangi kesinti süresini tolere edebileceğini belirtmelidir. SLA bu toleransı teknik servis seviyesine dönüştürür.

SLA'nın Tedarikçi Yönetimindeki Rolü

Tedarikçi performansı yalnız aylık memnuniyet toplantılarıyla yönetilmemelidir. SLA ölçümleri objektif performans verisi sağlar. Tekrarlayan ihlaller Service Improvement Plan başlatmak için kullanılabilir. Sözleşme yenileme veya fiyat görüşmeleri bu veri üzerinden yapılabilir. Böylece tedarikçi yönetimi kişisel izlenim yerine ölçülebilir sonuçlara dayanır.

SLA Ana Bilişim Sözleşmesiyle Nasıl İlişkilendirilmelidir?

SLA'nın etkili olabilmesi için ana bilişim sözleşmesiyle açık hukuki bağ kurması gerekir. Belgenin hangi sözleşmenin eki olduğu, hangi tarih ve versiyonla yürürlüğe girdiği belirtilmelidir. Ana sözleşmede sorumluluk, fesih ve tazminat hükümleri bulunurken SLA servis kredisi veya kronik ihlal gibi özel sonuçlar düzenleyebilir. Bu hükümler birbirini tamamlamalıdır. Aksi halde aynı ihlal için iki farklı sonuç veya birbirini geçersiz kılan hükümler ortaya çıkabilir.

SLA'nın Ana Sözleşmeye Eklenmesi

SLA ek olarak kullanılıyorsa ana sözleşmede açık referans bulunmalıdır. Ek numarası ve versiyonu yazılabilir. Tarafların SLA'yı imza veya elektronik onayla kabul ettiği kayıt altına alınmalıdır. Sonradan yapılan değişikliklerin de aynı onay mekanizmasına tabi olması gerekir. Böylece operasyon dokümanı ile bağlayıcı sözleşme eki birbirinden ayrılır.

Ana Sözleşme ile SLA Arasında Çelişki

Çelişki halinde hangi belgenin öncelikli olduğu açıkça yazılmalıdır. Örneğin ana sözleşmede sorumluluk sınırı yüzde 100 iken SLA'da sınırsız kredi sonucu yaratmak istemeden çelişki oluşabilir. Benzer sorun fesih veya mücbir sebep hükümlerinde de görülebilir. Belge öncelik maddesi bu riski azaltır. Taslaklar birlikte gözden geçirilmelidir.

Dokümanların Öncelik Sırası

Bir bilişim projesinde birden fazla doküman aynı anda uygulanabilir. Ana sözleşme, SLA, teknik şartname, teklif ve iş emri farklı konuları düzenleyebilir. Öncelik sırası yazılmadığında aynı konu iki belgede farklı şekilde ele alınabilir. Kurumlar bu sıralamayı sözleşmenin başında veya özel bir hükümde belirleyebilir. Böylece yorum uyuşmazlıkları önemli ölçüde azaltılır.

Ana Sözleşme

Ana sözleşme tarafların temel ticari ve hukuki ilişkisini düzenler. Bedel, sorumluluk, gizlilik, fesih ve uyuşmazlık mekanizması burada yer alabilir. SLA bu metne bağlı çalışır. Ana sözleşmenin önceliği veya özel hükümlerde SLA'nın önceliği ayrıca tanımlanabilir. Her iki metin birlikte okunmalıdır.

SLA

SLA hizmet performansının operasyonel detaylarını düzenler. Uptime, ticket süreleri ve servis kredileri burada bulunabilir. Teknik hizmete ilişkin özel hüküm olarak belirli alanlarda öncelik tanınabilir. Ancak ana sorumluluk rejimiyle uyum korunmalıdır. Versiyon kontrolü özellikle önemlidir.

Teknik Şartname

Teknik şartname sistemin özelliklerini ve fonksiyonel gereksinimleri belirler. SLA ise bu sistemin hangi hizmet seviyesinde işletileceğini açıklar. İki belge aynı konuya farklı değer yazmamalıdır. Örneğin destek saatleri yalnız bir belgede farklı olmamalıdır. Teknik ekip ve hukuk birlikte kontrol yapmalıdır.

Teklif

Teklif fiyat ve hizmet kapsamını içerir. Pazarlama ifadesi sözleşmedeki SLA'dan daha geniş taahhüt yaratabilir. Bu nedenle kabul edilen teklifin sözleşmeyle ilişkisi netleştirilmelidir. Ticari ekiplerin verdiği taahhütler operasyon kapasitesiyle kontrol edilmelidir. Teklif versiyonu açıkça belirtilmelidir.

İş Emri veya Statement of Work

SOW belirli proje veya hizmet döneminin kapsamını detaylandırabilir. Ana sözleşmeye bağlı çalışır. Özel SLA seviyeleri SOW içinde de tanımlanabilir. Bu durumda genel SLA ile özel SOW arasındaki öncelik yazılmalıdır. Proje bitiminde hangi hükümlerin devam edeceği açıklanmalıdır.

SLA'daki Tanımların Ana Sözleşmeyle Uyumlu Olması

“Hizmet”, “kesinti”, “iş günü”, “kritik olay” ve “planlı bakım” gibi kavramlar iki belgede farklı tanımlanmamalıdır. Farklı tanımlar hesaplama sonucunu doğrudan etkileyebilir. Özellikle iş günü ve saat dilimi uluslararası hizmetlerde önemlidir. Tanımlar tek sözlük altında toplanabilir. Böylece aynı kavram farklı ekipler tarafından farklı yorumlanmaz.

SLA Değişikliklerinin Ana Sözleşmeye Etkisi

SLA hedefleri zaman içinde değişebilir. Yeni sistem, kullanıcı artışı veya mimari dönüşüm hizmet seviyesini etkileyebilir. Değişiklik süreci ana sözleşmedeki change control mekanizmasına bağlanmalıdır. Tek taraflı portal güncellemesi her sözleşme için uygun olmayabilir. Tarafların geçerli onay yöntemini baştan belirlemesi gerekir.

SLA, SLI, SLO, KPI, OLA ve XLA Arasındaki Fark Nedir?

Bu kavramlar sıkça birbirinin yerine kullanılsa da farklı işlevlere sahiptir. SLI gerçekte ne olduğunu ölçer, SLO hedefi belirler, SLA ise belirli hedefi sözleşmesel taahhüde dönüştürür. KPI operasyon ve iş performansını daha geniş biçimde izleyebilir. OLA kurum içindeki destek ekiplerini aynı hizmet hedefinde hizalar. XLA ise yalnız teknik metrik yerine kullanıcı deneyimini ölçmeye odaklanır.

SLI Nedir?

SLI, Service Level Indicator ifadesidir ve ölçülen performans göstergesini anlatır. Availability yüzdesi, API latency veya ticket response time birer SLI olabilir. SLI gerçekte gerçekleşen performansı gösterir. Hedef değil ölçümdür. Ölçüm kaynağı güvenilir ve tekrar üretilebilir olmalıdır.

SLO Nedir?

SLO, Service Level Objective ifadesidir ve hedeflenen performans seviyesidir. Örneğin aylık availability için yüzde 99,95 hedefi bir SLO'dur. SLO iç operasyon hedefi olarak da kullanılabilir. Her SLO müşteriye sözleşmesel olarak taahhüt edilmek zorunda değildir. Kurumlar iç hedefi dış SLA'dan daha yüksek tutabilir.

SLA Nedir?

SLA belirli hizmet hedeflerini taraflar arasında bağlayıcı taahhüde dönüştürür. Ölçüm, istisna ve ihlal sonucu içerir. Her teknik metriğin SLA haline getirilmesi gerekli değildir. İş açısından anlamlı ve kontrol edilebilir göstergeler seçilmelidir. Aksi halde çok sayıda metrik yönetimi zorlaştırır.

KPI Nedir?

KPI, Key Performance Indicator ifadesidir. Hizmet veya iş performansını yönetmek için kullanılan temel göstergedir. First Contact Resolution, reopen oranı veya kullanıcı memnuniyeti KPI olabilir. KPI her zaman sözleşmesel ceza veya servis kredisine bağlı değildir. Yönetim kararları için daha geniş bakış sağlar.

OLA Nedir?

OLA, Operational Level Agreement ifadesidir. Aynı organizasyon içindeki ekiplerin dış SLA'yı karşılamak için kendi aralarında belirlediği hizmet hedeflerini ifade eder. Örneğin müşteri SLA'sı 30 dakika müdahale gerektiriyorsa NOC ile uygulama ekibi arasında 10 dakikalık iç OLA kurulabilir. Böylece toplam süreç hedefe uyum sağlar. OLA genellikle müşteri sözleşmesinin parçası değildir.

XLA Nedir?

XLA, Experience Level Agreement yaklaşımıdır. Kullanıcının hizmet deneyimine daha fazla odaklanır. Teknik olarak yüzde 99,9 uptime sağlansa bile kullanıcı kritik saatlerde yavaşlık yaşıyorsa deneyim kötü olabilir. XLA bu boşluğu memnuniyet, kullanılabilirlik ve görev başarısı gibi göstergelerle ele alır. Özellikle çalışan deneyimi ve dijital iş yeri hizmetlerinde değerlidir.

Bu Kavramlar Birlikte Nasıl Kullanılır?

Bu kavramlar tek bir servis yönetim zinciri içinde birlikte kullanılabilir. Önce doğru SLI seçilir ve ölçüm sistemi kurulur. Ardından SLO ile iç veya dış hedef belirlenir. SLA yalnız müşteri açısından anlamlı ve sözleşmesel olarak yönetilebilir hedefleri taahhüt eder. KPI ve OLA ise operasyonun bu taahhüdü sürdürülebilir biçimde karşılamasını destekler.

SLI ile Ölç

Önce hangi hizmet özelliğinin ölçüleceği belirlenir. Veri kaynağı seçilir. Formül sabitlenir. Ölçüm düzenli yapılır. Sonuç denetlenebilir olmalıdır.

SLO ile Hedefle

İş ihtiyacına uygun hedef belirlenir. Hedef teknik kapasiteyle uyumlu olmalıdır. Aşırı yüksek değer gereksiz maliyet doğurabilir. İç ekipler hedefe göre kapasite planlar. Tarihsel performans dikkate alınabilir.

SLA ile Taahhüt Et

Müşteriye sunulacak hedef sözleşmeye bağlanır. İstisnalar ve ölçüm formülü yazılır. İhlal sonucu tanımlanır. Raporlama periyodu belirlenir. Taahhüt sağlayıcının gerçekten kontrol edebildiği alanlara dayanmalıdır.

KPI ile Yönet

SLA dışındaki operasyon göstergeleri de takip edilir. Reopen oranı ve backlog gibi metrikler erken uyarı sağlar. Yönetim iyileştirme aksiyonlarını bu verilerle belirler. KPI sayısı gereğinden fazla olmamalıdır. Karar üretmeyen metrikler azaltılabilir.

OLA ile İç Ekipleri Hizala

Müşteriye verilen SLA iç ekipler arasında paylaşılmalıdır. Her ekip kendi sorumluluk süresini bilmelidir. Eskalasyon zinciri belirlenir. Böylece dış taahhüt tek bir operasyon ekibine yüklenmez. İç hedefler dış hedeften daha sıkı olabilir.

SLA Hazırlamadan Önce Hizmet Envanteri Nasıl Çıkarılır?

SLA yazmaya başlamadan önce hangi hizmetlerin gerçekten sunulduğunu anlamak gerekir. Hizmet envanteri yapılmadan hazırlanan SLA çoğu zaman kritik bağımlılıkları dışarıda bırakır. Uygulamalar, entegrasyonlar, kullanıcı grupları, lokasyonlar ve üçüncü taraf servisleri tek haritada toplanmalıdır. Böylece hangi kesintinin hangi iş sürecini etkilediği görülebilir. Bu çalışma hizmet seviyesini gerçek iş ihtiyacına göre belirlemenin temelidir.

Hangi Hizmetler SLA Kapsamında?

Önce hizmet katalogu oluşturulmalıdır. SaaS uygulaması, help desk, ağ hizmeti veya veri tabanı ayrı servis olarak tanımlanabilir. Her servis için sorumlu sağlayıcı ve müşteri tarafı belirlenir. Kritik ve kritik olmayan hizmetler ayrılır. Böylece tek SLA içine birbirinden tamamen farklı servisler sıkıştırılmaz.

Kritik İş Süreçlerinin Belirlenmesi

Sistemden önce iş süreci analiz edilmelidir. Ödeme, üretim, müşteri hizmeti veya sipariş gibi süreçler kritik olabilir. Bu süreçlerin durması halinde finansal ve operasyonel etki belirlenir. Sonra hangi bilişim hizmetlerinin bu süreçleri desteklediği eşleştirilir. SLA öncelikleri bu haritaya göre verilir.

Uygulama ve Sistem Envanteri

Uygulamalar, sunucular, veri tabanları ve altyapı bileşenleri listelenmelidir. Sahiplik ve destek sorumluluğu kaydedilir. Sistemler arasındaki bağımlılık eklenir. Eski ve destek dışı bileşenler ayrıca işaretlenebilir. Bu envanter SLA kapsamının teknik temelini oluşturur.

Kullanıcı Grupları

Bütün kullanıcıların etkisi aynı değildir. İç çalışan, yönetici, son müşteri ve saha personeli farklı kritik seviyeye sahip olabilir. Kullanıcı sayısı olay önceliğini etkileyebilir. Belirli VIP kullanıcılar için özel süreç kurulabilir. Ancak öncelik matrisi yalnız unvana göre değil iş etkisine göre tasarlanmalıdır.

Lokasyonlar

Hizmet farklı şehir veya ülkelerde sunulabilir. Tek lokasyon kesintisinin etkisi toplam availability hesabında ayrıca düzenlenebilir. Saat dilimleri destek saatlerini etkiler. Yerinde müdahale süresi lokasyona göre değişebilir. SLA bu farklılıkları açık biçimde göstermelidir.

Entegrasyonlar

Bir hizmet başka sistemlerle API veya dosya aktarımı üzerinden çalışabilir. Ana uygulama açık olsa bile kritik entegrasyon kapalıysa iş hizmeti kullanılamaz hale gelebilir. Bu nedenle entegrasyonlar servis haritasına eklenmelidir. Kimin sorumlu olduğu ayrıca yazılmalıdır. Entegrasyon availability hesabının parçası olabilir.

Üçüncü Taraf Bağımlılıkları

Bulut, SMS, ödeme veya internet servisleri hizmeti etkileyebilir. Sağlayıcı bu üçüncü tarafları doğrudan kontrol etmeyebilir. Ancak müşteriye uçtan uca hizmet taahhüdü veriyorsa sorumluluk modeli dikkatle kurulmalıdır. Sınırsız third-party exclusion müşteriyi korumasız bırakabilir. Back-to-back SLA ve alternatif sağlayıcı seçenekleri değerlendirilmelidir.

Kritik Hizmet Haritası

Son aşamada iş süreçleri, sistemler ve üçüncü taraflar tek haritada birleştirilir. Her bileşenin kritikliği ve sahibi gösterilir. Olası tek hata noktaları görünür olur. RPO, RTO ve availability hedefleri bu haritaya göre belirlenebilir. Harita büyük mimari değişikliklerde güncellenmelidir.

SLA Kapsamı Nasıl Belirlenir?

SLA kapsamı hangi hizmetin hangi kullanıcı ve zaman aralığında taahhüt altında olduğunu açıkça göstermelidir. Kapsamın geniş olması her zaman daha iyi değildir. Ölçülemeyen veya sağlayıcının kontrol edemediği alanların eklenmesi sözleşmenin uygulanabilirliğini düşürebilir. Kapsam dışı alanların da açık yazılması gerekir. Böylece taraflar hangi olayın gerçekten SLA ihlali oluşturduğunu daha kolay belirler.

Kapsama Dahil Hizmetler

Hizmet isimleri genel ifadelerle bırakılmamalıdır. Uygulama, modül, API veya altyapı servisi açıkça listelenebilir. Production ve test ortamı ayrılmalıdır. Destek ve bakım hizmetleri ayrıca belirtilmelidir. Yeni hizmet eklenmesi change request sürecine bağlanabilir.

Kapsam Dışı Hizmetler

Development ortamı veya müşteri tarafından yönetilen bileşenler kapsam dışında olabilir. Bu alanlar açık listelenmelidir. “Sağlayıcının kontrolü dışındaki her şey” gibi çok geniş ifade kullanılmamalıdır. Kapsam dışı servislerin kritik hizmete etkisi ayrıca değerlendirilir. Böylece istisnalar sınırsız hale gelmez.

Hizmet Saatleri

Hizmet saatleri destek ve availability ölçümünü etkiler. 7/24 destek ile mesai saati destek ayrı konulardır. Uygulama 7/24 çalışırken destek yalnız 08.00–18.00 olabilir. P1 olayları için ayrı acil destek kanalı tanımlanabilir. Saat dilimi açıkça yazılmalıdır.

7/24 Hizmet ile Mesai Saati Hizmeti Arasındaki Fark

7/24 hizmet daha yüksek operasyon ve nöbet maliyeti gerektirir. Mesai saatlerinde çalışan destek modeli daha düşük maliyetli olabilir. İş ihtiyacı kritik değilse bütün olaylar için 7/24 taahhüt gereksiz olabilir. P1 için 7/24, düşük öncelikler için mesai saati modeli kullanılabilir. Böylece maliyet ve risk arasında denge kurulur.

Lokasyon Bazlı Kapsam

Belirli veri merkezi veya ofis için farklı SLA uygulanabilir. Uzak lokasyonlarda yerinde müdahale süreleri değişebilir. Bölgesel kesinti formüle ayrıca eklenebilir. Hizmet sağlayıcının fiziksel erişim kapasitesi dikkate alınmalıdır. Lokasyon listesi güncel tutulmalıdır.

Kullanıcı Bazlı Kapsam

Belirli kullanıcı grupları farklı servis seviyesine sahip olabilir. Premium destek alan müşteri grubu örnek verilebilir. Ancak aynı teknik altyapıda farklı availability garantisi sunmak her zaman mümkün değildir. Kullanıcı segmenti ile teknik servis seviyesi uyumlu olmalıdır. Raporlama ayrıştırılabiliyorsa farklı SLA uygulanabilir.

Sistem Bazlı Kapsam

Kritik sistemlere daha yüksek hedef verilebilir. Yardımcı uygulamalar daha düşük SLA ile yönetilebilir. Tek oran bütün sistemler için kullanılmamalıdır. Her sistemin iş etkisi ayrı değerlendirilir. Bu yaklaşım maliyeti daha kontrollü hale getirir.

Hizmet Kritiklik Seviyesi Nasıl Belirlenir?

Kritiklik, hangi sisteme ne kadar yüksek SLA gerektiğini belirleyen temel girdidir. İş, kullanıcı, finans, hukuk ve itibar etkileri birlikte değerlendirilmelidir. Çok kullanıcı etkilenen ama düşük iş etkili bir olay ile az kullanıcıyı etkileyen fakat finansal işlemi durduran olay aynı sınıfta olmayabilir. Objektif bir kritiklik matrisi hazırlanmalıdır. Böylece olay öncelikleri kişisel değerlendirmeye bağlı kalmaz.

İş Etkisi

Sistemin temel iş sürecini durdurup durdurmadığı değerlendirilir. Gelir üretimi veya müşteri hizmeti etkilenebilir. Alternatif süreç bulunup bulunmadığı incelenir. İş etkisi yüksekse daha sıkı SLA gerekir. Bu değerlendirme iş birimiyle birlikte yapılmalıdır.

Kullanıcı Etkisi

Etkilenen kullanıcı sayısı ve kullanıcı tipi ölçülür. Bütün müşteriler etkileniyorsa olay daha kritik olabilir. Tek kullanıcı sorunu genellikle daha düşük öncelikte kalır. Ancak kritik yönetici veya operasyon kullanıcısı için iş etkisi yüksek olabilir. Bu nedenle sayı tek kriter değildir.

Finansal Etki

Kesinti gelir kaybı veya ceza riski yaratabilir. Saatlik finansal etki yaklaşık hesaplanabilir. Bu veri availability yatırım kararını destekler. Yüksek kayıp yaratacak sistemlerde yedeklilik ekonomik hale gelebilir. SLA maliyeti iş riskiyle birlikte değerlendirilmelidir.

Hukuki ve Düzenleyici Etki

Bazı kesintiler düzenleyici yükümlülükleri etkileyebilir. Kayıt, güvenlik veya veri erişimi gereken sistemlerde risk daha yüksek olabilir. Sektörel düzenlemeler ayrıca kontrol edilmelidir. Kritik sınıflandırma buna göre artırılabilir. SLA ile mevzuat yükümlülüğü birbirine karıştırılmamalıdır.

İtibar Etkisi

Müşteri önündeki hizmet kesintisi marka güvenini doğrudan etkileyebilir. Kısa kesinti bile yoğun kullanım saatinde önemli olabilir. Sosyal medya ve kamu görünürlüğü etkiyi büyütebilir. Bu risk kritiklik değerlendirmesine dahil edilebilir. İş sürekliliği planı iletişim boyutunu da içermelidir.

Kritik Sistemlerin Sınıflandırılması

Sistemler kritik, yüksek, orta ve düşük gibi seviyelere ayrılabilir. Her seviye için availability ve recovery hedefleri belirlenir. Kritiklik yılda en az bir kez gözden geçirilebilir. İş süreçleri değiştikçe sınıflandırma da değişebilir. Yeni sistem devreye alınırken bu değerlendirme zorunlu hale getirilebilir.

P1, P2, P3 ve P4 Olay Seviyeleri Nasıl Tanımlanmalıdır?

P1, P2, P3 ve P4 seviyeleri olayların iş etkisi ve aciliyetine göre sınıflandırılması için kullanılır. Sınıflandırma yalnız teknik hatanın büyüklüğüne bakmamalıdır. Aynı hata farklı zaman veya kullanıcı grubunda farklı öncelik yaratabilir. Her seviyenin açık örnekleri SLA'da veya operasyon ekinde yer almalıdır. Böylece müşteri ve sağlayıcı olay önceliğini aynı çerçevede değerlendirir.

P1 – Kritik

P1 olay temel iş hizmetini durduran veya ciddi güvenlik ve veri riski yaratan olaydır. Genellikle 7/24 müdahale gerektirir. Yönetim eskalasyonu ve Major Incident süreci otomatik başlatılabilir. İlk yanıt ve güncelleme aralıkları diğer seviyelerden daha kısa olmalıdır. P1 tanımının çok geniş tutulması operasyonun sürekli alarm halinde çalışmasına neden olabilir.

Tüm Hizmetin Durması

Production hizmetine kullanıcıların erişememesi tipik P1 örneğidir. Kapsam bütün hizmet veya kritik müşteri segmenti olabilir. Alternatif kanal yoksa iş etkisi daha yüksektir. Monitoring alarmı otomatik P1 başlatabilir. Kesinti süresi availability hesabına dahil edilir.

Kritik Veri veya Güvenlik Riski

Aktif veri ihlali veya ciddi yetkisiz erişim P1 olarak sınıflandırılabilir. Sistem çalışıyor olsa bile risk yüksektir. Security Incident Response süreci devreye girer. Müşteri bildirimi kısa süre içinde yapılmalıdır. Mevzuat bildirim süreleri ayrıca takip edilmelidir.

İş Sürekliliğinin Kesilmesi

Temel iş işlemlerinin yapılamaması P1 olabilir. Ödeme, üretim veya müşteri hizmeti tamamen durabilir. Workaround yoksa etki daha büyüktür. Olay yöneticisi atanır. Yönetim seviyesinde düzenli bilgilendirme yapılır.

P2 – Yüksek

P2 olay önemli fonksiyon kaybı yaratır ancak tüm hizmeti durdurmaz. Büyük kullanıcı grubu etkilenebilir veya kritik özellik kullanılamayabilir. Workaround bulunması olayı P2 seviyesinde tutabilir. Yanıt ve çözüm hedefleri P1'den daha uzun olabilir. İş saatleri dışında nasıl ele alınacağı SLA'da ayrıca yazılmalıdır.

P3 – Orta

P3 olay sınırlı kullanıcı veya fonksiyonu etkileyen orta seviyeli sorundur. İş akışı devam edebilir. Alternatif yöntem genellikle mevcuttur. Müdahale mesai saatlerinde yapılabilir. Kalıcı düzeltme sonraki bakım veya sürüm planına alınabilir.

P4 – Düşük

P4 çoğu zaman kozmetik hata, bilgi talebi veya düşük etkili konuları kapsar. İş sürekliliğine etkisi yoktur. Uzun çözüm hedefi verilebilir. Planlı geliştirme sürecine alınabilir. P4 ile yeni özellik talebi birbirinden ayrıca ayrılmalıdır.

Örnek Öncelik Matrisi

Öncelik matrisi impact ve urgency değerlerini birleştirebilir. Yüksek etki ve yüksek aciliyet P1 oluşturabilir. Yüksek etki fakat düşük aciliyet P2 olarak sınıflandırılabilir. Düşük etki ve düşük aciliyet P4 olabilir. Matrisin örnek vakalarla desteklenmesi yanlış sınıflandırmayı azaltır.

Impact ve Urgency Matrisi Nasıl Oluşturulur?

Impact ve Urgency matrisi olay önceliğinin daha nesnel belirlenmesini sağlar. Impact olayın iş ve kullanıcı üzerindeki etkisini gösterir. Urgency ise çözümün ne kadar hızlı gerektiğini açıklar. Bu iki değer birleştirildiğinde P1–P4 seviyesi otomatik üretilebilir. Matris tarafların farklı öncelik algılarını azaltır.

Impact Nedir?

Impact olayın kapsam ve iş sonucuna etkisidir. Kullanıcı sayısı, gelir kaybı ve kritik fonksiyon etkisi dikkate alınabilir. Yüksek impact yalnız büyük kullanıcı sayısı demek değildir. Tek kritik süreç de yüksek etki yaratabilir. Değerlendirme kriterleri yazılı olmalıdır.

Urgency Nedir?

Urgency olayın çözülmesi gereken hızdır. Zaman geçtikçe zarar artıyorsa urgency yüksektir. Gece oluşan düşük etkili bir olay düşük urgency taşıyabilir. Yaklaşan finansal kapanış belirli sorunu daha acil hale getirebilir. Aciliyet iş bağlamına göre belirlenir.

Impact × Urgency ile Öncelik Belirleme

İki değişken tablo üzerinden eşleştirilebilir. Yüksek impact ve yüksek urgency P1 üretir. Orta değerler P2 veya P3'e karşılık gelebilir. Kurumun risk iştahına göre tablo farklılaşabilir. Sonuç ticket sisteminde otomatik hesaplanabilir.

Öncelik Seviyesini Kim Belirler?

İlk öncelik müşteri veya service desk tarafından verilebilir. Sağlayıcının doğrulama hakkı olabilir. Uyuşmazlık halinde eskalasyon mekanizması kullanılmalıdır. Tek tarafın sınırsız sınıflandırma yetkisi kötüye kullanım yaratabilir. Objektif matris bu nedenle önemlidir.

Yanlış Sınıflandırmaya Nasıl İtiraz Edilir?

Taraflar ticket içinde gerekçeli yeniden sınıflandırma talep edebilir. Impact veya urgency verisi paylaşılır. Kritik olayda tartışma müdahaleyi geciktirmemelidir. Önce çözüm, sonra sınıflandırma incelemesi yapılabilir. Değişiklik kayıt altında tutulmalıdır.

Öncelik Sonradan Değiştirilebilir mi?

Olay etkisi zaman içinde değişebilir. Küçük sorun büyüyerek P1 seviyesine çıkabilir. Tersi durumda workaround sonrası öncelik düşürülebilir. Değişikliğin SLA sayacına etkisi açıkça yazılmalıdır. Geçmiş sürelerin silinmesi otomatik olmamalıdır.

SLA'da Yanıt Süresi Nasıl Belirlenir?

Yanıt süresi müşterinin bildiriminden sağlayıcının gerçek olay incelemesine kadar geçen süreyi tanımlar. Otomatik ticket mesajının yanıt sayılıp sayılmadığı özellikle açıkça düzenlenmelidir. Kurumsal hizmetlerde çoğu müşteri insan tarafından inceleme veya olay sahipliği bekler. P1 için daha kısa, P4 için daha uzun süreler kullanılabilir. Başlangıç noktası ve çalışma saatleri hesaplamanın temelidir.

Yanıt Süresi Nedir?

Yanıt süresi ticket'ın alındığının operasyonel olarak kabul edilmesine kadar geçen zamandır. Salt teknik kayıt teyidi her zaman yeterli değildir. Olayın bir uzman tarafından görülmesi beklenebilir. Yanıt, çözüm anlamına gelmez. Bu iki süre ayrı ölçülmelidir.

Otomatik Ticket Mesajı Yanıt Sayılır mı?

Otomatik mesaj sistemin kaydı aldığını gösterir. Ancak olayın gerçekten incelendiğini kanıtlamaz. SLA içinde “otomatik acknowledgement yanıt sayılmaz” gibi açık hüküm kullanılabilir. Alternatif olarak iki ayrı metrik tanımlanabilir. Böylece ölçüm yoruma açık kalmaz.

İnsan Tarafından İnceleme Şartı

İlk yanıtın yetkili destek personeli tarafından verilmesi şart koşulabilir. Mesaj, olayın anlaşıldığını ve sonraki adımı içerebilir. Sadece hazır metin kullanılması yeterli sayılmayabilir. P1 olaylarında telefon doğrulaması istenebilir. Bu şart destek maliyetini artırabileceği için gerçek ihtiyaçla uyumlu olmalıdır.

P1–P4 İçin Örnek Yanıt Süreleri

Örneğin P1 için 15 dakika, P2 için 30 dakika, P3 için 4 iş saati ve P4 için 1 iş günü kullanılabilir. Bunlar evrensel standart değildir. Kritik sistemlerde P1 hedefi daha kısa olabilir. Hizmet saatleri ve ekip kapasitesi dikkate alınmalıdır. Örnek değerler sözleşme öncesi iş etkisi analizine göre uyarlanmalıdır.

Yanıt Süresinin Başlangıç Noktası

Sayaç ticket sistemine kayıt anında başlayabilir. Telefon veya monitoring alarmı ayrı kanal olabilir. Birden fazla kanal varsa hangisinin öncelikli olduğu yazılmalıdır. Sağlayıcı olaydan monitoring ile önce haberdar olmuşsa başlangıç müşteri ticket'ından daha erken olabilir. Bu konu SLA'da açıkça belirlenmelidir.

Müdahale Süresi ile Yanıt Süresi Aynı Şey midir?

Yanıt ve müdahale birbirine benzese de aynı kavram değildir. İlk yanıt olayın alındığını ve sahiplenildiğini gösterir. Müdahale ise teknik çalışmanın gerçekten başladığı anı ifade eder. Arada uzun fark varsa müşteri açısından yalnız hızlı yanıt yeterli olmaz. Bu nedenle iki süre özellikle kritik hizmetlerde ayrı tanımlanmalıdır.

İlk Yanıt

İlk yanıt müşteriyle ilk operasyonel temastır. Olayın alındığı doğrulanır. Öncelik seviyesi paylaşılır. Sorumlu ekip belirtilebilir. Bir sonraki bilgilendirme zamanı yazılabilir.

Teknik Müdahaleye Başlama

Teknik uzman olayın çözümü için çalışmaya başlar. Log analizi veya sistem kontrolü yapılabilir. Bu an ticket kaydında görünmelidir. P1 için müdahale süresi çok kısa tutulabilir. Sadece ticket'a cevap verilmesi müdahale sayılmamalıdır.

Bilgilendirme

Devam eden olaylarda müşteri belirli aralıklarla bilgilendirilmelidir. P1 için 30 dakikalık güncelleme sıklığı örnek olabilir. Yeni bilgi olmasa bile mevcut durum paylaşılabilir. Yönetim iletişimi teknik iletişimden ayrı olabilir. Bilgilendirme süresi SLA veya incident procedure içinde düzenlenebilir.

Eskalasyon

Belirli süre içinde ilerleme yoksa olay daha üst teknik veya yönetim seviyesine çıkarılabilir. Eskalasyon noktaları önceden tanımlanmalıdır. P1 olayda otomatik eskalasyon kullanılabilir. İletişim kişileri güncel tutulmalıdır. Eskalasyon çözümün yerine geçen bir işlem değildir.

Bu Sürelerin SLA'da Ayrı Tanımlanmasının Önemi

Tek metrik kullanılırsa sağlayıcı ilk mesajla SLA'yı karşılamış görünebilir. Teknik müdahale saatler sonra başlayabilir. Ayrı metrikler hizmet kalitesini daha doğru gösterir. Müşteri gerçek operasyon hızını görür. Sağlayıcı da ekip süreçlerini daha iyi yönetebilir.

Çözüm Süresi Nasıl Belirlenir?

Çözüm süresi olayın tamamen giderilmesine kadar geçen zamandır ancak her teknik arızada kesin süre taahhüt etmek mümkün olmayabilir. Karmaşık yazılım hatası veya üçüncü taraf bağımlılığı süreyi öngörmeyi zorlaştırabilir. Bu nedenle P1 olaylarda çözüm taahhüdü yerine workaround, recovery veya hedef süre kullanılabilir. Kalıcı çözüm ile hizmeti geri getiren geçici çözüm ayrılmalıdır. Sözleşmede bu fark net biçimde yazılmalıdır.

Resolution Time Nedir?

Resolution Time olayın kapanış koşuluna kadar geçen süredir. Tam teknik düzeltme veya hizmet geri dönüşü tanıma göre değişebilir. Başlangıç ve bitiş noktası açık olmalıdır. Ticket'ın idari olarak kapatılması çözüm sayılmamalıdır. Müşteri doğrulaması bazı hizmetlerde şart olabilir.

Workaround Çözüm Sayılır mı?

Workaround hizmeti kullanılabilir hale getirebilir fakat kök nedeni ortadan kaldırmayabilir. SLA'da workaround'un P1 sayaçlarını durdurup durdurmadığı yazılmalıdır. Kritik iş devam ediyorsa geçici çözüm kabul edilebilir. Kalıcı düzeltme için ayrı hedef verilebilir. Böylece sorun kapatılıp unutulmaz.

Geçici Çözüm ile Kalıcı Çözüm

Geçici çözüm hizmetin işlevini geri getirir. Kalıcı çözüm kök nedeni ortadan kaldırır. İki aşama farklı SLA veya KPI ile izlenebilir. RCA ve problem management süreci kalıcı çözümü destekler. Kritik olaylarda müşteriye her iki tarih de raporlanmalıdır.

Teknik Olarak Garanti Edilemeyen Çözüm Süreleri

Bazı hataların çözümü önceden tahmin edilemez. Bu durumda kesin “4 saatte kalıcı çözüm” taahhüdü sağlayıcı için sürdürülemez olabilir. Müdahale, workaround ve düzenli güncelleme taahhüdü daha gerçekçi olabilir. Sözleşme teknik gerçeklikle uyumlu olmalıdır. Aksi halde sürekli formal ihlal oluşur.

P1–P4 Bazlı Çözüm Hedefleri

P1 için dört saat içinde hizmet geri dönüşü, P2 için bir iş günü, P3 için beş iş günü gibi hedefler kullanılabilir. P4 sorunları planlı sürüme alınabilir. Bu değerler sektör ve hizmete göre değişir. Her hizmet için tek tablo kullanmak zorunlu değildir. İş kritikliği belirleyici olmalıdır.

SLA Sayacı Ne Zaman Başlamalıdır?

SLA sayacının başlangıç anı ölçümün en kritik unsurlarından biridir. Ticket açılışı, telefon bildirimi veya monitoring alarmı farklı zamanlar oluşturabilir. Müşteri olaydan önce sağlayıcının monitoring sistemiyle haberdar olması durumunda hangi anın esas alınacağı açık olmalıdır. Özellikle 7/24 yönetilen hizmetlerde otomatik tespit önemli rol oynar. Başlangıç tanımı yoksa aynı olay için farklı hesaplamalar ortaya çıkar.

Ticket Oluşturulduğunda

En yaygın yöntem ticket kayıt zamanıdır. Sistem zaman damgası objektif veri sağlar. Doğru kanal kullanımı müşteri yükümlülüğü olabilir. P1 için yalnız ticket yeterli olmayabilir. Telefon veya acil hat ek bildirim olarak istenebilir.

Telefon Bildiriminde

Kritik olaylar telefonla bildirilebilir. Çağrı kayıt zamanı SLA başlangıcı olabilir. Ticket sonradan açılırsa iki kayıt ilişkilendirilmelidir. Telefon hattının hangi numara olduğu açık olmalıdır. Sözlü bildirimin kayıt altına alınması gerekir.

Monitoring Alarmında

Yönetilen hizmette sağlayıcı alarmı müşteriden önce görebilir. Bu durumda sayaç alarm anında başlayabilir. Alarmın gerçek olay olduğunu doğrulama süresi ayrıca tanımlanabilir. False positive kayıtları yönetilmelidir. Monitoring sistemi tek doğruluk kaynağı olabilir.

Sağlayıcının Olaydan Haberdar Olduğu Anda

Daha geniş tanım “sağlayıcının makul olarak haberdar olduğu an” olabilir. Ancak bu ifade delil açısından dikkat gerektirir. Ticket veya alarm gibi zaman damgalı kayıt tercih edilmelidir. E-posta bildirimi de kullanılabilir. Başlangıç anı denetlenebilir olmalıdır.

Otomatik Tespit Edilen Arızalarda Başlangıç

Otomatik monitoring kritik hizmetlerde güçlü kontrol sağlar. Müşterinin ticket açmasını beklemek gereksiz gecikme yaratabilir. Alarm threshold'ları sözleşme veya teknik ekte tanımlanabilir. Olay kapanışında alarm ve ticket kayıtları eşleştirilir. Böylece proaktif hizmet modeli ölçülebilir hale gelir.

SLA Sayacı Hangi Durumlarda Durdurulabilir?

SLA sayacı sağlayıcının kontrolü dışında gerçekten beklemek zorunda kaldığı durumlarda durdurulabilir. Ancak pause hakkı çok geniş yazılırsa sağlayıcı bütün gecikmeleri müşteri veya üçüncü taraf üzerine atabilir. Bu nedenle durdurma nedeni, başlangıç ve resume zamanı kayıt altına alınmalıdır. Müşteri bilgilendirilmeden sayaç durdurulmamalıdır. Raporlarda toplam pause süresi ayrıca gösterilebilir.

Müşteriden Bilgi Beklenmesi

Çözüm için kritik bilgi müşteriden istenebilir. Bilgi olmadan çalışma ilerleyemiyorsa sayaç durabilir. Talebin makul ve gerekli olması gerekir. Gereksiz soru pause gerekçesi yapılamamalıdır. Ticket üzerinde talep zamanı kaydedilmelidir.

Müşteriden Erişim İzni Beklenmesi

Sağlayıcı production sistemine erişemiyorsa müdahale gecikebilir. Erişim talebi ve onay zamanı kayıt altına alınır. Acil olaylar için önceden tanımlı erişim prosedürü bulunmalıdır. Müşteri gecikmesi SLA hesabından çıkarılabilir. Bunun için objektif log gerekir.

Üçüncü Taraf Müdahalesinin Beklenmesi

Üçüncü taraf servis sağlayıcısının müdahalesi gerekebilir. Ana sağlayıcının yalnız beklemekle yetinip yetinmeyeceği sözleşmede düzenlenmelidir. Eskalasyon ve takip yükümlülüğü devam etmelidir. Her third-party gecikmesi otomatik exclusion olmamalıdır. Back-to-back SLA varsa daha güçlü kontrol sağlanır.

Planlı Bakım

Planlı bakım önceden tanımlı pencere içinde yapılırsa availability hesabından çıkarılabilir. Ancak ticket çözüm süresi bakım bahanesiyle sınırsız durdurulmamalıdır. Bakım ile olay müdahalesi farklı kavramdır. Acil bakım ayrıca tanımlanır. Aylık bakım limiti uygulanabilir.

Müşteri Kaynaklı Sorun

Müşteri konfigürasyon değişikliği olaya neden olabilir. Sağlayıcı bunu kayıtlarla göstermelidir. Bu durumda ilgili süre SLA dışı tutulabilir. Ancak ortak hatalar dikkatle değerlendirilmelidir. Sorumluluk yalnız varsayımla müşteriye yüklenmemelidir.

Bekleme Süresinin Belgelenmesi

Pause nedeni ticket içinde yazılmalıdır. Kimden ne beklendiği açık olmalıdır. Saat başlangıcı ve bitişi kaydedilir. Aylık raporda toplam pause süresi gösterilebilir. Bu kayıt uyuşmazlıkta önemli delil oluşturabilir.

Pause ve Resume Kayıtlarının Tutulması

Ticket sistemi otomatik zaman damgası tutmalıdır. Manuel değişiklikler audit log içinde görünmelidir. Kullanıcı nedeni görüntüleyebilmelidir. Sayaç yeniden başladığında bildirim yapılabilir. Böylece ölçüm şeffaf hale gelir.

Ticket Yeniden Açılırsa SLA Nasıl Hesaplanır?

Reopen edilen ticket'lar sağlayıcı performansını olduğundan iyi gösterebilir veya gerçek çözüm kalitesini gizleyebilir. Aynı kök neden nedeniyle kısa sürede açılan ticket'ın yeni olay sayılması her zaman doğru değildir. SLA içinde reopen penceresi belirlenebilir. Örneğin 24 veya 48 saat içinde aynı semptom tekrar ederse eski olayın devamı kabul edilebilir. Reopen oranı kalite KPI'ı olarak ayrıca izlenmelidir.

Aynı Olayın Devamı

Aynı hata yeniden ortaya çıkmışsa eski ticket devam ettirilebilir. Geçen süre toplam hesaba dahil edilebilir. Workaround başarısız olmuş olabilir. Problem management süreci başlatılmalıdır. Ticket'ın yapay biçimde kapanıp açılması engellenir.

Yeni Olay Kabul Edilmesi

Kök neden farklıysa yeni olay sayılabilir. Yeni ticket ve yeni sayaç başlar. Ancak sınıflandırma teknik kanıtla desteklenmelidir. Kullanıcı deneyimi de dikkate alınır. Benzer semptom tek başına aynı olay anlamına gelmez.

Sayaç Sıfırlama Sorunu

Her reopen işleminde sayacı sıfırlamak SLA performansını yapay olarak iyileştirebilir. Sözleşme bu ihtimali önlemelidir. Aynı olay için toplam elapsed time kullanılabilir. Sağlayıcının ticket kapanış kriteri açık olmalıdır. Müşteri onayı gerekebilir.

Reopen Oranının KPI Olarak Kullanılması

Yüksek reopen oranı düşük çözüm kalitesini gösterebilir. İlk seferde kalıcı çözüm sağlanmadığını ortaya koyar. Aylık raporlarda oran izlenebilir. Belirli eşiğin üzerinde SIP başlatılabilir. Bu metrik servis kredisine bağlanmak zorunda değildir.

Uptime ve Availability SLA Nasıl Belirlenir?

Uptime ve availability benzer görünse de sözleşmede nasıl tanımlandıkları önemlidir. Uptime sistemin teknik olarak açık kaldığı süreyi, availability ise kullanıcının hizmeti gerçekten kullanabildiği zamanı ifade edebilir. Sistem ayakta olsa bile kritik API çalışmıyorsa availability düşebilir. Ölçüm dönemi ve kesinti tanımı açık olmalıdır. Yüzde oranı tek başına yeterli değildir.

Uptime Nedir?

Uptime sistemin çalışır durumda olduğu toplam zamanı ifade eder. Genellikle yüzdelik oranla ölçülür. Teknik süreç veya sunucu seviyesi üzerinden hesaplanabilir. Kullanıcı deneyimiyle birebir aynı olmayabilir. Bu nedenle neyin “up” sayıldığı tanımlanmalıdır.

Availability Nedir?

Availability hizmetin kullanıcı tarafından kullanılabilir olmasını ölçer. Kritik fonksiyonlar çalışmıyorsa sistem teknik olarak açık olsa bile unavailable sayılabilir. Sentetik monitoring veya gerçek kullanıcı işlemleri kullanılabilir. Hizmet tanımı belirleyici olur. Özellikle SaaS sözleşmelerinde daha anlamlı göstergedir.

Kullanılabilirlik Yüzdesinin Hesaplanması

Genel formül uygun hizmet süresinden kesinti süresinin çıkarılması ve uygun süreye bölünmesiyle hesaplanabilir. Hariç tutulan planlı bakım ayrıca düşülebilir. Kısmi kesintilerin nasıl ağırlıklandırıldığı belirtilmelidir. Ölçüm dakikalık veya daha kısa periyotla yapılabilir. Formül sözleşmede açık yazılmalıdır.

Ölçüm Döneminin Belirlenmesi

Availability aylık, fatura dönemi veya yıllık ölçülebilir. Aylık ölçüm müşteriye daha hızlı telafi sağlar. Yıllık ölçüm kısa dönem büyük kesintiyi ortalamada gizleyebilir. Hizmet kredileri çoğu zaman aylık performansa bağlanır. Ölçüm dönemi ticari yapıyla uyumlu seçilmelidir.

Takvim Ayı

En yaygın ölçüm dönemidir. Her ay bağımsız hesap yapılır. Servis kredisi ilgili ay faturasına bağlanabilir. Raporlama kolaydır. Kısa dönem performans düşüşü görünür olur.

Fatura Dönemi

Fatura takvimi takvim ayından farklı olabilir. SLA hesabı aynı dönemle eşleştirilebilir. Hizmet kredisi hesabı kolaylaşır. Dönem başlangıç ve bitişi açık olmalıdır. Kısmi ilk ay ayrıca düzenlenebilir.

Yıllık Ölçüm

Uzun dönem trend sağlar. Ancak aylık ciddi kesintileri gizleyebilir. Yıllık SLA tek başına müşteri için yeterli olmayabilir. Aylık alt eşik eklenebilir. Stratejik raporlama için destekleyici metrik olarak kullanılabilir.

Kısmi Kesintiler Nasıl Hesaplanır?

Sadece belirli fonksiyon veya kullanıcı grubu etkilenebilir. Tam kesinti gibi saymak sağlayıcı açısından aşırı olabilir. Hiç saymamak ise müşteri deneyimini görmezden gelir. Ağırlıklı kesinti formülü kullanılabilir. Kritik fonksiyonların ağırlığı daha yüksek belirlenebilir.

%99, %99,9 ve %99,99 SLA Gerçekte Ne Anlama Gelir?

Yüzdelik SLA değerleri küçük farklarla görünse de izin verilen kesinti süreleri ciddi biçimde değişir. Yüzde 99 ile yüzde 99,99 arasında operasyonel ve mimari olarak büyük yatırım farkı olabilir. Bu nedenle en yüksek oranı istemek her zaman ekonomik değildir. İş sürecinin tolere edebileceği kesinti ve bunun maliyeti hesaplanmalıdır. Ardından uygun availability seviyesi seçilmelidir.

%99 Kullanılabilirlik

Yüzde 99 aylık availability yaklaşık 7 saat 18 dakikaya kadar kesinti anlamına gelebilir. Kritik finans veya ödeme sistemi için bu süre yüksek olabilir. Düşük kritik iç uygulama için kabul edilebilir olabilir. Hesaplama aylık gün sayısına göre küçük farklılık gösterebilir. Planlı bakımın hariç olup olmadığı ayrıca önemlidir.

%99,9 Kullanılabilirlik

Yüzde 99,9 aylık dönemde yaklaşık 43 dakika civarında kesintiye karşılık gelir. Birçok SaaS hizmetinde sık görülen hedeflerden biridir. Yine de kritik saatlerde 40 dakikalık kesinti büyük zarar yaratabilir. Bu nedenle sadece oran değil incident dağılımı da değerlendirilmelidir. Aylık ve yıllık etkiler ayrı incelenebilir.

%99,95 Kullanılabilirlik

Yüzde 99,95 aylık dönemde yaklaşık 22 dakika civarında kesintiye izin verir. Daha yüksek yedeklilik ve operasyon disiplini gerektirir. Altyapı maliyeti artabilir. Kritik kurumsal uygulamalarda tercih edilebilir. Sağlayıcı geçmiş performansını kanıtlamalıdır.

%99,99 Kullanılabilirlik

Yüzde 99,99 aylık dönemde yaklaşık 4 dakika 23 saniye civarında kesintiye karşılık gelir. Bu seviye güçlü mimari ve operasyon gerektirir. Tek hata noktalarının büyük ölçüde azaltılması gerekir. Üçüncü taraf bağımlılıkları hedefi etkileyebilir. Fiyatlandırma da genellikle daha yüksektir.

Yüzdelik SLA'nın Kesinti Süresine Çevrilmesi

Yüzde değeri iş birimlerine tek başına anlamlı gelmeyebilir. Kesinti dakikasına çevrilmesi karar vermeyi kolaylaştırır. Aylık ve yıllık tablo hazırlanabilir. Planlı bakım ve istisnalar ayrı gösterilir. Böylece satın alınan SLA'nın gerçek anlamı görülür.

İş İhtiyacına Göre Doğru Seviyeyi Seçmek

Hizmet kesildiğinde oluşacak kayıp hesaplanmalıdır. Yedek kanal bulunuyorsa daha düşük SLA yeterli olabilir. Kritik müşteri hizmetinde yüksek availability gerekebilir. Ek yüzde 0,09 için ödenen maliyet beklenen kayıpla karşılaştırılmalıdır. SLA iş kararıdır, yalnız teknik hedef değildir.

SLA Ölçümü Hangi Sistemden Yapılmalıdır?

SLA ölçüm kaynağı tarafların üzerinde en başta anlaşması gereken konulardan biridir. Sağlayıcı ve müşterinin monitoring sistemleri farklı değer üretebilir. Bağımsız sistem üçüncü veri kaynağı sunabilir. Tek doğruluk kaynağı belirlenmesi günlük operasyonu kolaylaştırır. Bunun yanında müşterinin ölçüm verisine erişim ve audit hakkı da düzenlenebilir.

Sağlayıcı Monitoring Sistemi

Sağlayıcı sistemin altyapı ve uygulama metriklerine doğrudan erişebilir. Ölçüm kolay ve düşük maliyetlidir. Ancak müşteri tek taraflı veriye bağımlı kalabilir. Audit log ve ham veri erişimi güveni artırır. Sistem değişikliği önceden bildirilmelidir.

Müşteri Monitoring Sistemi

Müşteri kendi dış izleme aracını kullanabilir. Kullanıcı perspektifine yakın ölçüm sağlar. Sağlayıcının iç ağı dışındaki sorunları da görebilir. Yanlış yapılandırma farklı sonuç üretebilir. Ölçüm lokasyonları ve interval'lar standartlaştırılmalıdır.

Bağımsız Monitoring Sistemi

Üçüncü taraf monitoring ortak veri kaynağı olarak kullanılabilir. Tarafsızlık avantaj sağlar. Ek maliyet doğurabilir. Hangi endpoint ve bölgelerin izlendiği tanımlanmalıdır. Kritik hizmetlerde faydalı olabilir.

Sistemler Farklı Sonuç Verirse Ne Olur?

Uyuşmazlık çözüm mekanizması SLA içinde bulunmalıdır. Belirli tolerans aralığı tanımlanabilir. Ham loglar birlikte incelenebilir. Bağımsız üçüncü sistem devreye girebilir. Son kararın hangi kaynağa göre verileceği önceden yazılmalıdır.

Tek Doğruluk Kaynağı

Single Source of Truth günlük raporlamayı kolaylaştırır. Hem müşteri hem sağlayıcı aynı dashboard'u görebilir. Yetki ve erişim seviyesi belirlenir. Tarihsel veri değiştirilemez şekilde saklanır. Raporlar bu kaynaktan üretilir.

Ölçüm Verisine Erişim Hakkı

Müşteri SLA hesabını doğrulayabilmelidir. Ham log veya özet dashboard erişimi verilebilir. Güvenlik gerekçesiyle sınırlamalar olabilir. En azından hesaplamayı doğrulayacak veri paylaşılmalıdır. Saklama süresi sözleşmede belirtilmelidir.

SLA Ölçüm Formülü Sözleşmede Yazılmalı mı?

Evet, özellikle availability ve performans SLA'larında formül açıkça yazılmalıdır. Yalnız “aylık yüzde 99,9” yazılması denominatör ve hariç tutulan süreleri belirsiz bırakır. Ölçüm aralığı, yuvarlama ve kısmi kesinti kuralları da sonucu değiştirebilir. Bölgesel veya kullanıcı bazlı kesintiler için özel hesap gerekebilir. Formül örnek hesapla desteklenirse yorum farkı daha da azalır.

Numeratör ve Denominatör

Hangi sürenin toplam uygun hizmet süresi olduğu belirtilmelidir. Kesinti dakikası numeratörü etkiler. Planlı bakım denominatörden çıkarılabilir. Kullanılabilir olmayan hizmet dakikası açık tanıma bağlanır. Matematiksel ifade mümkünse sözleşmeye eklenmelidir.

Ölçüm Aralığı

Monitoring her 1 dakika veya 5 saniye gibi aralıklarla ölçüm yapabilir. Uzun aralık kısa kesintileri kaçırabilir. Çok kısa aralık false positive üretebilir. Sistem özelliğine göre denge kurulmalıdır. Aralık değişirse onay mekanizması gerekebilir.

Yuvarlama Kuralları

Yüzde 99,949 gibi sonuçların nasıl yuvarlanacağı yazılmalıdır. Normal matematiksel yuvarlama servis kredisini etkileyebilir. Belirli ondalık basamak kullanılabilir. Müşteri aleyhine sürekli yukarı yuvarlamadan kaçınılmalıdır. Hesaplama sistemi aynı kuralı uygulamalıdır.

Kısmi Kesinti Hesabı

Hizmetin yarısı çalışıyorsa tam downtime sayılıp sayılmayacağı belirlenmelidir. Kullanıcı veya fonksiyon ağırlığı uygulanabilir. Kritik işlem başarısızsa daha yüksek etki verilebilir. Formül çok karmaşık olmamalıdır. Raporlama tarafların anlayabileceği seviyede kalmalıdır.

Bölgesel Kesinti

Tek bölge etkileniyorsa global hizmet tamamen down sayılmayabilir. Bölgenin trafik veya müşteri ağırlığı kullanılabilir. Premium bölgeler ayrı SLA'ya sahip olabilir. Ölçüm lokasyon bazlı yapılmalıdır. Sözleşme hizmet kapsamıyla uyumlu olmalıdır.

Kullanıcı Bazlı Kesinti

Belirli kullanıcı grubunun erişememesi kısmi availability kaybıdır. Aktif kullanıcı oranı kullanılabilir. Çok küçük grubun etkisi tam downtime sayılmayabilir. Ancak kritik kullanıcı segmenti farklı değerlendirilebilir. Hesaplama yöntemi önceden yazılmalıdır.

Örnek SLA Hesaplama Formülü

Basit formül “Uygun Hizmet Süresi eksi SLA'ya Dahil Kesinti Süresi, bölü Uygun Hizmet Süresi, çarpı 100” şeklinde kurgulanabilir. Uygun hizmet süresinin planlı bakım sonrası kalan zaman olduğu açıklanmalıdır. Kısmi kesinti varsa ağırlıklı dakika eklenebilir. Sonuç belirli ondalık basamakta gösterilir. Formülün örnek ay üzerinden test edilmesi faydalıdır.

Planlı Bakımlar SLA Hesabına Dahil Edilmeli mi?

Planlı bakım çoğu SLA'da availability hesabından hariç tutulabilir, ancak bu hariç tutma sınırsız olmamalıdır. Aksi halde sağlayıcı yüksek kesinti süresini “planlı bakım” olarak sınıflandırarak hedefi yapay biçimde karşılayabilir. Bakım penceresi, ön bildirim süresi ve aylık maksimum süre tanımlanmalıdır. Acil bakım için ayrı süreç kullanılabilir. Kritik dönemlerde bakım yapılmaması da sözleşmeye eklenebilir.

Planlı Bakım Nedir?

Planlı bakım önceden programlanmış teknik çalışma süresidir. Güncelleme, patch veya altyapı değişikliği yapılabilir. Önceden müşteri bildirimi gerekir. Belirli bakım penceresi içinde yapılmalıdır. Bildirim şartı karşılanmayan çalışma planlı bakım sayılmayabilir.

Bakım Penceresi

Bakım için belirli gün ve saat aralığı tanımlanabilir. Örneğin pazar 02.00–05.00 kullanılabilir. İş yoğunluğu düşük zaman tercih edilir. Global kullanıcılar varsa tek pencere herkese uygun olmayabilir. Bölgesel takvim hazırlanabilir.

Önceden Bildirim Süresi

Planlı bakım birkaç gün önce bildirilmelidir. Örneğin en az 5 iş günü kullanılabilir. Kritik değişikliklerde daha uzun süre gerekebilir. Bildirim kanal ve içeriği belirlenir. Müşteri itiraz süreci ayrıca düzenlenebilir.

Aylık Maksimum Bakım Süresi

Toplam hariç bakım süresine üst sınır konabilir. Örneğin ayda 4 saat gibi limit kullanılabilir. Süre hizmet kritikliğine göre değişir. Limit aşılırsa fazla bölüm availability hesabına dahil edilebilir. Bu yaklaşım kötüye kullanımı azaltır.

Acil Bakım

Güvenlik açığı veya kritik risk nedeniyle beklenmeyen bakım gerekebilir. Bildirim süresi daha kısa olabilir. Acil bakımın tanımı sınırlı tutulmalıdır. Olay sonrası rapor hazırlanabilir. Sık acil bakım kronik operasyon sorunu gösterebilir.

Planlı Bakımın Kötüye Kullanılmasını Önlemek

Bakım penceresi ve maksimum süre sınırı temel kontroldür. Gerçek bakım kaydı tutulmalıdır. Son dakika planlaması acil bakım kriterine tabi olabilir. Müşteri raporda tüm bakım sürelerini görmelidir. Tekrarlayan bakım nedenleri ayrıca incelenebilir.

Performans SLA'ları Nasıl Belirlenir?

Availability yüksek olsa bile hizmet çok yavaşsa kullanıcı açısından kalite düşük olabilir. Bu nedenle performans SLA'ları yanıt süresi, latency, throughput ve hata oranı gibi göstergeleri içerebilir. Her metriğin ölçüm noktası ve yük koşulu belirlenmelidir. Ortalama değer tek başına uç durumları gizleyebilir. P95 veya P99 gibi yüzdelik ölçümler kullanılabilir.

Response Time

Kullanıcı işlemine sistemin verdiği toplam yanıt süresidir. Tarayıcı, ağ ve backend etkileri ayrılabilir. Kritik ekranlar için ayrı hedef belirlenebilir. P95 değeri ortalamadan daha anlamlı olabilir. Ölçüm gerçek kullanıcı veya sentetik test üzerinden yapılabilir.

Latency

Latency belirli çağrı veya veri aktarımındaki gecikmeyi ifade eder. API ve network hizmetlerinde önemlidir. Bölgeye göre değişebilir. Ölçüm noktası sözleşmede yazılmalıdır. Çok uzak lokasyonlar için farklı hedef uygulanabilir.

Throughput

Belirli sürede işlenen işlem miktarını gösterir. Saniyede istek veya saatte batch işlem sayısı olabilir. Kapasite SLA'sıyla ilişkilidir. Belirli yük altında ölçülmelidir. Müşteri trafik varsayımını aşarsa sonuç farklılaşabilir.

İşlem Başarı Oranı

Toplam işlemlerin kaçının başarılı tamamlandığını gösterir. Ödeme veya API servislerinde önemlidir. Kullanıcı hataları ile sistem hataları ayrılmalıdır. Başarı kodları açıkça tanımlanmalıdır. Aylık hedef belirlenebilir.

Error Rate

Sistem kaynaklı hata oranıdır. 5xx veya uygulama hata kodları kullanılabilir. Müşteri hataları ayrıca sınıflandırılır. Hata oranı availability ile birlikte değerlendirilir. Kısa süreli spike'lar ayrıca raporlanabilir.

API Response Time

API endpoint bazlı hedef verilebilir. Kritik çağrılar daha sıkı olabilir. P95 veya P99 kullanılabilir. Payload büyüklüğü ve rate limit varsayımları belirtilir. Üçüncü taraf dependency etkisi ayrıca düzenlenir.

Batch İşlem Süresi

Gece raporu veya dosya işleme gibi batch işlemler için tamamlanma zamanı belirlenebilir. Başlangıç ve bitiş noktası tanımlanır. Veri hacmi varsayımı yazılır. Hedef saat kaçırılırsa iş etkisi değerlendirilir. Yeniden çalıştırma süreci ayrıca düzenlenebilir.

Performansın Kullanıcı Deneyimiyle İlişkisi

Teknik metrik kullanıcı deneyimine bağlanmalıdır. 2 saniyelik API yanıtı bazı işlemlerde kabul edilebilir, bazılarında değildir. Kritik kullanıcı yolculukları belirlenebilir. XLA göstergeleri destekleyici olarak kullanılabilir. Böylece performans sadece sunucu metriğine indirgenmez.

API Hizmetleri İçin SLA Nasıl Hazırlanır?

API SLA'sı yalnız uptime oranına dayanmaz. Response time, rate limit, error rate, timeout ve sürüm yönetimi de müşterinin entegrasyon deneyimini belirler. Breaking change bildirim süresi özellikle kritik konudur. API çalışıyor görünürken yanlış veri veya sürekli timeout oluşması gerçek availability kaybı yaratabilir. Bu nedenle fonksiyonel ve performans kriterleri birlikte ele alınmalıdır.

API Availability

Endpoint veya servis bazlı ölçüm yapılabilir. Başarılı health check tek başına yeterli olmayabilir. Gerçek iş işlemi test edilebilir. Bölgesel endpoint'ler ayrı izlenebilir. Aylık availability hedefi belirlenir.

Response Time

Belirli endpoint'lerde P95 yanıt süresi kullanılabilir. Payload ve authentication süresi dahil olup olmadığı yazılır. Çok yoğun trafik dönemleri ayrıca değerlendirilir. Ölçüm lokasyonu sabitlenir. Gecikme hedefi iş ihtiyacına göre seçilir.

Rate Limit

API'nin saniye veya dakika bazlı çağrı limiti açık olmalıdır. Limit aşımında dönen hata kodu belirtilir. Premium müşteriler için farklı limit olabilir. Ani trafik burst'ü desteklenebilir. Limit değişiklikleri önceden bildirilmelidir.

Error Rate

Sunucu kaynaklı hata oranı izlenir. 5xx cevaplar dahil edilebilir. İş kuralı nedeniyle reddedilen 4xx çağrılar ayrı tutulabilir. Retry sonrası başarı ayrıca ölçülebilir. Yüksek hata oranı availability ihlali yaratabilir.

Timeout

Client ve server timeout değerleri uyumlu olmalıdır. Aşırı uzun timeout kullanıcı deneyimini bozar. Retry mekanizması çift işlem riski yaratabilir. Kritik API'lerde idempotency düşünülmelidir. Timeout oranı KPI olarak izlenebilir.

API Sürüm Değişikliği

Yeni sürüm eski müşterileri bozmayacak biçimde yönetilmelidir. Versioning politikası yayınlanabilir. Destek süresi belirlenir. Eski sürüm emeklilik tarihi önceden bildirilir. Geçiş dokümanı sağlanmalıdır.

Breaking Change Bildirimi

Breaking change müşterinin entegrasyonunu etkileyebilir. En az belirli süre önce bildirim yapılmalıdır. Acil güvenlik değişikliği istisna olabilir. Test ortamı veya sandbox sunulabilir. Bildirim e-posta ve portal üzerinden yapılabilir.

Destek Hizmetleri İçin SLA Nasıl Belirlenir?

Destek SLA'sı hangi kanaldan bildirim yapılacağını, hangi saatlerde hizmet verileceğini ve her öncelik için hangi sürelerin uygulanacağını belirler. Ticket, telefon ve e-posta kanalları aynı hukuki sonucu doğurmayabilir. P1 olaylar için acil durum hattı kullanılabilir. İlk yanıt, güncelleme ve çözüm hedefleri ayrı olmalıdır. Eskalasyon zinciri de müşteriyle paylaşılmalıdır.

Destek Kanalları

Destek kanalları tek tek tanımlanmalıdır. Hangi kanalın SLA sayacını başlattığı belirtilir. P1 için telefon zorunlu tutulabilir. Düşük önceliklerde e-posta yeterli olabilir. Kanal dışı sosyal medya mesajları resmi bildirim sayılmayabilir.

Ticket

Ticket sistemi ana kayıt kaynağıdır. Zaman damgası ve audit log tutar. Öncelik ve durum bilgisi görülebilir. Pause ve resume işlemleri kaydedilir. Raporlama bu sistemden üretilebilir.

Telefon

Kritik olaylarda hızlı insan temasını sağlar. Çağrı kaydı tutulabilir. Arayan kişinin yetkisi kontrol edilebilir. Ticket otomatik veya manuel açılır. Telefon bildirimi SLA başlangıcı olabilir.

E-Posta

E-posta düşük ve orta öncelik olaylarda kullanılabilir. Otomatik ticket'a dönüşmesi tercih edilir. Teslim gecikmesi riski vardır. P1 için tek kanal olarak yeterli olmayabilir. Adres ve yanıt süresi açıkça belirtilmelidir.

Acil Durum Hattı

7/24 kritik olaylar için özel hat kullanılabilir. Yalnız P1 olaylar için sınırlandırılabilir. Yanlış kullanım öncelik sistemini bozabilir. Nöbetçi ekip doğrudan ulaşılabilir olmalıdır. Çağrılar kaydedilip ticket'a bağlanmalıdır.

Destek Saatleri

Destek saatleri hizmet kritikliğine göre belirlenir. 7/24 veya 8x5 model kullanılabilir. Tatil günleri ayrıca açıklanır. Saat dilimi belirtilir. P1 için genel saatlerden farklı destek uygulanabilir.

İlk Yanıt

İlk yanıt olay sahipliğini gösterir. İnsan tarafından verilmesi şart koşulabilir. Öncelik ve sorumlu ekip belirtilir. Müşteriden ek bilgi istenebilir. Otomatik mesajla karıştırılmamalıdır.

Güncelleme Sıklığı

Uzun olaylarda müşterinin ne sıklıkla bilgi alacağı belirlenmelidir. P1 için 30 dakika örnek olabilir. P2 için 2 saat uygun olabilir. Yeni gelişme olmasa bile durum paylaşılabilir. Böylece iletişim belirsizliği azaltılır.

Çözüm

Çözüm hedefleri önceliğe göre farklı olabilir. Geçici ve kalıcı çözüm ayrılır. Müşteri doğrulaması gerekebilir. Çözüm süresi teknik olarak garanti edilemiyorsa hedef veya workaround yaklaşımı kullanılabilir. Ticket kapanış kriteri açık olmalıdır.

Eskalasyon

Eskalasyon teknik ve yönetim seviyelerinde tanımlanabilir. Belirli süre aşımında otomatik çalışabilir. İletişim kişileri güncel tutulur. Kritik olaylarda üst yönetim bilgilendirilebilir. Eskalasyon matrisinin sözleşme ekinde bulunması faydalıdır.

Major Incident Süreci SLA'ya Nasıl Eklenir?

Major Incident kritik ve geniş etkili olayların standart ticket sürecinden daha yoğun biçimde yönetilmesini sağlar. P1 olay otomatik Major Incident sayılabilir veya ek kriter kullanılabilir. Olay yöneticisi atanır, War Room açılır ve müşteriye düzenli bilgi verilir. Teknik çözüm ile yönetim iletişimi paralel yürütülür. Olay sonrasında RCA ve iyileştirme aksiyonları devreye alınır.

Major Incident Tanımı

Tanım iş etkisine dayanmalıdır. Tüm hizmet kesintisi veya ciddi güvenlik olayı örnek olabilir. Çok sayıda müşteri etkilenmesi kriter ekleyebilir. Sadece teknik hata büyüklüğü yeterli değildir. Tanım operasyon prosedürüyle uyumlu olmalıdır.

Olay Yöneticisi

Tek bir Incident Manager koordinasyonu üstlenir. Teknik ekipler çözüm üzerinde çalışırken iletişim ve görev dağılımını yönetir. Müşteriyle ana temas noktası olabilir. Karar kayıtlarını tutar. Olay kapanışında zaman çizelgesini doğrular.

War Room

Kritik ekiplerin aynı iletişim kanalında çalışmasını sağlar. Video konferans veya mesajlaşma kanalı kullanılabilir. Gereksiz katılımcı sınırlandırılmalıdır. Teknik kararlar kayıt altına alınır. War Room kapanış kriteri belirlenir.

Müşteri Bilgilendirme Aralığı

P1 olaylarda düzenli güncelleme güven açısından önemlidir. 30 veya 60 dakika gibi aralık belirlenebilir. Bilgi olmasa bile mevcut durum paylaşılır. Tahmini çözüm zamanı kesin değilse açıkça söylenmelidir. Yanlış iyimser tahminlerden kaçınılmalıdır.

Yönetim Eskalasyonu

Belirli süreyi aşan olaylar üst yönetime taşınabilir. Finansal veya itibar etkisi bu kararı hızlandırabilir. Tarafların yönetim kontakları önceden tanımlanır. Eskalasyon teknik ekibe baskı yapmak için değil kaynak ve karar sağlamak için kullanılmalıdır. Yönetim iletişimi ayrı kanaldan yürütülebilir.

Olay Kapanışı

Hizmet geri geldiğinde olay hemen kapatılmayabilir. Stabilite belirli süre izlenir. Müşteri doğrulaması alınabilir. Kök neden analizi takip işi olarak açılır. Nihai kapanış kaydı tüm süreleri içermelidir.

Root Cause Analysis (RCA) Zorunluluğu Nasıl Düzenlenir?

RCA her küçük olay için zorunlu tutulursa operasyon yükü gereksiz artar. P1, belirli P2 olaylar veya tekrarlayan sorunlar için istenmesi daha uygundur. Teslim süresi, içerik ve müşteri inceleme hakkı SLA'da belirtilmelidir. RCA yalnız hata açıklaması değil tekrarın önlenmesi için aksiyon planı içermelidir. Aynı kök nedenin tekrar etmesi Service Improvement Plan başlatabilir.

RCA Ne Zaman İstenmeli?

P1 olaylar için otomatik zorunlu olabilir. Tekrarlayan P2 olaylar da kapsama alınabilir. Güvenlik ihlalleri ayrıca değerlendirilir. Küçük P3 ve P4 olaylar için problem management yeterli olabilir. Eşikler sözleşmede yazılmalıdır.

RCA Teslim Süresi

Olay sonrası birkaç iş günü içinde teslim hedefi verilebilir. Çok karmaşık olaylarda ön rapor ve nihai rapor ayrılabilir. Örneğin 2 iş gününde ilk rapor, 10 iş gününde nihai RCA kullanılabilir. Süre gerçek teknik analize izin vermelidir. Gecikme müşteriye gerekçesiyle bildirilmelidir.

RCA İçeriği

RCA standart şablon kullanabilir. Kök neden, zaman çizelgesi, etkilenen sistemler ve düzeltici faaliyetler bulunmalıdır. Tekrarı önleyici aksiyonlar ayrıca yazılır. Sorumlu ve son tarih eklenebilir. Böylece rapor yalnız geçmişi anlatan belge olmaktan çıkar.

Kök Neden

Yalnız “sunucu çöktü” açıklaması kök neden değildir. Neden çöktüğü analiz edilmelidir. İnsan, süreç ve teknoloji faktörleri birlikte ele alınır. Tek hata noktası veya kontrol eksikliği görülebilir. Kanıta dayalı açıklama yapılmalıdır.

Olay Zaman Çizelgesi

İlk alarmdan kapanışa kadar önemli anlar listelenir. Ticket, monitoring ve iletişim kayıtları kullanılır. Müdahale ve eskalasyon zamanları görünür olur. SLA hesaplaması doğrulanabilir. Zaman damgaları aynı saat diliminde tutulmalıdır.

Etkilenen Sistemler

Ana ve bağımlı sistemler listelenir. Kullanıcı ve lokasyon etkisi eklenir. Veri etkisi varsa belirtilir. İş süreçleri açıklanır. Böylece olayın gerçek kapsamı anlaşılır.

Düzeltici Faaliyetler

Mevcut hatayı gidermek için yapılan işlemler yazılır. Konfigürasyon veya kod değişikliği belirtilebilir. Acil aksiyon ile uzun dönem aksiyon ayrılır. Test sonucu eklenebilir. Sorumlu ekip atanır.

Tekrarı Önleyici Faaliyetler

Benzer olayın yeniden oluşmasını azaltan önlemler tanımlanır. Monitoring, yedeklilik veya süreç değişikliği olabilir. Son tarih belirlenir. İlerleme aylık SLA raporunda takip edilir. Tamamlanmayan aksiyon eskalasyona konu olabilir.

RCA'nın Müşteri Tarafından Onaylanması

Müşteri RCA'yı inceleyebilir. Onay teknik gerçeği değiştirme yetkisi anlamına gelmemelidir. Eksik bilgi için açıklama isteyebilir. Aksiyonların yeterliliği ortak görüşülebilir. Uzlaşmazlık halinde teknik eskalasyon mekanizması kullanılabilir.

Bilgi Güvenliği SLA'sı Nasıl Oluşturulur?

Bilgi güvenliği SLA'sı yalnız uptime'dan farklı metrikler gerektirir. Olay tespit, ilk bildirim, müdahale ve zafiyet kapatma süreleri belirlenebilir. Patch ve log saklama politikaları kritik sistemler için ayrıca düzenlenebilir. SOC hizmeti sunuluyorsa monitoring ve eskalasyon süreleri ölçülmelidir. Güvenlik SLA'ları güncel mevzuat ve sektör gereksinimleriyle uyumlu olmalıdır.

Güvenlik Olayı Tespit Süresi

Detection süresi SOC kapasitesini gösterir. Her olayın tam başlangıcı bilinmeyebilir. Monitoring alarmından doğrulamaya kadar geçen süre ölçülebilir. Kritik sistemlerde daha kısa hedef gerekir. Mean Time to Detect KPI olarak kullanılabilir.

İlk Bildirim Süresi

Müşteri kritik güvenlik olayından belirli sürede haberdar edilmelidir. Kesin kapsam bilinmese bile ilk uyarı yapılabilir. Sonraki güncellemeler devam eder. Bildirimin içeriği standartlaştırılabilir. Mevzuat bildirim süreleri ayrıca dikkate alınmalıdır.

Olay Müdahale Süresi

Güvenlik olayında containment hızlı olmalıdır. Hesap kapatma veya network izolasyonu gerekebilir. Yetki matrisi önceden hazırlanır. Müşteri onayı gereken işlemler ayrıca belirtilir. Müdahale logları saklanmalıdır.

Kritik Zafiyet Kapatma Süresi

CVSS veya başka risk sistemi kullanılabilir. Kritik zafiyet için kısa düzeltme süresi belirlenebilir. Exploit aktifse daha hızlı aksiyon gerekir. Patch yoksa compensating control kullanılabilir. Süre risk bazlı olmalıdır.

Patch Yönetimi

Güvenlik yamalarının değerlendirme ve kurulum süresi belirlenir. Kritik, yüksek ve orta seviyeler ayrılabilir. Test gereksinimi dikkate alınır. Emergency patch süreci ayrıca tanımlanır. Başarısız patch rollback planı bulunmalıdır.

Log Saklama

Güvenlik loglarının ne kadar süre saklanacağı yazılabilir. Süre iş ve düzenleyici ihtiyaçlara göre belirlenir. Log bütünlüğü korunmalıdır. Yetkisiz değişiklik engellenir. Müşteri audit hakkı ayrıca düzenlenebilir.

Güvenlik İzleme

7/24 veya mesai saati SOC hizmeti açıkça belirtilmelidir. Hangi log kaynaklarının izlendiği listelenir. Detection use-case'leri tanımlanabilir. Yeni sistemlerin monitoring kapsamına alınma süresi belirlenir. Kör noktalar düzenli gözden geçirilmelidir.

Veri İhlali Durumunda SLA Nasıl Çalışmalıdır?

Veri ihlali hem teknik olay hem hukuki risk olabilir. SLA teknik bildirim ve müdahale sürelerini tanımlarken mevzuattaki bildirim yükümlülükleri ayrıca yerine getirilmelidir. İlk durumda bütün detayların bilinmesi beklenmemelidir. Ön rapor, etki analizi ve nihai olay raporu aşamalı ilerleyebilir. Tarafların hangi bilgiyi hangi sürede paylaşacağı açık olmalıdır.

İhlalin Tespiti

Monitoring veya üçüncü taraf bildirimiyle olay keşfedilebilir. İlk görev olayın gerçekliğini doğrulamaktır. Gereksiz gecikme yaşanmamalıdır. Zaman damgası kayıt altına alınır. Hukuk ve güvenlik ekipleri koordineli çalışır.

Müşteriye Bildirim

Kritik veri olayı belirli süre içinde müşteriye bildirilmelidir. İlk mesaj doğrulanmış temel bilgiyi içerebilir. Spekülasyondan kaçınılır. İletişim kanalı önceden belirlenir. Düzenli güncelleme devam eder.

İlk Durum Raporu

Ne olduğu, hangi sistemlerin etkilendiği ve hangi aksiyonların alındığı özetlenir. Kesin olmayan bilgiler işaretlenir. Tahmini kapsam belirtilebilir. Sonraki rapor zamanı paylaşılır. Yönetim ve teknik ekip aynı bilgi setini kullanmalıdır.

Etki Analizi

Hangi veri ve kullanıcıların etkilenmiş olabileceği incelenir. Veri çıkışı olup olmadığı araştırılır. Log ve erişim kayıtları kullanılır. Hukuki bildirim gereksinimi değerlendirilir. Analiz sonuçları güncellenebilir.

Düzeltici Faaliyet

Aktif risk önce kontrol altına alınır. Erişim anahtarları değiştirilebilir. Zafiyet kapatılır. Etkilenen sistemler temizlenir. Kalıcı önlem ayrıca planlanır.

Nihai Olay Raporu

RCA ve etki sonuçlarını birleştirir. Olay zaman çizelgesi eklenir. Alınan ve planlanan aksiyonlar yazılır. Sorumlular ve son tarihler belirlenir. Rapor arşivlenir.

Mevzuattaki Bildirim Yükümlülükleriyle Koordinasyon

SLA süresi yasal bildirim yükümlülüğünün yerine geçmez. Sektör ve veri türüne göre farklı süreler olabilir. Hukuk ve veri koruma ekipleri erken dahil edilmelidir. Tarafların kim tarafından hangi bildirimin yapılacağı yazılabilir. Güncel düzenlemeler somut olayda ayrıca kontrol edilmelidir.

Yedekleme SLA'sı Nasıl Belirlenir?

Yedekleme SLA'sı yalnız “günlük yedek alınır” ifadesiyle sınırlı kalmamalıdır. Sıklık, saklama, şifreleme, coğrafi konum ve restore testleri birlikte tanımlanmalıdır. Başarısız yedekleme müşteri açısından görünür olmalıdır. Yedek alınması restore edilebilir olduğu anlamına gelmez. Bu nedenle düzenli geri dönüş testleri kritik öneme sahiptir.

Yedekleme Sıklığı

Sıklık RPO ihtiyacına göre belirlenir. Kritik veri saatlik veya daha sık yedeklenebilir. Düşük kritik sistemlerde günlük yedek yeterli olabilir. Full ve incremental model birlikte kullanılabilir. Başarısız job otomatik alarm üretmelidir.

Yedek Saklama Süresi

Günlük, haftalık ve aylık retention katmanları kullanılabilir. Süre iş ve hukuki ihtiyaca göre belirlenir. Gereksiz uzun saklama maliyet ve veri riski yaratabilir. Silme prosedürü tanımlanır. Backup catalog düzenli kontrol edilir.

Şifreleme

Yedekler at-rest şifrelenebilir. Anahtar yönetimi ayrıca güvenli olmalıdır. Transfer sırasında şifreleme kullanılabilir. Yetkisiz restore engellenmelidir. Güvenlik kontrolleri test edilmelidir.

Yedeklerin Coğrafi Konumu

Aynı veri merkezinde tutulan yedek büyük afet riskine karşı yetersiz olabilir. Farklı bölge veya lokasyon kullanılabilir. Veri yerelleştirme gereksinimleri dikkate alınmalıdır. Bulut region seçimi sözleşmeye yazılabilir. Kritik veriler için off-site kopya düşünülebilir.

Restore Testleri

Restore test edilmeden backup başarısı tam kanıtlanmış sayılmaz. Aylık veya üç aylık test yapılabilir. Örnek veri seti geri yüklenir. Süre ve veri bütünlüğü ölçülür. Sonuç raporu müşteriye sunulabilir.

Başarısız Yedekleme Bildirimi

Kritik yedek job başarısız olduğunda otomatik alarm oluşmalıdır. Müşteriye bildirim eşiği belirlenebilir. Yeniden deneme süreci çalışır. Başarısızlık birkaç döngü devam ederse P1 veya P2 olay olabilir. RPO riski raporlanmalıdır.

RPO ve RTO SLA'ya Nasıl Eklenir?

RPO ve RTO felaket veya ciddi kesinti sonrası veri ve hizmet geri dönüş hedeflerini tanımlar. RPO ne kadar veri kaybının tolere edilebileceğini, RTO ise hizmetin ne kadar sürede geri gelmesi gerektiğini gösterir. Bu hedefler backup ve DR mimarisini doğrudan etkiler. Çok düşük değerler ciddi maliyet yaratabilir. İş birimleri gerçek toleranslarını belirtmelidir.

RPO Nedir?

Recovery Point Objective kabul edilebilir veri kaybı penceresidir. RPO 1 saat ise en fazla yaklaşık 1 saatlik veri kaybı hedeflenir. Bunun için backup veya replication sıklığı uygun olmalıdır. Gerçek performans test edilmelidir. Her sistem aynı RPO'ya ihtiyaç duymaz.

RTO Nedir?

Recovery Time Objective hizmetin kesinti sonrası geri getirilmesi hedefidir. RTO 4 saat ise disaster recovery süreci bu süreyi karşılamalıdır. Manuel işlemler süreye dahil edilir. Veri restore ve uygulama doğrulaması birlikte düşünülmelidir. Test sonuçları hedefi doğrulamalıdır.

RPO ile Yedekleme Sıklığı İlişkisi

Günde bir backup ile 15 dakikalık RPO sağlanamaz. Hedef ile teknik mimari uyumlu olmalıdır. Log shipping veya replication kullanılabilir. Maliyet artışı hesaplanmalıdır. RPO kararını yalnız altyapı ekibi vermemelidir.

RTO ile Felaket Kurtarma İlişkisi

Düşük RTO hızlı failover gerektirir. Soğuk yedek veri merkezi uzun süre alabilir. Warm veya hot standby daha hızlıdır. Otomasyon RTO'yu azaltabilir. Mimari yatırım iş etkisine göre seçilmelidir.

Kritik Sistemlere Göre RPO/RTO

Ödeme sistemi ile iç raporlama sistemi aynı hedefe sahip olmamalıdır. Kritik hizmetler daha düşük RPO ve RTO alabilir. Tier bazlı tablo hazırlanabilir. İş süreçleriyle eşleştirme yapılır. Yıllık gözden geçirme faydalıdır.

RPO/RTO Testlerinin Belgelenmesi

DR testlerinde gerçek süreler ölçülmelidir. Hedefin karşılanıp karşılanmadığı raporlanır. Veri bütünlüğü kontrol edilir. Aksiyonlar takip edilir. Müşteri audit hakkı varsa sonuçlara erişebilir.

Felaket Kurtarma ve İş Sürekliliği SLA'sı

Felaket kurtarma SLA'sı olağan incident yönetiminden daha geniş senaryolara hazırlanır. Disaster Recovery Plan ve Business Continuity Plan birlikte değerlendirilmelidir. Yedek veri merkezi veya cloud region altyapısı hedefleri desteklemelidir. Failover sadece dokümanda değil gerçek testte doğrulanmalıdır. Yıllık test sonuçları taraflarla paylaşılabilir.

Disaster Recovery Plan

Teknik sistemlerin felaket sonrası geri dönüş adımlarını içerir. Roller ve iletişim bilgileri tanımlanır. RPO ve RTO hedefleri plana bağlanır. Bağımlılıklar listelenir. Plan büyük değişiklik sonrası güncellenir.

Business Continuity Plan

BCP iş süreçlerinin devamını hedefler. Teknik sistemlerin yanında insan ve lokasyon faktörünü de kapsar. Alternatif operasyon yöntemleri tanımlanır. Kritik tedarikçiler dahil edilir. Düzenli masa başı veya gerçek test yapılabilir.

Yedek Veri Merkezi

Farklı fiziksel veya coğrafi konum kullanılabilir. Kapasite production yükünü taşıyabilmelidir. Replikasyon modeli belirlenir. Veri güvenliği korunur. Lokasyon değişikliği müşteriye bildirilebilir.

Failover

Primary sistemden yedek ortama geçiş sürecidir. Manuel veya otomatik olabilir. DNS ve network değişiklikleri hesaba katılır. Veri bütünlüğü doğrulanır. Failback süreci ayrıca planlanmalıdır.

Yıllık DR Testleri

En az yıllık test kritik hizmetlerde uygun olabilir. Gerçek failover veya kontrollü senaryo kullanılabilir. RTO ve RPO ölçülür. Başarısız adımlar raporlanır. Sonraki test öncesi aksiyonlar tamamlanmalıdır.

Test Sonuçlarının Müşteriyle Paylaşılması

Müşteri kritik hizmetin DR kapasitesini doğrulayabilmelidir. Tam teknik detay güvenlik nedeniyle sınırlandırılabilir. Özet rapor ve sonuç paylaşılabilir. Başarısızlık varsa iyileştirme planı sunulur. Bu hak sözleşmede düzenlenebilir.

SaaS Sözleşmelerinde SLA Nasıl Belirlenir?

SaaS SLA'sı uygulamanın yalnız açık olmasını değil kullanıcı deneyimini ve veri güvenliğini de ele almalıdır. Availability, performans, destek, yedekleme ve entegrasyon temel başlıklardır. Sürüm güncellemelerinin müşteriyi beklenmedik biçimde etkilememesi gerekir. Sözleşme bitiminde veri çıkışı da hizmet seviyesinin parçası olabilir. Kurumsal SaaS müşterileri özellikle bu alanları ayrıntılı müzakere eder.

SaaS Availability

Uygulamanın kritik fonksiyonları üzerinden ölçüm yapılmalıdır. Login ekranının açık olması tek başına yeterli olmayabilir. Bölgesel kullanıcı etkisi hesaba katılabilir. Aylık hedef belirlenir. Planlı bakım sınırlandırılır.

Uygulama Performansı

Sayfa ve API yanıt süreleri ölçülebilir. Kritik kullanıcı akışları seçilir. P95 veya P99 kullanılabilir. Müşteri internet bağlantısı dış faktör olarak ayrılır. Performans raporu düzenli paylaşılabilir.

Destek Hizmeti

Ticket ve kritik destek kanalları belirlenir. Öncelik seviyeleri açıklanır. İlk yanıt ve güncelleme süreleri yazılır. Premium destek ayrı paket olabilir. Destek dili ve saat dilimi belirtilir.

Veri Yedekleme

Backup sıklığı ve retention yazılır. Müşterinin kendi export alıp alamadığı belirtilir. Restore talebi için süre tanımlanabilir. Şifreleme ve lokasyon açıklanır. Veri kaybı halinde sorumluluk ana sözleşmeyle uyumlu olmalıdır.

Entegrasyon

API ve üçüncü taraf connector'lar hizmetin kritik parçası olabilir. Desteklenen entegrasyon listesi belirtilir. Değişiklik bildirimi yapılır. Müşteri tarafından geliştirilen özel entegrasyonlar kapsam dışı tutulabilir. Teknik SLA açıkça ayrıştırılmalıdır.

Sürüm Güncellemesi

SaaS sağlayıcı düzenli release yapabilir. Breaking change önceden bildirilmelidir. Kritik güvenlik güncellemesi istisna olabilir. Release note yayınlanabilir. Büyük değişiklikler için test ortamı sunulabilir.

Veri Çıkışı

Müşteri sözleşme sonunda verisini alabilmelidir. Format ve teslim süresi belirlenir. API veya dosya export kullanılabilir. Ek ücret varsa baştan yazılmalıdır. Veri silme süreci teslim sonrası başlatılır.

IaaS ve PaaS Hizmetlerinde SLA

IaaS ve PaaS hizmetlerinde SLA, altyapı katmanlarının ayrı ayrı değerlendirilmesini gerektirir. Compute, storage, network ve platform servisleri farklı availability seviyelerine sahip olabilir. Region ve Availability Zone mimarisi toplam hizmet riskini etkiler. Üçüncü taraf bulut SLA'sı müşteriye sunulan üst hizmetin alt sınırını belirleyebilir. Ana sağlayıcı kendi mimarisini bu bağımlılığa göre tasarlamalıdır.

Altyapı Kullanılabilirliği

Compute instance veya sanal makine erişilebilirliği ölçülebilir. Tek instance ile cluster SLA'sı farklıdır. Yedekli mimari şart koşulabilir. Müşteri konfigürasyon sorumluluğu ayrılır. Availability formülü servis dokümanıyla uyumlu olmalıdır.

Region ve Availability Zone

Tek AZ tasarımı daha yüksek kesinti riski taşır. Multi-AZ mimari daha güçlü dayanıklılık sağlayabilir. Region arası replikasyon ek maliyet getirir. Müşteri iş ihtiyacı belirleyicidir. Mimari varsayım SLA'ya veya teknik eke yazılmalıdır.

Depolama

Storage availability ve durability farklı kavramlardır. Verinin erişilebilirliği ile kaybolma olasılığı ayrı ölçülür. Backup ayrıca gerekir. IOPS veya latency hedefi belirlenebilir. Depolama sınıfı performansı etkiler.

Ağ Bağlantısı

Network availability ve paket kaybı izlenebilir. İnternet çıkışı ve özel bağlantı farklı SLA'ya sahip olabilir. Bölgesel latency dikkate alınır. Müşteri lokasyonu dış etken yaratabilir. Ölçüm noktaları açık olmalıdır.

Platform Servisleri

Managed database veya queue gibi servislerin kendi SLA'ları bulunabilir. Uygulama bu servislerin birleşimine bağlıdır. Tek tek SLA değerleri toplam end-to-end availability'yi garanti etmez. Mimari hata toleransı önemlidir. Kritik servisler için alternatif planlanabilir.

Üçüncü Taraf Bulut SLA'larının Etkisi

Alt sağlayıcı yüzde 99,9 SLA veriyorsa ana sağlayıcının yüzde 99,99 taahhüt vermesi ek mimari olmadan gerçekçi olmayabilir. Back-to-back şartlar analiz edilmelidir. Ana sağlayıcı redundancy ile daha yüksek hizmet seviyesi oluşturabilir. Üçüncü taraf kredisi müşteriye otomatik aktarılmayabilir. Sözleşme bu ilişkiyi açıkça düzenlemelidir.

Yönetilen BT Hizmetlerinde SLA

Yönetilen BT hizmetlerinde sağlayıcı sistemin günlük operasyonunu üstlenir. Bu nedenle monitoring, müdahale ve eskalasyon SLA'nın merkezindedir. Sunucu, ağ, veri tabanı, NOC, SOC ve help desk servisleri farklı metrikler gerektirir. Yerinde müdahale coğrafi koşullara bağlı olabilir. Tek tablo yerine servis bazlı SLA matrisi daha kullanışlıdır.

Sunucu Yönetimi

Availability, patch ve incident müdahalesi ölçülebilir. Sunucunun hardware veya cloud altyapı bağımlılığı ayrılır. Monitoring kapsamı belirtilir. Backup sorumluluğu yazılır. Capacity alert'leri ayrıca KPI olabilir.

Ağ Yönetimi

Network availability ve packet loss izlenebilir. Kritik cihaz arızası için müdahale süresi belirlenir. ISP bağımlılığı ayrıca düzenlenir. Konfigürasyon yedekleri tutulmalıdır. Değişiklik yönetimi SLA'yı etkileyebilir.

Veri Tabanı Yönetimi

Database availability ve performans hedefleri belirlenebilir. Backup, replication ve restore sorumluluğu yazılır. Kritik query sorunları olay olarak ele alınabilir. Capacity planning yapılmalıdır. Failover testi düzenli olabilir.

NOC

NOC altyapı olaylarını proaktif izler. Alarm doğrulama ve eskalasyon süreleri ölçülür. 7/24 kapsam açık olmalıdır. False positive oranı KPI olabilir. Müşteri bilgilendirme süreci tanımlanır.

SOC

SOC güvenlik olaylarını izler. Detection ve notification süreleri temel SLA'dır. Use-case kapsamı belirtilir. Log onboarding süresi ayrıca ölçülebilir. Kritik olayda incident response ekibi devreye girer.

Help Desk

İlk yanıt ve çözüm oranı öne çıkar. First Contact Resolution KPI olarak kullanılabilir. Kullanıcı memnuniyeti XLA yaklaşımıyla eklenebilir. Çağrı terk oranı takip edilebilir. Destek saatleri açıkça belirlenmelidir.

Yerinde Müdahale

Fiziksel lokasyona gitme gerektiren olaylar farklı süreye sahiptir. Mesafe ve ulaşım koşulları dikkate alınır. Şehir bazlı hedef verilebilir. Yedek parça temin süresi ayrıca düzenlenir. Acil durum erişim prosedürü müşterinin sorumluluğunda olabilir.

Yazılım Bakım ve Destek Sözleşmelerinde SLA

Yazılım bakım sözleşmelerinde hata ile yeni özellik talebinin ayrılması çok önemlidir. Bug fix SLA kapsamına girerken yeni özellik roadmap veya change request süreciyle yönetilebilir. Versiyon güncelleme ve güvenlik yamaları için ayrı zaman hedefleri belirlenebilir. Garanti kapsamı ile ücretli bakım hizmeti birbirine karıştırılmamalıdır. Her hata sınıfı için destek ve çözüm hedefi açıkça yazılmalıdır.

Hata Sınıflandırması

Fonksiyonun beklenen davranıştan sapması hata olarak tanımlanır. Kritik, yüksek, orta ve düşük sınıflar kullanılabilir. İş etkisi dikkate alınır. Dokümantasyona göre çalışan özellik hata sayılmayabilir. Sınıflandırma örneklerle desteklenmelidir.

Bug Fix Süresi

Kritik bug için hızlı patch gerekebilir. Düşük hata planlı release'e alınabilir. Kesin süre yerine hedef kullanılabilir. Regression test süresi hesaba katılır. Acil patch sonrası kalıcı release ayrıca yapılabilir.

Versiyon Güncelleme

Desteklenen sürüm politikası açık olmalıdır. Eski versiyon ne kadar süre desteklenecek belirlenir. Major upgrade ayrı proje olabilir. Güvenlik gereksinimi güncellemeyi zorunlu kılabilir. Müşteri gecikmesi SLA'yı etkileyebilir.

Güvenlik Yaması

Kritik zafiyet patch'i daha kısa sürede uygulanabilir. Test ve rollback planı hazırlanır. Müşteri onayı gereken sistemler belirtilir. Emergency maintenance kullanılabilir. Sonuç raporlanır.

Yeni Özellik Talebi ile Hata Ayrımı

Yeni fonksiyon ihtiyacı SLA bug fix süresine bağlanmamalıdır. Gereksinim değişikliği change request sayılır. Mevcut fonksiyonun hatalı çalışması bug'dır. İki kategori için farklı süreç kullanılır. Tartışma halinde ürün dokümantasyonu referans olabilir.

Garanti Kapsamı ile SLA İlişkisi

Garanti yazılım teslimi sonrası belirli hataların ücretsiz düzeltilmesini içerebilir. SLA ise bu düzeltmenin hangi hizmet seviyesinde yapılacağını düzenleyebilir. Bakım dönemi garanti bittikten sonra devam edebilir. Ücret ve kapsam ayrı yazılmalıdır. Ana sözleşmeyle tutarlılık korunmalıdır.

Açık Kaynak Yazılım Kullanılan Sistemlerde SLA Nasıl Kurulur?

Açık kaynak yazılım kullanılması SLA yapılamayacağı anlamına gelmez. Community projesi doğrudan sözleşmesel SLA vermeyebilir fakat sistemi yöneten ticari sağlayıcı kendi SLA'sını sunabilir. Kritik bağımlılıkların güvenlik ve bakım sorumluluğu açıkça belirlenmelidir. “Bu açık kaynak, bizim sorumluluğumuz değil” yaklaşımı uçtan uca hizmet modelinde yeterli olmayabilir. Sağlayıcının seçtiği bileşenler için makul sorumluluk üstlenmesi gerekir.

Open Source Projenin Kendisi SLA Verir mi?

Gönüllü açık kaynak topluluğu genellikle sözleşmesel SLA vermez. Release veya güvenlik patch süresi garanti edilmez. Ticari destek şirketleri ayrı SLA sağlayabilir. Proje governance yapısı incelenmelidir. Kritik sistemlerde yalnız community desteğine güvenmek riskli olabilir.

Topluluk Desteği ile Ticari Destek Arasındaki Fark

Community forumu iyi niyetli yardım sunar. Yanıt süresi garantisi yoktur. Ticari destek ise ücretli sözleşmeyle hizmet seviyesi verir. Kritik işletmeler için ticari destek daha uygun olabilir. Maliyet ve risk birlikte değerlendirilmelidir.

Açık Kaynak Bileşenin Destek Sorumluluğu

Sistemi geliştiren sağlayıcı seçtiği open source bileşeni yönetebilir. Destek kapsamı sözleşmede açık olmalıdır. Unsupported dependency kullanımı ayrıca risk yaratır. Güncelleme ve patch sorumluluğu belirlenir. Müşterinin kendi eklediği bileşenler ayrı tutulabilir.

Güvenlik Güncelleme Süresi

Kritik CVE'ler için değerlendirme süresi belirlenebilir. Upstream patch bekleniyorsa compensating control kullanılabilir. Aktif exploit durumunda hızlı aksiyon gerekir. Dependency scanning düzenli yapılmalıdır. Sonuç müşteriye raporlanabilir.

Kritik Açık Kaynak Bağımlılıklarının Takibi

SBOM veya dependency envanteri tutulabilir. Kritik projeler işaretlenir. Maintainer aktivitesi ve güvenlik durumu takip edilir. Alternatif kütüphane planı hazırlanabilir. EOL veya abandoned proje riski yönetilmelidir.

Hizmet Sağlayıcının Open Source Bileşenlerden Sorumluluğu

Sağlayıcı kendi çözüm mimarisinde kullandığı bileşenleri dikkate almalıdır. Alt bileşen arızası otomatik sorumsuzluk yaratmamalıdır. Sözleşmedeki third-party exclusion makul sınırda olmalıdır. Alternatif ve mitigation yükümlülüğü getirilebilir. Uçtan uca hizmet hedefi korunmalıdır.

Alt Yükleniciler SLA'yı Nasıl Etkiler?

Alt yüklenici kullanımı hizmet zincirini genişletir ancak müşteri açısından ana sağlayıcının sorumluluğunu otomatik ortadan kaldırmamalıdır. Ana sağlayıcı müşteriye taahhüt ettiği SLA'yı kendi tedarikçilerine de yansıtmalıdır. Bu nedenle back-to-back SLA yapısı önemlidir. Alt sağlayıcı değişikliği kritik hizmetlerde bildirim konusu olabilir. Ana sağlayıcı tedarikçi yönetimini aktif biçimde yürütmelidir.

Subcontractor Kullanımı

Hangi hizmetlerde alt yüklenici kullanılabileceği belirtilir. Kritik alt yükleniciler listelenebilir. Müşteri onayı veya bildirim mekanizması olabilir. Veri işleyen alt taraflar ayrıca değerlendirilir. Sağlayıcı koordinasyon sorumluluğunu korur.

Alt Sağlayıcının Hizmet Kesintisi

Alt tedarikçi arızası müşterinin hizmetini etkileyebilir. Ana sağlayıcı olay yönetimini üstlenmelidir. Alt sağlayıcıya eskalasyon yapar. Müşteriye tek temas noktası sunulur. Kesintinin SLA hesabından tamamen çıkarılması her zaman uygun değildir.

Ana Sağlayıcının Sorumluluğu

Ana sağlayıcı kendi seçtiği alt tedarikçiyi yönetir. Müşteri alt sağlayıcıyla ayrı sözleşme yapmadıysa uçtan uca sorumluluk ana sağlayıcıda kalabilir. Sorumluluk sınırı ana sözleşmeyle belirlenir. Alt tedarikçi hatası için rücu ilişkisi tarafların iç meselesidir. Sözleşme yapısı buna göre hazırlanmalıdır.

Back-to-Back SLA

Ana sağlayıcının müşteriye verdiği hedefler alt sağlayıcı sözleşmesinde de desteklenmelidir. Aksi halde sağlayıcı karşılayamadığı riski üstlenir. Daha sıkı iç hedefler kullanılabilir. Servis kredileri de back-to-back tasarlanabilir. Bu yapı tedarik zinciri riskini azaltır.

Alt Yüklenici Değişikliğinin Bildirimi

Kritik hizmet sağlayıcısı değişirse müşteri bilgilendirilebilir. Veri lokasyonu veya güvenlik etkisi varsa onay gerekebilir. Bildirim süresi belirlenir. Yeni alt sağlayıcının SLA kapasitesi doğrulanır. Değişiklik hizmet seviyesini düşürmemelidir.

Üçüncü Taraf Bağımlılıkları SLA'da Nasıl Düzenlenmelidir?

Modern bilişim hizmetlerinin çoğu bulut, internet, SMS, ödeme veya başka API servislerine bağlıdır. Bu bağımlılıklar SLA'nın gerçekçi tasarlanmasında dikkate alınmalıdır. Ancak üçüncü taraf kaynaklı her kesintiyi otomatik olarak kapsam dışına çıkarmak müşterinin satın aldığı uçtan uca hizmeti anlamsız hale getirebilir. Sağlayıcının kontrol, alternatif ve eskalasyon kapasitesi değerlendirilmelidir. Third-Party Exclusion maddeleri sınırlı ve ölçülebilir olmalıdır.

Bulut Sağlayıcıları

Cloud availability ana hizmeti doğrudan etkileyebilir. Multi-region veya multi-cloud seçenekleri değerlendirilebilir. Alt SLA değerleri analiz edilir. Bulut kredisinin müşteriye aktarımı ayrıca düzenlenebilir. Ana sağlayıcının mimari sorumluluğu korunmalıdır.

İnternet Servis Sağlayıcıları

Tek ISP kritik tek hata noktası olabilir. Yedek bağlantı kullanılabilir. Müşteri lokasyon interneti ayrı sorumluluk olabilir. Data center bağlantıları sağlayıcı kapsamına girebilir. Kesinti kaynağı ölçümle belirlenmelidir.

SMS ve E-Posta Sağlayıcıları

Bildirim hizmetleri üçüncü tarafa bağlı olabilir. Başarı oranı ve teslim süresi ayrı izlenir. Alternatif sağlayıcı geçişi planlanabilir. Spam veya operatör etkisi dikkate alınır. Müşteri iş akışı bu servise kritik derecede bağlıysa yedeklilik gerekir.

Ödeme Sistemleri

Ödeme servisinin kesintisi gelir sürecini durdurabilir. Birden fazla provider kullanılabilir. Timeout ve retry politikası önemlidir. Hata sorumluluğu loglarla ayrıştırılır. Uçtan uca müşteri deneyimi yine izlenmelidir.

API Sağlayıcıları

Dış API kesintisi uygulama fonksiyonunu bozabilir. Fallback veya cache kullanılabilir. Sağlayıcının SLA'sı takip edilir. Breaking change bildirimi kontrol edilir. Kritik dependency için alternatif planlanabilir.

Third-Party Exclusion Maddelerinin Sınırı

İstisna yalnız sağlayıcının makul kontrolü dışındaki durumları kapsamalıdır. Sağlayıcının yanlış konfigürasyonu kapsam dışı tutulamaz. Yedeklilik taahhüdü varsa üçüncü taraf kesintisine rağmen hizmet sürdürülmesi beklenebilir. İstisna süresi ve bildirim şartı yazılabilir. Çok geniş ifadeler müzakere edilmelidir.

SLA İstisnaları Nasıl Yazılmalıdır?

SLA istisnaları performans hesabının hangi durumlarda uygulanmayacağını belirler. Müşteri kaynaklı değişiklik, planlı bakım veya gerçek mücbir sebep makul istisnalar olabilir. Fakat istisnalar genel ve sınırsız yazılırsa SLA'nın ticari değeri azalır. Her istisna mümkün olduğunca objektif kriter ve kayıt şartına bağlanmalıdır. Müşteri raporda hangi sürenin neden hariç tutulduğunu görebilmelidir.

Müşteri Kaynaklı Kesintiler

Müşterinin sistem veya ağ değişikliği soruna neden olabilir. Sağlayıcı olay kaynağını kayıtlarla göstermelidir. Ortak hata varsa süre paylaşımı ayrıca değerlendirilebilir. Müşteri sorumluluğu tanımlanır. İstisna otomatik varsayılmamalıdır.

Yetkisiz Değişiklik

Müşteri veya üçüncü kişi izinsiz konfigürasyon değiştirirse hizmet etkilenebilir. Bu durum kapsam dışı tutulabilir. Yetkisiz değişikliğin kanıtı loglarla gösterilmelidir. Sağlayıcının erişim kontrol sorumluluğu ayrıca incelenir. Change management süreci açık olmalıdır.

Planlı Bakım

Yalnız önceden bildirilmiş ve tanımlı pencere içinde kalan bakım hariç tutulmalıdır. Aylık süre limiti uygulanabilir. Son dakika çalışmalar ayrı sınıflandırılır. Müşteri kritik iş takvimini bildirebilir. Raporlama bakım dakikalarını ayrı göstermelidir.

Mücbir Sebep

Tarafların makul kontrolü dışındaki olağanüstü olaylar olabilir. Tanım ana sözleşmeyle uyumlu olmalıdır. Her teknik arıza mücbir sebep değildir. Önlenebilir altyapı eksiklikleri ayrıca değerlendirilir. Bildirim ve azaltma yükümlülüğü korunmalıdır.

Üçüncü Taraf Sorunları

Üçüncü taraf kesintisi belirli şartlarda istisna olabilir. Ancak sağlayıcının seçtiği kritik tedarikçi için sorumluluk tamamen dışlanmamalıdır. Alternatif ve eskalasyon kapasitesi göz önüne alınır. Back-to-back SLA kullanılır. Sınırlı ve açık istisna tercih edilir.

İstisnaların Sınırsız Yazılmasının Riski

Geniş istisna maddesi SLA'yı görünürde yüksek fakat pratikte düşük korumalı hale getirir. Sağlayıcı hemen her olayda exclusion kullanabilir. Müşteri gerçek availability performansını göremez. Pazarlama oranı ile gerçek hizmet seviyesi ayrışır. Bu nedenle istisna listesi dikkatle müzakere edilmelidir.

Mücbir Sebep ile SLA İstisnası Aynı Şey midir?

Mücbir sebep daha geniş sözleşmesel bir kavramdır ve yalnız SLA ölçümünü değil tarafların genel yükümlülüklerini etkileyebilir. SLA istisnası ise belirli performans hesabından bazı süreleri çıkarır. Her SLA istisnası mücbir sebep değildir. Planlı bakım buna en açık örnektir. Bu iki kavram ana sözleşmede ve SLA'da birbirini destekleyecek şekilde ayrılmalıdır.

Mücbir Sebebin Sözleşmedeki Yeri

Genellikle ana sözleşmede düzenlenir. Tarafların ifa yükümlülüğüne etkisi açıklanır. Bildirim ve mitigation yükümlülüğü bulunabilir. Uzun sürmesi halinde fesih hakkı doğabilir. SLA yalnız ilgili performans etkisini referans alabilir.

Teknik Kesinti ile Mücbir Sebep Ayrımı

Sunucu arızası normal operasyon riski olabilir. Doğal afet gibi olağanüstü olay farklı değerlendirilir. Sağlayıcı her büyük arızayı mücbir sebep ilan edememelidir. Bakım ve yedeklilik kapasitesi dikkate alınır. Olayın önlenebilirliği önemli kriterdir.

Önlenebilir Olaylar

Yedek disk bulunmaması veya patch yapılmaması çoğu zaman operasyonel ihmaldir. Mücbir sebep sayılması doğru olmayabilir. Sağlayıcının sözleşmesel bakım yükümlülüğü incelenir. Risk kontrolü yapılmamışsa exclusion sınırlandırılabilir. Kök neden analizi bu ayrımı destekler.

Yedekli Mimari Bulunmamasının Etkisi

Yüksek availability taahhüdü verilip tek sunucu kullanılmışsa mimari uyumsuzluk vardır. Donanım arızası bu durumda öngörülebilir risktir. Sağlayıcı mimari varsayımları açıkça belirtmelidir. Müşteri daha düşük maliyet için tekil yapı seçtiyse sorumluluk farklılaşabilir. Karar kayıt altına alınmalıdır.

İş Sürekliliği Tedbirlerinin Önemi

Mitigation kapasitesi mücbir sebep etkisini azaltabilir. DR, backup ve alternatif iletişim kanalı bulunmalıdır. Olay tamamen önlenemese bile hizmet daha hızlı geri dönebilir. Sözleşme makul iş sürekliliği yükümlülüğü koyabilir. Böylece istisna sorumluluktan tamamen kaçış aracına dönüşmez.

SLA İhlali Nedir?

SLA ihlali belirlenen hizmet seviyesinin ölçüm dönemi veya olay bazında karşılanmamasıdır. Tekil düşük öncelik ihlali ile kronik kritik ihlal aynı sonuç doğurmamalıdır. Kademeli yaklaşım kullanılabilir. Birden fazla metrik aynı olayda ihlal edilebilir. Sözleşme aynı kesinti nedeniyle çifte kredi veya ceza uygulanıp uygulanmayacağını açıkça düzenlemelidir.

Tekil İhlal

Bir kez gerçekleşen SLA sapmasıdır. Örneğin P3 yanıt süresi bir kez aşılmış olabilir. Düşük etki nedeniyle yalnız raporlama yeterli olabilir. Tekrarlama izlenir. Her tekil ihlal ağır cezaya bağlanmamalıdır.

Kritik İhlal

P1 müdahale veya kritik availability eşiğinin aşılması ciddi ihlaldir. Servis kredisi daha yüksek olabilir. RCA zorunlu tutulabilir. Yönetim eskalasyonu çalışır. Belirli durumda fesih hakkı doğabilir.

Tekrarlayan İhlal

Aynı metrik kısa dönemde birden fazla kez ihlal edilirse sistemik sorun olabilir. SIP başlatılabilir. Ek raporlama istenebilir. Servis kredisi kademeli artırılabilir. Tekrarlama kriteri açık yazılmalıdır.

Kronik SLA İhlali

Belirli dönem boyunca sürekli hedef kaçırılmasıdır. Örneğin 6 ayın 3'ünde availability ihlali olabilir. Müşteri için hizmet kalitesinin kalıcı biçimde yetersiz olduğunu gösterebilir. Cure Period verilebilir. Düzelmezse fesih hakkı doğabilir.

Birden Fazla Metrikte Aynı Anda İhlal

Tek olay availability, response ve resolution SLA'larını aynı anda ihlal edebilir. Kredilerin toplanıp toplanmayacağı belirlenmelidir. Maksimum aylık kredi tavanı kullanılabilir. Kritik ihlalin diğerlerinden öncelikli sonucu olabilir. Çifte yaptırım konusu ana sorumluluk rejimiyle uyumlu olmalıdır.

SLA İhlalinde Servis Kredisi Nasıl Hesaplanır?

Servis kredisi SLA hedefinin karşılanmaması halinde müşteriye sonraki fatura veya hizmet bedeli üzerinden tanımlanan ticari telafidir. Kredi oranı ihlal seviyesine göre kademeli olabilir. Hangi hizmet bedelinin esas alınacağı açıkça yazılmalıdır. Otomatik kredi müşteriyi sürekli talep prosedüründen kurtarabilir. Maksimum kredi oranı ise sağlayıcının finansal riskini sınırlar.

Service Credit Nedir?

Hizmet kredisi nakit tazminattan farklı ticari telafi mekanizmasıdır. Genellikle sonraki faturadan düşülür. SLA performansına bağlıdır. Zarar ispatı gerekmeyebilir. Ancak sözleşmede açık hesap yöntemi bulunmalıdır.

Kredinin Hangi Bedel Üzerinden Hesaplanacağı

Toplam sözleşme bedeli yerine etkilenen hizmetin aylık bedeli esas alınabilir. Birden fazla hizmet varsa ayrıştırma önemlidir. Paket fiyatlarda oran yöntemi kullanılabilir. Vergi ve ek ücretlerin dahil olup olmadığı yazılmalıdır. Hesaplama örnekle gösterilebilir.

Kademeli Servis Kredisi

Yüzde 99,9 hedef altında yüzde 5, daha düşük seviyede yüzde 10 gibi kademeler kullanılabilir. Kritik sapma daha yüksek kredi doğurur. Kademeler teşvik yaratmalıdır. Çok düşük kredi etkisiz kalabilir. Aşırı yüksek kredi ise ticari dengeyi bozabilir.

Maksimum Kredi Oranı

Aylık hizmet bedelinin belirli yüzdesi tavan olabilir. Örneğin yüzde 20 veya yüzde 50 kullanılabilir. Kronik ihlalde fesih hakkı ayrıca korunabilir. Tavan sağlayıcı riskini öngörülebilir hale getirir. Müşterinin diğer hakları ayrıca düzenlenmelidir.

Otomatik Kredi veya Talep Üzerine Kredi

Otomatik kredi daha müşteri dostudur. Sağlayıcı performans raporuna göre kendiliğinden uygular. Talep üzerine model müşterinin belirli sürede başvuru yapmasını gerektirir. Kısa başvuru süresi hakkı fiilen anlamsızlaştırabilir. Süre makul olmalıdır.

Kredi Başvuru Süresi

Talep modeli kullanılıyorsa başvuru penceresi açık yazılmalıdır. 30 gün gibi süre kullanılabilir. Rapor gecikirse süre rapor tesliminden başlayabilir. Başvuru yöntemi belirtilir. Eksik prosedür nedeniyle hak kaybı yaratmaktan kaçınılmalıdır.

Servis Kredisi ile Tazminat Aynı Şey midir?

Servis kredisi, cezai şart ve zarar tazmini birbirinden farklı hukuki ve ticari mekanizmalardır. Servis kredisi genellikle hizmet bedeli üzerinden indirim sağlar. Cezai şart sözleşme ihlaline bağlı önceden belirlenmiş yaptırım niteliği taşıyabilir. Zarar tazmini ise gerçekleşen zarar ve genel sorumluluk hükümleriyle ilişkilidir. Bu mekanizmaların birbirini dışlayıp dışlamadığı ana sözleşmede açıkça düzenlenmelidir.

Hizmet Kredisi

Hizmet performansı düşüklüğüne bağlı ticari telafidir. Fatura indirimi şeklinde uygulanabilir. Genellikle zarar ispatı gerekmez. Kademeli hesap yapılabilir. Aylık tavan bulunabilir.

Cezai Şart

Belirli ihlalin gerçekleşmesi halinde uygulanacak sözleşmesel yaptırımdır. Kritik veya tekrarlayan ihlaller için kullanılabilir. Orantılılık önemlidir. Genel sorumluluk rejimiyle ilişkilendirilmelidir. Somut sözleşmede hukuki değerlendirme yapılmalıdır.

Zarar Tazmini

Müşterinin gerçek zararı servis kredisinden çok daha yüksek olabilir. Tazminat hakkının korunup korunmadığı sözleşmeye bağlıdır. Sorumluluk sınırı uygulanabilir. Dolaylı zarar istisnaları bulunabilir. Bu alan ana sözleşmenin genel hükümleriyle birlikte değerlendirilmelidir.

Sorumluluk Sınırı

Toplam sorumluluk sözleşme bedelinin belirli oranıyla sınırlandırılabilir. Bazı ihlaller bu sınır dışında tutulabilir. SLA kredilerinin limite dahil olup olmadığı yazılmalıdır. Sınırsız sorumluluk çoğu sağlayıcı için sürdürülemez olabilir. Risk ve fiyat arasında denge kurulmalıdır.

Münhasır Çözüm Hükümleri

Bazı sözleşmeler servis kredisini SLA ihlalinin tek çözümü olarak düzenler. Bu müşterinin başka haklarını sınırlayabilir. Kritik ve kronik ihlal için istisna düşünülebilir. Fesih hakkı ayrıca korunabilir. Hüküm açık ve bilinçli müzakere edilmelidir.

Ana Sözleşmeyle Uyum

SLA'daki kredi ve ceza hükümleri ana sorumluluk maddeleriyle tutarlı olmalıdır. Aynı olay için çelişkili sonuç çıkmamalıdır. Fesih ve tazminat hakları birlikte incelenir. Belge önceliği önemlidir. Hukuk ve teknik ekip birlikte gözden geçirmelidir.

SLA İhlalinde Cezai Şart Belirlenebilir mi?

SLA ihlali için cezai şart düzenlenmesi mümkün olabilir, ancak somut sözleşmenin hukuki yapısı, tarafların niteliği ve uygulanacak hukuk dikkate alınmalıdır. Cezai şart özellikle kritik veya tekrarlayan ihlallerde kullanılabilir. Her küçük sapmayı yüksek cezaya bağlamak ticari dengeyi bozabilir. Kademeli ve orantılı yapı daha uygulanabilir olabilir. Servis kredisiyle birlikte kullanım açıkça düzenlenmelidir.

Cezai Şartın Amacı

Amaç hizmet seviyesine uyumu teşvik etmektir. Aynı zamanda ihlal halinde ekonomik sonuç sağlar. Kritik hizmetlerde güçlü disiplin yaratabilir. Ancak ceza sağlayıcının ifasını imkansız hale getirmemelidir. Ticari risk fiyatlamaya yansıyacaktır.

İhlal Seviyesine Göre Kademelendirme

P1 ihlali daha yüksek sonuç doğurabilir. P3 küçük gecikme daha düşük seviyede kalabilir. Kronik ihlal ayrı kategori olabilir. Kademeler objektif ölçüme bağlanmalıdır. Aynı olayda toplam tavan belirlenebilir.

Servis Kredisi ile Birlikte Kullanılması

Servis kredisi rutin performans düşüşünü telafi edebilir. Cezai şart daha ağır ihlaller için saklanabilir. İki mekanizmanın aynı olayda birlikte uygulanıp uygulanmayacağı yazılmalıdır. Çifte sonuç bilinçli tasarlanmalıdır. Ana sorumluluk rejimiyle uyum sağlanmalıdır.

Orantılılık

Yaptırım hizmet bedeli ve ihlal etkisiyle makul ilişkide olmalıdır. Çok yüksek oran tedarik maliyetini artırabilir. Çok düşük oran ise davranış değiştirmez. İş kritikliği ve olası zarar değerlendirilir. Hukuki geçerlilik açısından somut sözleşme ayrıca incelenmelidir.

Sözleşme Genel Sorumluluk Rejimiyle İlişkisi

Cezai şartın sorumluluk tavanına dahil olup olmadığı yazılmalıdır. Zarar tazminiyle ilişkisi açıklanır. Fesih hakkı ayrıca düzenlenebilir. Mücbir sebep istisnası kontrol edilir. Belge önceliği açık olmalıdır.

Kronik SLA İhlali Fesih Sebebi Olarak Düzenlenebilir mi?

Kronik SLA ihlali hizmetin kalıcı biçimde beklenen seviyeyi karşılamadığını gösterebilir. Bu durumda müşterinin yalnız servis kredisi alması yeterli olmayabilir. Sözleşmede belirli tekrar sayısı veya dönem kriteri üzerinden fesih hakkı düzenlenebilir. Sağlayıcıya Cure Period ve Service Improvement Plan fırsatı verilebilir. Kritik ihlallerde daha hızlı fesih mekanizması ayrıca düşünülebilir.

Aynı Metrikte Art Arda İhlal

Örneğin üç ay üst üste availability hedefinin kaçırılması kronik ihlal sayılabilir. Aynı metrikte tekrar sistemik sorunu gösterir. SIP zorunlu tutulabilir. Kredi oranı artırılabilir. Düzelmezse fesih hakkı doğabilir.

Belirli Dönemde Toplam İhlal Sayısı

Altı ayda dört SLA ihlali gibi eşik kullanılabilir. Farklı metrikler birlikte değerlendirilebilir. Düşük etkili olayların aynı ağırlıkta sayılması doğru olmayabilir. Kritik ağırlıklandırma yapılabilir. Hesap yöntemi açık olmalıdır.

Kritik SLA İhlali

Tek bir çok ağır olay bile fesih hakkı doğurabilir. Uzun süreli hizmet kesintisi veya ciddi güvenlik ihlali örnek olabilir. Bu durum ana sözleşmenin material breach hükmüyle ilişkilendirilebilir. Cure hakkı olayın niteliğine göre sınırlı olabilir. Hukuki yapı somut sözleşmede değerlendirilmelidir.

Cure Period

Sağlayıcıya sorunu düzeltmesi için süre verilebilir. 30 gün gibi dönem kullanılabilir. Bu sürede iyileştirme planı uygulanır. Kritik risk devam ediyorsa daha kısa süre gerekebilir. Sonuç ölçülebilir KPI'larla değerlendirilir.

Service Improvement Plan

SIP kök neden ve aksiyonları içeren resmi iyileştirme planıdır. Sorumlu kişiler ve son tarihler belirlenir. Müşteri periyodik ilerleme alır. Başarı kriterleri açık olmalıdır. Plan başarısızsa sözleşmesel sonuç uygulanabilir.

Fesih Eşiği

Eşik açık ve objektif olmalıdır. Tarafların hangi durumda fesih hakkı doğduğunu önceden bilmesi gerekir. Servis kredisi tavanına ulaşılması ek kriter olabilir. Kritik olay sayısı ayrı kullanılabilir. Exit SLA fesih mekanizmasıyla birlikte düşünülmelidir.

Service Improvement Plan (SIP) Nedir?

SIP, hizmet performansı istenen seviyeyi sürekli karşılamadığında uygulanan yapılandırılmış iyileştirme planıdır. Amaç hemen sözleşmeyi sonlandırmak yerine kök nedenleri ortadan kaldırmaktır. Plan teknik, süreçsel ve organizasyonel aksiyonlar içerebilir. Her aksiyon için sorumlu ve son tarih belirlenir. Başarı objektif metriklerle ölçülür.

Hangi Durumlarda Başlatılır?

Kronik SLA ihlali en yaygın tetikleyicidir. Büyük P1 olayı sonrası da SIP istenebilir. Reopen veya incident trendi bozulduğunda kullanılabilir. Yönetim toplantısı kararıyla başlatılabilir. Eşikler sözleşmede tanımlanabilir.

Kök Nedenlerin Belirlenmesi

Tek tek olaylar yerine ortak nedenler araştırılır. Kapasite eksikliği veya yetersiz monitoring görülebilir. Süreç hataları da değerlendirilir. Veri ve RCA kayıtları kullanılır. Sorun yalnız personele indirgenmemelidir.

İyileştirme Aksiyonları

Mimari, süreç veya ekip değişikliği yapılabilir. Monitoring artırılabilir. Yedeklilik kurulabilir. Eğitim ve otomasyon eklenebilir. Aksiyonlar ölçülebilir olmalıdır.

Sorumlular

Her aksiyonun sahibi belirlenmelidir. Genel “teknik ekip” ifadesi yeterli değildir. Yönetim sponsorluğu gerekebilir. Müşteri bağımlılığı olan aksiyonlar ayrıca yazılır. Sorumlu değişirse kayıt güncellenir.

Son Tarihler

Her aksiyon için gerçekçi bitiş tarihi konur. Kritik riskler önce ele alınır. Gecikmeler gerekçeli raporlanır. Uzun aksiyonlar ara milestone'lara bölünebilir. Tarihler SLA raporunda izlenebilir.

Başarı Kriterleri

Örneğin üç ay boyunca SLA ihlali olmaması hedeflenebilir. Incident sayısında belirli düşüş beklenebilir. Reopen oranı azaltılabilir. Müşteri memnuniyeti iyileştirilebilir. Kriterler plan başlamadan belirlenmelidir.

SLA Performansı Nasıl Raporlanmalıdır?

SLA raporu yalnız yüzde değerlerini gösteren bir tablo olmamalıdır. Uptime, ticket performansı, kritik olaylar, ihlaller ve iyileştirme aksiyonları birlikte sunulmalıdır. Servis kredileri hesaplanabiliyorsa raporda açıkça gösterilmelidir. Kronik sorunlar trend üzerinden izlenmelidir. Aylık rapor yönetim ve operasyon için ortak veri kaynağı oluşturur.

Aylık SLA Raporu

Her hizmet için hedef ve gerçekleşen değer gösterilir. İhlal olup olmadığı belirtilir. Hariç tutulan süreler listelenir. Açık aksiyonlar eklenir. Rapor belirli tarihte düzenli teslim edilmelidir.

Uptime

Aylık availability yüzdesi gösterilir. Kesinti dakikaları ayrıca yazılır. Planlı bakım ayrı sütunda tutulur. Bölgesel veya kısmi kesinti açıklanır. Önceki aylarla trend karşılaştırması yapılabilir.

Ticket Performansı

P1–P4 ticket sayıları paylaşılır. Yanıt ve çözüm SLA uyum oranı gösterilir. Ortalama ve percentile değerler eklenebilir. Reopen ve backlog metrikleri destekleyici olabilir. Tekil kritik olaylar ayrıca incelenir.

Kritik Olaylar

P1 ve major incident listesi raporlanır. Süre ve iş etkisi yazılır. RCA durumu belirtilir. Açık düzeltici aksiyonlar gösterilir. Tekrarlayan kök nedenler işaretlenir.

SLA İhlalleri

Hangi metrik ve olayda ihlal olduğu açıkça yazılır. Nedeni ve süresi belirtilir. İstisna kullanıldıysa gerekçesi gösterilir. Kredi veya ceza hesabı eklenir. Kronik eşik takip edilir.

Servis Kredileri

Hesaplanan kredi tutarı gösterilir. Hangi hizmet bedeline uygulandığı belirtilir. Otomatik veya talep modeli açıklanır. Önceki aydan devreden kredi varsa eklenir. Faturayla uyum kontrol edilir.

Kronik Problemler

Tekrarlayan incident ve problem kayıtları listelenir. Trend analizi yapılır. RCA ve SIP durumu gösterilir. İş etkisi açıklanır. Yönetim aksiyonu gerekebilir.

İyileştirme Aksiyonları

Aksiyon sahibi ve son tarih yazılır. Tamamlanan ve geciken işler ayrılır. Beklenen performans etkisi belirtilir. Müşteri bağımlılıkları gösterilir. Sonraki ay durum tekrar kontrol edilir.

Müşterinin SLA Verilerini Denetleme Hakkı Olmalı mı?

Müşterinin SLA hesabını doğrulayabilecek makul denetim hakkı bulunması şeffaflığı artırır. Bu hak sağlayıcının bütün sistemlerine sınırsız erişim anlamına gelmemelidir. Monitoring, ticket ve ilgili log kayıtları kontrollü biçimde paylaşılabilir. Bağımsız denetim yüksek riskli hizmetlerde kullanılabilir. Log saklama süresi audit ihtiyacına göre belirlenmelidir.

Monitoring Kayıtlarına Erişim

Müşteri dashboard görüntüleyebilir. Ham veri belirli durumda talep edilebilir. Güvenlik açısından hassas altyapı bilgisi maskelenebilir. Hesabı doğrulayacak veri yeterli olmalıdır. Erişim yetkisi rol bazlı verilir.

Ticket Logları

Ticket zaman damgaları SLA için temel kanıttır. Durum değişiklikleri audit log içinde görülmelidir. Manuel düzenlemeler kaydedilir. Müşteri kendi ticket'larını inceleyebilmelidir. Export imkanı faydalı olabilir.

Sistem Logları

Kritik uyuşmazlıkta altyapı veya uygulama logu gerekebilir. Kişisel ve güvenlik verisi korunmalıdır. Belirli zaman aralığı paylaşılır. Log bütünlüğü doğrulanabilir. Erişim prosedürü sözleşmede tanımlanabilir.

Bağımsız Denetim

Üçüncü taraf denetçi hesaplamayı inceleyebilir. Maliyet paylaşımı düzenlenebilir. Sık ve gereksiz denetim sağlayıcıyı zorlamamalıdır. Belirli ihlal veya şüphe eşiğinde kullanılabilir. Gizlilik yükümlülüğü uygulanır.

Ölçüm Uyuşmazlıklarının Çözümü

Önce tarafların teknik ekipleri veriyi karşılaştırır. Sonra yönetim eskalasyonu yapılabilir. Bağımsız monitoring veya uzman görüşü kullanılabilir. Tolerans aralığı belirlenebilir. Son karar mekanizması açık olmalıdır.

Log Saklama Süresi

SLA itiraz süresinden kısa olmamalıdır. 6 veya 12 ay gibi dönem kullanılabilir. Güvenlik ve maliyet dikkate alınır. Yasal saklama gereksinimleri ayrıca değerlendirilir. İmha prosedürü bulunmalıdır.

SLA Kayıtları Uyuşmazlıkta Nasıl Kullanılır?

SLA uyuşmazlığında zaman damgalı teknik kayıtlar tarafların iddialarını destekleyebilir. Ticket, monitoring, e-posta ve olay raporlarının birbirini doğrulaması önemlidir. Sistem saatlerinin senkronizasyonu özellikle kritik konudur. Kayıt bütünlüğü ve değişiklik geçmişi korunmalıdır. Somut uyuşmazlıkta delil değerlendirmesi uygulanacak hukuk ve yargılama kurallarına göre ayrıca ele alınmalıdır.

Ticket Kayıtları

Bildirim ve durum değişikliklerini gösterir. Öncelik seviyesi kaydedilir. Pause ve resume süreleri izlenir. Kapanış zamanı bulunur. Audit log güvenilirliği artırır.

Monitoring Logları

Kesintinin teknik başlangıç ve bitişini gösterebilir. Alarm threshold bilgisi önemlidir. Ham veriler saklanmalıdır. Sistem değişikliği kayıt altında olmalıdır. Uptime hesabının temelini oluşturabilir.

E-Posta Bildirimleri

Müşteri ve sağlayıcı iletişim zamanlarını gösterir. Kritik olay güncellemeleri kanıtlanabilir. E-posta tek SLA kaynağı olmamalıdır. Ticket ile ilişkilendirilmesi faydalıdır. Saklama politikası uygulanmalıdır.

Olay Raporları

Olayın kapsam ve zaman çizelgesini özetler. RCA ile desteklenebilir. Etkilenen sistemler gösterilir. Yönetim kararları kayıt altına alınır. Sonraki iyileştirme aksiyonlarına referans olur.

Sistem Zaman Damgaları

Farklı sistemlerin saatleri senkron olmalıdır. NTP veya benzeri yöntem kullanılabilir. Saat dilimi aynı raporda açıkça belirtilir. Zaman kayması hesaplamayı bozabilir. Audit kontrolleri uygulanmalıdır.

Kayıtların Bütünlüğü

Kayıtların sonradan iz bırakmadan değiştirilmesi engellenmelidir. Audit log tutulur. Yetki sınırlandırılır. Kritik kayıtlar immutable storage üzerinde saklanabilir. Bu yaklaşım güvenilirliği artırır.

SLA'da Değişiklik Yönetimi Nasıl Yapılır?

Hizmet kapsamı ve teknoloji değiştikçe SLA'nın da kontrollü biçimde güncellenmesi gerekir. Yeni servis, mimari veya sürüm performans hedeflerini etkileyebilir. Değişiklik tek taraflı operasyon kararıyla yapılmamalıdır. Change Request üzerinden etki, maliyet ve risk değerlendirilir. Taraf onayı sonrası yeni versiyon yürürlüğe girer.

Change Request

Değişiklik talebi yazılı kayda alınır. Gerekçe ve etkilenen SLA maddeleri belirtilir. Maliyet ve zaman etkisi analiz edilir. Teknik ve ticari ekip onay verir. Yürürlük tarihi belirlenir.

Yeni Hizmet Eklenmesi

Yeni servis için kritiklik ve metrik belirlenir. Mevcut SLA otomatik uygulanmamalıdır. Ölçüm sistemi hazır olmalıdır. Fiyat etkisi değerlendirilir. Ek veya yeni versiyon yayınlanır.

Hizmet Kapsamının Daralması

Kapsam dışına çıkan sistemler açıkça listelenir. Müşteri etkisi değerlendirilir. Ücret ve sorumluluk değişebilir. Eski ölçüm kayıtları korunur. Değişiklik tarihi raporlamada gösterilir.

Mimari Değişiklik

Cloud veya veri merkezi geçişi availability riskini değiştirebilir. Yeni dependency'ler eklenebilir. DR ve backup hedefleri yeniden test edilir. Transition döneminde geçici SLA uygulanabilir. Değişiklik sonrası baseline alınır.

Yeni Sürüm

Major version performans ve entegrasyon davranışını değiştirebilir. Eski sürüm desteği ayrıca belirlenir. SLA hedefleri iki sürüm için farklı olabilir. Migration planı hazırlanır. Müşteri onayı gereken değişiklikler bildirilir.

SLA Hedeflerinin Revizyonu

Tarihsel veri hedefin gerçekçi olmadığını gösterebilir. İş ihtiyacı da değişebilir. Hedef düşürülüyorsa ticari bedel etkisi değerlendirilmelidir. Hedef yükseliyorsa ek kapasite gerekebilir. Revizyon karşılıklı onayla yapılmalıdır.

Taraf Onayı

Yetkili kişiler veya dijital onay mekanizması kullanılabilir. Operasyon ekiplerinin sözlü mutabakatı yeterli olmayabilir. Onay kayıt altında tutulur. Yeni versiyon herkese duyurulur. Eski doküman arşivlenir.

SLA Versiyonlama Nasıl Yapılmalıdır?

Versiyonlama değişikliklerin hangi tarihten itibaren geçerli olduğunu göstermeyi sağlar. Özellikle uzun süreli bilişim sözleşmelerinde birden fazla SLA sürümü oluşabilir. Versiyon numarası, yürürlük tarihi ve değişiklik geçmişi bulunmalıdır. Eski sürümler silinmemeli, arşivlenmelidir. Yetkili onay kayıtlarıyla birlikte saklanmalıdır.

Versiyon Numarası

1.0, 1.1 veya tarih bazlı sistem kullanılabilir. Major ve minor değişiklik ayrılabilir. Belge üzerinde görünür olmalıdır. Ticket ve raporlarda referans verilebilir. Tek isimli dosya karmaşasından kaçınılır.

Yürürlük Tarihi

Yeni versiyonun ne zaman uygulanacağı açık olmalıdır. Geçmiş olaylara geriye dönük uygulanmamalıdır. Transition dönemi varsa belirtilir. Faturalama ve raporlama buna göre düzenlenir. Saat dilimi gerekirse eklenir.

Değişiklik Geçmişi

Hangi maddelerin değiştiği özetlenir. Gerekçe eklenebilir. Önceki hedef ve yeni hedef görünür olur. Müzakere süreci kolaylaşır. Audit sırasında geçmiş takip edilebilir.

Eski Versiyonların Arşivlenmesi

Eski belge saklanmalıdır. O dönem gerçekleşen olaylar eski versiyona göre değerlendirilir. Yetkisiz değişiklik engellenir. Arşiv erişimi sınırlı olabilir. Saklama süresi sözleşme ve hukuk ihtiyacına göre belirlenir.

Yetkili Onayları

Teknik ve ticari yetki ayrılabilir. Kritik değişiklik hukuk onayı gerektirebilir. Elektronik imza veya kurumsal onay akışı kullanılabilir. Onay tarihi kaydedilir. Yetkisiz doküman değişikliği geçersiz sayılabilir.

SLA Ne Sıklıkla Gözden Geçirilmelidir?

SLA imzalandıktan sonra yıllarca değişmeden bırakılmamalıdır. Aylık operasyonel ve üç aylık hizmet değerlendirmeleri sorunları erken gösterir. Yıllık sözleşme incelemesinde hedef ve ticari yapı yeniden değerlendirilebilir. Büyük sistem değişikliği veya ciddi ihlal ek gözden geçirme tetikleyebilir. Böylece SLA gerçek hizmetle uyumunu korur.

Aylık Operasyonel Değerlendirme

Aylık rapor üzerinden performans incelenir. Açık incident ve aksiyonlar konuşulur. Servis kredileri kontrol edilir. Trendler izlenir. Küçük iyileştirmeler hızlı uygulanır.

Üç Aylık Hizmet Değerlendirmesi

Daha stratejik performans analizi yapılır. Kapasite ve kullanıcı trendi değerlendirilir. Kronik sorunlar ele alınır. Yeni ihtiyaçlar konuşulur. SIP durumu gözden geçirilir.

Yıllık Sözleşme Gözden Geçirmesi

Hedefler iş ihtiyacıyla karşılaştırılır. Fiyat ve risk yapısı incelenir. Yeni regülasyon veya güvenlik gereksinimleri eklenebilir. Exit ve DR planları kontrol edilir. Yeni versiyon hazırlanabilir.

Büyük Sistem Değişiklikleri Sonrası

Cloud geçişi veya major release SLA'yı etkileyebilir. Yeni dependency'ler eklenir. Performance baseline yeniden ölçülür. RPO ve RTO test edilir. Hedefler gerekiyorsa güncellenir.

Büyük SLA İhlali Sonrası

P1 veya kronik ihlal SLA tasarımında eksikliği gösterebilir. RCA yalnız teknik nedeni değil sözleşme mekanizmasını da değerlendirmelidir. Pause veya eskalasyon kuralları yetersiz olabilir. Taraflar madde güncellemesi yapabilir. Öğrenme yeni versiyona aktarılır.

Yapay Zekâ Hizmetleri İçin SLA Nasıl Belirlenebilir?

Yapay zekâ servislerinde klasik API availability yanında model sürümü ve veri işleme gibi ek başlıklar önem kazanır. Model davranışı deterministik olmayabilir ve doğruluk her kullanım senaryosunda aynı ölçülemez. Bu nedenle teknik erişilebilirlik ile model kalite hedefleri ayrı ele alınmalıdır. Model değişikliği müşterinin sonuçlarını etkileyebilir. Kritik iş akışlarında fallback mekanizması düşünülmelidir.

API Kullanılabilirliği

AI servisinin endpoint availability'si ölçülür. Health check yanında gerçek inference çağrısı kullanılabilir. Region bazlı farklılık olabilir. Aylık hedef belirlenir. Kesinti ve rate limit ayrı tutulmalıdır.

Latency

Model boyutu ve çıktı uzunluğu süreyi etkiler. P95 latency hedefi kullanılabilir. Streaming cevap ayrı ölçülebilir. İlk token süresi farklı KPI olabilir. Yoğun kullanım koşulları tanımlanmalıdır.

Rate Limit

İstek veya token bazlı limit uygulanabilir. Müşteri paketine göre değişebilir. Limit artış talebi için süreç bulunur. Ani trafik için burst desteği açıklanır. Limit değişikliği önceden bildirilmelidir.

Model Sürümü

Hangi model sürümünün kullanıldığı görünür olmalıdır. Sabit sürüm veya otomatik güncel model seçilebilir. Regüle kullanımda versiyon kontrolü daha önemlidir. Sonuç kalitesini etkileyen değişiklikler kaydedilir. Rollback imkanı değerlendirilebilir.

Model Değişikliği Bildirimi

Breaking davranış değişikliği önceden bildirilmelidir. Güvenlik veya acil risk istisna olabilir. Test ortamı sunulabilir. Release note yayınlanabilir. Müşterinin yeniden validasyon yapabilmesi için makul süre tanınmalıdır.

Veri İşleme

Prompt ve çıktı verisinin nasıl işlendiği açıklanmalıdır. Eğitim amacıyla kullanılıp kullanılmadığı sözleşmede belirtilir. Saklama süresi tanımlanır. Güvenlik ve veri lokasyonu değerlendirilir. Kişisel veri işleniyorsa özel kontroller gerekir.

Kritik Hizmetlerde Fallback Mekanizması

AI servisi kesildiğinde alternatif model kullanılabilir. Manuel iş akışı devreye girebilir. Daha düşük kapasiteli yedek servis tasarlanabilir. Failover süresi ölçülebilir. Kritik süreç tamamen tek modele bağımlı bırakılmamalıdır.

SLA ile Kapasite Yönetimi Nasıl İlişkilendirilir?

SLA hedefleri belirli trafik ve kullanıcı varsayımlarına dayanmalıdır. Müşteri beklenen kapasitenin çok üzerine çıktığında aynı performansın garanti edilmesi zor olabilir. Bu nedenle maksimum kullanıcı, işlem kapasitesi ve trafik eşikleri belirtilmelidir. Sağlayıcı da capacity planning ile büyümeyi önceden takip etmelidir. Kapasite aşımları yalnız müşteri kusuru olarak görülmemelidir.

Maksimum Kullanıcı

Lisans veya mimari kapasiteye göre kullanıcı sınırı belirlenebilir. Eş zamanlı aktif kullanıcı ayrıca ölçülür. Büyüme tahmini düzenli paylaşılır. Limit yaklaşınca sağlayıcı uyarı verir. Kapasite artışı için change request açılabilir.

İşlem Kapasitesi

Saniye veya dakika bazlı işlem limiti tanımlanabilir. Normal ve peak yük ayrılır. Performans testi bu kapasiteyi doğrular. Aşım durumunda throttling uygulanabilir. Müşteri önceden bilgilendirilmelidir.

Eş Zamanlı Oturum

Concurrent session uygulama performansını etkileyebilir. Lisans veya infrastructure sınırı bulunabilir. Peak saatleri izlenir. Capacity alarmı oluşturulur. SLA hedefi belirli eşik altında garanti edilebilir.

Depolama Kapasitesi

Storage doluluğu performans ve availability riski yaratır. Threshold alarmı belirlenir. Müşteri veri büyümesini paylaşabilir. Otomatik ölçekleme kullanılabilir. Ek maliyet koşulları açık olmalıdır.

Trafik Artışı

Kampanya veya dönemsel yoğunluk önceden bildirilebilir. Ani trafik için burst kapasitesi planlanır. DDoS saldırıları ayrı güvenlik süreci gerektirir. Normal büyüme capacity plan'a dahil edilir. Trafik aşımlarının SLA etkisi tanımlanır.

Capacity Planning

Aylık veya üç aylık kapasite analizi yapılabilir. Trendler değerlendirilir. Kaynak artışı için erken uyarı verilir. Müşteri ve sağlayıcı ortak plan yapar. Böylece performans ihlalleri proaktif biçimde azaltılır.

Sözleşme Sona Erdiğinde SLA Ne Olur?

Sözleşme sona erdiğinde hizmet bir anda kesilirse müşteri ciddi operasyon riski yaşayabilir. Bu nedenle geçiş döneminde uygulanacak hizmet seviyesi ayrıca belirlenmelidir. Veri ihracı, teslim, silme ve yeni sağlayıcıya devir aşamaları zaman hedeflerine bağlanabilir. Transition Assistance ücretli veya sözleşme bedeline dahil olabilir. Exit SLA normal operasyon SLA'sını tamamlayan ayrı mekanizmadır.

Hizmetin Devam Süresi

Fesih sonrası belirli süre hizmet devam edebilir. 30 veya 90 gün gibi dönem kullanılabilir. Ücretlendirme baştan yazılır. Kritik güvenlik ihlali halinde farklı kural olabilir. Geçiş süresi müşterinin yeni çözüm kurmasına izin vermelidir.

Geçiş Dönemi

Transition plan taraflarca hazırlanır. İş ve teknik sorumlular atanır. Data export ve knowledge transfer planlanır. Normal destek devam eder. Performans seviyesinin bilinçli düşürülmesi engellenmelidir.

Veri İhracı

Müşteri verisi standart formatta teslim edilebilir. Format ve yöntem sözleşmede belirlenir. API veya dosya export kullanılabilir. Büyük veri için transfer süresi planlanır. Bütünlük kontrolü yapılır.

Veri Teslim Süresi

Talep sonrası belirli iş günü içinde teslim hedefi verilebilir. Veri büyüklüğü ve güvenlik süreci dikkate alınır. Gecikme exit SLA ihlali sayılabilir. Müşteri indirme süresi ayrıca olabilir. Teslim teyidi kayıt altına alınır.

Veri Silme

Teslim sonrası sağlayıcının kopyaları belirli sürede silmesi gerekebilir. Backup retention etkisi açıklanmalıdır. Silme sertifikası verilebilir. Hukuki saklama zorunlulukları istisna olabilir. Alt yükleniciler de kapsama dahil edilmelidir.

Transition Assistance

Sağlayıcı yeni sisteme geçiş için teknik destek verebilir. Dokümantasyon ve toplantı sağlanır. Ek ücret modeli açık olmalıdır. Saat veya paket bazlı fiyatlama kullanılabilir. İşbirliği makul süreyle sınırlandırılır.

Yeni Sağlayıcıya Devir

Mevcut sağlayıcı yeni sağlayıcıyla bilgi paylaşabilir. Erişim ve konfigürasyon dosyaları teslim edilir. Gizlilik hükümleri korunur. Ortak geçiş toplantıları yapılabilir. Devir tamamlanana kadar sorumluluk matrisi geçerli olur.

Exit SLA Nedir?

Exit SLA sözleşme sona erdikten sonraki geçiş faaliyetlerinin hizmet seviyesini tanımlar. Normal SLA'nın bittiği gün müşteri korunmasız bırakılmaz. Veri teslimi, dokümantasyon, konfigürasyon ve knowledge transfer süreleri belirlenir. Yeni sağlayıcıya destek de kapsama alınabilir. Bu yapı vendor lock-in riskini azaltır.

Fesih Sonrası Hizmet Seviyesi

Geçiş boyunca mevcut availability hedefi korunabilir. Düşürülmüş ama açık seviye de belirlenebilir. Kritik destek kanalları devam etmelidir. Süre ve ücret yazılır. Fesih nedeni hizmet kalitesini kötüleştirme gerekçesi olmamalıdır.

Veri Teslimi

Format ve süre açık olmalıdır. Şifreli transfer kullanılabilir. Büyük veri için fiziksel yöntem düşünülebilir. Bütünlük hash veya kontrol raporuyla doğrulanabilir. Eksik veri teslimi exit ihlali sayılabilir.

Dokümantasyon

Güncel mimari ve operasyon dokümanı teslim edilmelidir. Eski ve güncel olmayan belgeler yeterli değildir. Sistem bağımlılıkları gösterilir. Support runbook eklenebilir. Eksik doküman listesi geçiş başında çıkarılır.

Konfigürasyon Dosyaları

İlgili konfigürasyon export edilebilir. Secret değerleri güvenli yöntemle aktarılır. Sağlayıcıya ait lisanslı bileşenler ayrılır. Infrastructure as Code varsa teslim koşulu belirlenir. Format yeniden kullanılabilir olmalıdır.

Bilgi Transferi

Teknik oturumlar planlanır. Kritik operasyon senaryoları anlatılır. Kayıt alınabilir. Soru-cevap dönemi sağlanır. Transfer tamamlanma kriteri belirlenir.

Yeni Sağlayıcıya Destek

Eski sağlayıcı makul teknik soruları yanıtlayabilir. Ortak toplantı yapılabilir. Erişim ve güvenlik sınırı korunur. Sorumluluk geçiş tarihi açık olmalıdır. Destek süresi sınırlı ve ölçülebilir olmalıdır.

Exit Süresi ve Ücretleri

Transition hizmeti ücretsiz veya ücretli olabilir. Fiyatlama önceden yazılır. Acil fesih durumunda farklı model uygulanabilir. Saatlik ücret aşırı yüksek olmamalıdır. Müşteri exit maliyetini sözleşme imzalanırken görmelidir.

Hizmet Alan Açısından SLA Müzakere Stratejisi

Hizmet alan tarafın temel amacı en yüksek rakamı istemek değil, iş riskiyle uyumlu koruma sağlamaktır. Kritik metrikler önceliklendirilmeli ve sağlayıcının standart SLA'sı gerçek operasyon verisiyle test edilmelidir. Ölçüm ve audit hakları güvence altına alınmalıdır. İstisnalar ve third-party exclusion maddeleri dar tutulmalıdır. Kronik ihlal ve exit hakları özellikle uzun süreli hizmetlerde güçlü biçimde ele alınmalıdır.

İş Kritik Metrikleri Belirlemek

Her metriği SLA'ya bağlamak gerekli değildir. Gelir ve iş sürekliliğini etkileyen göstergeler seçilir. Availability, P1 müdahale ve RTO öncelikli olabilir. Düşük etkili KPI'lar operasyon raporunda kalabilir. Böylece sözleşme daha yönetilebilir olur.

Sağlayıcının Standart SLA'sını Test Etmek

Geçmiş performans raporu istenebilir. Standart hedef gerçek verilerle karşılaştırılır. Referans müşterilerden bilgi alınabilir. Teklifteki pazarlama ifadesi doğrulanır. Yüksek oranların istisnaları özellikle incelenmelidir.

Ölçüm Hakkını Güvenceye Almak

Monitoring verisine erişim talep edilebilir. Audit veya bağımsız doğrulama mekanizması kurulabilir. Ölçüm formülü sözleşmeye yazılır. Log saklama süresi belirlenir. Tek taraflı veri değişikliği engellenir.

İstisnaları Daraltmak

Planlı bakım limiti konur. Third-party exclusion sınırlanır. Müşteri kaynaklı kesinti kanıt şartına bağlanır. Mücbir sebep ana sözleşmeyle uyumlu tutulur. Genel “kontrol dışı her olay” ifadesinden kaçınılır.

Kronik İhlal Hakkı

Tekrarlayan düşük performans için özel mekanizma eklenir. SIP ve Cure Period kullanılabilir. Belirli eşiğin ardından fesih hakkı doğabilir. Servis kredisi tek çözüm olmamalıdır. Eşikler objektif yazılmalıdır.

Exit Haklarını Güvenceye Almak

Veri teslimi ve transition süresi baştan belirlenir. Yeni sağlayıcıya destek yükümlülüğü eklenebilir. Exit ücreti görünür olmalıdır. Dokümantasyon ve konfigürasyon teslimi şart koşulabilir. Böylece vendor lock-in riski azaltılır.

Hizmet Sağlayıcı Açısından SLA Müzakere Stratejisi

Sağlayıcı açısından iyi SLA, müşteriye gerçek güvence sunarken kontrol edilemeyen riskleri sınırsız biçimde üstlenmemelidir. Hedefler geçmiş performans ve teknik mimariyle doğrulanmalıdır. Müşterinin bilgi, erişim ve kapasite sorumlulukları açıkça yazılmalıdır. Pause kuralları ve üçüncü taraf bağımlılıkları objektif biçimde tanımlanmalıdır. Sorumluluk sınırı ana sözleşmeyle tutarlı olmalıdır.

Kontrol Edilemeyen Riskleri Ayırmak

Müşteri ağı veya üçüncü taraf servis etkisi ayrıştırılabilir. Ancak sağlayıcının seçtiği dependency için tam sorumsuzluk talep etmek doğru değildir. Mitigation kapasitesi gösterilmelidir. İstisna kanıt ve bildirim şartına bağlanır. Risk fiyatlamaya yansıtılabilir.

Gerçekçi Hedef Belirlemek

Geçmiş performans yüzde 99,8 ise hemen yüzde 99,99 taahhüt risklidir. Önce mimari iyileştirme yapılmalıdır. Hedef kapasite testleriyle doğrulanabilir. SLO iç hedefi SLA'dan daha yüksek tutulabilir. Aşırı taahhüt sürekli ihlal yaratır.

Müşteri Yükümlülüklerini Tanımlamak

Erişim izni veya gerekli bilgiyi sağlama müşterinin sorumluluğu olabilir. Trafik artışı önceden bildirilmelidir. Desteklenen versiyon kullanılması şart koşulabilir. Yetkisiz değişiklik riski tanımlanır. Bu yükümlülükler pause kurallarıyla ilişkilendirilir.

Saat Durdurma Kurallarını Yazmak

Pause yalnız gerçek bekleme halinde uygulanmalıdır. Müşteri bilgilendirilir. Kayıt tutulur. Gereksiz sorularla sayaç durdurulmamalıdır. Resume otomatik veya onaylı şekilde yapılır.

Sorumluluk Sınırını Ana Sözleşmeyle Uyumlaştırmak

Servis kredisi ve cezai şart toplam riskle birlikte değerlendirilir. Aynı ihlal için birden fazla yaptırım açıkça düzenlenir. Sorumluluk tavanı belirlenir. Sigorta gereksinimi varsa dikkate alınır. Ticari fiyatlama bu riski karşılamalıdır.

Kapasite Varsayımlarını Belirtmek

SLA belirli kullanıcı ve trafik seviyesinde garanti edilebilir. Maksimum yük açık yazılır. Aşım durumunda capacity change gerekir. Sağlayıcı trend monitoring yapmalıdır. Müşterinin planlı kampanyaları önceden bildirmesi istenebilir.

Örnek SLA Matrisi Nasıl Hazırlanır?

Örnek SLA matrisi olay seviyelerini yanıt, müdahale, güncelleme ve çözüm hedefleriyle tek tabloda birleştirebilir. Değerler her şirket için aynı olmak zorunda değildir. Kritik hizmetlerde süreler daha kısa, düşük öncelikte daha uzun olabilir. Matris support saatleri ve sayaç pause kurallarıyla birlikte okunmalıdır. Aşağıdaki yaklaşım yalnız model niteliğindedir ve gerçek sözleşmede iş ihtiyacına göre uyarlanmalıdır.

P1 Kritik Olay

P1 için 7/24 destek uygulanabilir. İlk yanıt 15 dakika ve teknik müdahale 30 dakika hedeflenebilir. Müşteri 30 dakikada bir bilgilendirilebilir. Hizmet geri dönüşü için 4 saatlik hedef kullanılabilir. Kalıcı çözüm RCA sonrası ayrıca planlanabilir.

Yanıt Süresi

Örneğin 15 dakika olarak belirlenebilir. İnsan yanıtı şart koşulabilir. Otomatik mesaj dahil edilmez. Telefon doğrulaması yapılabilir. Süre 7/24 işler.

Müdahale Süresi

Teknik ekibin 30 dakika içinde çalışmaya başlaması hedeflenebilir. İlgili uzman çağrılır. Monitoring ve log analizi başlar. Müdahale kaydı ticket'a eklenir. Gerekirse eskalasyon otomatik çalışır.

Güncelleme Sıklığı

Her 30 dakika örnek hedef olabilir. Yeni bilgi olmasa bile durum paylaşılır. Yönetim özeti ayrı hazırlanabilir. Tahmini çözüm zamanı dikkatle verilir. İletişim tek sorumlu üzerinden yürütülür.

Çözüm Hedefi

Dört saat içinde hizmet geri dönüşü hedeflenebilir. Workaround kabul edilip edilmediği yazılmalıdır. Kalıcı fix daha uzun sürebilir. RTO ile uyum kontrol edilir. Süre aşılırsa SLA ihlali oluşabilir.

P2 Yüksek Öncelikli Olay

P2 için 30 dakika veya 1 saat yanıt hedeflenebilir. Müdahale birkaç saat içinde başlayabilir. Güncelleme iki saatte bir yapılabilir. Çözüm bir iş günü veya benzeri hedefle yönetilebilir. İş saatleri dışındaki davranış ayrıca yazılmalıdır.

P3 Orta Öncelikli Olay

P3 olaylarda yanıt 4 iş saati olabilir. Çözüm birkaç iş günü içinde hedeflenebilir. Günlük güncelleme yeterli olabilir. Workaround varsa kalıcı düzeltme planlı release'e alınabilir. Mesai saati desteği uygulanabilir.

P4 Düşük Öncelikli Olay

P4 için 1 iş günü yanıt hedefi kullanılabilir. Çözüm planlı bakım veya sürüm takvimine alınabilir. Yeni özellik talebi olup olmadığı kontrol edilir. Servis kredisine bağlanması çoğu durumda gerekli değildir. KPI olarak takip edilebilir.

Örnek Kullanılabilirlik SLA Maddesi Nasıl Kurgulanır?

Kullanılabilirlik maddesi hizmetin ne olduğunu, hangi dönemde ölçüldüğünü ve hangi formülle hesaplandığını açıkça göstermelidir. Veri kaynağı ve hariç süreler belirlenmelidir. İhlal eşiği ve servis kredisi aynı çerçevede yazılabilir. Böyle bir madde yalnız yüzde oranı yazmaktan daha uygulanabilir olur. Gerçek sözleşmede hukuki ve teknik metin birlikte gözden geçirilmelidir.

Hizmet Tanımı

Hangi production servisin ölçüldüğü belirtilir. Kritik fonksiyonlar listelenir. Test ortamı kapsam dışı olabilir. API ve web arayüzü ayrı tanımlanabilir. Kullanıcı perspektifi açıklanmalıdır.

Ölçüm Dönemi

Takvim ayı veya fatura dönemi seçilebilir. Başlangıç ve bitiş zamanı belirtilir. Saat dilimi yazılır. Kısmi ilk ay için yöntem belirlenir. Raporlama aynı dönemle eşleştirilir.

Hesaplama Formülü

Uygun süre ve downtime açıkça tanımlanır. Planlı bakımın denominatörden çıkarılıp çıkarılmadığı yazılır. Kısmi kesinti kuralı eklenir. Yuvarlama yöntemi belirlenir. Örnek hesap verilebilir.

Veri Kaynağı

Monitoring sistemi adı belirtilir. Yedek veri kaynağı tanımlanabilir. Müşteri erişim hakkı düzenlenir. Uyuşmazlık mekanizması eklenir. Sistem değişikliği önceden bildirilir.

Hariç Tutulan Süreler

Planlı bakım, müşteri kaynaklı sorun ve gerçek mücbir sebep listelenebilir. Her istisna kanıt şartına bağlanır. Aylık bakım limiti olabilir. Third-party exclusion sınırlandırılır. Hariç süre raporda gösterilir.

İhlal Eşiği

Örneğin yüzde 99,9 altı ihlal sayılabilir. Daha düşük bantlar kademeli sonuç doğurabilir. Ölçüm iki ondalık basamakta yapılabilir. Kronik ihlal ayrı tanımlanır. Tek ay ve yıllık hedef ayrılabilir.

Servis Kredisi

Yüzde 99,9–99,5 arası yüzde 5 kredi gibi kademeler kullanılabilir. Kredi etkilenen hizmet bedeli üzerinden hesaplanır. Aylık tavan belirlenir. Otomatik uygulama tercih edilebilir. Diğer haklarla ilişkisi ana sözleşmede düzenlenir.

Örnek Destek SLA Maddesi Nasıl Kurgulanır?

Destek SLA maddesi yalnız “7/24 destek sunulur” dememelidir. Bildirim kanalı, öncelik, başlangıç, yanıt, müdahale, güncelleme ve çözüm ayrı tanımlanmalıdır. Eskalasyon süreci özellikle P1 olaylarda önemlidir. Pause ve reopen kuralları aynı sistemle ilişkilendirilmelidir. Böylece support performansı gerçek veriyle takip edilir.

Bildirim Kanalı

Ticket ana kanal olarak belirlenebilir. P1 için telefon zorunlu olabilir. E-posta düşük öncelikler için kullanılabilir. Sosyal medya resmi kanal sayılmayabilir. Kanal değişikliği önceden bildirilir.

Öncelik Seviyesi

P1–P4 matrisine referans verilir. Impact ve urgency kriterleri kullanılır. Sağlayıcının doğrulama hakkı olabilir. İtiraz mekanizması tanımlanır. Öncelik değişikliği loglanır.

SLA Başlangıcı

Ticket veya monitoring timestamp esas alınır. Telefon bildirimi varsa kayıt zamanı kullanılabilir. Otomatik tespit ayrı tanımlanır. Başlangıç saat dilimi nettir. Çift kayıt durumunda en erken geçerli an kullanılabilir.

Yanıt

İlk insan yanıtı tanımlanır. Otomatik acknowledgement ayrılır. Öncelik bazlı süre yazılır. Yanıt olay sahipliğini göstermelidir. Gerekirse ek bilgi talep edilir.

Müdahale

Teknik çalışmanın başladığı an ayrı ölçülür. Sorumlu ekip atanır. P1 için kısa hedef uygulanır. Log veya ticket kaydı tutulur. Eskalasyon gecikmeden yapılır.

Güncelleme

Her öncelik için iletişim sıklığı belirlenebilir. P1 daha sık güncellenir. Yeni bilgi yoksa mevcut durum paylaşılır. İletişim kanalı bellidir. Yönetim özeti ayrı olabilir.

Çözüm

Workaround ve kalıcı çözüm ayrılır. Hedef süre öncelik bazlı belirlenir. Teknik garanti verilemiyorsa recovery hedefi kullanılabilir. Müşteri doğrulaması istenebilir. Reopen kuralı ayrıca uygulanır.

Eskalasyon

Zaman veya etki eşiğine göre eskalasyon yapılır. Teknik ve yönetim kontakları listelenir. P1 olay otomatik Major Incident olabilir. İletişim kayıt altına alınır. Eskalasyon planı düzenli test edilmelidir.

SLA Hazırlarken En Sık Yapılan Hatalar

SLA hazırlarken en yaygın hata yüksek bir uptime yüzdesi yazıp geri kalan detayları boş bırakmaktır. Hesaplama formülü, başlangıç noktası, pause kuralları ve ölçüm kaynağı yazılmadığında oran pratikte anlamını kaybeder. Üçüncü taraf ve planlı bakım istisnalarının çok geniş tutulması da sık görülen başka sorundur. Kronik ihlal ve exit planı unutulduğunda müşteri sürekli düşük hizmet seviyesine rağmen sözleşmede sıkışabilir. İyi SLA bu boşlukları imza öncesinde kapatır.

Sadece "%99,9 Uptime" Yazmak

Oran tek başına ölçüm standardı değildir. Hangi servis ve dönem olduğu bilinmez. Kesinti tanımı eksiktir. Planlı bakım belirsiz olabilir. Formül ve veri kaynağı mutlaka eklenmelidir.

Hesaplama Formülünü Belirtmemek

Taraflar aynı rakama farklı yöntemle ulaşabilir. Denominatör ve exclusion farklılaşır. Kısmi kesinti tartışma yaratır. Yuvarlama sonucu etkiler. Formül yazılı olmalıdır.

Yanıt ile Çözüm Süresini Karıştırmak

İlk mesaj çözüm değildir. Teknik müdahale ayrıca izlenmelidir. Tek süre sağlayıcı performansını yanlış gösterebilir. Müşteri beklentisi bozulur. Ayrı tanımlar kullanılmalıdır.

SLA Başlangıcını Belirsiz Bırakmak

Ticket mı telefon mu esas olduğu bilinmez. Monitoring önce alarm üretebilir. Farklı kayıtlar farklı süre oluşturur. Uyuşmazlık büyür. Tek ve açık başlangıç tanımı gerekir.

Pause Kurallarını Yazmamak

Sayaç keyfi durdurulabilir. Müşteri beklemesi gerektiği halde sağlayıcı tam süreyi üstlenebilir. İki taraf için de belirsizlik oluşur. Pause nedenleri sınırlı yazılmalıdır. Log zorunlu olmalıdır.

Ölçüm Kaynağını Belirlememek

Müşteri ve sağlayıcı farklı monitoring kullanabilir. Sonuçlar uyuşmayabilir. Tek doğruluk kaynağı bilinmez. Audit zorlaşır. Ölçüm sistemi sözleşmede belirtilmelidir.

Planlı Bakımı Sınırsız Hariç Tutmak

Sağlayıcı çok uzun bakım yapabilir. Availability hedefi yapay olarak yüksek kalır. Müşteri gerçek kesintiyi yaşar. Aylık bakım limiti koymak gerekir. Ön bildirim şartı eklenmelidir.

Üçüncü Taraf İstisnalarını Çok Geniş Yazmak

Modern hizmetlerin çoğu third-party bağımlıdır. Hepsini kapsam dışına çıkarmak SLA'yı zayıflatır. Ana sağlayıcının mimari ve tedarik sorumluluğu unutulmamalıdır. Back-to-back SLA kullanılabilir. İstisna dar tanımlanmalıdır.

Kronik İhlali Düzenlememek

Müşteri her ay küçük kredi alıp düşük hizmete mahkum kalabilir. Tekrarlama eşiği belirlenmelidir. SIP ve Cure Period kullanılabilir. Fesih hakkı eklenebilir. Böylece uzun dönem kalite korunur.

Ana Sözleşmeyle SLA'yı Çelişkili Hale Getirmek

Sorumluluk ve fesih maddeleri farklı olabilir. Belge önceliği yoksa yorum tartışması çıkar. Servis kredisi ana limite uymayabilir. Mücbir sebep tanımı farklılaşabilir. Belgeler birlikte kontrol edilmelidir.

Fesih Sonrası Geçiş Hizmetlerini Unutmak

Sözleşme biter bitmez veri ve sistem erişimi kaybolabilir. Yeni sağlayıcıya geçiş zorlaşır. Vendor lock-in oluşur. Exit SLA yazılmalıdır. Veri ve dokümantasyon teslimi süreye bağlanmalıdır.

SLA Hazırlama Kontrol Listesi

SLA kontrol listesi imza öncesinde önemli başlıkların unutulmamasını sağlar. Hizmet kapsamı, metrikler, ölçüm ve yaptırımlar birlikte değerlendirilmelidir. Raporlama ve audit hakkı yalnız operasyon ekibine bırakılmamalıdır. Fesih ve exit planı da hizmetin yaşam döngüsünün parçasıdır. Kontrol listesi kurumun standart sözleşme sürecine eklenebilir.

Hizmet Kapsamı

Ölçülen servis açık mı kontrol edilmelidir. Production ve test ayrımı yapılır. Kullanıcı ve lokasyon kapsamı belirtilir. Kapsam dışı alanlar listelenir. Yeni hizmet ekleme süreci bulunur.

Kritik Hizmetler

İş etkisi analizi yapılmalıdır. Kritik sistemler ayrı SLA alabilir. RPO ve RTO belirlenir. Major Incident süreci eklenir. Yıllık kritiklik gözden geçirilir.

SLI ve SLO

Önce ölçüm göstergesi seçilmelidir. Ardından hedef belirlenir. SLO gerçek teknik kapasiteye dayanır. Her SLO SLA olmak zorunda değildir. Ölçüm sistemi test edilmelidir.

Uptime

Availability yüzdesi ve dönem yazılmalıdır. Kesinti tanımı bulunur. Formül eklenir. Planlı bakım kuralları belirlenir. Kısmi kesinti yöntemi yazılır.

Yanıt ve Çözüm Süreleri

İlk yanıt ve teknik müdahale ayrılır. Çözüm ve workaround tanımlanır. P1–P4 süreleri belirlenir. Hizmet saatleri belirtilir. Sayaç başlangıcı eklenir.

Öncelik Matrisi

Impact ve urgency kriterleri yazılır. P1–P4 tanımlanır. Örnek vakalar eklenir. İtiraz ve yeniden sınıflandırma süreci bulunur. Öncelik değişikliği loglanır.

Ölçüm Yöntemi

Monitoring kaynağı belirlenir. Formül yazılır. Audit hakkı tanımlanır. Log saklama süresi belirlenir. Uyuşmazlık çözüm süreci eklenir.

Bakım Pencereleri

Gün ve saat belirlenir. Ön bildirim süresi yazılır. Aylık maksimum bakım sınırı konur. Acil bakım tanımlanır. Kritik dönemler istisna olabilir.

İstisnalar

Müşteri kaynaklı ve third-party olaylar sınırlı yazılır. Mücbir sebep ana sözleşmeyle uyumlu olur. Kanıt yükümlülüğü belirlenir. Hariç süreler raporlanır. Sınırsız exclusion'dan kaçınılır.

Raporlama

Aylık rapor formatı belirlenir. Uptime ve ticket verisi gösterilir. İhlal ve kredi hesabı eklenir. Aksiyonlar takip edilir. Rapor teslim tarihi yazılır.

Servis Kredileri

Kademeli oran belirlenir. Hesaplama bedeli açıklanır. Otomatik veya talep yöntemi seçilir. Aylık tavan yazılır. Diğer haklarla ilişkisi düzenlenir.

Sorumluluk

Ana sözleşme limitiyle uyum kontrol edilir. Cezai şart ve kredi ilişkisi yazılır. Kritik istisnalar değerlendirilir. Sigorta gereksinimi olabilir. Sorumluluk açık olmalıdır.

Kronik İhlal

Tekrar eşiği belirlenir. SIP mekanizması eklenir. Cure Period tanımlanır. Kredi kademesi artırılabilir. Fesih hakkı düzenlenir.

Fesih

Kritik ihlal ve kronik performans koşulları yazılır. Bildirim süresi belirlenir. Cure hakkı değerlendirilir. Sorumluluklar kapanışta devam edebilir. Exit planına referans verilir.

Exit Planı

Veri ve dokümantasyon teslimi düzenlenir. Transition Assistance yazılır. Yeni sağlayıcı desteği eklenir. Veri silme süresi belirlenir. Ücretler görünür olmalıdır.

Versiyon ve Onay

Versiyon numarası bulunmalıdır. Yürürlük tarihi yazılır. Değişiklik geçmişi saklanır. Yetkili onayları kayıt altına alınır. Eski versiyon arşivlenir.

İmzadan Önce Sorulması Gereken 15 Kritik SLA Sorusu

İmzalanan Bilişim Anlaşmalarında Hizmet Seviyesi (SLA) Belirleme sürecinde en iyi kontrol yöntemi doğru soruları imzadan önce sormaktır. Birçok uyuşmazlık aslında hizmet başladıktan sonra değil sözleşme müzakeresinde atlanan tanımlardan kaynaklanır. Ölçüm, kesinti, bakım, pause, üçüncü taraf ve exit başlıkları özellikle kontrol edilmelidir. Aşağıdaki 15 soru sözleşme değerlendirme toplantısında doğrudan kullanılabilir. Cevaplardan biri belirsizse ilgili madde daha açık hale getirilmelidir.

Tam Olarak Hangi Hizmet Ölçülüyor?

Ürün adı tek başına yeterli olmayabilir. Kritik modül ve API'ler listelenmelidir. Production ortamı açıkça belirtilir. Entegrasyon kapsamı yazılır. Böylece availability'nin neyi temsil ettiği anlaşılır.

SLA'yı Hangi Sistem Ölçüyor?

Monitoring kaynağı belli olmalıdır. Müşteri erişim hakkı değerlendirilir. İkinci veri kaynağı varsa çatışma kuralı yazılır. Sistem değişikliği bildirilir. Audit log korunur.

Ölçüm Dönemi Nedir?

Aylık veya yıllık dönem sonucu değiştirir. Hizmet kredisi buna göre hesaplanır. Takvim ayı veya fatura dönemi seçilir. Kısmi ay yöntemi belirlenir. Saat dilimi yazılır.

Kesinti Nasıl Tanımlanıyor?

Tam ve kısmi kesinti ayrılmalıdır. Yavaşlık availability sayılır mı belirtilir. Kritik fonksiyon bozulması tanımlanır. Monitoring threshold'ı yazılır. Kullanıcı perspektifi dikkate alınır.

Planlı Bakım Limiti Var mı?

Bakım sınırsız hariç tutulmamalıdır. Aylık maksimum süre konabilir. Ön bildirim şartı bulunur. Acil bakım ayrı tanımlanır. Bakım raporda görünür olmalıdır.

SLA Saati Ne Zaman Başlıyor?

Ticket, telefon veya alarm anı seçilmelidir. P1 için en erken geçerli kayıt kullanılabilir. Saat dilimi belirlenir. Otomatik tespit kuralı yazılır. Çift bildirim uyuşmazlığı önlenir.

Saat Hangi Hallerde Duruyor?

Müşteri bilgi veya erişimi beklenebilir. Pause nedeni sınırlı olmalıdır. Müşteriye bildirim yapılır. Start ve resume zamanı loglanır. Keyfi pause engellenir.

Workaround Çözüm Sayılıyor mu?

Hizmet geri dönebilir ama kök neden devam edebilir. Workaround'un hangi SLA'yı durdurduğu yazılmalıdır. Kalıcı çözüm için ayrı hedef olabilir. RCA zorunlu tutulabilir. Ticket kapanış kriteri açık olmalıdır.

Üçüncü Taraf Arızası Kimin Riski?

Bulut ve API bağımlılıkları incelenir. Ana sağlayıcının tedarik sorumluluğu belirlenir. Back-to-back SLA kontrol edilir. Third-party exclusion dar tutulur. Alternatif plan olup olmadığı sorulur.

İhlal Nasıl Raporlanıyor?

Sağlayıcı otomatik rapor sunuyor mu kontrol edilmelidir. İhlal müşterinin tespitine bırakılmamalıdır. Hesap ve veri kaynağı paylaşılır. Aylık rapor tarihi belirlenir. İtiraz süresi yazılır.

Servis Kredisi Otomatik mi?

Otomatik model müşteri için daha kolaydır. Talep gerekiyorsa süre makul olmalıdır. Kredi oranı ve tavan yazılır. Hangi faturaya uygulanacağı belirtilir. Tazminat haklarıyla ilişkisi kontrol edilir.

Kronik İhlal Ne Zaman Oluşuyor?

Aynı metrikte tekrar eşiği tanımlanır. Belirli dönemde toplam ihlal sayısı kullanılabilir. Kritik olay ayrı değerlendirilir. SIP ve Cure Period eklenir. Fesih eşiği açık olmalıdır.

Müşterinin Audit Hakkı Var mı?

Monitoring ve ticket kayıtlarına erişim değerlendirilir. Bağımsız denetim şartları yazılır. Log saklama süresi yeterli olmalıdır. Güvenlik sınırları korunur. Ölçüm uyuşmazlığı mekanizması bulunur.

Ana Sözleşmeyle Çelişirse Ne Oluyor?

Belge öncelik sırası yazılmalıdır. Sorumluluk ve fesih hükümleri karşılaştırılır. Mücbir sebep tanımları uyumlu olmalıdır. Kredi ve ceza aynı rejime bağlanır. Çelişki imza öncesinde çözülmelidir.

Fesih Halinde Geçiş Desteği Var mı?

Exit SLA mutlaka değerlendirilmelidir. Veri teslimi ve silme süresi yazılır. Yeni sağlayıcıya destek düzenlenir. Geçiş döneminde hizmet seviyesinin ne olacağı belirlenir. Ücretler önceden görünür olmalıdır.

Sıkça Sorulan Sorular

İmzalanmış bilişim sözleşmelerinde SLA konusunda en sık sorulan sorular uptime, ticket süreleri, planlı bakım, servis kredisi ve fesih etrafında toplanır. Yazılım ve BT hizmet sözleşmelerinde SLA maddeleri nasıl hazırlanır sorusuna tek bir standart metinle cevap vermek doğru değildir, çünkü iş kritikliği ve teknik mimari her hizmette değişir. Kurumsal SLA sözleşmesi hazırlama ve bilişim hukuku danışmanlığı ihtiyacında teknik operasyon ile sözleşme hükümlerinin birlikte değerlendirilmesi önemlidir. SLA ve bilişim sözleşmesi avukatı yakınımda şeklinde araştırma yapılırken de yalnız hukuk metni değil teknik ölçüm mantığını anlayabilen çalışma modeline dikkat edilmelidir. Aşağıdaki yanıtlar temel karar noktalarını kısa biçimde özetler.

SLA Nedir?

SLA hizmet seviyesini ölçülebilir taahhütlere dönüştüren sözleşmesel mekanizmadır. Availability, yanıt, müdahale ve çözüm gibi metrikler içerebilir. Ölçüm formülü ve veri kaynağı belirlenir. İhlal sonucu servis kredisi veya başka mekanizma olabilir. İyi SLA teknik ve hukuki açıdan birlikte uygulanabilir olmalıdır.

SLA Bilişim Sözleşmesinin Zorunlu Bir Unsuru mudur?

Her bilişim sözleşmesinde ayrı SLA bulunması zorunlu bir kural olarak değerlendirilmemelidir. Basit ve düşük kritik hizmetlerde detaylı SLA gerekmeyebilir. Kritik ve sürekli hizmetlerde ise güçlü ticari değer sağlar. Somut mevzuat veya sektör düzenlemesi ayrıca incelenmelidir. İhtiyaç iş riskine göre belirlenir.

SLA Ana Sözleşmeden Ayrı İmzalanabilir mi?

Evet, bağımsız belge olarak hazırlanabilir. Ana sözleşmeyle hukuki bağlantısı açık olmalıdır. Belge öncelik sırası yazılır. Versiyon ve yürürlük tarihi belirtilir. Ayrı imza değişiklik yönetimini kolaylaştırabilir.

SLA ile SLO Arasındaki Fark Nedir?

SLO hedeflenen servis seviyesidir. SLA ise belirli hedefi sözleşmesel taahhüde dönüştürür. Her SLO müşteri taahhüdü değildir. İç ekip daha yüksek SLO kullanabilir. SLA ihlalinde ticari sonuç olabilir.

SLA ile KPI Arasındaki Fark Nedir?

KPI daha geniş performans göstergesidir. SLA belirli müşteriye verilen hizmet taahhüdüdür. Reopen oranı KPI olabilir ama SLA olmayabilir. Availability ikisi birden olabilir. KPI yönetim, SLA sözleşmesel performans için kullanılır.

%99,9 Uptime Ne Kadar Kesinti Anlamına Gelir?

Aylık ölçümde yaklaşık 43 dakika civarında izin verilen kesintiye karşılık gelir. Ay uzunluğuna göre küçük fark oluşabilir. Planlı bakım hariçse gerçek kullanıcı kesintisi daha fazla olabilir. Kısmi kesinti formülü sonucu etkiler. Bu nedenle yalnız yüzde oranına bakılmamalıdır.

Yanıt Süresi ile Çözüm Süresi Arasındaki Fark Nedir?

Yanıt süresi sağlayıcının olayı sahiplenmesine kadar geçen süredir. Çözüm süresi olayın giderilmesine kadar devam eder. Teknik müdahale üçüncü bir süre olarak tanımlanabilir. Otomatik ticket mesajı gerçek yanıt olmayabilir. SLA'da bu kavramlar ayrı yazılmalıdır.

Planlı Bakım SLA'ya Dahil midir?

Sözleşme kurgusuna göre hariç tutulabilir. Ön bildirim ve bakım penceresi bulunmalıdır. Aylık maksimum süre konması faydalıdır. Acil bakım ayrı düzenlenmelidir. Sınırsız istisna müşteriyi korumasız bırakır.

SLA İhlalinde Para İadesi Alınabilir mi?

Sözleşme servis kredisi veya iade mekanizması içerebilir. Otomatik para iadesi her durumda varsayılamaz. Hesap yöntemi sözleşmeye göre belirlenir. Hizmet kredisi sonraki faturadan düşülebilir. Diğer tazminat hakları ayrıca değerlendirilir.

Servis Kredisi Nedir?

Servis kredisi performans ihlaline bağlı ticari telafidir. Genellikle hizmet bedelinin belirli yüzdesidir. Kademeli olabilir. Otomatik veya talep üzerine uygulanabilir. Zarar tazminatıyla aynı şey değildir.

SLA İhlalinde Tazminat Talep Edilebilir mi?

Bu konu ana sözleşme ve uygulanacak hukukla birlikte değerlendirilmelidir. Servis kredisi tek çözüm olarak düzenlenmiş olabilir. Sorumluluk sınırı bulunabilir. Kritik veya farklı türde zararlar ayrıca ele alınabilir. Somut olayda hukuki inceleme yapılması gerekir.

SLA İhlali Fesih Sebebi Olabilir mi?

Sözleşmede kritik veya kronik ihlal fesih sebebi olarak düzenlenebilir. Tekrarlama eşiği açık olmalıdır. Cure Period verilebilir. SIP uygulanabilir. Ağır ihlallerde daha hızlı fesih mekanizması kurulabilir.

Bulut Sağlayıcının Kesintisinden Yazılım Firması Sorumlu mudur?

Cevap sözleşme yapısına bağlıdır. Ana sağlayıcı bulutu kendi hizmetinin parçası olarak seçmiş olabilir. Third-party exclusion maddesi sınırları önemlidir. Yedekli mimari taahhüdü varsa sorumluluk daha geniş olabilir. Somut sözleşme birlikte incelenmelidir.

SLA Ölçümünü Kim Yapmalıdır?

Sağlayıcı, müşteri veya bağımsız sistem ölçüm yapabilir. Tek doğruluk kaynağı belirlenmesi faydalıdır. Müşterinin doğrulama hakkı olmalıdır. Formül ve monitoring lokasyonu sabitlenmelidir. Uyuşmazlık çözüm yöntemi önceden yazılmalıdır.

Ticket Beklemeye Alındığında SLA Süresi Durur mu?

Her bekleme durumu otomatik pause yaratmamalıdır. Müşteriden kritik bilgi veya erişim bekleniyorsa süre durabilir. Neden ve zaman kaydedilmelidir. Müşteri bilgilendirilmelidir. Resume işlemi audit log içinde görünmelidir.

Açık Kaynak Yazılımlar İçin SLA Yapılabilir mi?

Evet, açık kaynak kullanan hizmet için ticari SLA yapılabilir. Community projesi kendisi SLA vermeyebilir. Ticari sağlayıcı destek ve patch taahhüdü sunabilir. Kritik dependency yönetimi sözleşmede düzenlenir. Açık kaynak olması sorumluluğu otomatik ortadan kaldırmaz.

SLA Ne Sıklıkla Güncellenmelidir?

En az yıllık gözden geçirme faydalıdır. Aylık operasyonel performans ayrıca izlenmelidir. Büyük sistem değişikliği yeni değerlendirme gerektirir. Kritik ihlal sonrası maddeler gözden geçirilebilir. Versiyonlama ve onay süreci kullanılmalıdır.

Bilişim anlaşmalarında SLA (Hizmet Seviyesi Anlaşması) nasıl belirlenir?

Bilişim anlaşmalarında SLA belirlenirken önce kritik hizmet ve iş süreçleri haritalanmalıdır. Ardından availability, yanıt, müdahale, çözüm, RPO ve RTO gibi gerçekten anlamlı metrikler seçilmelidir. Her metriğin formülü, ölçüm sistemi, başlangıç noktası, pause koşulları ve istisnaları yazılmalıdır. İhlal halinde servis kredisi, SIP, kronik ihlal ve gerektiğinde fesih mekanizması belirlenebilir. İmzalanan Bilişim Anlaşmalarında Hizmet Seviyesi (SLA) Belirleme sürecinin başarılı olması için teknik ekip, hukuk, satın alma ve iş biriminin aynı beklentiler üzerinde anlaşması gerekir.

SLA sözleşmesinde hangi performans kriterleri ve KPI’lar yer almalıdır?

Kriterler hizmet türüne göre seçilmelidir. Availability, P1 yanıt süresi, teknik müdahale, çözüm hedefi, API latency, error rate ve yedekleme başarısı sık kullanılan metriklerdir. Reopen oranı, First Contact Resolution ve müşteri memnuniyeti yönetim KPI'ı olarak eklenebilir. Güvenlik hizmetlerinde tespit ve bildirim süreleri ayrıca önemli olabilir. Her metriği yaptırıma bağlamak yerine yalnız iş açısından kritik olanların sözleşmesel SLA olması daha yönetilebilir sonuç verir.

Bilişim hizmetlerinde uptime, müdahale süresi ve çözüm süresi nasıl tanımlanmalıdır?

Uptime hangi hizmet bileşeninin hangi dönem içinde kullanılabilir olduğunu açık formülle ölçmelidir. Müdahale süresi ilk ticket yanıtından farklı olarak teknik çalışmanın gerçekten başladığı an üzerinden hesaplanmalıdır. Çözüm süresinde workaround ile kalıcı çözüm ayrılmalıdır. P1–P4 olayları için farklı hedefler kullanılabilir. SLA sözleşmesinde uptime yanıt süresi ve çözüm süresi nasıl belirlenir sorusunun cevabı, bu sürelerin başlangıç ve bitiş noktalarının objektif zaman damgalarıyla tanımlanmasına dayanır.

SLA ihlalinde uygulanacak cezai şart ve hizmet kredileri nasıl belirlenir?

Hizmet kredisi genellikle etkilenen hizmetin aylık bedeli üzerinden kademeli olarak hesaplanabilir. Cezai şart daha kritik veya tekrarlayan ihlallere ayrılabilir. Aynı olayda kredi ve cezai şartın birlikte uygulanıp uygulanmayacağı açıkça yazılmalıdır. Maksimum aylık kredi oranı ve genel sorumluluk sınırı ana sözleşmeyle uyumlu olmalıdır. Bilişim sözleşmelerinde SLA ihlali cezai şart ve hizmet kredisi tasarlanırken ihlalin iş etkisi, orantılılık ve somut sözleşmenin hukuki yapısı birlikte değerlendirilmelidir.

Bilişim sözleşmelerinde SLA belirleme konusunda danışmanlık hizmeti yakınımda nerede bulunur?

Kurumsal SLA sözleşmesi hazırlama ve bilişim hukuku danışmanlığı araştırırken yalnız standart sözleşme metni sunan değil, monitoring, uptime, güvenlik, ticket yönetimi ve exit süreçlerini de anlayabilen çalışma modeline bakmak faydalıdır. Diyarbakır Yazılım Topluluğu'nun yapısı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Teknoloji ve proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects sayfası incelenebilir. Bilişim odaklı destek, yönetim ve raporlama yaklaşımları hakkında tamamlayıcı içerik olarak https://www.diyarbakiryazilim.com.tr/posts/bilisim-odakli-bolgesel-tesviklerin-yonetimi-ve-raporlanmasi adresi kullanılabilir. SLA ve bilişim sözleşmesi avukatı yakınımda şeklinde arama yapılırken somut sözleşmenin hukuki incelemesi için yetkili hukuk uzmanı desteği ayrıca değerlendirilmelidir.

Sonuç: İyi SLA Yüksek Bir Uptime Yüzdesi Değil, Ölçülebilir ve Uygulanabilir Bir Sözleşme Mekanizmasıdır

İmzalanan Bilişim Anlaşmalarında Hizmet Seviyesi (SLA) Belirleme sürecinin temel amacı mümkün olan en yüksek uptime oranını yazmak değil, tarafların gerçekten ölçebileceği ve uygulayabileceği bir hizmet yönetim sistemi kurmaktır. Hizmet kapsamı, P1–P4 seviyeleri, response ve resolution süreleri, availability formülü, planlı bakım, üçüncü taraf bağımlılıkları, RPO/RTO, güvenlik, servis kredisi, kronik ihlal ve exit mekanizması aynı bütünün parçalarıdır. İyi hazırlanmış SLA hem hizmet alanın iş sürekliliğini korur hem de sağlayıcının kontrol edemediği riskleri makul sınırlar içinde tutar. Teknik verinin sözleşmesel karşılığı açık olduğunda aylık performans görüşmeleri daha verimli, uyuşmazlıklar ise daha yönetilebilir hale gelir. Bilişim projeleri, teknik işbirlikleri ve kurumsal teknoloji içerikleri hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.