Bakım penceresi: alarm yok, veri var
Cuma 02:54. Veri merkezi ekibi DC02 sunucusunda RAM yükseltmesi için planned reboot başlatır. 03:08'de ShamashAi'nin monitoring panelinde kırmızı zil: "DC02 - HEARTBEAT_LOST", "DC02 - SERVICE_DOWN: mssql.exe", "DC02 - DISK_IO_SPIKE". Nöbetçi sysadmin telefonda uyanır, VPN bağlanır, ekrana bakar — maintenance takviminde zaten yazıyor. Alarmı manuel dismiss eder, geri yatar. 04:20'de ikinci dalga: "DC02 - AUTH_FAIL_USER: sa account locked". Bu sefer gerçek sorun mu, yoksa yine bakım etkisi mi? Log'lara dalıp correlation yapar. Sabah mesaisi: 16 dismiss edilmiş ticket, 2 saat uyku kaybı, 1 gerçek incident gözden kaçmış.
ShamashAi'nin maintenance_windows modülü bu senaryo için tasarlandı. Planlı bakım pencerelerini sistem içinde tanımlarsınız; scope olarak project, site veya device seçersiniz; başlangıç/bitiş zamanını ayarlarsınız. Aktif window içinde ingest devam eder (agent veri göndermeye devam eder, event'ler dbo.events tablosuna yazılır) ama alert evaluation atllanır. Bakım biter bitmez normal moda döner. Geçmiş bakım kayıtları dbo.audit_log tablosunda retention-immune olarak saklanır; compliance audit sırasında "Bu 4 saatlik boşluk neden?" sorusuna yanıt hazırdır.
Maintenance window scope'ları
ShamashAi üç seviye scope sunar:
1. Project scope
Tüm proje sessizliğe alınır. Örnek senaryo: merkezi firewall policy güncellemesi, tüm site'lar etkilenecek. POST /maintenance-windows isteğinde scope: "project" parametresi ile tüm device ve site'ları kapsarsınız. Alert rule evaluator çalışırken active project window varsa değerlendirme adımını atlar.
2. Site scope
Belirli bir site (örneğin İstanbul DC, Ankara Yedekleme Merkezi) için bakım penceresi. POST /maintenance-windows isteğinde scope: "site", site_id: 7 şeklinde belirtirsiniz. O site'a bağlı tüm device'lar (dbo.devices.site_id = 7) için alert susturulur. Diğer site'lardaki cihazlar normal şekilde izlenmeye devam eder.
3. Device scope
Tekil cihaz bakımı: "DC02 sunucusu RAM upgrade". POST /maintenance-windows isteğinde scope: "device", device_id: "dc02.fabrikam.local" parametresiyle sadece o makineyi kapsarsınız. Aynı rack'teki DC01 veya DB01 sunucuları normal şekilde alert üretmeye devam eder.
Endpoint kullanımı
ShamashAi REST API üzerinden bakım penceresi açmak:
javascript // Node.js Fastify handler örneği (ShamashAi backend) fastify.post('/maintenance-windows', async (request, reply) => { const { scope, site_id, device_id, starts_at, ends_at, reason } = request.body; // Validasyon if (!['project', 'site', 'device'].includes(scope)) { return reply.code(400).send({ error: 'Invalid scope' }); } if (scope === 'site' && !site_id) { return reply.code(400).send({ error: 'site_id required for site scope' }); } if (scope === 'device' && !device_id) { return reply.code(400).send({ error: 'device_id required for device scope' }); }
const windowId = uuidv4(); await request.db.query(` INSERT INTO dbo.maintenance_windows (id, scope, site_id, device_id, starts_at, ends_at, reason, created_by) VALUES (@id, @scope, @site_id, @device_id, @starts_at, @ends_at, @reason, @user) `, { id: windowId, scope, site_id: site_id || null, device_id: device_id || null, starts_at: new Date(starts_at), ends_at: new Date(ends_at), reason, user: request.user.username });
// Audit log await request.db.query(` INSERT INTO dbo.audit_log (event_type, entity_type, entity_id, details, user_id) VALUES ('MAINTENANCE_WINDOW_CREATED', 'maintenance_window', @id, @details, @user) `, { id: windowId, details: JSON.stringify({ scope, starts_at, ends_at, reason }), user: request.user.id });
return reply.send({ window_id: windowId, status: 'scheduled' }); });
C# .NET 8 agent tarafında window check örneği:
csharp // ShamashAi Agent - Alert gönderim öncesi kontrol public async Task<bool> ShouldSuppressAlert(string deviceId, int siteId) { var now = DateTime.UtcNow; using var connection = new SqlConnection(_connectionString); var command = new SqlCommand(@" SELECT COUNT(*) FROM dbo.maintenance_windows WHERE (scope = 'project') OR (scope = 'site' AND site_id = @siteId) OR (scope = 'device' AND device_id = @deviceId) AND starts_at <= @now AND ends_at >= @now ", connection); command.Parameters.AddWithValue("@siteId", siteId); command.Parameters.AddWithValue("@deviceId", deviceId); command.Parameters.AddWithValue("@now", now); await connection.OpenAsync(); var count = (int)await command.ExecuteScalarAsync(); return count > 0; // Aktif window varsa suppress = true }
public async Task SendEvent(EventPayload evt) { // Ingest: olay her zaman yazılır await _eventRepository.InsertEvent(evt); // Alert: aktif maintenance window varsa atla if (await ShouldSuppressAlert(evt.DeviceId, evt.SiteId)) { _logger.LogInformation( "Alert suppressed due to active maintenance window: {Device}", evt.DeviceId ); return; } // Normal alert değerlendirmesi await _alertEngine.EvaluateRules(evt); }
İngest devam eder, alert atlanır
Klasik SIEM çözümlerinde bakım modu iki şekilde çalışır:
1. Ingest kapanır: Agent veri göndermez veya collector devre dışı bırakılır. Bakım sonrası log gap oluşur. Compliance audit'te açıklama gerekir. 2. Tüm alert kapalı: Ingest devam eder ama tüm kurallar susturulur. Bakım sırasında gerçek bir saldırı olursa (örneğin bakım fırsatını bilen içeriden biri BRUTE_FORCE_DETECTED tetikleyecek aktivite yaparsa) tespit edilmez.
ShamashAi farklı yaklaşım: ingest hiç durmuyor, ama alert rule evaluator aktif window kontrolü yapar. Örnek akış:
1. Agent DC02'den event toplar: event_type: AUTH_FAIL_USER, user: sa, failure_count: 15 2. Event dbo.events tablosuna yazılır (timestamp: 2026-09-23 03:14:22) 3. Alert engine rule "Brute force 10+ failed login" tetiklenir 4. Engine sorgu atar: sql SELECT COUNT(*) FROM dbo.maintenance_windows WHERE device_id = 'dc02.fabrikam.local' AND starts_at <= '2026-09-23 03:14:22' AND ends_at >= '2026-09-23 03:14:22' 5. Sonuç > 0 ise alert atlanır, dbo.audit_log'a ALERT_SUPPRESSED_MAINTENANCE yazılır 6. Sonuç = 0 ise normal alert akışı: dbo.incident_groups'a ticket, SOAR_ACTION tetiklenirse POST /soar/block çağrılır
Bakım bitince (ends_at geçilince) aynı kural yeniden tetiklenirse artık normal alert üretilir. Veri kaybı olmadığı için post-maintenance forensic analiz mümkün: "Bakım sırasında kim ne yaptı?" sorusuna dbo.events tablosundan tam cevap alırsınız.
Geçmiş bakım kayıtları: retention-immune
ShamashAi'de event retention policy tipik 90 gün (dbo.events tablosunda eski kayıtlar silinir). Ama dbo.maintenance_windows ve ilgili dbo.audit_log kayıtları retention-immune (silinmez). Neden?
- Compliance audit: "2026-03-15 tarihinde 4 saatlik alert boşluğu var, açıklayın." → dbo.audit_log'da
MAINTENANCE_WINDOW_CREATEDkaydı gösterirsiniz. Reason field: "DC upgrade - planned downtime". - SLA hesaplaması: Uptime SLA'sına maintenance window dahil edilmez. POST /reports/evidence-pack endpoint'i otomatik hesaplamada past windows'u dikkate alır.
- Incident root cause: Bakım sonrası 2 saat içinde anomali tespit edildiyse (BEHAVIORAL_ANOMALY event_type), bakım değişikliklerini correlation için kullanırsınız.
sql SELECT mw.id, mw.scope, mw.starts_at, mw.ends_at, mw.reason, u.username AS created_by, COUNT(e.id) AS events_during_window FROM dbo.maintenance_windows mw LEFT JOIN dbo.users u ON mw.created_by = u.id LEFT JOIN dbo.events e ON e.timestamp BETWEEN mw.starts_at AND mw.ends_at AND (mw.scope = 'project' OR (mw.scope = 'site' AND e.site_id = mw.site_id) OR (mw.scope = 'device' AND e.device_id = mw.device_id)) WHERE mw.starts_at >= DATEADD(month, -6, GETDATE()) GROUP BY mw.id, mw.scope, mw.starts_at, mw.ends_at, mw.reason, u.username ORDER BY mw.starts_at DESC;
Son 6 aydaki tüm bakım pencerelerini, her birinde kaç event toplandığını (ama alert tetiklenmediğini) gösterir.
Overlap ve çakışma yönetimi
Aynı device için çakışan iki window tanımlanırsa ne olur? Örnek:
- Window A: device_id = dc02, starts_at = 2026-09-23 02:00, ends_at = 2026-09-23 06:00
- Window B: device_id = dc02, starts_at = 2026-09-23 04:00, ends_at = 2026-09-23 08:00
COUNT(*) > 0 kontrolü yaptığı için overlap durumunda yine suppress edilir. İki window'dan biri bittiğinde (06:00) diğeri hâlâ aktifse (B window 08:00'e kadar) suppress devam eder.
SOAR entegrasyonu: bakım sırasında otomatik aksiyon yok
ShamashAi'nin SOAR Engine modülü aktif window kontrolü yapar. Örnek senaryo:
1. Bakım sırasında KNOWN_BAD_IP event'i gelir (test IP veya yanlış whitelist) 2. Normal şartlarda SOAR rule "Malicious IP → POST /soar/block" tetiklenir 3. Aktif maintenance window varsa SOAR_ACTION da atlanır, dbo.soar_actions tablosuna status: skipped_maintenance yazılır 4. Bakım bitince aynı IP tekrar görülürse bu sefer blok aksiyonu gerçekleşir
Bu davranış yanlış pozitif block'ları önler. Bakım sırasında network topology değişiyor, test IP'leri geçici olarak allowlist'te değil — otomatik blok production'ı kırabilir.
Web UI: maintenance takvimi
ShamashAi Next.js frontend'inde (shamashai.com.tr paneli) Maintenance menüsü altında:
- Active Windows: Şu anda aktif bakım pencereleri (yeşil badge)
- Scheduled: Gelecek tarihli bakımlar (mavi badge)
- Past: Geçmiş bakımlar, reason ve events_during_window bilgisi
- Scope dropdown: Project / Site / Device
- Scope = Site ise site dropdown aktif olur (dbo.sites tablosundan liste)
- Scope = Device ise device autocomplete (dbo.devices.hostname araması)
- Tarih/saat picker: starts_at, ends_at (timezone: Europe/Istanbul)
- Reason textarea: "Planned RAM upgrade DC02" gibi serbest metin
Behavioural baseline: bakım sonrası yeniden öğrenme
ShamashAi'nin behavior_baselines modülü (BEHAVIORAL_ANOMALY event_type) normalde 7-14 günlük veri üzerinden baseline oluşturur. Bakım sonrası sistem davranışı değişirse (yeni RAM → daha fazla concurrent process, yeni disk → farklı IO pattern) anomali alarmı üretebilir.
ShamashAi dokümantasyonu bu konuda daha fazla bilgi vermiyor; pilot kapsamında detay paylaşılır. Önerilen yaklaşım: bakım sonrası 24 saat için o device'a özel behavioral rule threshold'unu %20 yükseltmek veya ikinci bir kısa maintenance window açmak ("post-maintenance grace period").
Limitler ve dürüst notlar
- Zaman dilimi: Şu an sadece Europe/Istanbul timezone destekleniyor. Farklı timezone'da site varsa UTC'ye manuel çevirip starts_at/ends_at göndermek gerekir.
- Recurring window yok: Haftalık periyodik bakımlar için (her Cuma 02:00-04:00) her hafta manuel window açmanız gerekir. Otomatik tekrarlama özelliği yok.
- Partial scope: Aynı site'daki bazı device'lar bakımda, bazıları normal modda — bu durumda her device için ayrı window açmanız gerekir. "Site scope ama exclude device_X" mantığı yok.
- Emergency extend: Bakım uzarsa (planned 4 saat, fiili 6 saat) mevcut window'u POST /maintenance-windows/:id endpoint'i ile güncelleyebilirsiniz ama ShamashAi dokümantasyonu PATCH semantiği için daha fazla bilgi vermiyor; pilot kapsamında detay paylaşılır.
- Alert replay yok: Bakım sırasında gelen event'leri bakım bitince retrospektif olarak rule'lara tabi tutmak ("suppressed alert'leri şimdi değerlendir") şu an mümkün değil. Event dbo.events'te var, manuel sorgu ile inceleyebilirsiniz.