SLA Yönetimi ve Yazılım Destek Süreçleri: Kurumsal Rehber [2026]

SLA Nedir ve Neden Önemli?

SLA (Service Level Agreement), müşteri ile hizmet sağlayıcısı arasında yazılı bir anlaşmadır. "Bu yazılım, yüzde 99.9 uptime'da çalışacak. Eğer bu hedefi tutturmazsam, sana para iade edeceğim veya hizmet uzatabilirim" demek.

SLA sadece bir taahhüt değil—operasyonel disiplin sağlayan bir araçtır. İyi yazılmış bir SLA, hem müşterinin beklentilerini netleştirir, hem de ekibin neler yapması gerektiğini rehberlendirer.

Neden önemli?

Müşteri Perspektifi: Yazılım ne yapabilir bekliyorum? Ne kadar downtime kabul edilebilir? Sorun çıktığında, kaç dakika içinde destek alacağım?

Operasyon Perspektifi: Hangi göstergeleri ölçmeli? Alarm ne zaman tetiklenmelidir? Sorunlar nasıl öncekilendirilmelidir?

İş Perspektifi: Müşteri memnuniyeti, sözleşme yenileme, itibar. SLA ihlali, maddi ceza demek.

SLA olmadan, belirsizlik ve anlaşmazlık ortaya çıkar. İyi yazılmış SLA, bu kaotikliği azaltır.

SLA Bileşenleri: Neler Yer Almalı?

Etkili bir SLA, belirli öğeleri içerir:

Hizmet Tanımı

SLA'nın hangi hizmetleri kapsadığı açıklanmalı. "Yazılım", çok geniş. Daha özel olması gerekir:

• "Web uygulaması sunucuya isteklerin yüzde 99.5'i cevap alacak."
• "API, ortalama yanıt süresi 500ms'yi aşmayacak."
• "Veritabanı backup, her gün 2AM'de tamamlanacak."

Muğlak tanımlar, anlaşmazlığa yol açabilir.

Metriks ve İndikatörler

Müşteri ve hizmet sağlayıcı, hangi sayıları takip ettiğini bilmelidir. Örneğin:

• Uptime: Sistem, ne kadar süre çalışır? Yüzde 99.5 mi, 99.9 mi, 99.99 mi?
• Yanıt Süresi: İstekler ne kadar hızlı cevap aldığı?
• Yanlışsızlık: Veri doğruluğu, işlem başarı oranı.
• Veri Kaybı: Backup düzenli alınıyor mu?

Her SLA, en az bir kaç metrik belirlemeli.

Ölçüm Yöntemi

Metrikler nasıl hesaplanacak? Örneğin, uptime:

"Uptime = (Toplam Dakika - Downtime Dakika) / Toplam Dakika * 100"

Ama "Downtime" nedir? Bakım süresi sayılır mı? Müşteri hatasından kaynaklanan kesinti sayılır mı? Tanımlanmalı.

Destek Saatleri

Destek ne zaman mevcut? 9-5 mi (iş saatleri), 24/7 mi? Farklı sorun tiplerinin farklı saatleri olabilir:

• Kritik sorunlar: 24/7
• Yüksek öncelik: 9-5
• Normal: İşletim saatleri, belki öğleden sonra kapalı

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

Kritik sorun bildiriminden ne kadar hızlı bir insan yanıt vermesi gerekir? Sorun ne kadar hızlı çözülmesi gerekir?

Örneğin:

Sorun Düzeyi	Yanıt Süresi	Çözüm Süresi
P1 (Kritik)	15 dakika	4 saat
P2 (Yüksek)	1 saat	8 saat
P3 (Orta)	4 saat	24 saat
P4 (Düşük)	1 gün	1 hafta

Bu tablodaki rakamlar, işletme tarafından belirlenmelidir. Gerçekçi olması lazım.

İstisnaları

SLA'nın kapsamı dışında kalan durumlar tanımlanmalı. Örneğin:

• "Müşteri hatasından kaynaklanan downtime SLA kapsamı dışı."
• "Planlı bakım, bildirim yapılırsa SLA kapsamı dışı."
• "Müşteri tarafından istenilen özellik gecikmesi SLA kapsamı dışı."

İstisna sayısı az olmalı (yoksa SLA boş bir söz haline gelir), ama gerekli istisnalar belirtilmelidir.

Ceza ve Kredi

SLA ihlali durumunda ne olur? Yaygın seçenekler:

