Manuel Değişiklik Yönetiminin Gerçek Maliyeti: Fark Etmeden Ödediğiniz Fatura

Şirketinizin veritabanı altyapısı büyüyor. Ekip genişliyor. Sistem karmaşıklaşıyor. Ve siz hâlâ değişiklikleri e-posta zinciriyle onaylıyor, Excel'e not düşüyor, "ekip biliyor" diyerek ilerliyorsunuz. Bu yaklaşım yıllarca "çalışıyor" gibi görünüyor. Çünkü maliyetler tek bir kalemde görünmüyor. Dağılıyor. Gizleniyor. Birikiyor. Ta ki bir gün fatura çıkana kadar. Bu yazı, veritabanı değişiklik yönetimini hâlâ manuel veya yetersiz araçlarla yürüten kurumların farkında olmadan ödediği bedeli anlatıyor. Satır satır.

1. Her Geçiş Bir Kumar Geliştirici script'i hazırladı. Test ortamında çalıştı. "Tamam" mesajı gönderdi. DBA production'a aldı. Bu süreçte şu soruların kaçına net cevap var? Script risk analizi yapıldı mı? WHERE koşulsuz bir UPDATE var mıydı, fark edildi mi? Bu değişiklik hangi bağımlı nesneleri etkiliyor, hepsi test edildi mi? Rollback planı yazıldı mı, test edildi mi? Deployment süresi tahmin edildi mi? Çoğu kurumda bu soruların yarısına bile net cevap yok. Her deployment belgelenmiş bir süreç değil, tecrübeli bir kişinin sezgisiyle yönetilen bir kumar. Küçük tablolarda bu kumar genellikle kazanılıyor. Büyük tablolarda, yoğun saatlerde, yeni bir ekip üyesinin elinde kaybediliyor. Görünmez maliyet: Bir production krizinin ortalama çözüm süresi 3-6 saattir. 3-4 kişi dahil olur. Sadece adam-saat maliyeti değil, o sürede duran işlemler, etkilenen müşteriler, yönetim toplantıları, kök neden analizleri. Yılda 3-4 kriz yaşayan bir kurum, bunun maliyetini hiç hesaplamadan "zaten hep böyle oldu" diye geçiştiriyor.

2. Denetim Hazırlığı: Görünmez Bir Proje BDDK denetimi geliyor. Ya da ISO 27001 yenileme. Ya da bir KVKK soruşturması. "Son 6 ayda veritabanlarınızda yapılan değişikliklerin listesini, kim onayladı bilgisiyle verin" deniyor. Manuel sistemlerde bu talep bir projeye dönüşüyor. Biri e-posta arşivini karıştırıyor. Biri Jira'ya bakıyor. Biri DBA'lara soruyor. Biri eski toplantı notlarını açıyor. Veriler çelişiyor. Bazı değişiklikler hiçbir yerde yok. "O dönemde acil yapıldı, not düşülmedi" cümleleri çıkıyor ortaya. Bu hazırlık süreci ciddi kurumsal kurumlarda 2-4 hafta arasında sürüyor. Bir veya iki kişinin neredeyse tam zamanı bu işe gidiyor. Görünmez maliyet: Denetim hazırlığına harcanan adam-günü maliyeti. Eksik belgeler nedeniyle denetim bulgusu alınma riski. Bir dahaki denetim için aynı sürecin tekrarlanacağı gerçeği. Ve en ağır maliyet: tüm bunları bilerek bir sonraki denetime kadar sistemi değiştirmemek.

