Pazartesi 08:42'de SOC lideri Deniz'in gözünden

Pazartesi sabahı 08:42'de ShamashAi web arayüzüne giriş yapıyorsunuz. Hafta sonu Ankara şubesinden BRUTE_FORCE_DETECTED, İzmir data center'dan CERT_EXPIRING ve Istanbul HQ'dan AUTH_FAIL_USER olayları düşmüş. Toplam 37 açık vaka. Ekibinizde 3 analist: Ahmet, Ayşe, Mehmet. Slack'te kimse ses çıkarmıyor ama cuma günü Ahmet "yetişemiyorum" diye yazmıştı. Ayşe ve Mehmet'ten haftada 2-3 mesaj geliyor, Ahmet'ten günde 15. Hangisi gerçekten yüklü, hangisi rahat ediyor? Klasik SIEM araçlarında bu sorunun yanıtı yok. "Assigned user" kolonunda isim var ama kimin kaç açık vakası olduğu, her vakanın ne kadar süre açık kaldığı, SLA hedeflerinden hangisinin tehlikede olduğu görünmez. Yönetici manuel olarak rapor çeker, Excel'de pivot tablo yapar, 2 saat sonra şunu anlar: Ahmet 22 vaka taşıyor (ortalama time-to-resolve 9 saat), Ayşe 8 vaka taşıyor (ortalama 3 saat), Mehmet 7 vaka taşıyor (ortalama 2.5 saat). Sonuç: Ahmet burnout riskinde, Ayşe ve Mehmet kapasitelerinin %40'ını kullanıyor. ShamashAi Ownership modülü bu analizi otomatik yapar. /ownership/sla sayfası kullanıcı başına atanan vakaları, açık/kapalı oranını, ortalama time-to-ack (ilk müdahale süresi) ve time-to-resolve (çözüm süresi) metriklerini gösterir. SLA basıncı renkli heatmap'te (yeşil-sarı-kırmızı) gerçek zamanlı yansır. IT yöneticisi 5 dakikada burnout riskini tespit eder, 2 tıklamayla vakayı başka kullanıcıya reassign eder.

ShamashAi Ownership modülü: Metrik tabanlı ekip yük dağılımı

ShamashAi Ownership modülü dbo.events tablosundaki assigned_user_id alanı ile dbo.audit_log tablosundaki zaman damgalarını birleştirerek kullanıcı başına şu metrikleri hesaplar:

Active workload count: Kullanıcının şu anda açık (status='open' veya status='investigating') olan vaka sayısı.

Time-to-ack (ortalama): Vaka atandığı andan ilk audit_log kaydına ("opened", "acknowledged") kadar geçen süre (dakika cinsinden ortalama).

Time-to-resolve (ortalama): Vaka atandığı andan status='closed' olana kadar geçen süre (dakika cinsinden ortalama).

SLA overdue distribution: Kullanıcının açık vakalarından kaçının SLA hedefini aştığı (örneğin kritik vaka için 2 saat, orta önem için 8 saat).

Açık/kapalı oran: Son 30 gün içinde kullanıcıya atanan tüm vakaların yüzde kaçının kapatıldığı.

