Production Veritabanına Kim Dokundu? Bir DBA'nın Sabah 08:15'i
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.
Kahvenizi aldınız, bilgisayarınızı açtınız. İlk mesaj zaten gelmiş. Müşteri hizmetlerinden: "Sipariş ekranı hata veriyor, sabahtan beri müşteriler ulaşamıyor."
DBA olarak bu cümleyi ilk gördüğünüz an içinizde bir şey sıkışır. Hem teknik hem içgüdüsel bir his. Bir şeyler değişti.
Sorguyu çalıştırıyorsunuz. Tablo yapısına bakıyorsunuz. Stored procedure'ü açıyorsunuz.
Değişmiş.
Kim değiştirdi?
Bu Soru Her Şeyi Değiştirir
"Kim değiştirdi" sorusu teknik bir soru gibi görünür. Ama aslında çok daha derin bir şeyi sorguluyor: bu sistemi gerçekten kontrol ediyor muyuz?
Cevabı bulmak için logları karıştırmaya başlıyorsunuz. Transaction logları, Windows event logları, belki dağınık e-postalar. Birkaç saat sonra muhtemelen bir isim bulacaksınız. Ya da bulmayacaksınız.
Bu ikinci ihtimal, yani "bulamıyoruz", bir kriz değil. Krizin ötesinde bir şey. Sistemin kör noktası.
Göremediğiniz Şeyi Yönetemezsiniz
Yönetim biliminde klasik bir söz var: ölçemediğiniz şeyi yönetemezsiniz.
Veritabanı yönetiminde bunun bir adım önce gelen versiyonu var: göremediğiniz şeyi yönetemezsiniz.
Bir veritabanında her gün onlarca, büyük kurumlarda yüzlerce değişiklik olabilir. Bunların tamamını görmek demek, kimin ne zaman, hangi nesneye, ne yaptığını bilmek demek. Bu bilgi olmadan yönetim değil, tahmin yapıyorsunuz.
Ve tahmin üzerine kurulu sistemler, bir gün mutlaka sizi 08:15'te yakalıyor.
"Bende Bir Şey Yok" Kültürü
Üretim ortamında bir şeyler ters gittiğinde toplantı odasına girilir. Herkes birbirine bakar. Kimse sahiplenmez.
Bu kötü niyet değil çoğunlukla. Gerçekten kimse hatırlamıyor. Ya da hatırlıyor ama kayıt olmadığı için kanıtlayamıyor. Ya da yapılan değişiklik o kadar "küçük" görünüyordu ki sorunla bağlantısını kuramıyorlar.
Bu kültür zamanla bir kurumun en büyük operasyonel riskine dönüşür. Çünkü hesap verebilirlik olmayan yerde disiplin de olmaz. Disiplin olmayan yerde hatalar tekrarlanır.
Peki Ya Kasıtlı Değişiklikler?
Çoğu yetkisiz değişiklik kasıtsız. Biri aceleyle production'a bağlandı, bir şeyler yaptı, belki test etmek istedi, belki gerçekten düzeltmeye çalıştı.
Ama her zaman böyle değil.
Bir veritabanına erişimi olan kişi veri değiştirebilir, silebilir, kopyalayabilir. Bunu hiçbir kayıt olmadan yapabiliyorsa, bu hem kurumsal hem de hukuki bir açık demektir.
KVKK kapsamında "kişisel veri güvenliğini sağlamak" yükümlülüğü soyut bir ifade değil. Somut olarak şu anlama geliyor: veritabanınızda kimin ne yaptığını bilmek ve bunu kanıtlayabilmek zorundasınız.
Bu zorunluluğu karşılayamazsanız, bir ihlal yaşandığında "elimizde log yoktu" demek mazeretten çıkıp sorumluluğa dönüşür.
Sysadmin'e Güveniyorsunuz, Ama...
Ekibinize güveniyorsunuz. Bu değerli ve doğru.
Ama güven, denetimi ortadan kaldırmaz. Aksine gerçek güven, denetimle birlikte anlam kazanır.
Sysadmin yetkisine sahip birinin production'da her şeyi yapabilmesi teknik bir gerçek. Bu yetkiyi kaldırmak çoğu operasyonel ortamda mümkün değil. Zaten bunu savunmuyoruz.
Ama şunu savunuyoruz: o kişinin ne yaptığını bilmek mümkün. Ve bilmek, hem kurumu hem de o kişiyi korur.
Bir şey ters gittiğinde "ben yapmadım" iddiasını kanıtlayabilmek de ancak kayıt sisteminin varlığıyla mümkün.
İki Farklı Sabah
Şimdi iki sabahı hayal edin.
Birinci sabah: Müşteri hizmetleri mesaj attı, hata var. Logları açıyorsunuz, hiçbir şey yok. Kim yaptı bilmiyorsunuz. Saatler harcıyorsunuz. Belki buluyorsunuz, belki bulamıyorsunuz. O sürede sistem çalışmıyor.
İkinci sabah: Müşteri hizmetleri mesaj attı, hata var. Sistemi açıyorsunuz. Dün gece 23:47'de stored procedure X değiştirilmiş. Kim değiştirdi, hangi bağlantıdan, ne değiştirdi, bunların tamamı önünüzde. Beş dakika içinde rollback yapıyorsunuz. Saat 08:22'de sistem tekrar çalışıyor.
Bu iki sabah arasındaki fark bir araç farkı. Ama aynı zamanda bir kültür farkı. Kontrol altındaki bir sistem ile tahmin üzerine çalışan bir sistem arasındaki fark.
Değişiklik Yönetimi Bir Yük Değil
Birçok ekip değişiklik yönetimini ekstra bürokratik iş olarak görüyor. "Zaten az kişiyiz, bir de onay süreci mi?"
Bu bakış açısı tersine çevrilmeli.
Değişiklik yönetimi ekibi yavaşlatmaz. Tam tersi, krizi hızlı çözmesini sağlar. Denetimi kolaylaştırır. Ekip içi güveni artırır. Yeni gelen DBA'nın sistemi anlamasını hızlandırır. Geceleri daha rahat uyumanızı sağlar.
Bürokratik bir yük değil, operasyonel bir güvence.
Başlamak İçin Doğru An Ne Zaman?
Cevap basit: bir kriz yaşamadan önce.
Çünkü kriz yaşandıktan sonra herkes "neden hazırlıklı değildik" diye soruyor. Ama o soruyu sormak için bazen çok geç olabiliyor. Müşteri kaybedilmiş, itibar zedelenmiş, denetim cezası gelmiş.
Değişiklik yönetimi altyapısı kurmanın maliyeti, yaşanmamış bir krizin maliyetiyle kıyaslandığında neredeyse sıfır.
Son Söz
Saat 08:15.
Kahvenizi aldınız, bilgisayarınızı açtınız. İlk mesaj geldi.
Bu kez ne göreceksiniz?
SQL Server değişiklik yönetimi hakkında daha fazla bilgi için sqlchangeguard.com