Cuma 18:47'de başlayan rollback ve kanıt zincirinin dağılması
Cuma akşamı 18:47'de sistem yöneticisi firewall kuralını günceller. 19:15'te web uygulaması yanıt vermeyi keser. 19:23'te rollback başlar. 19:41'de servis ayağa kalkar. Pazartesi sabahı müşteri temsilcisi sorar: "Cuma akşamı ne oldu, değişiklik onaylı mıydı, rollback ne zaman tamamlandı?" IT yöneticisi Slack'te mesaj arar. Kimin ne zaman ne yaptığı, hangi onayın hangi değişikliğe ait olduğu, rollback'in başlangıç-bitiş saati birbirinden kopuk kanallara dağılmış durumda. ISO 27001 Annex A.8.32 (change management) kontrolü için denetçiye sunulacak "change log" Excel'de tutulmaya çalışılıyor ama değişiklik sırasında kimse Excel'i güncellemedi.
ShamashAi Change Calendar modülü bu sorunu çözmek için tasarlandı: her planlı değişiklik
change_calendar tablosunda açılır, risk seviyesi atanır, durum geçişleri (planned → in_progress → completed veya rolled_back) audit zincirine otomatik bağlanır ve rollback kanıtı (evidence) compliance evidence pack içine dahil edilir. Böylece "ne zaman ne yapıldı, geri alındı mı, onaylı mıydı" sorusuna tek bir sorgu ile yanıt verebilirsiniz.
ShamashAi Change Calendar tablosu ve risk seviyesi
ShamashAi'de planlı değişiklikler
dbo.change_calendar tablosunda saklanır. Tablonun temel alanları:
- change_id (UUID): değişiklik kaydının benzersiz tanımlayıcısı
- title (string): "Firewall kural 443/tcp açılması", "SQL Server 2019→2022 yükseltme" gibi açıklama
- planned_start (datetime2): planlanan başlangıç zamanı
- planned_end (datetime2): planlanan bitiş zamanı
- risk_level (enum):
low, medium, high
- status (enum):
planned, in_progress, completed, rolled_back
- owner (string): değişikliği uygulayacak kişi (email veya kullanıcı adı)
- approver (string): onay veren kişi
- rollback_evidence (nvarchar(max)): rollback yapıldıysa kanıt metni veya bağlantı
- created_at, updated_at: kayıt oluşturma ve son güncelleme zamanları
Risk seviyesi (risk_level) üç değer alabilir:
- low: rutin işlemler (sertifika yenileme, log rotation, küçük config değişikliği)
- medium: ara etki (database index rebuild, web sunucusu restart, patch uygulaması)
- high: üretim kritik (firewall kural değişikliği, veri taşıma, sürüm yükseltme)
Risk seviyesi maintenance window ile entegre çalışır. Örneğin
risk_level: high olan bir değişiklik sadece tanımlı bakım penceresi içinde (cumartesi 02:00-06:00 gibi)
in_progress durumuna geçebilir. Pencere dışında durum geçişi denerseniz API HTTP 409 döndürür ve
dbo.audit_log tablosuna "change blocked: outside maintenance window" kaydı düşer.
Değişiklik açma: POST /changes endpoint'i
Yeni bir değişiklik kaydetmek için
/changes endpoint'ine POST isteği atarsınız:
http
POST https://shamashai.local/api/changes
Content-Type: application/json
Authorization: Bearer <token>
{
"title": "SQL Server 2019 → 2022 yükseltme (prod-db01)",
"planned_start": "2026-08-30T02:00:00Z",
"planned_end": "2026-08-30T05:00:00Z",
"risk_level": "high",
"owner": "ahmet.yilmaz@example.com",
"approver": "mehmet.kaya@example.com",
"description": "Prod veritabanı sunucusunda SQL Server 2022 CU3'e yükseltme. Rollback planı: snapshot geri yükleme."
}
Yanıt:
{
"change_id": "c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f",
"status": "planned",
"created_at": "2026-08-24T09:15:59Z"
}
Bu kayıt
dbo.change_calendar tablosuna yazılır ve aynı anda
dbo.audit_log içine şu şekilde audit entry düşer:
{
"event_type": "CHANGE_CREATED",
"user": "ahmet.yilmaz@example.com",
"change_id": "c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f",
"details": {
"title": "SQL Server 2019 → 2022 yükseltme (prod-db01)",
"risk_level": "high"
},
"timestamp": "2026-08-24T09:15:59Z"
}
Durum geçişi: PATCH /changes/:id/status ve audit zinciri
Değişiklik planlanan zamanda başlatıldığında durum
planned →
in_progress geçer:
http
PATCH https://shamashai.local/api/changes/c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f/status
Content-Type: application/json
Authorization: Bearer <token>
{
"status": "in_progress",
"note": "Snapshot alındı, yükseltme başlatıldı."
}
API önce maintenance window'u kontrol eder:
- Eğer
planned_start ile planned_end arasındaysanız ve pencere açıksa → durum güncellenir.
- Eğer pencere dışındaysanız → HTTP 409 Conflict döner, audit_log'a "change blocked" yazılır.
Durum geçişi başarılı olursa
dbo.audit_log'a şu entry eklenir:
{
"event_type": "CHANGE_STATUS_UPDATED",
"user": "ahmet.yilmaz@example.com",
"change_id": "c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f",
"old_status": "planned",
"new_status": "in_progress",
"note": "Snapshot alındı, yükseltme başlatıldı.",
"timestamp": "2026-08-30T02:03:12Z"
}
Böylece kim, ne zaman, hangi notu ekleyerek durumu değiştirdi — tüm zincir
audit_log içinde kayıtlı kalır.
Rollback senaryosu ve rollback_evidence alanı
Değişiklik sırasında sorun çıkarsa (örneğin SQL Server upgrade sonrası uygulama bağlantı hatası verdi) durum
rolled_back olarak işaretlenir:
http
PATCH https://shamashai.local/api/changes/c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f/status
Content-Type: application/json
{
"status": "rolled_back",
"rollback_evidence": "Snapshot prod-db01-pre-upgrade-2026-08-30 geri yüklendi. Restore log: https://shamashai.local/logs/restore-2026-08-30-0412.txt",
"note": "Uygulama TLS 1.3 hatası verdi,eski sürüme geri dönüldü."
}
rollback_evidence alanı rollback işleminin kanıtını saklar: snapshot adı, geri yükleme log bağlantısı, commit hash (kod değişikliği ise), firewall kural export dosyası gibi. Bu alan compliance evidence pack içine dahil edilir. Denetçi "rollback yapıldığını nasıl kanıtlarsınız?" diye sorduğunda
GET /compliance/evidence?change_id=... sorgusuyla bu metni ve bağlantıları sunarsınız.
Durum
rolled_back olduğunda audit_log'a şu kayıt düşer:
{
"event_type": "CHANGE_ROLLED_BACK",
"user": "ahmet.yilmaz@example.com",
"change_id": "c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f",
"old_status": "in_progress",
"new_status": "rolled_back",
"rollback_evidence": "Snapshot prod-db01-pre-upgrade-2026-08-30 geri yüklendi...",
"timestamp": "2026-08-30T04:12:47Z"
}
Compliance evidence pack entegrasyonu
ShamashAi compliance modülü
GET /compliance/evidence ve
GET /reports/evidence-pack endpoint'leri ile denetim kanıtlarını toplar. Change Calendar kayıtları bu pack içine otomatik dahil edilir:
http
GET https://shamashai.local/api/reports/evidence-pack?start_date=2026-08-01&end_date=2026-08-31&include_changes=true
Yanıt ZIP veya JSON formatında döner ve
changes bölümünde
dbo.change_calendar +
dbo.audit_log birleştirilerek şu yapı oluşturulur:
{
"changes": [
{
"change_id": "c7a3f891-4b2e-4d6a-9f1c-3e8d7a2b5c9f",
"title": "SQL Server 2019 → 2022 yükseltme (prod-db01)",
"risk_level": "high",
"status": "rolled_back",
"planned_start": "2026-08-30T02:00:00Z",
"planned_end": "2026-08-30T05:00:00Z",
"owner": "ahmet.yilmaz@example.com",
"approver": "mehmet.kaya@example.com",
"rollback_evidence": "Snapshot prod-db01-pre-upgrade-2026-08-30 geri yüklendi. Restore log: https://shamashai.local/logs/restore-2026-08-30-0412.txt",
"audit_trail": [
{
"event_type": "CHANGE_CREATED",
"timestamp": "2026-08-24T09:15:59Z",
"user": "ahmet.yilmaz@example.com"
},
{
"event_type": "CHANGE_STATUS_UPDATED",
"old_status": "planned",
"new_status": "in_progress",
"timestamp": "2026-08-30T02:03:12Z"
},
{
"event_type": "CHANGE_ROLLED_BACK",
"old_status": "in_progress",
"new_status": "rolled_back",
"timestamp": "2026-08-30T04:12:47Z"
}
]
}
]
}
Bu pack'i ISO 27001, SOC 2 veya KVKK Madde 12 (veri güvenliği tedbirleri) denetiminde sunarsınız. "Değişiklik yönetimi süreciniz var mı, rollback kanıtlayabiliyor musunuz?" sorusuna tek bir JSON dosyası ile yanıt verirsiniz.
C# .NET 8 kod örneği: change_calendar sorgulama ve durum güncelleme
ShamashAi tech stack .NET 8 agent içerdiği için değişiklik kayıtlarını C# ile sorgulamak yaygındır. Örnek:
csharp
using System;
using System.Net.Http;
using System.Net.Http.Json;
using System.Threading.Tasks;
var client = new HttpClient { BaseAddress = new Uri("https://shamashai.local/api/") };
client.DefaultRequestHeaders.Add("Authorization", "Bearer <token>");
// Yeni change kaydı oluştur
var newChange = new
{
title = "Firewall kural 8443/tcp açılması (prod-fw01)",
planned_start = "2026-08-25T22:00:00Z",
planned_end = "2026-08-25T22:30:00Z",
risk_level = "medium",
owner = "ali.celik@example.com",
approver = "fatma.demir@example.com",
description = "Yeni monitoring port için firewall kuralı."
};
var createResponse = await client.PostAsJsonAsync("changes", newChange);
var createdChange = await createResponse.Content.ReadFromJsonAsync<ChangeResponse>();
Console.WriteLine($"Change ID: {createdChange.change_id}, Status: {createdChange.status}");
// Değişiklik başlatıldığında durum güncelle
await Task.Delay(TimeSpan.FromHours(12)); // simulate wait
var statusUpdate = new { status = "in_progress", note = "Firewall kuralı ekleniyor." };
var updateResponse = await client.PatchAsJsonAsync(
$"changes/{createdChange.change_id}/status",
statusUpdate
);
if (updateResponse.IsSuccessStatusCode)
{
Console.WriteLine("Durum in_progress olarak güncellendi.");
}
else
{
Console.WriteLine($"Hata: {updateResponse.StatusCode} - maintenance window dışında olabilir.");
}
record ChangeResponse(string change_id, string status, DateTime created_at);
Bu kod .NET 8 agent içinde zamanlanmış görev (scheduled task) veya manuel tetikleyici ile çalıştırılabilir. Durum geçişi başarısızsa (maintenance window dışında) agent log dosyasına yazar ve IT yöneticisine bildirim gönderir.
Maintenance window entegrasyonu ve pencere dışında engelleme
ShamashAi
dbo.maintenance_windows tablosunda bakım pencerelerini tanımlar:
sql
SELECT window_id, day_of_week, start_time, end_time, risk_level_allowed
FROM dbo.maintenance_windows
WHERE active = 1;
Örnek:
| window_id | day_of_week | start_time | end_time | risk_level_allowed |
|-----------|-------------|------------|----------|--------------------|
| w1 | Saturday | 02:00 | 06:00 | high |
| w2 | Sunday | 01:00 | 04:00 | high |
| w3 | Weekdays | 12:00 | 13:00 | low, medium |
risk_level: high olan bir değişiklik sadece cumartesi 02:00-06:00 veya pazar 01:00-04:00 arasında
in_progress yapılabilir. Hafta içi öğle saatinde denerse API HTTP 409 döner:
{
"error": "change_blocked_outside_window",
"message": "risk_level 'high' değişiklik sadece cumartesi 02:00-06:00 veya pazar 01:00-04:00 pencerelerinde başlatılabilir.",
"allowed_windows": [
{ "day": "Saturday", "start": "02:00", "end": "06:00" },
{ "day": "Sunday", "start": "01:00", "end": "04:00" }
]
}
Bu kontrol sayesinde üretim kritik değişiklikler yanlışlıkla mesai saatinde yapılamaz.
Limitler ve dürüst notlar
- Otomatik rollback tetikleme yok: ShamashAi bir değişikliğin başarısız olduğunu otomatik algılamaz. Rollback kararı ve
rolled_back durumuna geçiş manuel yapılır. SOAR entegrasyonu ile kısmi otomasyon planlanıyor ama şu an dokümantasyon bunu içermiyor.
- Değişiklik onay akışı (approval workflow) sınırlı:
approver alanı sadece metin. Onay butonu veya e-posta onay mekanizması yoktur; onay dış sistemde (Jira, ServiceNow) yapılıp kayıt ShamashAi'a POST edilir.
- Rollback evidence doğrulama yok:
rollback_evidence alanına yazılan metin veya bağlantı ShamashAi tarafından doğrulanmaz. Snapshot gerçekten var mı, log dosyası erişilebilir mi — bu kontroller kullanıcıya bırakılmıştır.
- Risk seviyesi skorlama otomatik değil:
risk_level değerini siz belirlersiniz. ShamashAi "bu değişiklik kaç cihazı etkiler, kaç kullanıcı var" gibi analiz yapıp risk puanı hesaplamaz. Pilot kapsamında detay paylaşılabilir.
- Değişiklik çakışma tespiti yok: Aynı cihazda aynı saatte iki
high riskli değişiklik planlanmışsa ShamashAi sizi uyarmaz. Çakışma kontrolü manuel yapılmalıdır.
Sonuç
ShamashAi Change Calendar modülü, planlı değişiklikleri
dbo.change_calendar tablosunda kaydeder, risk seviyesine göre maintenance window ile eşleştirir, durum geçişlerini
dbo.audit_log'a zincirler ve rollback kanıtlarını compliance evidence pack içine entegre eder. "Cuma akşamı ne yaptık, rollback ne zaman tamamlandı" sorusuna Slack mesajı araması yerine tek SQL sorgusu veya REST API çağrısı ile yanıt verebilirsiniz. ISO 27001 Annex A.8.32 ve KVKK Madde 12 denetimlerinde değişiklik yönetimi sürecinizi kanıtlamak için
GET /reports/evidence-pack endpoint'ini kullanırsınız.
Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim
