SLA Yönetimi Nedir?
IT’de SLA yönetimi (Service Level Agreement Yönetimi), IT ekibinin kullanıcılarına veya iş birimlerine verdiği hizmet taahhütlerini — yanıt süresi, çözüm süresi ve kullanılabilirlik oranı — tanımlama, izleme, ihlalleri önleme ve sürekli iyileştirme sürecinin tamamıdır.
Kısaca: kime, ne kadar sürede, hangi kalitede hizmet vereceğinizin yazılı ve ölçülebilir taahhüdüdür.
Çoğu IT ekibi SLA’nın ne olduğunu bilir. Ama departmana veya markaya göre nasıl farklılaştırılacağını, ihlallerin gerçek nedenlerini ve SLA ötesinde hangi KPI’ların izlenmesi gerektiğini bilmez. Bu rehber tam olarak bu boşluğu dolduruyor.
SLA'nın 3 Boyutu — Herkes "Ne" Bilir, "Nasıl Kurulur" Bilmez
Bir SLA tanımı üç temel bileşenden oluşur. Bu üçü doğru kurulmadan hiçbir servis level performansı ve yönetimi sağlıklı çalışmaz.
Yanıt Süresi (First Response Time — FRT)
Kullanıcı talebi açtıktan sonra IT ekibinin ilk kez iletişime geçtiği süredir. Yanıt süresi çözümü değil, “talebinizi aldık, bakıyoruz” mesajını kapsar.
Kritik hata: pek çok kurum yanıt süresini çözüm süresiyle karıştırır. Birisi “sizi duyduk” der, diğeri “sorununuzu çözdük” der. Bu ikisinin ayrı SLA hedefleri olması şarttır.
Çözüm Süresi (Resolution Time)
Talebin tamamen kapatıldığı süreye kadar geçen toplam süredir. Ticket kategorisine, önceliğe ve departmana göre bu süre dramatik biçimde değişmelidir.
Kullanılabilirlik (Availability %)
Bir sistem veya hizmetin belirli bir dönem içinde erişilebilir olduğu süredir. Kritik üretim sistemleri için %99,9 olan bir hedef, ofis intranet portalı için %95 olabilir. Hepsine aynı kullanılabilirlik hedefi koymak hem kaynak israfıdır hem de yanlış önceliklendirmeye yol açar.
Kendi Marka Bazlı SLA Yapınızı Kuralım!
Birden fazla marka veya departmanınız için ayrı SLA hedefleri kurmak, eskalasyon mekanizması eklemek veya MTTR ve yük dengesi raporlamasını devreye almak istiyorsanız, sürecinizi birlikte analiz edelim.
Bizimle İletişime Geçin!Neden Tek SLA Herkese Uymuyor?
Fabrika Hattı Durması ≠ Ofis Yazıcısı Arızası
Bu soruyu sormak garip görünüyor — ama pek çok IT ekibi hâlâ bu iki talebi aynı SLA kuralıyla işliyor.
Fabrika üretim hattının durması, her dakika doğrudan finansal kayba ve müşteriye gecikme taahhüdüne dönüşür. Ofis yazıcısının arızası ise çalışanı rahatsız eder ama operasyonu durdurmaz. Aynı yanıt ve çözüm süresini bu iki talebe uygulamak; ya üretim kaybı ya da gereksiz yere hızlandırılmış basit talepler anlamına gelir.
Marka A ve Marka B: Farklı Kritiklik, Farklı SLA
Birden fazla marka veya iş birimi yöneten organizasyonlarda IT’de SLA yönetimi daha karmaşık bir boyut kazanır.
Marka A kritik üretim hattı yönetiyorsa; P1 (kritik) talep için yanıt süresi 15 dakika, çözüm süresi 2 saat olabilir. Marka B standart ofis operasyonu yürütüyorsa; aynı öncelik seviyesi için yanıt süresi 1 saat, çözüm süresi 8 saat makul olabilir.
Bu ayrımı kurmak için ihtiyaç duyulan araç: Etki-Aciliyet Matrisi.
Etki-Aciliyet Matrisi: Otomatik Önceliklendirme
P2 — Yüksek
FRT: 30dk
Çözüm: 4s
P1 — Kritik
FRT: 15dk
Çözüm: 2s
P1 — Kritik
FRT: 15dk
Çözüm: 2s
P3 — Normal
FRT: 2s
Çözüm: 1gün
P2 — Yüksek
FRT: 30dk
Çözüm: 4s
P2 — Yüksek
FRT: 30dk
Çözüm: 4s
P4 — Düşük
FRT: 1gün
Çözüm: 3gün
P4 — Düşük
FRT: 1gün
Çözüm: 3gün
P3 — Normal
FRT: 2s
Çözüm: 1gün
SLA İhlalinin 5 Yaygın Nedeni
Manuel takip → Gözden kaçan süreler
Ticket'lar spreadsheet veya e-postayla izlendiğinde hangi talebin ne zaman süresi doldu takip edilemez. İhlal fark edildiğinde çok geçtir.
Eskalasyon kuralı tanımlı değil
SLA süresi dolmak üzere ama kimse haberdar değil. Üst seviyeye taşınma kuralı yoksa talep olduğu yerde bekler.
Bildirim mekanizması yok
Teknisyen talebi görüyor ama önceliklendirmiyor. Kullanıcı da ne zaman yanıt alacağını bilmiyor. İki taraf da karanlıkta.
Tek SLA her şeye uygulanıyor
Fabrika hattı duruşu ile yazıcı kağıdı bitmesi aynı öncelik kuyruğuna giriyor. Kritik talep basit taleple aynı sırayı bekliyor.
Raporlama eksik → İhlaller görünmez
Kaç ticket SLA'yı aştı? Hangi departman en çok ihlale uğrıyor? Hangi teknisyen en çok gecikiyor? Bu sorulara cevap yoksa iyileştirme de yok.
SLA Ötesinde KPI Takibi
SLA bir taban çizer. Ama gerçek IT servis kalitesini ölçmek için SLA uyum oranının ötesine geçmek gerekir.
| KPI | Ne Ölçer? | Neden SLA'dan Fazlası? | İyi Değer |
|---|---|---|---|
| MTTR | Ortalama çözüm süresi | SLA uyumu "süre dolmadan kapattık" der. MTTR gerçek ortalamayı gösterir — 2 saatlik SLA'yı 1h58'de kapatan ekip tehlike sinyali veriyor olabilir. | Sektöre göre değişir; trend önemli |
| FRT | İlk yanıt süresi ortalaması | SLA tanımı maksimum süreyi verir. FRT ortalaması asıl deneyimi yansıtır — maksimuma yakın çalışmak risk demek. | SLA hedefinin %60'ı altında |
| CSAT | Kullanıcı memnuniyeti skoru | SLA karşılanabilir ama kullanıcı deneyimi kötü olabilir. CSAT bu açığı kapatır; teknik uyum ile algılanan kalite arasındaki farkı gösterir. | %85 ve üzeri |
| Yük Dengesi | Teknisyen başına açık ticket | Bir teknisyen 40 ticket taşırken diğeri 8 taşıyorsa SLA tutsa da sistem çöküyor demektir. Yük dengesi ihlalleri önceden önler. | Teknisyenler arası %20'den az sapma |
Ekip Yük Dengesi Raporu: Görünmez Darboğazı Bulmak
SLA ihlallerinin büyük bölümü teknik yetersizlikten değil, dengesiz iş yükünden kaynaklanır. Bir IT ekibinde en tecrübeli teknisyenin üzerine talepler yığılırken diğerleri kapasitelerinin altında çalışır.
Ekip yük dengesi raporu şu soruları yanıtlar:
- Kimin üzerinde kaç açık ticket var?
- Hangi teknisyen hangi kategoride en fazla gecikiyor?
- Belirli bir departmanın talepleri sistematik olarak aynı kişiye mi düşüyor?
Bu görünürlük olmadan yöneticiler körü körüne SLA hedefleri koyar — ama neden ihlal edildiğini asla anlayamaz.
SLA Tanımı Yaparken Sık Yapılan 3 Stratejik Hata
Hata 1 — SLA’yı teknoloji ekibinin tek başına belirlemesi: SLA bir iş taahhüdüdür, sadece teknik bir parametre değil. İş birimi yöneticilerinin ne kadarlık bir kesinti tolere edebileceklerini, hangi hizmetin onlar için kritik olduğunu söylemesi gerekir.
Hata 2 — Gerçekçi olmayan hedefler: “Her şeye 30 dakikada yanıt” yazmak kolay, uygulamak zor. Karşılanamayan SLA, karşılanmış ama geniş tutulan SLA’dan daha kötüdür. Güven aşınır.
Hata 3 — SLA’yı kurup unutmak: Operasyon değişir, ekip büyür, talep profili değişir. SLA’lar en az yılda bir gözden geçirilmeli ve güncellenmeli.
SLA’ların %80’i Neden Başarısız Oluyor? (Ve Sizinki Nasıl Düzeltilir?)
IT'de SLA Yönetimini Platforma Taşımak
Departman ve marka bazında farklı SLA hedefleri tanımlamak, bunu manuel takip etmek anlamına gelirse operasyonu yavaşlatır.
Doğru yapılandırılmış bir ITSM platformunda IT’de SLA yönetimi şöyle çalışır:
- Ticket açıldığı an hangi marka, hangi departman, hangi kategori olduğuna göre SLA kuralı otomatik uygulanır.
- Geri sayım başlar.
- Süre dolmadan belirli bir eşikte teknisyene, bir sonraki eşikte yöneticiye bildirim gider.
- İhlal gerçekleşirse eskalasyon otomatik tetiklenir.
Cheetah Platform’da marka ve departman bazlı SLA tanımları ayrı ayrı kurgulanır; etki-aciliyet matrisine göre öncelik otomatik atanır. Yük dengesi raporu ve gerçek zamanlı SLA dashboard üzerinden MTTR, FRT ve CSAT ekip bazında izlenebilir.
Sonuç + CTA
IT’de SLA yönetimi, “ne kadar sürede yanıt verelim” sorusundan çok daha büyük bir disiplindir. Doğru kurulduğunda şunları sağlar:
- Kritik talepler önce çözülür, basit talepler bekler — otomatik
- İhlaller olmadan önce önlenir — eskalasyon mekanizmasıyla
- Ekip yükü görünür hale gelir — darboğaz insana değil sisteme bağlanır
- Marka ve departman bazında farklı taahhütler tek platformdan yönetilir
