DBA'nın Korkulu Rüyası: Açıklanamayan Production Değişiklikleri
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
Saat 08:15. Ofise girdiniz, kahvenizi aldınız. Monitörü açtınız. İlk bildirim geliyor: "Production'da bir şeyler yanlış."
DBA olarak bu cümleyi duymak yeterince kötü. Ama asıl korku ondan sonra geliyor.
"Kim Yaptı?" Sorusu
Sorunu tespit ettiniz. Bir tablo değişmiş, bir index düşmüş, bir stored procedure farklı davranıyor.
Ekibe soruyorsunuz. Kimse sahiplenmedi. Herkes "ben dokunmadım" diyor.
Logları açıyorsunuz. Ya çok detaylı ve içinden çıkılmaz, ya da hiç yok.
Bu nokta DBA'nın gerçek kâbusu. Sorunu bulmak yetmiyor, kaynağını da bulmak zorundasınız. Ama elimizde hiçbir şey yok.
Neden Böyle Oluyor?
SQL Server'da varsayılan yapıda DDL değişiklikleri otomatik loglanmaz. Birisi SSMS'i açar, ALTER TABLE çalıştırır, bağlantıyı kapatır. Geriye hiçbir şey kalmaz.
Üstelik sysadmin yetkisine sahip herkes bunu yapabilir. Geliştirici, başka bir DBA, sistem yöneticisi, hatta bazen dışarıdan bir danışman.
Bunu engellemek SQL Server mimarisi gereği mümkün değil. Ama takip etmek mümkün.
En Çok Karşılaşılan Senaryolar
Gece yapılan "küçük düzeltme" Bir geliştirici acil bir sorunu gidermek için gece production'a bağlanır. "Küçük bir şey" yapar, uyur. Sabah ekibin haberi yok.
"Test için" yapılan değişiklik "Sadece test edecektim" diye başlayan müdahale, production ortamında kalır. Haftalar sonra başka bir sorunun kaynağı olur.
Yetki devri sonrası belirsizlik Ekipten biri ayrıldı. Onun yaptığı son değişiklikler nerede kayıtlı? Hiçbir yerde.
Danışman müdahalesi Dışarıdan gelen bir danışman bir şeyler yaptı. Ne yaptığını biliyor musunuz? Büyük ihtimalle hayır.
DBA'nın Buna Karşı Yapabilecekleri
Sıfırdan kurmak isteyenler için birkaç yol:
DDL Trigger yazabilirsiniz. Her CREATE, ALTER, DROP işlemini bir log tablosuna yazdırır. Ama bakımı zordur, devre dışı bırakılabilir, alarm üretmez.
SQL Server Audit aktif edebilirsiniz. Daha kapsamlı ama kurulumu karmaşık, logları düzenli takip etmek ayrı iş yükü demek.
Her ikisi de "bir şey yapıldıktan sonra bakarız" modunda çalışır. Gerçek zamanlı bildirim sağlamaz.
Gerçek Zamanlı Tespit
İdeal olan şu: sistem dışından bir değişiklik yapıldığı anda ilgili kişilere bildirim gitsin. DBA sabah değil, o an haberdar olsun.
Bu mümkün. Bunun için değişikliklerin belirli bir platform üzerinden yönetilmesi ve platform dışı her hareketin otomatik tespit edilmesi gerekiyor.
Engelleyemezsiniz, ama haberdar olabilirsiniz. Bu fark, kriz ile kontrollü müdahale arasındaki fark.
Sonuç
DBA'nın en büyük güvencesi bilgi. Kimin ne yaptığını bilmek, neyin değiştiğini bilmek, ne zaman değiştiğini bilmek.
Bu bilgi sistematik olarak toplanmıyorsa, kâbus her an gerçeğe dönüşebilir.
Detaylı bilgi için: sqlchangeguard.com