3. Standart Yok, Kişi Var Manuel değişiklik yönetiminin en büyük açmazı şu: süreç kişiye bağlı. Kıdemli DBA işleri yönetiyor. Her şeyi biliyor. Nelerin riskli olduğunu sezgisiyle anlıyor. Hangi değişikliğin ne kadar süreceğini tahmin ediyor. Bağımlılıkları kafasından biliyor. Sonra o kişi izine çıkıyor. Ya da işten ayrılıyor. Arkasında ne kalıyor? Belgesiz bir sistem. Kafasındaki bilgi onunla gitti. Yeni gelen DBA aynı sistemi anlamak için haftalarca uğraşıyor. Aynı hatalar yeniden yapılıyor. Aynı çözümler yeniden keşfediliyor. Bu sadece verimlilik sorunu değil. Standartsız ortamlarda her değişiklik farklı yapılıyor. Kimi script başına açıklama yazıyor, kimi yazmıyor. Kimi rollback düşünüyor, kimi düşünmüyor. Kimi test ediyor, kimi "çalışır" deyip geçiyor. Zaman içinde bu tutarsızlık birikir. Sistem büyür ama okunaksızlaşır. Her yeni değişiklik öncekinin üstüne eklenir. Anlayabilen kişi sayısı azalır. Görünmez maliyet: Yeni ekip üyelerinin sisteme adaptasyon süresi uzar. Bilgi transferi olmadan yapılan her ayrılık kurumsal hafıza kaybı. Standart yoksa kalite denetimi de yok.

4. Veritabanı Büyüyor, Ama Doğru Büyüyor mu? Bir kurumun veritabanı 5 yılda nasıl büyür? İyi senaryoda: planlı, belgelenmiş, her değişiklik bir ihtiyaca karşılık veren, temiz bir yapı. Kötü senaryoda: üst üste yığılmış geçici çözümler, kullanılmayan tablolar, birbiriyle çelişen stored procedure'ler, kimsenin silmeye cesaret edemediği nesneler, "o ne işe yarıyor bilmiyorum ama dokunmayalım" kültürü. İkinci senaryo rastlantı değil. Sistematik değişiklik yönetimi olmayan her kurumun kaçınılmaz sonu. Her acil değişiklik bir "geçici çözüm" bırakıyor. Geçici çözümler zamanla kalıcı oluyor. Kalıcı olan geçici çözümler üstüne yenileri ekleniyor. 5 yıl sonra o veritabanında değişiklik yapmak neredeyse imkansız hale geliyor. Her değişikliğin neleri kıracağı bilinmiyor. Test kapsamı genişliyor çünkü her şey her şeye bağlı. Deployment süreleri uzuyor. Ekip değişiklik yapmaktan korkuyor. Teknik borç bu şekilde birikilir. Ve teknik borç faizle geri ödenir. Görünmez maliyet: Karmaşıklaşan sistemde her yeni özelliğin geliştirilme süresi uzar. Her deployment riskli hale gelir. En deneyimli ekip üyeleri "bu sisteme dokunmak istemiyorum" demeye başlar.

5. Kim Girdi, Ne Yaptı? Bilmiyoruz. Production veritabanına erişimi olan kaç kişi var? DBA'lar, geliştiriciler, sistem yöneticileri, danışmanlar, dış destek ekipleri. Belki bir önceki projede geçici erişim verilen ama erişimi kaldırılmamış kişiler. Bu kişilerin geçen hafta ne yaptığını biliyor musunuz? Manuel sistemlerde bu sorunun cevabı genellikle "tam olarak hayır." Bağlantı logları var belki. Ama kim hangi tabloyu sorguladı, kim hangi değişikliği yaptı, kim gece bağlanıp ne yaptı — bu detaylar ya hiç tutulmuyor ya da tutulsa bile analiz edilemiyor. Bu durumun üç farklı riski var. Operasyonel risk: Biri yanlışlıkla bir şey değiştirdi. Sorun çıktı. Kim ne yaptı bilinmiyor. Kaynağı bulmak saatler alıyor. Güvenlik riski: Biri kasıtlı olarak veri görüntüledi ya da değiştirdi. Bunu ispat etmek mümkün değil. Bunu önlemek de mümkün olmadı. Uyum riski: KVKK kapsamında kişisel veriye yetkisiz erişim bir ihlal. Bu ihlalin yaşandığını tespit edememek ikinci bir ihlal. Kurumun "bilmiyorduk" savunması yasal koruma sağlamıyor. Görünmez maliyet: Tespit edilemeyen her ihlal potansiyel bir yaptırım. Açıklanamayan her erişim potansiyel bir itibar kaybı. Kontrol edilemeyen her değişiklik potansiyel bir kriz.

