Prod’a Geçmeden Önce: Veritabanı Değişiklik Sürecini Ciddiye Almanın Tam Zamanı

Şunu kabul edelim: çoğu kurumda “veritabanı değişiklik süreci” diye bir şey var ama bu süreç büyük ölçüde kişilerin birikimine, tecrübesine ve o günkü dikkatine dayanıyor. Bir DBA sabahın köründe acil bir geçiş yapıyorsa, kontrol listesi zihninde. Onay alınmışsa genellikle bir mail zincirinde. Test yapılmışsa belki.

Bu yazıda dört temel konuyu gerçekçi bir gözle ele almak istiyorum: prod geçişinde ne kontrol edilmeli, değişiklik kontrol süreci nasıl kurulur, görevler ayrılığı nasıl işler ve bütün bunları bir arada düşündüğünüzde sizi nerede buluyorsunuz?

1. Prod Geçiş Kontrol Listesi: Yazılı Olmayanlar Yok Sayılır

Her kurumun “zaten bilinen” bir kontrol listesi var. Problem şu: yazılı olmayan, sisteme girmeyen ve kişiden bağımsız çalışmayan bir liste, gerçek anlamda liste değil.

Prod geçişi öncesinde şu soruların net cevabı olmalı:

Script tam olarak ne yapıyor? Hangi tablolara, hangi nesnelere dokunuyor? Bu soruyu gözle script okuyarak cevaplamak yerine, sistemin otomatik analiz etmesi gerekiyor. Özellikle uzun ve karmaşık script’lerde gözden kaçan bir satır, büyük sonuçlar doğurabiliyor.

Hangi ortamda, ne zaman test edildi? “Test ettim” bir bilgi değil. Test ortamı ne, sonuç ne, kaç saniye sürdü, hata aldı mı almadı mı? Bu bilginin bir yerde kayıtlı olması gerekiyor.

Rollback senaryosu var mı ve hazır mı? Script başarısız olursa ya da istenmeyen bir sonuç üretirse geri dönüş planı nedir? Bu plan üretilmiş mi yoksa “bir sorun olursa bakarız” mı?

Bağımlılıklar değerlendirildi mi? Bu değişiklik başka bir nesneyi, başka bir süreci etkiler mi? Özellikle çok sayıda talep aynı anda prod’a alınıyorsa sıralama önemli.

Bunların tamamı elle doldurulan bir formdaysa, süreci değil niyeti yönetiyorsunuz demektir.

2. Değişiklik Kontrol Süreci: “Onay Aldım” Yetmiyor

Bir script’in onaylanması için şu an kurumunuzda ne gerekiyor? Büyük ihtimalle bir mail ya da sözlü “tamam.” Bu iki şeyden biri hiçbir zaman kanıt sayılmaz; biri kaybolur diğeri hiç var olmaz.

Gerçek anlamda bir değişiklik kontrol süreci şu unsurları içeriyor:

Her değişiklik talep olarak sisteme giriyor. “Ağzından çıkan” ya da mail üzerinden iletilen değil, kayıt numarasıyla takip edilebilen, durumu görünür olan bir talep.

Talep içeriği değerlendirilebilir hale geliyor. Onaylayan kişinin önüne sadece “şu script’i geçeceğim” bilgisi değil, script’in analiz sonucu, risk seviyesi ve etki alanı geliyor. Böylece onay bilinçli veriliyor.

Her statü değişikliği kayıt altına alınıyor. Kim onayladı, ne zaman, hangi aşamada ne oldu, execution ne kadar sürdü, hata aldı mı? Bunlar otomatik olarak oluşuyor, kimse “şimdi bunu da yazayım” diye uğraşmıyor.

Değişiklik kontrol sürecinin işe yaraması için bir şart var: kişiden bağımsız olması. Süreç o kişi olmadan da aynı şekilde çalışmalı. Aksi halde süreç değil, o kişi var.

3. Görevler Ayrılığı: Kâğıtta Var, Pratikte Nerede?

COBIT’te var. ITIL’de var. BDDK yönetmeliğinde var. Hemen her kurumun iç denetim politikasında var.

