İçindekiler
Bir sabah test ortamında sorunsuz çalışan bir betik üretimde hata verir. İnceleyince görülür ki üretimdeki tabloda test ortamında olmayan bir kolon var, ya da bir index eksik. Kimse bu farkı ne zaman ve neden oluştuğunu bilmiyordur. Bu duruma şema kayması denir.
Şema Kayması Nedir
Şema kayması, üretim veritabanının yapısının, kayıtlarda yazan hâlinden sessizce ayrışmasıdır. Kaydınız "bu tablonun şu kolonları var" der, gerçek başka şey söyler. Kaymanın tanımı gereği iki özelliği vardır: sessizdir ve zamanla birikir.
Zararı üç yerde görünür. Dağıtım kırılır, çünkü betik beklediği yapıyı bulamaz. Test güvenilirliğini kaybeder, çünkü test ortamı üretimi temsil etmez. Ve denetimde cevap verilemez, çünkü "üretimdeki her değişiklik onaydan geçer" cümlesi tek bir kaymayla çöker.
Kayma Nasıl Oluşur
Kaymanın kaynağı neredeyse hiçbir zaman kötü niyet değildir. Kaynak, aracın kapsamadığı bir yoldan yapılan meşru bir iştir.
| Kaynak | Neden kayıt dışı kalır |
|---|---|
| Gece yapılan acil düzeltme | Üretim durmuşken hattı beklemek kesintiyi uzatır; müdahale doğrudan yapılır |
| Performans için eklenen index | Bakım işi sayılır, değişiklik süreci kapsamında görülmez |
| Yetki ve rol düzenlemesi | Şema değişikliği sayılmaz ama erişim sınırını değiştirir |
| Üçüncü taraf ürünün kendi güncellemesi | Kurulum sihirbazı şemayı kendi değiştirir, kimse betiği görmez |
| Geri alınmış ama tam geri alınmamış bir dağıtım | Oracle'da DDL örtük COMMIT ürettiği için kalıntı kalabilir |
Şema sürümleme aracı kaymayı önlemez
Şema sürümleme araçları kendi taşıdıkları değişiklikleri çok iyi kaydeder. Kaymanın kaynağı ise tam olarak o araçtan GEÇMEYEN iştir. Araç kurulduktan sonra kayma sorununun çözüldüğünü varsaymak, kaymanın en sık yapılan hatasıdır.
Tespit Etmenin Üç Yolu
Bir: iki ortamı karşılaştırmak. Üretim ile test ya da üretim ile sürüm deposu arasında şema farkı alınır. Kolaydır ve hemen sonuç verir. İki zayıf yanı vardır: farkın hangisinin doğru olduğunu söylemez (test mi geride kaldı, üretim mi kaydı) ve elle yapıldığı için yoğun dönemlerde atlanır.
İki: beklenen hâl ile gerçek hâli karşılaştırmak. Ürün, bir nesneye en son uyguladığı değişikliği bilir. Nesnenin sunucudaki güncel tanımı bu beklentiyle uyuşmuyorsa, aradaki fark kayıt dışı bir değişikliktir. Bu yöntem birinciden güçlüdür çünkü hangi tarafın doğru olduğunu söyler: kayıt doğrudur, fark kaymadır.
Prosedür, görünüm, fonksiyon ve tetikleyicide bu karşılaştırma doğrudan yapılabilir, çünkü son uygulanan betik nesnenin tam gövdesidir. Tabloda ise kayıtlar çoğu zaman yalnız yapılan değişikliği taşır (ALTER TABLE ADD COLUMN gibi); beklenen tam hâli üretmek için tanımın çalıştırma anında saklanması gerekir.
Üç: veritabanının kendi izleme düzeneği. DDL tetikleyicisi, genişletilmiş olaylar ya da veritabanı denetim özelliği. Tek gerçek zamanlı yöntem budur ve tek "kim yaptı" cevabını veren de budur. Bedeli, hedef sunucuya kurulum yapmak ve o kaydı saklamaktır; kurumun veritabanı yöneticisinin onayını gerektirir.
Üçüncü yol bizim işimiz değil
Üretim trafiğini gerçek zamanlı izleyip kayıt dışı işlemi yakalamak, veritabanı erişim izleme ürünlerinin alanıdır ve o araçlar bunu bizden iyi yapar. SQL Change Guard bu alana girmez. Bizim ürettiğimiz şey, o izleme kaydının karşısına konacak meşru karardır: talep, kural, onay ve çalıştırma izi. İki katman birbirini doğrular; bizim izimiz olmayan bir değişiklik, izleme aracınız için doğrudan bir istisnadır.
"Kim Yaptı" Sorusu Ayrı Bir Sorudur
Bu ayrımı yapmamak yaygın bir hayal kırıklığı üretir. Karşılaştırmaya dayalı yöntemler "bir şey değişmiş" der; failin kim olduğunu ve ne zaman yaptığını söyleyemez, çünkü karşılaştırma yalnız iki durumu görür, aradaki olayı görmez.
Pratik sonuç şudur: kaymayı görmek ile failini bulmak iki ayrı yatırımdır. Çoğu kurum için doğru sıra önce görmek, sonra gerekirse fail takibine geçmektir. Kaymayı hiç görmeyen bir kurumun fail takibine yatırım yapması, ölçmeden optimize etmeye benzer.
Tespitten Önce: Kaymayı Azaltmak
Kaymayı tespit etmek bir kontroldür ama asıl kazanç kaymanın oluşmasını azaltmaktır. Üç pratik adım:
- Beyan yolunu yapma yolundan kolaylaştırın. Hat dışında yapılan bir işi kaydetmek, işi yapmaktan zahmetliyse kaydedilmez. Bu bir disiplin meselesi değil, tasarım meselesidir.
- Bakım işlerini ve yetki değişikliklerini kapsama alın. Kaymanın en sessiz iki kaynağı bunlardır ve ikisi de çoğu kurumda "değişiklik" sayılmaz.
- Acil yolu kapatmayın, kısaltın. Tamamen kapanan bir kural acil durumda tamamen devre dışı bırakılır ve o gece yapılan iş hiçbir yere kaydedilmez.
Sık Sorulan Sorular
Şema kayması ile veri kayması aynı şey mi?
Değil. Şema kayması yapının (tablo, kolon, index, kısıt, yetki) kayıttan ayrışmasıdır. Veri kayması ise verinin içeriğinin beklenen dağılımdan ayrışmasıdır ve daha çok analitik ile makine öğrenmesi bağlamında kullanılır. Bu yazının konusu birincisi.
Ne sıklıkla kontrol etmeliyiz?
Sıklığı değişiklik hacminiz belirler, ama pratik bir eşik şudur: her sürüm öncesi mutlaka, ayrıca kritik nesneler için düzenli olarak. Sürüm öncesi kontrol, kaymanın en pahalı sonucunu (dağıtımın üretimde kırılması) engeller.
Kayma bulduk, geri almalı mıyız?
Otomatik geri alma tehlikelidir. Bulunan fark meşru bir acil müdahale olabilir ve geri alınması üretimi bozabilir. Doğru sıra şudur: farkı kaydet, kim ne zaman yapmış olabileceğini araştır, meşruysa geriye dönük olarak kayda al, değilse planlı biçimde düzelt.
Üç ortamımız var, hangisi referans olmalı?
Referans hiçbir ortam olmamalı, kayıt olmalıdır. Ortamlardan birini referans seçmek, o ortama yapılan kayıt dışı bir değişikliği kural hâline getirir. Doğru referans, hangi değişikliğin onaylanıp uygulandığını gösteren kayıttır; ortamlar ona göre ölçülür.
Kendi nesnelerinizde deneyin
Bir nesnenin kayıtlı hâli ile sunucudaki güncel tanımını yan yana koyalım, aradaki farkı birlikte okuyalım.
Demo Planlayın →