Veritabanınıza Güveniyor musunuz, Yoksa Sadece Umut mu Ediyorsunuz?
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
İki farklı DBA vardır dünyada.
Birincisi şöyle düşünür: "Ekibim iyi insanlar, kimse kötü bir şey yapmaz. Bir şey olursa zaten fark ederiz."
İkincisi şöyle düşünür: "Ekibim iyi insanlar. Ve tam da bu yüzden onları korumam gerekiyor."
Bu iki bakış açısı arasındaki fark, bir kurumun veritabanı olgunluğunu belirler.
Güven ile Körlük Arasındaki İnce Çizgi
Güven değerli. Ekibinize güvenmek sağlıklı bir iş ortamının temelidir. Ama veritabanı yönetiminde güven, görünürlüğün yerini tutamaz.
Şöyle düşünün: bir bankanın kasasını yöneten güvenilir bir çalışanı var. Bu çalışana güveniliyor. Ama kasada kamera var, her işlem kayıt altına alınıyor, periyodik sayım yapılıyor.
Bu kamera çalışana güvensizlikten mi konulmuş? Hayır. Hem çalışanı hem kurumu korumak için.
Veritabanı tam olarak böyle. Sysadmin yetkisine sahip birine güveniyorsunuz. Ama o kişinin yaptıklarını kayıt altına almak hem onu hem sizi korur. Bir şey ters gittiğinde "ben yapmadım" demek için bile kayıt gerekiyor.
"Bir Şey Olmadı ki" Yanılgısı
Birçok kurum değişiklik yönetimi ihtiyacını hissetmiyor çünkü "şimdiye kadar bir şey olmadı."
Bu cümle her zaman yanlış. Sadece bazen geç fark ediliyor.
Bir stored procedure üç ay önce değiştirildi. O değişiklikten bu yana üretilen raporlarda küçük bir tutarsızlık var. Kimse fark etmedi çünkü fark büyük değil. Ama üç aylık finansal veri yanlış. Bunun kaynağını bulmak için üç ay önceki değişiklik geçmişine bakılması gerekiyor. Geçmiş yok.
"Bir şey olmadı" değil. "Olanı fark etmedik."
Kontrol İllüzyonu
Veritabanı yönetiminde en tehlikeli his kontrol illüzyonu.
Sisteme her gün bakıyorsunuz. Her şey normal görünüyor. Bu "her şey yolunda" anlamına gelmez. "Görünür bir sorun yok" anlamına gelir. İkisi çok farklı.
Kontrol illüzyonunu kırmak için şu soruyu sorun: son 30 günde veritabanında kaç değişiklik yapıldı? Bunların tamamını listeleyebilir misiniz?
Eğer cevap "tam olarak bilmiyorum" ise, kontrol ettiğinizi düşündüğünüz sistemi aslında sadece gözlemliyor olabilirsiniz.
Olgunluk Seviyeleri
Veritabanı yönetiminde kurumlar genellikle şu evrelerden geçer.
Birinci seviye: Reaktif
Sorun çıkınca müdahale edilir. Değişiklik yönetimi yok, kayıt yok. Her kriz sıfırdan çözülür. Aynı hatalar tekrarlanır.
İkinci seviye: Farkındalık
Sorunların fark edildiği, kayıt tutulmaya çalışıldığı ama tutarsız uygulandığı dönem. Bazen süreç işliyor, bazen atlanıyor. Kişiye bağımlı.
Üçüncü seviye: Tanımlı süreç
Değişiklik yönetimi yazılı kurallara bağlı. Ama hâlâ manuel, hâlâ kişiye bağımlı boşluklar var.
Dördüncü seviye: Ölçülüp yönetilen
Süreç sistematik. Metrikler takip ediliyor. Prosedür dışı değişiklikler otomatik tespit ediliyor. Denetim hazırlığı rutin bir işlem.
Beşinci seviye: Optimize
Süreç sürekli iyileştiriliyor. Geçmiş verilerden öğreniliyor. Değişiklik yönetimi kurumun DNA'sına işlemiş.
Çoğu kurum kendini üçüncü seviyede sanır. Gerçekte birinci veya ikinci seviyededir.
Neden Bu Kadar Zor?
Değişiklik yönetimini kurumsal disiplin haline getirmek neden bu kadar zorlanıyor?
Görünmez getiri. İyi değişiklik yönetiminin getirisi "yaşanmayan krizler." Bunları ölçmek ve raporlamak zor. Yöneticiye "bu ay şu kadar krizi önledik" diyemiyorsunuz.
Kısa vadeli baskı. Hızlı deployment yapın, şimdi çalışsın, sonra belgelenir. "Sonra" çoğunlukla gelmez.
Kültür meselesi. Tek kişinin benimsemesiyle olmaz. Tüm ekibin, hatta yönetimin sahiplenmesi gerekiyor. Bu zaman alıyor.
Yanlış araç kullanımı. Excel, e-posta, iyi niyet. Bunlarla değişiklik yönetimi kurulmaz, sadece taklit edilir.
Bir Gün Mutlaka Gelir
Değişiklik yönetimini ertelemenin bir maliyeti var. Bu maliyet bugün görünmüyor. Ama bir gün mutlaka geliyor.
Ya denetimde "bu değişikliği kim onayladı" sorusuna yanıt veremiyorsunuz.
Ya production'da açıklanamayan bir değişiklik saatlik işlemi durduruyor.
Ya bir veri ihlali yaşanıyor ve kaynağını tespit etmek için geriye dönük bakılacak bir log yok.
Ya da ayrılan bir çalışanın hesabıyla aylar sonra yetkisiz bir giriş yapılıyor.
Bu anlardan biri yaşandığında değişiklik yönetimine yatırım yapmanın ne anlama geldiği çok daha net görünüyor. Ama o an iş işten geçmiş oluyor.
Başlamak İçin Kriz Beklemeyin
Her kriz değişiklik yönetiminin önemine dair en iyi öğretmen. Ama en pahalı öğretmen de o.
Başlamak için büyük bir bütçeye, mükemmel bir plana ya da tam bir ekibe gerek yok. Tek gerek şu: bugün yapılan her değişikliğin kim tarafından, ne zaman, neden yapıldığı kayıt altına alınmaya başlanması.
Bu küçük adım bile çoğu kurumun şu anki durumundan çok daha ileride.
Son Söz
Veritabanınıza güveniyor musunuz, yoksa sadece umut mu ediyorsunuz?
Güven kör olmak değildir. Gerçek güven görünürlükle inşa edilir. Her değişikliğin izlendiğini, her anomalinin tespit edildiğini, her deployment'ın kayıt altında olduğunu bilerek çalışmak — işte o zaman gerçekten güveniyorsunuz demektir.
Geri kalan her şey umuttur.
SQL Server değişiklik yönetimi hakkında daha fazla bilgi için sqlchangeguard.com