Hizmet Seviyesi Sözleşmesi (SLA) Nedir?
Hizmet seviyesi sözleşmesi (Service Level Agreement — SLA), bir hizmet sağlayıcı ile hizmet alan taraf arasında sunulacak hizmetin kapsamını, kalite standartlarını, ölçüm yöntemlerini, sorumlulukları ve ihlal durumunda uygulanacak yaptırımları tanımlayan resmi belgedir.
IT bağlamında hizmet seviyesi sözleşmesi, IT ekibinin kullanıcılara ya da iş birimlerine ne kadar sürede yanıt vereceğini, hangi hizmet kesintisini tolere edebileceğini ve sorun yaşandığında hangi adımların izleneceğini yazılı ve ölçülebilir biçimde taahhüt ettiği dokümandır.
SLA bir güven belgesidir — hem hizmet alan tarafı korur hem de hizmet veren tarafın ne taahhüt ettiğini netleştirir.
👉 Kurumsal IT’de SLA yönetimini derinlemesine anlamak için:
IT’de SLA Yönetimi: Departman & Marka Bazlı Hedefler Nasıl Kurulur?
SLA, OLA ve UC: Hangi Sözleşme Ne Zaman Kullanılır?
Bu üç kavram sıkça karıştırılır. Kurumsal IT’de doğru yapıyı kurabilmek için aralarındaki farkı bilmek şarttır.
| Tür | Açılımı | Taraflar | Ne Tanımlar? | Ne Zaman Kullanılır? |
|---|---|---|---|---|
| SLA | Service Level Agreement | IT ekibi ↔ Son kullanıcı / iş birimi | Kullanıcıya verilen dışa dönük hizmet taahhüdü | IT'nin kullanıcıya karşı taahhüdünü belgelemek için |
| OLA | Operational Level Agreement | IT ekibi ↔ İç destek ekipleri | SLA'yı destekleyen iç operasyon taahhütleri | Ağ, güvenlik, sunucu ekipleri arası iç koordinasyon için |
| UC | Underpinning Contract | IT ekibi ↔ Dış tedarikçi | Dış hizmet sağlayıcıdan alınan destek taahhüdü | Cloud sağlayıcı, donanım servisi veya outsource için |
Örnek zincir: Kullanıcı sunucu erişim sorunu bildirdi. IT ekibinin kullanıcıya taahhüdü SLA; ağ ekibinin IT’ye destek süresi OLA; veri merkezi sağlayıcısının IT’ye taahhüdü UC. Üçü birbirine bağlıdır — UC ve OLA sağlam değilse SLA ihlali kaçınılmaz olur.
Etkili Bir Hizmet Seviyesi Sözleşmesinde Bulunması Gereken 6 Bileşen
Her hizmet seviyesi sözleşmesi aşağıdaki altı unsuru içermek zorundadır. Bunlardan biri eksik olduğunda sözleşme kağıt üzerinde kalır, operasyonda karışıklık çözülmez.
Hizmet Kapsamı
Hangi hizmetlerin SLA kapsamında olduğu, hangi saatlerde geçerli olduğu ve istisnaların neler olduğu açıkça tanımlanır.
Performans Metrikleri
Yanıt süresi, çözüm süresi, kullanılabilirlik oranı gibi ölçülebilir hedefler sayısal olarak belirtilir. "Hızlı yanıt" belirsizdir, "30 dakika içinde" ölçülebilir.
Sorumluluklar
Hizmet sağlayıcının ve hizmet alanın karşılıklı yükümlülükleri tanımlanır. Kullanıcının doğru bilgi vermesi de SLA'nın bir parçasıdır.
Eskalasyon Prosedürü
Süre aşımında ya da çözümsüz kalan taleplerde kimle iletişime geçileceği, hangi sırayla üst seviyeye taşınacağı adım adım belirlenir.
İzleme ve Raporlama
SLA performansının nasıl ve ne sıklıkla raporlanacağı belirlenir. Raporlama yoksa ihlal de görünmez, iyileştirme de yapılamaz.
Yaptırım ve Revizyon
SLA ihlali durumunda ne olacağı (hizmet kredisi, eskalasyon, tazminat) ve sözleşmenin hangi dönemde gözden geçirileceği tanımlanır.
SLA ile SLO Farkı: Neden İkisi Birlikte Kullanılmalı?
Bu ayrım Türkçe içeriklerde neredeyse hiç ele alınmıyor — ama kurumsal IT için kritik bir kavramdır.
SLA (Service Level Agreement) — dışa dönük, bağlayıcı sözleşme. Kullanıcıya veya müşteriye verilen taahhüt. İhlal edilirse yaptırım sonucu doğurur.
SLO (Service Level Objective) — içe dönük, teknik hedef. IT ekibinin SLA’yı tutturabilmek için kendine koyduğu iç hedeftir. SLA hedefinden genellikle daha sıkı tutulur.
Örnek: Kullanıcıya verilen SLA yanıt süresi 2 saattir. IT ekibinin iç SLO’su 1 saattir. Bu tampon sayesinde beklenmedik gecikmeler yaşansa bile SLA ihlali önlenir.
SLO olmadan çalışan ekipler SLA sınırına kadar çalışır — ve küçük bir aksaklıkta ihlal kaçınılmaz olur.
📉 SLA’ların %80’i Neden Başarısız Oluyor? (Ve Sizinki Nasıl Düzeltilir?)
5 Adımda Kurumsal IT için Hizmet Seviyesi Sözleşmesi Oluşturma
Hizmet Envanteri Çıkarın
IT ekibinin sunduğu tüm hizmetleri kategorize edin: altyapı hizmetleri, uygulama desteği, güvenlik, ağ, kullanıcı destek masası. Her kategorinin kritiklik düzeyi farklıdır — envanter olmadan gerçekçi hedef konamaz.
İş Birimlerinin Beklentilerini Toplayın
Hizmet seviyesi sözleşmesi yalnızca IT'nin değil, iş biriminin ihtiyacını yansıtmalıdır. Her departman için "bu hizmet ne kadar süre aksarsa operasyonunuz durur?" sorusunu yanıtlayın. Üretim, finans ve İK'nın tolerans seviyeleri birbirinden farklıdır.
Öncelik Matrisini ve Metrikleri Tanımlayın
Etki ve aciliyet kombinasyonuna göre P1-P4 öncelik seviyeleri belirlenir. Her seviye için yanıt süresi, çözüm süresi ve kullanılabilirlik hedefi ayrı ayrı tanımlanır. SLO tamponları da bu adımda eklenir.
Eskalasyon Zincirini Kurun
SLA ihlali gerçekleşmeden kaç dakika önce kim uyarılır? İhlal gerçekleşince ilk, ikinci ve üçüncü seviye kime taşınır? Bu zincir yazılı ve isimlere değil rollere bağlı olmalıdır — kişi değişince zincir çökmemelidir.
Onaylayın, Platforma Taşıyın ve Periyodik Gözden Geçirin
Hizmet seviyesi sözleşmesi iş birimi yöneticileri tarafından onaylanmalı ve IT platformuna işlenmelidir. Kağıtta kalan SLA değersizdir. Ayrıca en az yılda bir gözden geçirilmeli — operasyon değiştikçe sözleşme de güncellenmelidir.
SLA Türleri: Kurumsal IT'de Hangi Model Kullanılmalı?
Tüm organizasyonlar aynı SLA modeliyle çalışmaz. Doğru modeli seçmek operasyonu basitleştirir.
Hizmet Bazlı SLA: Aynı hizmet tüm kullanıcılara aynı koşullarla sunulur. Basit ve yönetilmesi kolaydır. Ancak farklı departmanların farklı kritiklik düzeylerini görmezden gelir.
Müşteri/Departman Bazlı SLA: Her iş birimi veya müşteri için ayrı koşullar tanımlanır. Üretim hattı için P1 yanıt süresi 15 dakika, İK departmanı için 2 saattir. Gerçekçi ve adil — ama yönetim karmaşıklığı artar.
Çok Düzeyli (Multi-Level) SLA: En olgun modeldir. Kurumsal düzeyde genel politika, departman düzeyinde özelleştirilmiş hedefler ve hizmet düzeyinde teknik taahhütler iç içe çalışır. Birden fazla marka ya da şirket yöneten IT ekipleri için zorunlu yapıdır.
Kurumsal Use Case: Çok Lokasyonlu Üretim Grubu
500 kullanıcısı olan, 3 farklı üretim tesisinde çalışan bir grubu düşünün. Tek bir hizmet seviyesi sözleşmesi tüm organizasyona uygulanıyor — fabrika hattı arızası ile muhasebe yazıcısı arızası aynı öncelik kuyruğuna giriyor.
Sonuç: Kritik üretim duruşları ortalama 4 saat bekliyor, SLA teknik olarak ihlal edilmiyor çünkü hedef zaten herkese eşit olarak 8 saat tanımlanmış.
Multi-level hizmet seviyesi sözleşmesi yapısına geçildiğinde: fabrika hattı arızası P1 tanımlandı, 15 dakika FRT, 2 saat çözüm hedefi konuldu. Muhasebe yazıcısı P4 kaldı, 1 gün çözüm hedefiyle. Kritik üretim duruşu çözüm süresi 4 saatten 90 dakikaya indi.
Hizmet Seviyesi Sözleşmesini Platforma Taşımak
Yazılı bir hizmet seviyesi sözleşmesi operasyonun yarısıdır. İkinci yarısı, o sözleşmenin ITSM platformuna işlenmesidir.
Doğru yapılandırılmış bir ITSM platformunda, hizmet seviyesi sözleşmesindeki her kural otomatik çalışır: ticket açıldığı anda hangi SLA kuralının uygulanacağı otomatik belirlenir, geri sayım başlar, süre dolmadan ilgili kişilere bildirim gider, eskalasyon zinciri devreye girer. IT yöneticisi SLA ihlal raporunu haftalık otomatik alır — manuel takip olmadan.
Cheetah Low-Code Development Platform üzerinde departman ve marka bazlı hizmet seviyesi sözleşmeleri ayrı ayrı kurgulanır; öncelik matrisi otomatik çalışır; eskalasyon zincirleri rol bazlı tanımlanır. Hizmet seviyesi sözleşmesinin kağıttan platforma taşınması için bizimle iletişime geçin!