• Para iade (aylık ücretin %5'i ihlal durumunda)
• Ücretsiz uzatma (1 ay ücretsiz hizmet)
• Bireysel hizmet kredisi

Dikkat: Ceza, uygulanabilir olmalı. Aksi takdirde, boş bir tehdittir.

SLO ve SLI: SLA'nın Operasyonel Muadilleri

SLA, müşteriye yapılan söz. Ancak operasyon ekibinin neler yapması gerektiğini belirtmez. SLO ve SLI bu boşluğu doldurur.

SLI (Service Level Indicator): Ölçülebilir bir metrik. Örneğin, "İsteklerin yüzde kaçı 200ms'de cevap aldı? Sistem uptime neydi?"

SLO (Service Level Objective): İç hedef. Örneğin, "İsteklerin yüzde 99.5'i 200ms'de cevap almalı. Uptime hedefi yüzde 99.9 olmalı."

Dikkat: SLO, SLA'dan daha sıkı olmalı. Neden? Bağlantılar, ölçüm hataları, işletme marjı.

Örneğin, SLA yüzde 99.5 uptime taahhütü ise, SLO hedef yüzde 99.7 veya 99.8 olabilir. Böylece, SLA ihlal etmeden önce, alarm tetiklenebilir.

Destek Katmanları: Kimin Ne Yapması Gerektiği

Yazılım desteği, çoğu zaman tiered bir yapı:

L1 Destek (Birinci Kademe)

Müşteri destek, ilk teması sağlar. Telefon, email, chat.

Sorumlulukları:

• Sorun bildirimini al
• Temel sorun gider (bağlantıyı kontrol et, önyükleme yap, şifre sıfırla)
• Sorun hakkında bilgi top
• Gerekirse L2'ye eskalasyon yap

Yeterlilik: Geniş ama sığ. Birkaç satırlık script'ler, sık sorulan cevaplar.

Örnek: Müşteri, "Şifremi unuttum" derse, L1 sıfırlar.

L2 Destek (İkinci Kademe)

Teknik uzmanlar. L1'in eskalasyon ettiği sorunları çözerler.

Sorumlulukları:

• L1'in çözemediği sorunları araştırma
• Loglar, metrikler analiz
• Geçici çözüm (workaround) sunma
• Gerekirse L3'e eskalasyon yap
• Sorun hakkında belgeleme

Yeterlilik: Sistem mimarisi, kod, veri tabanı hakkında bilgi.

Örnek: Müşteri, "Sistem yavaş, nasıl çözeceğiz?" derse, L2 performans analizi yapıp, optimizasyon önerir.

L3 Destek (Üçüncü Kademe)

Yazılım geliştirme ekibi veya sistem mimarları.

Sorumlulukları:

• L2'nin çözemediği sorunlar
• Hata düzeltme, kod değişikliği
• Mimari sorunlar
• Yeni özellik istekleri

Yeterlilik: Yazılım tasarımı, geliştirme.

Örnek: Yazılım hatası varsa, L3 kodu düzeltir.

Tipik bir sorunun yolculuğu: L1 -> L2 -> L3 -> Geri çözüm -> L2 -> L1 -> Müşteri.

Eskalasyon Prosedürleri

Sorunlar, her zaman alt katmanda çözülemez. Eskalasyon, sorunun doğru yerde çözülmesini sağlar.

Etkili eskalasyon prosedürü:

Zaman Bazlı: L1, 30 dakika çözemediyse L2'ye eskalasyon yap. L2, 2 saat çözemediyse L3'e.

Ciddiyet Bazlı: P1 (kritik) sorunlar, anında L3'e gidebilir. P4 (düşük) sorunlar, L1 ile başlayabilir.

Sorun Türü Bazlı: Performans sorunları direkt L2'ye. Veri hata sorunları direkt L3'e.

Eskalasyon kuralları, açıkça tanımlanmalı. "Belirsiz olduğunda eskalasyon yap" yöntemi, L1 kaç medeniyetçi yapabilir.

Sorun Sınıflandırması: Hangi Sorun Ne Kadar Önemli?

Her sorun eşit acil değildir. Sorun sınıflandırması (prioritization), kaynakları doğru yere yönlendirir.

Yaygın sınıflandırma:

P1 - Kritik

Yazılım tamamen çalışmıyor veya kritik özellik tamamen engellendi. Müşteri, hiçbir iş yapamıyor.

• Downtime 30+ dakika
• Veri kaybı tehlikesi
• Tüm ağ etkilenir

Yanıt Süresi: 15 dakika
Çözüm Süresi: 4 saat

P2 - Yüksek

Önemli özellik etkilenir ama workaround var veya kısmen çalışıyor.

• Performans ciddi şekilde düşmüş
• Çoğu kullanıcı etkilenir
• İş akışı aksabilir

Yanıt Süresi: 1 saat
Çözüm Süresi: 8 saat

P3 - Orta

Belirli bir özellik etkilenir. Workaround kolay.

• Sorunun etki alanı sınırlı
• Azınlık kullanıcı etkilenir
• Temel işler yürüyebiliyor

Yanıt Süresi: 4 saat
Çözüm Süresi: 24 saat

P4 - Düşük

Küçük sorunlar, kullanıcı rahatsızlığı, doc hatası.

• Minör UI sorunu
• Belgeleme hatası
• İstek veya iyileştirme

Yanıt Süresi: 1 gün
Çözüm Süresi: 1 hafta

Sınıflandırma süreci, standartlaştırılmalı. "Ne düşünüyorsanız" yaklaşımı, tutarsızlığa yol açabilir.

SLA Raporlama ve Dashboard

SLA'nın değeri ölçme ve raporlamada yatar. Aylık rapor, hem müşteriye hem de yönetimine sunulmalı.

Raporun içeriği:

• Toplam uptime yüzde
• Ortalama yanıt süresi
• SLA ihlal saatleri, sebebi
• İyileştirme trendleri
• Müşteri memnuniyet puanı

Dashboard, gerçek zamanlı metrikleri göstermelidir. Müşteri, SLA durumunu güncel olarak görebilmeli.

SLA Başarısızlığı Taşımak

SLA ihlali olmuş. Sonra ne?

İletişim: Müşteriye, hemen bildir. Sorun ne, çalışıyorlar, tahmini çözüm süresi.

Köksel Analiz: Neden oldu? Bir kez hata mıdır, sistem problemi mi?

Telafi: Ceza ödemek, hizmet uzatmak, ekstra hizmet sunmak.

Prevantif Yapı: Tekrarlamamasını sağlamak için ne değiştirdi?

SLA ihlali, başarısızlık değil—öğrenme fırsatıdır. Nasıl gerçektir, iyileştirilir?

Best Practices: İyi Bir SLA Yazma

Öğrenilen derslerden, best practice'ler:

1. Gerçekçi Olun: Yüzde 99.99 uptime taahhüt etme, eğer mimariniz bunu desteklemiyorsa. Başarısız, itibarsızlık oluşturur.

2. Açık Olun: Muğlaklık, anlaşmazlığa yol açar. Her terim tanımlanmalı.

3. Ölçülebilir Olun: "Hızlı çalışacak" vs "Yanıt süresi 500ms'yi aşmayacak". İkinci measurable.

4. Müşteri ile Müzakere Edin: SLA, tek taraflı empoze edilemez. Müşterinin ihtiyaçları, işletmenin kapasite ile balance.

5. Hafif Başlayın: Zamanla, operasyon kabiliyeti arttıkça, SLA sıkılaştırılabilir.

6. Düzenli Gözden Geçirin: SLA, değişmez değil. Teknoloji, işletme ihtiyaçları değişirse, SLA revize edilmelidir.

SLA Başarısızlığı Geri Dönüşü: Müşteri Tutma

SLA ihlali, müşteri kaybının öncüsüdür. Ama doğru yapılırsa, ilişki pekişebilir.

SLA ihlali oluştuğunda:

1. Hızlı Bildirim: Müşteriye, 1 saat içinde, resmi bildirim gönder.
2. Gerçek Zamanlı Güncelleme: Her saatte, ilerleme güncellemesi.
3. Üstün Destek: O müşteriye, ekstra kaynaklar ayır.
4. Telafi: SLA'ya göre, kredi veya ücret indirimi.
5. Köksel Analiz: Neden oldu? Tekrarlanmasını nasıl engellersiniz?
6. Sonuç Paylaşımı: Müşteriye, neler değiştiğini anlat. Müşteri, sistem iyileştiğini görür.

SLA ihlalini doğru yönetirsek, müşteri bağlılığı artış gösterebilir. "Sorun oldu, ama hemen çözdüler, iyileştirdiler" pozitif izlenim yaratır.

Üçüncü Taraf SLA'lar: Dış Hizmetlerin Yönetimi

Kurumlar, bulut, API, database gibi dış hizmetlere bağlı. Bu hizmetler, kendi SLA'ları var.

Örnek: AWS uptime taahhütü yüzde 99.99. Ama müşteriye yüzde 99.9 söylediyseniz?

Bu gap'ı yönetmek lazım:

• Dış hizmet SLA'sını anla
• Müşteriye, gerçekçi bir taahhüt ver (daha düşük olabilir)
• Dış hizmet başarısız olursa, SLA kriterlerine gir (durumun özel koşulsa, SLA kapsamı dışı)

Sonuç: SLA, Ortak Dil

SLA, teknik bir dokument değil—müşteri ve işletme tarafı arasında ortak dil sağlar. "Beklentiler nedir? Yapabileceğimiz nedir? Başarısızlık nasıl yönetilir?"

Etkili SLA, yönetim, müşteri memnuniyetini artırır ve operasyonel disiplin sağlar.

Daha geniş bağlam için, Kurumsal Yazılım Bakım ve Modernizasyon rehberimizi okuyun. Yazılım Performans İzleme, SLA hedeflerinizi karşılamanıza yardımcı olan teknik altyapıyı açıklar.

SLA yapılandırma ve yönetimi hakkında destek istiyorsanız, Smart Maple danışmanları yardımcı olabilir. Müşteri ihtiyaçlarınız ve operasyonel kapasitenize uygun SLA'lar oluşturmamıza yardımcı olabiliriz. Ziyaret edin smart-maple.com adresini daha fazla bilgi için.