Bir Yazılım Geliştiricinin İtirafı: Production'a Dokunduğumda Ne Hissediyorum?
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
Bu yazıyı bir itirafla başlatmak istiyorum.
Kariyerimde production veritabanına belgelemeden, onay almadan, "hızlıca bir bakayım" diyerek bağlandım. Birden fazla kez. Muhtemelen sizin de başınıza geldi.
O an hep aynı hissi yaşıyorsunuz: bir yandan "bu küçük bir şey, sorun olmaz" rahatlığı, öte yandan "ya bir şeyler ters giderse" endişesi. İki his aynı anda. Ve çoğunlukla rahatlık kazanıyor.
Production Neden Cazip Geliyor?
Production veritabanına doğrudan bağlanmak teknik olarak mümkün olduğunda, insan doğası devreye giriyor.
Test ortamında denemek zaman alıyor. Onay beklemek sabır istiyor. "Sadece bir bakacağım" ile başlayan şey bazen "tamam şunu da düzelteyim" ile devam ediyor.
Bu bir karakter sorunu değil. Sistem tasarımı sorunu.
Eğer kolay olan yol doğrudan production'a bağlanmaksa insanlar o yolu seçer. Bu kaçınılmaz.
O "Küçük Şey"in Hikayesi
Bir meslektaşımın yaşadığı bir olay anlatayım.
Müşteri şikayeti geldi: bir raporda sayılar yanlış görünüyordu. Klasik "hızlı bakış" kararı alındı. Production'a bağlanıldı, sorgu çalıştırıldı, sorun bulundu. Küçük bir stored procedure hatasıydı. İki satır değişiklik.
Test ortamında çalıştırdı, düzeldi. Production'a attı. Rapor düzeldi. Mutlu son.
Ertesi gün farklı bir müşteri şikayet etti. Farklı bir rapor, farklı bir hata. Araştırıldı. Dün düzeltilen iki satır, başka bir hesaplamayı bozmuştu. O hesaplama daha az kullanılan bir raporun parçasıydı, bu yüzden hemen fark edilmemişti.
Düzeltme iki satırdı. Etkisi iki gün sonra görüldü. Ve bu iki günde onlarca müşteri yanlış rapor aldı.
"Ben Dikkatli Yapıyorum" Yanılgısı
Bu hikayeyi anlattığımda çoğu kişinin ilk tepkisi "ben böyle yapmam, ben daha dikkatli olurum" oluyor.
Bu cümleyi kim söylüyor biliyor musunuz? O meslektaşım da production'a bağlanmadan önce bunu düşünüyordu.
Dikkat bir koruma mekanizması değil. İyi niyetli insanlar da hata yapıyor. Yorgun insanlar daha fazla hata yapıyor. Baskı altındaki insanlar en fazla hata yapıyor.
Ve production'a "hızlıca" bağlanma kararları genellikle müşteri şikayetinin geldiği, herkesin beklediği, baskının en yüksek olduğu anlarda alınıyor.
Süreç İnsanı Korur
Bunu yıllarca yanlış anladım. Değişiklik yönetimi sürecini bir kısıtlama olarak gördüm. "Beni yavaşlatıyor, güvenmiyorlar bana."
Sonra bir şeyi fark ettim: süreç beni de koruyor.
Bir değişiklik onay sürecinden geçtiyse ve bir sorun çıktıysa bu benim hatam değil, sürecin atlayamadığı bir şey. Ama ben tek başıma production'a bağlanıp bir şey yaptıysam ve sorun çıktıysa bu benim hatam. Savunma mekanizmam yok.
Süreç sadece sistemi korumaz. İçindeki insanları da korur.
İki Senaryo
Bir sorun çıktı. Müdür soruyor: "Bu değişikliği kim yaptı, onaylı mıydı?"
Birinci senaryo: "Ben yaptım, onay almadım, hızlıca halledelim diye düşündüm."
İkinci senaryo: "Sistem üzerinden talep oluşturduk, teknik değerlendirme yapıldı, onaylandı ve deployment edildi. Logs'larda görebilirsiniz."
Hangisi daha rahat bir pozisyon? Hangisi daha profesyonel? Hangisi kariyerinizi daha iyi koruyor?
Kültür Meselesi
Değişiklik yönetiminin önündeki en büyük engel teknik değil kültürel.
"Süreç var ama kimse uymuyor" cümlesi birçok kurumun gerçeği. Araç kurulmuş, politika yazılmış ama kültür değişmemiş.
Kültürü değiştirmek için tek bir insan yeterli değil. Ama bir insanın dürüst konuşması başlangıç olabilir.
"Production'a doğrudan bağlanmak yanlış" demek kolay. Bunun neden yanlış olduğunu, hangi riskleri taşıdığını ve alternatiflerin ne kadar daha iyi sonuçlar verdiğini anlatmak daha etkili.
Production'a Son Kez Doğrudan Bağlandığınız Zamanı Hatırlayın
Neyin için bağlandınız? Onaylı mıydı? Kayıt var mı? Bir sorun çıksaydı bunu açıklayabilir miydiniz?
Bu soruları kendi kendinize dürüstçe yanıtlayın. Cevaplar rahatsız ediciyse iyi bir işaret. Değişim rahatsızlıkla başlar.
Son Düşünce
Production veritabanı bir laboratuvar değil. Oraya her dokunuş bir sorumluluğu beraberinde getiriyor. Bu sorumluluğu taşımanın en sağlıklı yolu sistematik bir süreçle desteklemek.
"Ben dikkatli yapıyorum" yeterli değil. Dikkat önemli ama tek başına kafi değil.
Süreç, araç ve kültür. Üçü bir arada.
SQL Server değişiklik yönetimi hakkında daha fazla bilgi için sqlchangeguard.com