Bir sistem çöktüğünde ya da saldırı başladığında en kritik soru "ne zaman müdahale edilecek?" olur. SLA bu belirsizliği ortadan kaldırır; ilk yanıt, çözüm hedefi ve eskalasyonu önceden netleştirir.
Bir sorun başladığında en kritik soru: ne zaman müdahale edilecek?
Bir sistem çöktüğünde, bir servis durduğunda ya da aktif bir siber saldırı başladığında akla gelen ilk soru hep aynıdır: bu olaya ne zaman müdahale edilecek? Bu sorunun cevabı belirsizse, teknik bir aksaklık kısa sürede operasyonel bir krize dönüşebilir. Çalışanlar sisteme erişemez, müşteri hizmetleri aksar, üretim durur, veriye ulaşım kesilir ve yönetim tarafında "kim ilgileniyor?" sorusu giderek büyür.
SLA, yani Servis Seviyesi Anlaşması, tam da bu belirsizliği ortadan kaldırmak için vardır. Hangi olayın ne kadar kritik olduğu, ilk yanıtın ne zaman verileceği, çözüm hedefinin ne olduğu ve hangi durumda eskalasyon yapılacağı önceden tanımlanır. 113SEC için SLA bir satış cümlesi değil; destek, SOC, ticket, eskalasyon ve aylık raporlama süreçlerinin temel ölçüm noktasıdır.
SLA tam olarak ne anlama gelir?
SLA, "Service Level Agreement" ifadesinin kısaltmasıdır; Türkçede servis seviyesi anlaşması ya da servis seviyesi taahhüdü olarak kullanılır. Sade bir tanımla SLA, hizmet sağlayıcının bir talebe ne kadar sürede yanıt vereceğini, ne kadar sürede çözüm hedefleyeceğini ve bu süreci nasıl takip edeceğini belirleyen çerçevedir.
Burada kritik nokta, her olayın aynı önemde olmamasıdır. Bir kullanıcının yazıcı kurulum desteği istemesi düşük öncelikli olabilir. Ancak üretim sunucusu çökmüşse ya da fidye yazılımı şüphesi varsa, bu kritik bir olaydır ve çok daha kısa bir SLA süresiyle ele alınmalıdır. Bu ayrım yapılmadığında destek ekipleri doğru önceliklendirme yapamaz ve gerçekten kritik bir olay, sıradan talepler arasında gecikebilir.
İlk müdahale süresi neden bu kadar önemli?
Kritik olaylarda her dakika değerlidir. Özellikle siber güvenlik tarafında geç fark edilen ya da geç müdahale edilen olaylar çok daha büyük hasara yol açabilir. Başarısız giriş denemeleri, şüpheli veri hareketleri, bir EDR alarmı, başarısız bir yedekleme veya servis kesintisi ilk anda küçük bir uyarı gibi görünebilir. Doğru önceliklendirilmezse aynı uyarı kısa sürede büyük bir olaya dönüşebilir.
İlk müdahale süresi, sorunun anında çözüleceği anlamına gelmez. Ancak uzman ekibin olayı gördüğünü, sınıflandırdığını, etkisini değerlendirdiğini ve aksiyon almaya başladığını gösterir. Bu yüzden SLA'da iki kavram birlikte düşünülür: ilk yanıt süresi ekibin olaya müdahaleye başladığı andır; çözüm hedefi ise olayın kabul edilebilir bir süre içinde kapatılması için belirlenen hedeftir.
113SEC öncelik seviyeleri: P1, P2, P3, P4
113SEC süreçlerinde destek talepleri, olayın iş üzerindeki etkisine göre dört seviyeye ayrılır. Bu sınıflandırma, hangi olaya önce müdahale edileceğini herkes için net hale getirir.
P1 — Kritik
Üretim sisteminin tamamen durduğu ya da aktif saldırı şüphesinin olduğu durumlardır: fidye yazılımı belirtisi, merkezi sunuculara erişim kaybı, kritik servislerin tamamen çökmesi veya aktif ihlal alarmı. Bu seviyede ilk yanıt hedefi 1 saat, çözüm hedefi 4 saattir ve P1 olaylar 7/24 kapsamda değerlendirilir.
P2 — Yüksek
Kritik bir servisin kısmen çalışmadığı, yedeklemenin başarısız olduğu veya önemli bir iş sürecinin etkilendiği olaylardır. Sistem tamamen durmamış olabilir ama iş sürekliliği açısından ciddi bir risk vardır. İlk yanıt hedefi 4 saat, çözüm hedefi 8 saattir.
P3 — Orta
Performans sorunu, alarm eşiğinin aşılması ya da genel hata mesajları gibi orta öncelikli durumlardır. Operasyonu tamamen durdurmazlar, ancak takip edilmezse daha büyük bir probleme dönüşebilirler. İlk yanıt hedefi 8 iş saati, çözüm hedefi 2 iş günüdür.
P4 — Düşük
Bilgi talebi, küçük bir iyileştirme, raporlama ya da standart konfigürasyon değişikliği gibi düşük öncelikli işlerdir. İlk yanıt hedefi 2 iş günü, çözüm hedefi 5 iş günüdür.
SLA yalnızca süre değil, süreçtir
SLA çoğu zaman tek bir soruyla değerlendirilir: "Kaç saatte dönersiniz?" Oysa iyi kurgulanmış bir SLA yalnızca sürelerden ibaret değildir; sürecin tamamını kapsar. 113SEC destek akışında sorun fark edildiğinde e-posta, portal ya da telefon üzerinden bir destek talebi açılır. Talep otomatik olarak ticket sistemine düşer; ardından öncelik belirlenir, uzman atanır, SLA saati başlar, gerekirse uzaktan müdahale yapılır, çözüm doğrulanır ve ticket kapatılır.
Bu yapı sayesinde hem müşteri hem de teknik ekip aynı süreci takip eder. "Kime yazmıştık?", "Kim bakıyor?", "Ne zaman dönüş yapılacak?" gibi sorular havada kalmaz. Bu disiplinin nasıl bir teknik altyapıya dayandığını teknoloji yaklaşımımız sayfasında inceleyebilirsiniz.
Ticket sistemi SLA için neden şarttır?
SLA'nın ölçülebilmesi için taleplerin kayıt altına alınması gerekir; bu yüzden ticket sistemi kritik bir rol oynar. Telefonda konuşulan ama ticket'a yazılmayan bir iş takip edilemez. E-posta ile gelen ama öncelik verilmeyen bir talep SLA raporuna yansımaz. Sözlü iletilen talepler ise unutulabilir ya da yanlış anlaşılabilir.
113SEC tarafında müşteri talepleri, alarm eskalasyonları, SLA takibi, self-servis portalı ve otomatik bildirimler bir ticket sistemi üzerinden yönetilir. Her işin ticket olarak açılıp kapanması, hizmet kalitesini ölçülebilir hale getirir.
Eskalasyon zinciri neden önemli?
Her olay aynı uzmanlık seviyesinde çözülmez. Bazı olaylar ilk seviye SOC analisti tarafından hızlıca değerlendirilebilirken, bazıları kıdemli mühendis ya da mimari/yönetim kararı gerektirir. Bu yüzden eskalasyon zinciri SLA'nın ayrılmaz bir parçasıdır.
- L1 SOC analisti ilk müdahaleyi yapar ve olayı sınıflandırır.
- L2 kıdemli mühendis gerektiğinde teknik eskalasyonu devralır.
- L3 mimari/yönetim seviyesi kritik karar gereken durumlarda devreye girer.
Bu yapı sayesinde olay büyümeden doğru kişiye ulaşır. Özellikle P1 olaylarda müşteri bilgilendirmesi anlık yapılır; P2 ve P3 olaylarda belirli aralıklarla durum güncellemesi verilir.
SLA raporlama neyi gösterir?
SLA, sözleşmede yazan bir taahhüt olarak kalmamalı; düzenli raporlanmalıdır. Aylık SLA raporları uptime, ticket çözüm süreleri, SLA uyum oranı, geciken talepler, kök neden analizleri ve iyileştirme aksiyonlarını gösterir. Bu raporlar teknik ekibe operasyonel kaliteyi, yönetime ise hizmet performansını görünür kılar. 113SEC operasyon takviminde aylık SLA performans raporu sabit bir adımdır.
KOBİ'ler için SLA neden daha da kritik?
KOBİ'lerde teknik ekip genellikle sınırlıdır. Aynı kişi hem sunucu, hem ağ, hem kullanıcı desteği, hem güvenlik hem de yedekleme ile ilgilenmek zorunda kalabilir. Böyle bir tabloda kritik olaylara zamanında müdahale etmek giderek zorlaşır.
Yönetilen hizmet modeli bu yükü hafifletir: müşteri kendi işine odaklanırken izleme, alarm, destek, eskalasyon ve raporlama dışarıdan uzman bir ekip tarafından yürütülür. SLA burada güven ilişkisini somutlaştırır. Hizmet sağlayıcının "hızlı döneriz" demesi yetmez; hangi öncelikte ne kadar sürede yanıt vereceğini açıkça taahhüt etmesi gerekir. Bu taahhüdün arkasındaki çalışma disiplinini çalışma ilkelerimiz sayfasında bulabilirsiniz.
Sonuç: SLA, güvenin ölçülebilir halidir
SLA; destek kalitesini, müdahale hızını ve operasyonel disiplini ölçülebilir kılar. Özellikle kritik olaylarda ilk müdahale süresi, iş sürekliliği açısından belirleyici olabilir. İyi tanımlanmış bir SLA sayesinde müşteriler ne bekleyeceğini bilir, teknik ekip hangi olaya önce müdahale edeceğini net görür, yönetim ise hizmet performansını düzenli raporlarla takip eder.
113SEC olarak hedefimiz yalnızca sorun çıktığında destek vermek değil; sorunu büyümeden fark etmek, doğru önceliklendirmek, hızlı müdahale etmek ve tüm süreci şeffaf biçimde raporlamaktır. Destek ve güvenlik süreçlerinizi ölçülebilir hale getirmek isterseniz bizimle iletişime geçebilirsiniz.
P1 kritik bir olayda hedefimiz 1 saat içinde ilk müdahale, 4 saat içinde çözüm; ve her aşamada şeffaf, ölçülebilir bir takip.