Veritabanı Değişiklik Yönetimi Nedir? Sekiz Adımda Uçtan Uca Rehber

Veritabanı değişiklik yönetimi, bir veritabanı üzerinde yapılacak her değişikliğin talep edilmesinden çalıştırılmasına ve kayıt altına alınmasına kadar geçen sürecin kurallara bağlanmasıdır. Tanım kulağa basit gelir, uygulaması nadiren basittir. Çünkü çoğu kurumda bu süreç bir sistem değil, alışkanlıklar toplamıdır: script e-postayla gelir, onay yazışmada kalır, çalıştırma bir kişinin gece nöbetine bağlıdır ve kayıt yalnızca hafızada durur.

Tanım: Yaygın Yanlış Anlama

En yaygın yanlış anlama, veritabanı değişiklik yönetimini şema teslimatıyla eş tutmaktır. Şema teslimatı, tabloların ve prosedürlerin ortamlar arasında tutarlı biçimde taşınmasıdır. Değişiklik yönetimi ise şu soruların cevabını üretir: Bu değişikliği kim istedi? Neden gerekliydi? Kim inceledi, kim onayladı? Riski neydi? Test edildi mi? Geri alma planı var mıydı? Kim çalıştırdı? Sonuç ne oldu? Bugün kim kanıtlayabilir?

Bir kurum şema teslimatını mükemmel çözmüş olabilir ve yine de bu soruların hiçbirine cevap veremeyebilir. İki konu birbirini tamamlar ama biri diğerinin yerine geçmez.

Sürecin Sekiz Adımı

1. Talep

Değişiklik bir kayıt olarak başlar: kim istiyor, hangi sistem için, hangi iş gerekçesiyle, hangi ortamda. Bu adımın tek amacı sohbeti kayda dönüştürmektir. Talep numarası olmayan bir değişiklik, altı ay sonra hiç olmamış sayılır.

2. Otomatik doğrulama

Script kaydedilirken çözümlenir ve kurum standartlarına göre değerlendirilir. Burada aranan tipik durumlar: WHERE koşulu olmayan UPDATE veya DELETE, TRUNCATE kullanımı, kritik tablolara dokunma, adlandırma kuralı ihlali, geri dönüşü olmayan yapı değişiklikleri. Bu adımın kritik özelliği, insan gözden geçirmesinden önce çalışmasıdır. İnsanı yormadan önce makinenin bakması gerekir.

3. Risk sınıflandırması

Her değişikliğin riski aynı değildir. Bir indeks eklemek ile üretim tablosunda toplu güncelleme yapmak aynı süreçten geçmemelidir. Risk sınıflandırması onay derinliğini belirler. Kritik nokta şudur: sınıflandırma en kötü duruma göre yapılmalıdır. Tetiklenen en yüksek seviye kararı belirlemeli, küçük uyarılar kritik bir bulguyu dengelememelidir.

4. Onay

Onay adımları riske göre değişmelidir. Düşük riskli bir değişiklik tek onayla ilerlerken, kritik tabloya dokunan bir değişiklik veritabanı yöneticisi ve güvenlik onayını birlikte gerektirebilir. Onayın kim tarafından, ne zaman verildiği kaydedilmeli ve talebi açan kişinin kendi talebini onaylayıp onaylayamayacağı açık bir kural olmalıdır.

5. Doğrulama ortamında deneme

Script'in gerçekten çalıştığını production'da öğrenmek pahalı bir öğrenme yöntemidir. Çalıştır ve geri al yaklaşımı, script'i gerçek bir ortamda deneyip etkisini geri alır. Bu adım özellikle uzun süren güncellemelerde beklenmedik kilitlenmeleri önceden gösterir.

6. Geri alma planı

Geri alma planı olmayan bir değişiklik, kabul edilmiş bir risktir. Plan yedekten dönüş olabilir ama yedekten dönüş dakikalar değil saatler alır. Karşıt işlemleri içeren bir rollback script'i çoğu durumda tek gerçekçi seçenektir. Bu script'in değişiklikle birlikte üretilmesi ve talebin parçası olması gerekir.

7. Çalıştırma

Çalıştırma, onaylanmış kaydın üzerinden yapılmalıdır. Onaylanan metin ile çalıştırılan metin arasında fark olmamalıdır; bu ayrım denetimde en sık kırılan noktadır. Bakım penceresi gerekiyorsa çalıştırma planlanmalı, gece uyanmak zorunluluk olmaktan çıkmalıdır.

