# Veritabanınıza Güveniyor musunuz, Yoksa Sadece Umut mu Ediyorsunuz?

İki farklı DBA vardır dünyada.

Birincisi şöyle düşünür: "Ekibim iyi insanlar, kimse kötü bir şey yapmaz. Bir şey olursa zaten fark ederiz."

İkincisi şöyle düşünür: "Ekibim iyi insanlar. Ve tam da bu yüzden onları korumam gerekiyor."

Bu iki bakış açısı arasındaki fark, bir kurumun veritabanı olgunluğunu belirler.

* * *

## Güven ile Körlük Arasındaki İnce Çizgi

Güven değerli. Ekibinize güvenmek sağlıklı bir iş ortamının temelidir. Ama veritabanı yönetiminde güven, görünürlüğün yerini tutamaz.

Şöyle düşünün: bir bankanın kasasını yöneten güvenilir bir çalışanı var. Bu çalışana güveniliyor. Ama kasada kamera var, her işlem kayıt altına alınıyor, periyodik sayım yapılıyor.

Bu kamera çalışana güvensizlikten mi konulmuş? Hayır. Hem çalışanı hem kurumu korumak için.

Veritabanı tam olarak böyle. Sysadmin yetkisine sahip birine güveniyorsunuz. Ama o kişinin yaptıklarını kayıt altına almak hem onu hem sizi korur. Bir şey ters gittiğinde "ben yapmadım" demek için bile kayıt gerekiyor.

* * *

## "Bir Şey Olmadı ki" Yanılgısı

Birçok kurum değişiklik yönetimi ihtiyacını hissetmiyor çünkü "şimdiye kadar bir şey olmadı."

Bu cümle her zaman yanlış. Sadece bazen geç fark ediliyor.

Bir stored procedure üç ay önce değiştirildi. O değişiklikten bu yana üretilen raporlarda küçük bir tutarsızlık var. Kimse fark etmedi çünkü fark büyük değil. Ama üç aylık finansal veri yanlış. Bunun kaynağını bulmak için üç ay önceki değişiklik geçmişine bakılması gerekiyor. Geçmiş yok.

"Bir şey olmadı" değil. "Olanı fark etmedik."

* * *

## Kontrol İllüzyonu

Veritabanı yönetiminde en tehlikeli his kontrol illüzyonu.

Sisteme her gün bakıyorsunuz. Her şey normal görünüyor. Bu "her şey yolunda" anlamına gelmez. "Görünür bir sorun yok" anlamına gelir. İkisi çok farklı.

Kontrol illüzyonunu kırmak için şu soruyu sorun: son 30 günde veritabanında kaç değişiklik yapıldı? Bunların tamamını listeleyebilir misiniz?

Eğer cevap "tam olarak bilmiyorum" ise, kontrol ettiğinizi düşündüğünüz sistemi aslında sadece gözlemliyor olabilirsiniz.

* * *

## Olgunluk Seviyeleri

Veritabanı yönetiminde kurumlar genellikle şu evrelerden geçer.

**Birinci seviye: Reaktif**

Sorun çıkınca müdahale edilir. Değişiklik yönetimi yok, kayıt yok. Her kriz sıfırdan çözülür. Aynı hatalar tekrarlanır.

**İkinci seviye: Farkındalık**

Sorunların fark edildiği, kayıt tutulmaya çalışıldığı ama tutarsız uygulandığı dönem. Bazen süreç işliyor, bazen atlanıyor. Kişiye bağımlı.

**Üçüncü seviye: Tanımlı süreç**

Değişiklik yönetimi yazılı kurallara bağlı. Ama hâlâ manuel, hâlâ kişiye bağımlı boşluklar var.

**Dördüncü seviye: Ölçülüp yönetilen**

Süreç sistematik. Metrikler takip ediliyor. Prosedür dışı değişiklikler otomatik tespit ediliyor. Denetim hazırlığı rutin bir işlem.

**Beşinci seviye: Optimize**

Süreç sürekli iyileştiriliyor. Geçmiş verilerden öğreniliyor. Değişiklik yönetimi kurumun DNA'sına işlemiş.

Çoğu kurum kendini üçüncü seviyede sanır. Gerçekte birinci veya ikinci seviyededir.

* * *

## Neden Bu Kadar Zor?

Değişiklik yönetimini kurumsal disiplin haline getirmek neden bu kadar zorlanıyor?

**Görünmez getiri.** İyi değişiklik yönetiminin getirisi "yaşanmayan krizler." Bunları ölçmek ve raporlamak zor. Yöneticiye "bu ay şu kadar krizi önledik" diyemiyorsunuz.

**Kısa vadeli baskı.** Hızlı deployment yapın, şimdi çalışsın, sonra belgelenir. "Sonra" çoğunlukla gelmez.

**Kültür meselesi.** Tek kişinin benimsemesiyle olmaz. Tüm ekibin, hatta yönetimin sahiplenmesi gerekiyor. Bu zaman alıyor.

**Yanlış araç kullanımı.** Excel, e-posta, iyi niyet. Bunlarla değişiklik yönetimi kurulmaz, sadece taklit edilir.

* * *

## Bir Gün Mutlaka Gelir

Değişiklik yönetimini ertelemenin bir maliyeti var. Bu maliyet bugün görünmüyor. Ama bir gün mutlaka geliyor.

Ya denetimde "bu değişikliği kim onayladı" sorusuna yanıt veremiyorsunuz.

Ya production'da açıklanamayan bir değişiklik saatlik işlemi durduruyor.

Ya bir veri ihlali yaşanıyor ve kaynağını tespit etmek için geriye dönük bakılacak bir log yok.

Ya da ayrılan bir çalışanın hesabıyla aylar sonra yetkisiz bir giriş yapılıyor.

Bu anlardan biri yaşandığında değişiklik yönetimine yatırım yapmanın ne anlama geldiği çok daha net görünüyor. Ama o an iş işten geçmiş oluyor.

* * *

## Başlamak İçin Kriz Beklemeyin

Her kriz değişiklik yönetiminin önemine dair en iyi öğretmen. Ama en pahalı öğretmen de o.

Başlamak için büyük bir bütçeye, mükemmel bir plana ya da tam bir ekibe gerek yok. Tek gerek şu: bugün yapılan her değişikliğin kim tarafından, ne zaman, neden yapıldığı kayıt altına alınmaya başlanması.

Bu küçük adım bile çoğu kurumun şu anki durumundan çok daha ileride.

* * *

## Son Söz

Veritabanınıza güveniyor musunuz, yoksa sadece umut mu ediyorsunuz?

Güven kör olmak değildir. Gerçek güven görünürlükle inşa edilir. Her değişikliğin izlendiğini, her anomalinin tespit edildiğini, her deployment'ın kayıt altında olduğunu bilerek çalışmak — işte o zaman gerçekten güveniyorsunuz demektir.

Geri kalan her şey umuttur.

* * *

*SQL Server değişiklik yönetimi hakkında daha fazla bilgi için* [*sqlchangeguard.com*](http://sqlchangeguard.com)