ZY KPI ve Raporlama: MTTR, SLA ve Kapanış Doğruluğu

Kısaca

• Az metrik, yüksek etki: MTTR, SLA uyumu, retest başarısı.
• Yönetici için özet, ekip için detay: iki katmanlı gösterim.

Özet Anlatım

Her metriğin bir karara hizmet etmesi gerekir. Yönetim; trendleri ve uyum oranlarını görmek isterken, ekipler darboğazları ve kök sebepleri çözmekle ilgilenir. Bu yüzden tek bir panelde “özet” ve “detay” katmanı birlikte kurgulanmalıdır.

Temel KPI’lar

• MTTR (kritik/yüksek) ve zaman içinde trendi
• SLA uyum oranı ve ihlal analizi
• Retest başarısı ve kapanış doğruluğu
• Gürültü azaltma (false positive, tekilleştirme başarısı)

Görselleştirme ve Sunum

• Yönetim özeti (1–2 slayt), ekibin çalışma paneli (detay)
• Eşikler ve hedefler; uyarı/eskalasyon eşikleri

Pratik Rehber

Hedef değerler ve eşikler: Önce birkaç net hedef belirleyin ve tüm ekipte aynı dili konuşun. Örneğin MTTR (bir bulgunun ortalama kapatma süresi) kritik bulgular için 7 gün, yüksek bulgular için 14 gün hedeflenebilir. Bu değerler şirketinizin büyüklüğüne ve ekip kapasitesine göre güncellenebilir. SLA uyumu için pratik hedef %90 ve üzeridir; her ihlal için kısa bir kök sebep analizi ve tekrarını engelleyecek kalıcı bir önlem (ör. kalıp kural, playbook) kaydı tutmak faydalıdır. “Kapanış gerçekten düzeldi mi?” sorusunun yanıtı retest başarısıdır; kritik ve yüksek bulguların mümkünse otomatik retest’e girmesi, doğruluk oranını %95 ve üzerine taşır. Gürültüyü azaltmak için yanlış pozitif oranını %5’in altında, aynı bulgunun farklı kaynaklardan tekrarlanmasını önleyen tekilleştirme başarısını ise %85 ve üzeri hedeflemek anlamlıdır.

Kullanım senaryoları: Yönetim kuruluna giderken detaylar yerine resmi gösterin: Son 90 güne ait MTTR trendi ve SLA ihlallerini ısı haritasıyla sunmak, nerede zorlandığınızı birkaç saniyede anlatır. Ekip planlamasında ayrıntıya inin: Uygulama/modül bazında MTTR’yi karşılaştırın; sürekli geciken bileşenlerde darboğaz (kapasite, sahiplik, borç) olduğunu göreceksiniz. Denetim döneminde ise “kanıt” konuşur: Kapatılan bulguların retest kayıtları ve ekran görüntüleri, hem kapanış doğruluğunu hem de sürecin izlenebilirliğini gösterir.

Örnek senaryo: Kritik bir zafiyet kapatıldıktan sonra otomatik retest başarısız oldu diyelim. Dashboard’da bu durum anında görünür, ilgili ticket tekrar açılır ve kök sebep notunda “yama yalnızca ön uca uygulandı, arka uç servis güncellenmedi” yazılıdır. Ekip, kalıcı önlem olarak “yama playbook’una arka uç kontrol adımı ekle” kararını kaydeder. Bu sayede aynı hata tekrarlandığında düzeltilmesi dakikalar sürer.

Adım adım (dashboard kurulumu):

1. Veri kaynaklarını bağlayın. Zafiyet platformu, iş takip (ticket) sistemi, varlık/envanter ve kimlik yönetimi en azından tek yöne (okuma) bağlansın. Amaç, “bulgu → sahip → varlık → kapatma → retest” zincirini tek ekranda görebilmek.
2. Basit bir model tanımlayın. Her bulguya; kritiklik (CVE skoru değil, iş etkisiyle birlikte), maruziyet (iç/dış, internet’e açık mı) ve iş etki katsayıları atayın. Bu üçlü, öncelik sıralamasını otomatik üretir.
3. Görünümleri hazırlayın. Yönetim için: MTTR trend + SLA uyum oranı. Ekip için: açık bulguların yaş dağılımı, tekrar açılanlar, retest başarısı ve gürültü/tekilleştirme panelleri. Her görünümde en çok 3–4 grafik tutun.
4. Uyarı kurallarını kalibre edin. Eşikler başlangıçta geniş tutulabilir (ör. kritik MTTR 10 gün). 2–3 sprint sonunda gerçekleşen değerlere bakıp eşikleri sıkılaştırın. Uyarıların gürültü üretmediğinden emin olun; gereksiz bildirim, önemli olanı görünmez yapar.