/ownership/sla sayfası bu metrikleri 3×3 heatmap'te gösterir. Her hücre bir kullanıcı. Hücre rengi active workload count ile time-to-resolve ortalamasının çarpımına göre belirlenir: yeşil (hafif yük, hızlı çözüm), sarı (orta), kırmızı (ağır yük, yavaş çözüm). Yönetici fare ile hücreye gelince tooltip açılır: Ahmet Yılmaz Açık vaka: 22 Ortalama time-to-ack: 18 dk Ortalama time-to-resolve: 547 dk (9.1 saat) SLA overdue: 7 vaka (kritik=3, orta=4) Son 30 gün: 68 vaka atandı, 46 kapandı (%67.6 kapanma) Ayşe için: Ayşe Kara Açık vaka: 8 Ortalama time-to-ack: 12 dk Ortalama time-to-resolve: 185 dk (3.1 saat) SLA overdue: 0 vaka Son 30 gün: 34 vaka atandı, 34 kapandı (%100 kapanma) Bu görünümde Ahmet kırmızı, Ayşe yeşil. Yönetici Ahmet'in hücresine tıklayınca "Reassign from Ahmet" modal açılır. Modalda Ahmet'e atanmış açık 22 vakanın listesi (event_type, severity, assigned_date) ve yanlarında checkbox. Yönetici 10 vakayı seçer, hedef kullanıcı olarak Ayşe'yi seçer, "Reassign" butonuna basar. Arka planda ShamashAi şu SQL komutunu çalıştırır: sql UPDATE dbo.events SET assigned_user_id = @target_user_id, reassigned_at = GETUTCDATE(), reassigned_by = @manager_user_id WHERE event_id IN (@selected_event_ids) AND assigned_user_id = @source_user_id AND status IN ('open', 'investigating'); INSERT INTO dbo.audit_log (event_id, action, user_id, timestamp, details) VALUES (@event_id_1, 'reassigned', @manager_user_id, GETUTCDATE(), 'from=ahmet_id to=ayse_id'), (@event_id_2, 'reassigned', @manager_user_id, GETUTCDATE(), 'from=ahmet_id to=ayse_id'), -- diğer seçilen vakalar ; Reassignment tamamlanınca heatmap otomatik güncellenir: Ahmet 12 açık vaka (sarı), Ayşe 18 açık vaka (yeşil-sarı arası). Ayşe'nin ortalama time-to-resolve 3.1 saat olduğu için yeni atanan 10 vaka muhtemelen 1 gün içinde kapanır. Ahmet'in geri kalan 12 vakası daha yönetilebilir.

Per-user incident metrics: Kimsenin görmediği yük dağılım adaletsizliği

Geleneksel SIEM veya ticketing sistemlerinde "kimin kaç ticket'ı var" raporu vardır. Ancak bu rapor şunu göstermez:

Ahmet'e atanan 22 vakanın 18'i kritik severity, Mehmet'e atanan 7 vakanın 6'sı düşük severity olabilir. Sayısal olarak Ahmet 3 kat yüklü görünür ama severity bazında Ahmet 9 kat yüklüdür.

Ahmet'in 22 vakası son 3 günde atanmış olabilir (günlük 7+ vaka), Mehmet'in 7 vakası son 2 haftada atanmış olabilir (günlük 0.5 vaka). Akış hızı çok farklıdır.

Ahmet'in vakalarının %32'si SLA overdue, Mehmet'in vakalarının %0'ı overdue. Ahmet baskı altında, Mehmet rahat.

