Canlıya Geçmeden Önce Sistem Zaten Biliyordu
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
Bir değişiklik canlıya gittiğinde iki şeyden biri olur: ya sorunsuz çalışır, ya da bir şeyler ters gider ve soruşturma başlar. İkinci senaryoda herkes aynı yere koşar loglar, geçmiş, kayıtlar. Ve genellikle bulunan şey, aslında daha önce fark edilebilirdi.
Bu yazıda tam bu noktayı konuşmak istiyorum: bir veritabanı değişiklik platformunun değeri, sorun çıktıktan sonra neyi gösterdiğiyle değil, sorun çıkmadan önce neyi gördüğüyle ölçülür.
Şeffaflık bir özellik değil, bir mimari karardır
"Şeffaf sistem" denince akla genellikle güzel bir dashboard gelir. Renkli grafikler, anlık metrikler, belki bir log ekranı. Bunlar şeffaflığın yüzeyidir.
Gerçek şeffaflık, bir değişikliğin fikir aşamasından canlı ortama taşınmasına kadar geçen her adımın kimin ne zaman ne yaptığının, hangi kararın neden alındığının, hangi onayın kimden geldiğinin herhangi bir anda sorgulanabilir ve doğrulanabilir olmasıdır.
SQL Change Guard'ın mimarisini bu anlayış üzerine kurulmuş. Bir değişiklik talebi açıldığı andan itibaren sistem bir zaman damgası basmaya başlıyor: talep kim tarafından açıldı, hangi nesneler dahil, bağımlılık analizi ne gösteriyor, validasyon aşamasından ne çıktı, hangi yetkili hangi saatte onayladı, sandbox'ta nasıl davrandı, canlıya ne zaman taşındı, taşındıktan sonra performans metrikleri ne dedi.
Bu zincir kırılmıyor. Bir halka atlanmıyor. Her adım bir sonrakine bağlanıyor.
Kontrol altında olmak, kısıtlanmak değildir
Kurumsal ortamlarda "kontrollü süreç" kavramı zaman zaman yanlış anlaşılıyor. Geliştiriciler duyduklarında "bürokratik engel" hissedebiliyor. DBA'lar duyduklarında "ek iş yükü" düşünüyor. Yöneticiler duyduklarında "daha yavaş deployment" kaygısı taşıyor.
Ama kontrol, hız düşmanı değildir. Kontrolsüz hız, düzeltme maliyetiyle birlikte hesaplandığında her zaman daha yavaştır.
SQL Change Guard'da her ekip üyesi kendi rolünün gerekliliklerini sistemin içinde buluyor. Geliştirici, değişikliği nasıl tanımlayacağını ve hangi aşamalardan geçireceğini biliyor çünkü platform bunu adım adım gösteriyor. DBA, hangi taleplerin validasyonu geçtiğini ve hangilerinin dikkat gerektirdiğini tek ekranda görüyor. Yönetici, onay süreçlerinin tıkandığı noktaları gerçek zamanlı takip edebiliyor.
Herkes kendi alanında çalışıyor, ama hepsi aynı sistemin parçası. Bu, koordinasyon toplantılarını, "sen ne yaptın, ben ne yapmalıyım" e-postalarını ve kafadan atma kararları azaltıyor. Süreç insanları yönlendiriyor, insanlar süreci yönetiyor.
Hata canlıda değil, daha önce yakalanır
Bir SQL değişikliğinin canlı ortamda sorun çıkarması için mutlaka büyük bir hata yapılmış olması gerekmiyor. Bazen küçük bir gözden kaçma yeterli: bir index eksikliği, bir sorgu planı değişikliği, beklenmedik bir veri hacmiyle karşılaşma.
SQL Change Guard'ın validasyon ve performans analiz katmanları bu küçük ama kritik sorunları erkenden yüzeye çıkarmak için tasarlanmış.
Bir script sisteme yüklendiğinde, validasyon motoru devreye giriyor. Tanımlı kurallara göre analiz yapıyor: bu komut kurum politikasıyla örtüşüyor mu, bu yapıda bilinen bir performans riski var mı, etkilenecek nesne sayısı beklenen sınırlar içinde mi? Bunlar insan gözünden geçmeden önce sistem kendi kontrolünü yapıyor ve işaret ediyor.
Sandbox aşaması ise validasyonun ötesine geçiyor. Değişikliği kontrollü bir ortamda, gerçeğe yakın koşullarda çalıştırıyor. Kaç satır etkilendi, ne kadar sürdü, kaynak tüketimi ne oldu bunlar sayılar halinde geliyor. Canlıya taşımadan önce ekip bir tahminden değil, gerçek bir ölçümden bakıyor.
Risk skoru da bu sürecin bir parçası. Her talep için otomatik olarak üretilen risk değerlendirmesi, onay sürecini de şekillendiriyor: düşük riskli bir değişiklik hızlı ilerleyebilirken, yüksek riskli bir değişiklik daha kapsamlı bir inceleme sürecine giriyor. Bu, DBA zamanını doğru yere harcıyor.
Her şey kayıt altında, sadece neyin kayıt altında olduğu değil
Audit kavramı çoğu zaman dar yorumlanıyor: kimin sisteme girip çıktığı, hangi komutun çalıştığı. Bunlar önemli ama yeterli değil.
SQL Change Guard'ın sağladığı audit, değişiklik yönetiminin tamamını kapsıyor. Kimin hangi talebi açtığı. Talep üzerinde hangi yorumların yapıldığı. Hangi validasyon sonuçlarının üretildiği. Kimin, hangi saatte, hangi yetkiyle onay verdiği. Sandbox'ta ne gözlemlendiği. Canlıya geçişin tam zamanı. Sonrasındaki performans ölçümleri.
Ve bir o kadar önemli: SQL Change Guard dışında yapılan değişiklikler de tespit ediliyor. Birisi doğrudan veritabanına bağlanıp bir nesneyi değiştirdiyse, bu hareket sistem tarafından fark ediliyor ve alarm üretiliyor. Yani "prosedür dışı" hiçbir şey görünmez kalmıyor.
Bu iki taraflı görünürlük hem doğru yoldan gelen değişikliklerin tam kaydı, hem de yanlış yoldan gelen değişikliklerin tespiti gerçek bir audit trail'in temelidir. Kurumunuz bir denetimle karşılaştığında ya da bir soruşturma başlattığında, "ne oldu?" sorusunun cevabı elimizde değil, sistemin içinde zaten var.
Object History: bir nesnenin tüm hayatı tek yerde
Veritabanındaki bir nesneyle ilgili soru sorulduğunda "bu stored procedure ne zamandan beri böyle?", "bu trigger'a en son kim dokundu?", "bu tabloda geçen çeyrek içinde kaç değişiklik yapıldı?" cevap genellikle yoktur. Ya birinin aklındadır ya da eski bir e-postanın derinliklerindedir.
Object History modülü bu boşluğu kapatıyor. Her veritabanı nesnesi için, üzerinde gerçekleştirilen her değişikliğin hangi talebe, hangi kullanıcıya, hangi tarihe ait olduğu görülebiliyor. Bir sorun çıktığında forensik analiz yapılmıyor geçmiş zaten orada, düzenli ve sorgulabilir biçimde duruyor.
Bu özellik özellikle iki durumda kritik öneme sahip: biri canlı ortamda beklenmedik bir davranış gözlemlendiğinde, diğeri yönetimsel veya hukuki bir denetim sürecinde. Her iki durumda da ekip "neyi hatırlıyoruz?" yerine "sisteme bakalım" diyebiliyor.
Rollback: panik değil, prosedür
Canlıya geçen bir değişikliğin geri alınması gerektiğinde ekiplerin yaşadığı stres, çoğu zaman değişikliğin kendisinden değil, geri alma sürecinin belirsizliğinden kaynaklanır. Önceki durum neydi? Tam olarak ne değişmişti? Geri aldığımızda başka bir şey bozulur mu?
SQL Change Guard'da rollback bir prosedürdür, reaktif bir müdahale değil. Değişiklik canlıya taşınmadan önce önceki durum kaydedilmiş olduğu için, geri alma kararı alındığında sistem zaten hazır. Adımlar tanımlı, risk değerlendirilmiş, hareket kontrollü.
Bu, "haydi geri alalım bakalım" ile "rollback prosedürü başlatıyoruz" arasındaki fark. İkincisi hem daha hızlı hem de çok daha güvenli.
Ekipler arası koordinasyon: herkes aynı gerçekliği görüyor
Büyük kurumlarda veritabanı değişikliklerinin en zorlu yanı teknik değildir. Koordinasyondur.
Geliştirici değişikliği hazırladı, DBA inceledi, QA test etti, ops canlıya aldı — ama bu dört adım dört farklı araçta, dört farklı konuşmada, dört farklı zaman çizelgesinde yaşandıysa, ortada tutarlı bir süreç yoktur; sadece bir tesadüfen iş biten bir dizi aktivite vardır.
SQL Change Guard bu ekipleri aynı platform üzerinde buluşturuyor. Herkes kendi rolünden bakıyor ama aynı talebi, aynı durumu, aynı geçmişi görüyor. Bir aşama tamamlandığında bir sonraki sorumluya bildirim gidiyor. Bir talep tıkandığında nerede tıkandığı görünüyor. Kimse "o bana söylemedi" ya da "ben bilmiyordum" diyemiyor.
Koordinasyon, iletişim çabasına değil, sistem tasarımına bırakılmış. Bu ekiplerin işini kolaylaştırmakla kalmıyor, sorumluluk zincirini de netleştiriyor.
Kaygıyla değil, güvenle
Veritabanı yönetiminde kaygı genellikle iki şeyden beslenir: bilmemek ve kontrol edememek. Kim ne yaptı, ne olacak, bir şey ters giderse ne yaparız.
SQL Change Guard her ikisini de adresliyor. Şeffaf süreçler bilmemeyi ortadan kaldırıyor. Validasyon, sandbox ve risk skoru kontrolsüzlüğü azaltıyor. Kapsamlı kayıt ve nesne geçmişi, ters giden her durumda ekibe somut bir zemin sağlıyor.
Sonuçta amaç, veritabanı değişikliklerini heyecan verici olmaktan çıkarmak. Rutin, tahmin edilebilir, denetlenebilir bir süreç haline getirmek.
Sıkıcı bir veritabanı süreci iyi bir veritabanı sürecidir.
SQL Change Guard hakkında daha fazla bilgi almak veya platformu yakından görmek için:
Web: https://sqlchangeguard.com E-posta: info@sqlchangeguard.com
SQL Change Guard; veritabanı değişiklik yönetimini otomatize eden, denetleyen ve ekiplere tam görünürlük sağlayan kurumsal bir platformdur. Sorularınız için her zaman ulaşabilirsini