“Aynı kişi hem değişikliği talep edip hem onaylayıp hem de çalıştırmamalı.”

Bu ilkeyi bilen herkes biliyor. Uygulaması ise çoğunlukla şöyle oluyor: küçük ekiplerde aynı kişi her şeyi yapıyor ama “onay alındı” yazılıyor. Ya da DBA hem onaylıyor hem execute ediyor çünkü başka kimse teknik olarak değerlendiremez.

Görevler ayrılığını gerçekten uygulamak için önce rolleri net tanımlamak gerekiyor. Kim talep açabilir? Kim onaylayabilir? Kim execute edebilir? Kim sadece görebilir?

Sonra bu rollerin sistem üzerinde tanımlı olması gerekiyor. “X kişisi onaylamaz çünkü biliyoruz” değil, “X kişisi sistem üzerinde onaylama yetkisine sahip değil” olmalı. İkincisi hem denetlenebilir hem de kişiden bağımsız.

Bir de şu gerçeği söyleyelim: görevler ayrılığı sadece güvenlik için değil, aynı zamanda çalışanı korumak için. Tüm yetkiye sahip tek bir kişi, tüm sorumluluğu da taşıyor. O kişi bir hata yaptığında arkasında sistematik bir süreç yok, sadece kendisi var. Bu hem kuruma hem de o kişiye haksızlık.

4. Değişiklik Yönetiminde Olgunluk: Nerede Duruyorsunuz?

Veritabanı değişiklik yönetimini bir olgunluk skalasında düşünebilirsiniz. Basitçe üç seviye:

İlk seviye — Reaktif: Değişiklikler yapılıyor, bir şeyler yanlış gittiğinde müdahale ediliyor. Süreç yok, sadece alışkanlık var. Kanıt isteniyor, aranıyor, bulunamıyor. Denetim dönemi en stresli dönem oluyor.

İkinci seviye — Prosedürel: Bir süreç var, yazılı da olabilir. Ama büyük ölçüde manuel. Onaylar alınıyor ama takibi zor. Raporlama elle yapılıyor. Süreç kişiye bağlı, ekip değişimlerinde sarsılıyor.

Üçüncü seviye — Sistemik: Talep girişinden execution’a kadar her adım sistem üzerinde. Kontroller otomatik. Raporlama anlık. Görevler ayrılığı sistem düzeyinde tanımlı. Kanıtlar sonradan üretilmiyor, sürecin doğal çıktısı olarak zaten var. Denetim hazırlığı sıfır.

Çoğu kurum birinci ile ikinci seviye arasında bir yerde duruyor. Üçüncü seviyeye geçiş için büyük bir yatırım ya da köklü bir değişim şart değil. Doğru araç ve doğru süreç tasarımıyla bu geçiş düşündüğünüzden kısa sürebiliyor.

Bunları Bir Arada Düşündüğünüzde

Prod geçiş kontrol listesi, değişiklik kontrol süreci, görevler ayrılığı ve değişiklik yönetimi olgunluğu birbirinden bağımsız konular değil. Birini çözerseniz diğerleri de oturuyor. Birini atlarsanız diğerleri havada kalıyor.

SQL Change Guard bu dört konuyu tek bir sistem altında birleştiriyor. Script analizi otomatik yapılıyor ve kontrol listesi sisteme gömülü hale geliyor. Onay akışı ve aksiyon logları değişiklik kontrol sürecini oluşturuyor. Rol tanımları görevler ayrılığını sistem düzeyine taşıyor. Bütün bunlar bir arada çalışınca değişiklik yönetimi olgunluğu kendiliğinden yükseliyor.

Kendi sürecinizin bu dört başlık karşısında nerede durduğunu görmek ister misiniz? 15 dakikalık bir demo yeterli.

E-posta: info@sqlchangeguard.com Web: www.sqlchangeguard.com

SQLChangeGuard #SQLServer #ProdDeployment #ChangeManagement #SeparationOfDuties #DatabaseGovernance #ChangeControl #DBA #BilgiGüvenliği #COBIT #ITIL #BDDK #VeritabanıYönetimi