8. Kayıt ve kanıt

Son adım en çok ihmal edilen adımdır. Sonuç, etkilenen nesneler, süre, hata varsa hata mesajı ve kimin çalıştırdığı kaydedilmelidir. Kayıt sonradan değiştirilebiliyorsa kanıt değeri düşer; bu yüzden bütünlük koruması ciddi kurumlarda beklenen bir özelliktir.

Roller ve Sorumluluklar

Dört Olgunluk Seviyesi

Kurumunuzun bugün nerede olduğunu bulmak için aşağıdaki dört seviyeyi okuyun. Çoğu kurum ikinci seviyede olduğunu düşünürken birincidedir.

• Seviye 1: Sözlü. Script mesajla gelir, onay sözlü verilir, kayıt yoktur. "Kim yaptı" sorusunun cevabı hatırlamaya bağlıdır.
• Seviye 2: Yazışma. Talepler e-posta veya bilet sisteminde tutulur ama script metni ve onay ayrı yerlerdedir. Kanıt toplamak arşiv taraması gerektirir.
• Seviye 3: Merkezî kayıt. Talep, script, onay ve sonuç aynı kayıtta durur. Ancak kontroller hâlâ insan dikkatine bağlıdır ve kural ihlali otomatik yakalanmaz.
• Seviye 4: Politika tabanlı. Kurallar sistemde tanımlıdır, ihlal otomatik yakalanır, onay derinliği riske göre değişir, geri alma üretilir ve kanıt işlem anında oluşur.

En Sık Yapılan Beş Hata

1. Süreci yalnızca DDL için kurmak. Denetimde en çok sorulan DML ve yetki değişiklikleridir. Veri düzeltme script'leri kapsam dışı bırakıldığında en riskli işlemler kayıtsız kalır.

2. Onayı tek kişiye bağlamak. Onaylayan kişi izne ayrıldığında süreç durur ve ekip resmi olmayan yollar bulur. Yedek onaylayıcı tanımlanmalıdır.

3. Acil durum yolunu hiç tanımlamamak. Acil müdahale er ya da geç gerekir. Tanımlı bir istisna yolu yoksa ekip süreci tamamen atlar. Doğru yaklaşım istisnayı yasaklamak değil, kayıt altına almaktır.

4. Test ortamını kapsam dışı bırakmak. Test ortamında gerçek müşteri verisi bulunması yaygın bir durumdur. Kapsam dışı bırakılan ortam, kişisel veri açısından en zayıf halka olur.

5. Kanıtı denetim döneminde toplamaya çalışmak. Kanıt sonradan derlenemez; işlem anında oluşmalıdır. Denetim döneminde ekran görüntüsü toplamak hem pahalıdır hem de kanıt değeri düşüktür.

Uygulama Kontrol Listesi

Sık Sorulan Sorular

Veritabanı değişiklik yönetimi ile şema göçü (migration) aracı aynı şey mi?

Değildir. Göç aracı değişikliği hedefe taşır ve sürümler arasında tutarlılığı korur; teknik teslimat problemini çözer. Değişiklik yönetimi ise kararın kendisiyle ilgilenir: bu değişiklik neden gerekli, riski ne, kim onaylıyor, geri dönüş planı var mı ve karar kanıtlanabilir mi. İki katman birbirinin yerine geçmez, üst üste durur.

Küçük bir ekipte sekiz adımın hepsi gerekli mi?

Adımların hepsi gereklidir ama her adım ayrı bir kişi gerektirmez. Küçük ekipte bir kişi birden çok rolü taşıyabilir; kritik olan aynı işte hem talep eden hem onaylayan olmamasıdır. Adım sayısını azaltmak yerine adımların bir kısmını düşük riskli işlerde otomatik geçirmek daha sağlıklı bir yaklaşımdır.

Olgunluk seviyemizi nasıl ölçeriz?

En pratik ölçüt şudur: aynı değişikliği iki farklı kişi değerlendirdiğinde aynı sonuca varıyor mu? Varıyorsa süreç kişilerden bağımsızlaşmış demektir. İkinci ölçüt kanıttır: geçen ayın herhangi bir değişikliği için kim istedi, kim onayladı, ne çalıştı sorularını dakikalar içinde cevaplayabiliyor musunuz.