6. "Basit Araçlar" Görünmez Karmaşıklık Üretir JIRA, e-posta, Excel, Confluence. Bunlar kötü araçlar değil. Ama veritabanı değişiklik yönetimi için tasarlanmamışlar. Bu araçlarla süreç yönetilmeye çalışıldığında şu tablo oluşuyor: Onay e-postada ama script Jira'da. Deployment log Excel'de ama rollback planı yoktu zaten. Hangi versiyonun onaylandığı belirsiz çünkü mail ekinde iki farklı dosya vardı. Test ortamında çalıştırılan script ile production'a atılan script aynı mı? Bunu doğrulayan bir mekanizma yok. Her araç kendi silo'sunda çalışıyor. Entegrasyon yok. Bütünleşik görünürlük yok. Bir değişikliğin uçtan uca hikayesini tek bir yerden görmek mümkün değil. Ve her yeni kişi bu dağınık yapıyı öğrenmek zorunda. Kendi yorumunu ekliyor. Yapı daha da dağılıyor. Görünmez maliyet: Araçlar arası geçiş süreleri, bilgi kaybı, tutarsız kayıt kalitesi ve en kritik olanı: denetimde bu dağınık yapıyı "süreç" olarak sunmanın yarattığı güven kaybı.

7. Uzun Vadede Tablo Şu Oluyor Tüm bu maliyetler tek tek küçük görünüyor. Ama birlikte değerlendirildiğinde tablo netleşiyor. Yılda 3-4 production krizi: 50-100 adam-saat. Yıllık denetim hazırlığı: 20-40 adam-gün. Teknik borç nedeniyle uzayan development süreleri: %20-30 verimlilik kaybı. Ekip değişimlerinde yaşanan bilgi kaybı: ölçülemeyen ama hissedilen maliyet. Yetkisiz erişim ya da veri ihlali riski: potansiyel yaptırım ve itibar kaybı. Bu maliyetlerin toplamı, sistematik bir değişiklik yönetimi platformunun yıllık maliyetinin çok üzerinde. Ama görünmez oldukları için hiç hesaplanmıyor.

Peki Neden Değiştirilmiyor? Çünkü "şimdiye kadar çalıştı." Bu cümle gerçek. Ama yanıltıcı. Şimdiye kadar büyük bir kriz yaşanmadıysa bu sisteminizin iyi olduğunu göstermiyor. Henüz çarpmadığınızı gösteriyor. Ve her geçen gün, büyüyen sistem ve artan erişimle birlikte çarpma olasılığı artıyor. Değişim genellikle büyük bir krizden sonra geliyor. BDDK denetiminde ciddi bir bulgu alınıyor. Bir veri ihlali yaşanıyor. Bir production krizi saatlerce sistemi durduruyor. O an değişiklik yönetimine yatırım yapmak kararı çok kolay alınıyor. Ama o an iş işten geçmiş oluyor.

Son Söz Bu yazıyı okurken içinizde "bizde de bu riskler var" hissi oluştuysa bu his doğru. Çoğu kurum bu maliyetleri taşıyor. Farkında olmadan, her gün, biraz biraz. Farkındalık ilk adım. İkinci adım, bu maliyetlerin toplamını hesaplamak ve sistematik bir çözümün ne anlama geldiğini görmek. Üçüncü adım ise harekete geçmek. Büyük bir kriz beklenmeden.

SQL Server değişiklik yönetimi hakkında daha fazla bilgi için: sqlchangeguard.com