DBA Olmayan Biri Production'a Değişiklik Yaptığında Ne Olur?
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
"Sadece küçük bir şeydi" diye başlayan hikayeler çoğunlukla büyük sorunlarla biter.
Gerçek Bir Senaryo
Geliştirici bir performans sorununun kaynağını buldu. Çözüm basit görünüyordu: bir index eklemek. DBA'ya sormak yerine doğrudan production'a bağlandı ve çalıştırdı.
Index eklendi. Başlangıçta her şey iyi göründü. Ertesi gün farklı bir sorgu inanılmaz yavaşladı. Neden? Yeni index başka bir sorgu planını bozmuştu.
Sorunu bulmak saatler aldı. Çünkü kimse o index'ten habersizdi.
Neden Oluyor?
Çünkü erişim var, süreç yok.
Geliştirici production'a bağlanabiliyor. Bağlanabilmek demek değişiklik yapabilmek demek. Araya giren bir onay mekanizması yoksa bu durum kaçınılmaz.
DBA'nın Gözden Kaçırdığı Risk
DBA kendi yaptığı değişiklikleri takip eder. Ama başka birinin yaptığı değişikliği bilmiyorsa, sorun yaşandığında doğru yere bakamaz.
Bu "kör nokta" production sorunlarının en yaygın kaynaklarından biri.
Çözüm: Görünürlük
Teknik olarak yapabilmek ile yapıp yapmadığını bilmek ayrı şeyler.
Production üzerinde kimin bağlandığını, ne yaptığını görebilmek, DBA'nın en temel ihtiyaçlarından biri. Bu görünürlük olmadan veritabanı yönetmek karanlıkta yürümek gibi.
Detaylı bilgi için: sqlchangeguard.com