# DBA'nın Korkulu Rüyası: Açıklanamayan Production Değişiklikleri

Saat 08:15. Ofise girdiniz, kahvenizi aldınız. Monitörü açtınız. İlk bildirim geliyor: "Production'da bir şeyler yanlış."

DBA olarak bu cümleyi duymak yeterince kötü. Ama asıl korku ondan sonra geliyor.

* * *

## "Kim Yaptı?" Sorusu

Sorunu tespit ettiniz. Bir tablo değişmiş, bir index düşmüş, bir stored procedure farklı davranıyor.

Ekibe soruyorsunuz. Kimse sahiplenmedi. Herkes "ben dokunmadım" diyor.

Logları açıyorsunuz. Ya çok detaylı ve içinden çıkılmaz, ya da hiç yok.

Bu nokta DBA'nın gerçek kâbusu. Sorunu bulmak yetmiyor, kaynağını da bulmak zorundasınız. Ama elimizde hiçbir şey yok.

* * *

## Neden Böyle Oluyor?

SQL Server'da varsayılan yapıda DDL değişiklikleri otomatik loglanmaz. Birisi SSMS'i açar, ALTER TABLE çalıştırır, bağlantıyı kapatır. Geriye hiçbir şey kalmaz.

Üstelik sysadmin yetkisine sahip herkes bunu yapabilir. Geliştirici, başka bir DBA, sistem yöneticisi, hatta bazen dışarıdan bir danışman.

Bunu engellemek SQL Server mimarisi gereği mümkün değil. Ama takip etmek mümkün.

* * *

## En Çok Karşılaşılan Senaryolar

**Gece yapılan "küçük düzeltme"** Bir geliştirici acil bir sorunu gidermek için gece production'a bağlanır. "Küçük bir şey" yapar, uyur. Sabah ekibin haberi yok.

**"Test için" yapılan değişiklik** "Sadece test edecektim" diye başlayan müdahale, production ortamında kalır. Haftalar sonra başka bir sorunun kaynağı olur.

**Yetki devri sonrası belirsizlik** Ekipten biri ayrıldı. Onun yaptığı son değişiklikler nerede kayıtlı? Hiçbir yerde.

**Danışman müdahalesi** Dışarıdan gelen bir danışman bir şeyler yaptı. Ne yaptığını biliyor musunuz? Büyük ihtimalle hayır.

* * *

## DBA'nın Buna Karşı Yapabilecekleri

Sıfırdan kurmak isteyenler için birkaç yol:

DDL Trigger yazabilirsiniz. Her CREATE, ALTER, DROP işlemini bir log tablosuna yazdırır. Ama bakımı zordur, devre dışı bırakılabilir, alarm üretmez.

SQL Server Audit aktif edebilirsiniz. Daha kapsamlı ama kurulumu karmaşık, logları düzenli takip etmek ayrı iş yükü demek.

Her ikisi de "bir şey yapıldıktan sonra bakarız" modunda çalışır. Gerçek zamanlı bildirim sağlamaz.

* * *

## Gerçek Zamanlı Tespit

İdeal olan şu: sistem dışından bir değişiklik yapıldığı anda ilgili kişilere bildirim gitsin. DBA sabah değil, o an haberdar olsun.

Bu mümkün. Bunun için değişikliklerin belirli bir platform üzerinden yönetilmesi ve platform dışı her hareketin otomatik tespit edilmesi gerekiyor.

Engelleyemezsiniz, ama haberdar olabilirsiniz. Bu fark, kriz ile kontrollü müdahale arasındaki fark.

* * *

## Sonuç

DBA'nın en büyük güvencesi bilgi. Kimin ne yaptığını bilmek, neyin değiştiğini bilmek, ne zaman değiştiğini bilmek.

Bu bilgi sistematik olarak toplanmıyorsa, kâbus her an gerçeğe dönüşebilir.

Detaylı bilgi için: [sqlchangeguard.com](http://sqlchangeguard.com)