ShamashAi Ownership modülü bu 3 boyutu birleştirir. /ownership/sla sayfasının altında "Detailed metrics" tablosu vardır: | Kullanıcı | Açık vaka | Kritik | Orta | Düşük | Avg time-to-ack | Avg time-to-resolve | SLA overdue | Son 7 gün atanan | Kapanma oranı (30 gün) | |-----------|-----------|--------|------|-------|-----------------|---------------------|-------------|------------------|------------------------| | Ahmet | 22 | 18 | 3 | 1 | 18 dk | 547 dk (9.1 saat) | 7 | 22 | %67.6 | | Ayşe | 8 | 2 | 4 | 2 | 12 dk | 185 dk (3.1 saat) | 0 | 8 | %100 | | Mehmet | 7 | 1 | 1 | 5 | 9 dk | 152 dk (2.5 saat) | 0 | 3 | %100 | Bu tabloda açıkça görülür: Ahmet son 7 günde 22 yeni vaka almış (Ayşe 8, Mehmet 3). Ahmet'in %82'si kritik, Mehmet'in %14'ü kritik. Ahmet'in ortalama çözüm süresi 9 saat, Mehmet'in 2.5 saat. Kapanma oranı Ahmet %68 (yani 30 günde atanan 68 vakanın 22'si hala açık), Ayşe ve Mehmet %100. Yönetici bu tabloyu görmeden önce "Ahmet niye yetişemiyor?" diye sorar. Tabloyu gördükten sonra sorusu "Ahmet'e neden bu kadar kritik vaka atanıyor, otomatik round-robin dağılımı neden dengeli çalışmıyor?" olur. Cevap: ShamashAi dokümantasyonu şu anda round-robin algoritmasının severity farkındalığını destekleyip desteklemediğini belirtmiyor; pilot kapsamında detay paylaşılır. Ancak manuel reassignment ile yönetici dengeyi sağlayabilir.

Time-to-ack ve time-to-resolve: Burnout erken uyarı sinyali

Time-to-ack (ilk müdahale süresi) kullanıcının ne kadar hızlı tepki verdiğini gösterir. Ayşe'nin ortalama time-to-ack'ı 12 dakika, Ahmet'in 18 dakika. Fark küçük görünür ama Ahmet'in son 7 gün ortalaması 28 dakikaysa (genel ortalama 18 dakika) bu, Ahmet'in yavaşladığı anlamına gelir. Burnout erken uyarı sinyalidir. ShamashAi /ownership/sla sayfasında kullanıcı adına tıklayınca "7-day trend" grafiği açılır:

X ekseni: Son 7 gün (2026-09-07'den 2026-09-14'e).

Y ekseni: Ortalama time-to-ack (mavi çizgi) ve ortalama time-to-resolve (kırmızı çizgi).

Noktalar: Her gün o kullanıcının kapattığı vaka sayısı (yeşil çubuk).

Ahmet'in grafiğinde:

2026-09-07: time-to-ack 14 dk, time-to-resolve 6.2 saat, 4 vaka kapandı.

2026-09-10: time-to-ack 22 dk, time-to-resolve 9.8 saat, 2 vaka kapandı.

2026-09-13: time-to-ack 31 dk, time-to-resolve 11.4 saat, 1 vaka kapandı.

Çizgi yukarı doğru tırmanıyor, kapanan vaka sayısı düşüyor. Bu kalıp burnout'un klasik belirtisidir: Kullanıcı yavaşlıyor, çözüm süresi uzuyor, günlük kapanma oranı düşüyor. Yönetici bu grafiği görünce müdahale eder: Ahmet'ten vaka alır, hafta sonu nöbet görevinden çıkarır veya 1 gün izin verir. Ayşe ve Mehmet'in grafiklerinde çizgiler düz seyrediyor (Ayşe 12 dk / 3.1 saat, Mehmet 9 dk / 2.5 saat). Bu, stabil tempo anlamına gelir. Yönetici Ayşe ve Mehmet'e daha fazla vaka atayabilir.

SLA overdue distribution: Kırmızı alarm hangi kullanıcıda?

ShamashAi dbo.events tablosunda sla_deadline alanı vardır (datetime, vaka atandığı anda severity'ye göre hesaplanır: kritik +2 saat, orta +8 saat, düşük +24 saat). /ownership/sla sayfasında her kullanıcının SLA overdue sayısı gösterilir:

Ahmet: 7 vaka overdue (kritik=3, orta=4).

Ayşe: 0 vaka overdue.

Mehmet: 0 vaka overdue.

Yönetici Ahmet'in satırına tıklayınca "Overdue incidents" modal açılır: | Event ID | Event Type | Severity | Assigned Date | SLA Deadline | Overdue (hours) | |----------|-----------------------|----------|---------------------|---------------------|------------------| | 108234 | BRUTE_FORCE_DETECTED | kritik | 2026-09-12 14:22 | 2026-09-12 16:22 | 41 | | 108241 | KNOWN_BAD_IP | kritik | 2026-09-12 17:10 | 2026-09-12 19:10 | 38 | | 108256 | AUTH_FAIL_USER | kritik | 2026-09-13 08:55 | 2026-09-13 10:55 | 22 | | 108267 | BEHAVIORAL_ANOMALY | orta | 2026-09-11 11:30 | 2026-09-11 19:30 | 61 | | 108273 | M365_RISKY_SIGNIN | orta | 2026-09-11 15:45 | 2026-09-11 23:45 | 57 | | 108289 | CERT_EXPIRING | orta | 2026-09-12 09:00 | 2026-09-12 17:00 | 40 | | 108301 | BACKUP_FAILED | orta | 2026-09-12 22:15 | 2026-09-13 06:15 | 27 | Yönetici bu listeyi görünce şunu anlar: Ahmet'e atanan kritik vakalar 38-41 saat overdue. Bu kabul edilemez. Yönetici bu 3 kritik vakayı hemen başka kullanıcıya reassign eder. Modal içinde "Reassign selected" butonu vardır. Seçilen 3 vaka Ayşe'ye atanır. Ayşe'nin ortalama time-to-resolve'u 3.1 saat olduğu için bu 3 vaka muhtemelen 3-4 saat içinde kapanır.

Manager view: 2 tıklamayla reassignment

ShamashAi Ownership modülü "manager" rolüne sahip kullanıcılara reassignment yetkisi verir. /ownership/sla sayfasında yönetici herhangi bir kullanıcının hücresine tıklayınca "Reassign from X" modal açılır. Modal 3 bölüm içerir: 1. Open incidents: Kullanıcının açık vakalarının listesi (checkbox ile seçim). 2. Target user: Hedef kullanıcı dropdown menüsü (tüm SOC analisti kullanıcıları listelenir, yanlarında mevcut açık vaka sayısı). 3. Reassign button: Seçilen vakaları hedef kullanıcıya atar. Yönetici şu senaryoyu 2 dakikada çözer:

Ahmet'in hücresine tıkla.

Modal açılır: 22 açık vaka.

Severity=kritik olan 10 vakayı seç (checkbox).

Target user dropdown'dan Ayşe'yi seç (şu anda 8 açık vaka, kapasitesi var).

"Reassign 10 incidents" butonuna bas.

ShamashAi arka planda UPDATE dbo.events SET assigned_user_id=... SQL komutunu çalıştırır.

Heatmap otomatik güncellenir: Ahmet 12 açık vaka, Ayşe 18 açık vaka.

Reassignment işlemi dbo.audit_log tablosuna kaydedilir: sql SELECT event_id, action, user_id, timestamp, details FROM dbo.audit_log WHERE action = 'reassigned' AND timestamp >= '2026-09-14 09:00:00' ORDER BY timestamp DESC; Sonuç: event_id | action | user_id | timestamp | details ---------|------------|----------------|---------------------|------------------------------- 108234 | reassigned | deniz_manager | 2026-09-14 09:17:42 | from=ahmet_id to=ayse_id 108241 | reassigned | deniz_manager | 2026-09-14 09:17:42 | from=ahmet_id to=ayse_id 108256 | reassigned | deniz_manager | 2026-09-14 09:17:42 | from=ahmet_id to=ayse_id ... Bu audit trail compliance raporlarında (ISO 27001 Annex A.12.4.1: Event logging) kanıt olarak sunulur. Denetçi sorar: "Kritik vakalar nasıl dağıtılıyor?" Yanıt: dbo.audit_log tablosunda her reassignment kaydı var, yönetici kararı manuel veya otomatik tetiklenmiş.

Node.js API endpoint örneği: Reassignment işlemi

ShamashAi API (Node.js Fastify) /ownership/reassign endpoint'i şu şekilde çalışır: javascript // POST /ownership/reassign // Body: { event_ids: [108234, 108241, 108256], target_user_id: 'ayse_id', source_user_id: 'ahmet_id' } fastify.post('/ownership/reassign', { schema: { body: { type: 'object', required: ['event_ids', 'target_user_id', 'source_user_id'], properties: { event_ids: { type: 'array', items: { type: 'integer' } }, target_user_id: { type: 'string' }, source_user_id: { type: 'string' } } } }, preHandler: fastify.auth([fastify.verifyManagerRole]), // Manager rolü kontrolü handler: async (request, reply) => { const { event_ids, target_user_id, source_user_id } = request.body; const manager_id = request.user.id; // SQL transaction başlat const pool = fastify.mssql; const transaction = new pool.Transaction(); await transaction.begin(); try { // events tablosunu güncelle const updateRequest = new pool.Request(transaction); const updateQuery = ` UPDATE dbo.events SET assigned_user_id = @target_user_id, reassigned_at = GETUTCDATE(), reassigned_by = @manager_id WHERE event_id IN (${event_ids.join(',')}) AND assigned_user_id = @source_user_id AND status IN ('open', 'investigating'); `; updateRequest.input('target_user_id', pool.VarChar, target_user_id); updateRequest.input('manager_id', pool.VarChar, manager_id); updateRequest.input('source_user_id', pool.VarChar, source_user_id); await updateRequest.query(updateQuery); // audit_log'a kaydet const auditRequest = new pool.Request(transaction); for (const event_id of event_ids) { const auditQuery = ` INSERT INTO dbo.audit_log (event_id, action, user_id, timestamp, details) VALUES (@event_id, 'reassigned', @manager_id, GETUTCDATE(), @details); `; auditRequest.input('event_id', pool.Int, event_id); auditRequest.input('manager_id', pool.VarChar, manager_id); auditRequest.input('details', pool.VarChar, from=${source_user_id} to=${target_user_id}); await auditRequest.query(auditQuery); } await transaction.commit(); // WebSocket ile frontend'e güncelleme gönder fastify.websocketServer.clients.forEach(client => { if (client.readyState === 1) { client.send(JSON.stringify({ type: 'ownership_updated', source_user_id, target_user_id, reassigned_count: event_ids.length })); } }); return reply.send({ success: true, reassigned_count: event_ids.length }); } catch (error) { await transaction.rollback(); fastify.log.error(error); return reply.status(500).send({ error: 'Reassignment failed' }); } } }); Frontend (Next.js) WebSocket üzerinden ownership_updated mesajını alır, /ownership/sla sayfasındaki heatmap'i otomatik günceller. Yönetici manuel refresh'e gerek kalmadan yeni dağılımı görür.

Gerçek senaryoda kullanım: Cuma 17:00 öncesi yük dengeleme

Cuma günü saat 17:00'a yaklaşıyor. Yönetici /ownership/sla sayfasını açar, hafta sonu nöbet listesini kontrol eder. Hafta sonu nöbeti Mehmet'te. Mehmet'in şu anda 7 açık vakası var, hepsi düşük severity. Ancak Ahmet'in 22 açık vakasından 5'i kritik ve hafta sonu için atanmış (örneğin CERT_EXPIRING olayları pazartesi expire olacak, hafta sonu işlem yapılmalı). Yönetici şunu yapar: 1. Ahmet'in hücresine tıklar. 2. Modalda "Severity=kritik AND assigned_date < 2026-09-14" filtresi uygular (hafta sonu öncesi atanan kritik vakalar). 3. 5 kritik vakayı seçer. 4. Target user olarak Mehmet'i seçer. 5. "Reassign" butonuna basar. Şimdi Mehmet'in 12 açık vakası var (7 düşük + 5 kritik). Mehmet hafta sonu nöbetindeyken bu 5 kritik vakayı çözer. Ahmet hafta sonunu rahat geçirir, pazartesi 17 açık vaka ile başlar (hala yüklü ama SLA overdue riski düşer). Bu senaryo manuel müdahale gerektirir çünkü ShamashAi dokümantasyonu şu anda "nöbet rotasyonu farkındalıklı otomatik reassignment" özelliğinin varlığını belirtmiyor; pilot kapsamında detay paylaşılır.

Limitler ve dürüst notlar

Round-robin dağılımı severity farkındalığı: ShamashAi dokümantasyonu otomatik vaka dağılımının severity bazlı dengeleme yapıp yapmadığını belirtmiyor. Eğer desteklenmiyorsa yönetici manuel reassignment ile dengeyi sağlar.

Takım dışı faktörler: Time-to-resolve uzaması her zaman yük fazlalığından kaynaklanmaz. Kullanıcı hastalık izninde olabilir, o gün network sorunu yaşanmış olabilir. ShamashAi şu anda kullanıcı izin durumunu entegre etmiyor; bu veri manuel yorumlanmalı.

Heatmap renk algoritması özelleştirme: /ownership/sla sayfasındaki heatmap renk eşikleri (yeşil < 10 açık vaka, sarı 10-20, kırmızı > 20) admin panelinden özelleştirilebilir mi? ShamashAi dokümantasyonu bunu belirtmiyor; pilot kapsamında detay paylaşılır.

Cross-team reassignment: Eğer organizasyonda 2 ayrı SOC ekibi varsa (örneğin Network SOC ve Application SOC) /ownership/sla sayfası her iki ekibi aynı heatmap'te mi gösterir yoksa ekip bazlı filtre mi vardır? Dokümantasyon net değil.

Historical trend süresi: 7 günlük trend grafiği gösteriliyor. 30 günlük veya 90 günlük trend için ayrı rapor endpoint'i var mı? Şu anda belirtilmiyor.

Sonuç: Görünmeyen iş dağılımını görünür yap

Ekipte 3 kişi varsa 1'i tüm yükü çeker, 2'si rahat eder klasik senaryosunu ShamashAi Ownership modülü 5 dakikada tespit eder. /ownership/sla sayfasındaki renkli heatmap burnout riskini erken gösterir, 2 tıklamayla reassignment ile yük dengelenir. Time-to-ack ve time-to-resolve metrikleri yavaşlayan kullanıcıyı işaret eder, SLA overdue distribution kritik vakaların hangi kullanıcıda kaldığını ortaya çıkarır. Yönetici Excel pivot tablo yapmadan gerçek zamanlı karar verir. Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim

Paylaş

ShamashAi Ownership Matrix: Ekip yükünü dengeleyen metrik gösterge paneli