İçindekiler
Uygulama tarafında dağıtım hattı kurmuş bir ekip haklı olarak gurur duyar. Kod deposu, inceleme, otomatik test, sürüm etiketi, geri alma; hepsi yerindedir. Aynı olgunluk veritabanına da uygulanmıştır: şema değişiklikleri sürümlenir, hat bunları taşır, ortamlar tutarlı kalır. Bu yazı o kurulumu eleştirmiyor. Sorduğu soru tek: üretim veritabanınıza ulaşan işin yüzde kaçı gerçekten o hattan geçiyor?
"Biz Bunu CI/CD ile Çözdük"
Bu cümle uygulama katmanı için doğrudur. Veritabanı katmanı için ise kısmen doğrudur ve kısmın büyüklüğü kurumdan kuruma değişir. Fark, hattın kötü olmasından değil, veritabanının koddan farklı davranmasından kaynaklanır.
Kod ile Veritabanı Arasındaki Üç Yapısal Fark
1. Kod geri alınabilir, veri geri alınamaz
Hatalı bir sürümü geri almak, önceki paketi yeniden dağıtmaktır. Hatalı bir güncellemeyi geri almak ise eski değerleri bilmeyi gerektirir ve o değerler artık yoktur. Tablo boşaltma işleminde ise geri dönüş yolu tamamen kapalıdır. Dağıtım hattının "geri al" düğmesi bu iki durumu ayırt etmez; ikisine de aynı gözle bakar.
2. Kod durumsuzdur, veritabanı durum taşır
Aynı dağıtımı iki kez çalıştırmak uygulamada zararsızdır. Aynı betiği iki kez çalıştırmak veritabanında sonucu ikiye katlayabilir. Bu yüzden veritabanı betiği yazarken idempotentlik ayrı bir disiplindir ve hattın kendisi bunu denetlemez.
3. Doğru betik yine de üretimi durdurabilir
Bu, en çok gözden kaçan farktır. İnceleme betiğin doğruluğuna bakar. Üretimi durduran şey ise betiğin davranışıdır. Boş olmayan büyük bir tabloya varsayılan değerli bir kolon eklemek, çevrimdışı bir indeks yeniden oluşturmak, tek işlemde milyonlarca satır güncellemek, bir kısıtı doğrulamak: hepsi tamamen doğru olabilir ve hepsi kilitlenmeye yol açabilir. Bir indeksi veya istatistiği kaldırmak ise etkisini ertesi gün gösterir; dağıtım başarılı görünür, sorun sabaha çıkar.
Dürüst sınır
Hiçbir ürün bir betiğin kilit süresini önceden söyleyemez ve bunu vaat eden bir anlatı doğru olmaz. Yapılabilecek olan farklıdır: riskin içerikten üretilmesi (hangi nesne, hangi ifade türü, kritik nesne eşleşmesi var mı, koşul var mı), geri alma betiğinin önceden hazırlanması ve etkilenen satır sayısının çalıştırma sonrası kaydedilmesi.
Hattan Geçmeyen Yedi Yol
Bu yolların hiçbiri kural ihlali değildir. Her birinin gerekçesi o an makuldür. Kurumun yaşadığı şey kural ihlali değil, kapsam dışılıktır.
| Yol | O anki gerekçe | Geride bıraktığı |
|---|---|---|
| Acil düzeltme | Müşteri etkileniyor, beklenemez | Kayıt var, sonradan değerlendirme çoğu zaman yok |
| Veri düzeltmesi | Tek satır, sürüm çıkarmaya değmez | Şema değişmediği için hiçbir sürüm kaydına girmez |
| Yetki değişikliği | Yeni ekip üyesine erişim gerekiyor | Kimin neye eriştiği sessizce genişler |
| Bakım işleri | Rutin, her ay yapılıyor | İçeriğini yıllardır kimse okumamış zamanlanmış işler |
| Tedarikçi güncelleyicisi | Ürünün kendi aracı yapıyor | Değişikliği kurum yapmadı, sorumluluk kurumda kaldı |
| Sürüme gizlenmiş betik | Sürüm zaten onaylı | Onay sürüme verildi, veritabanı değişikliği ayrıca değerlendirilmedi |
| Üretimden veri okuma | İş birimi rapor istedi | Hat okuma taleplerini hiç taşımaz; dosya birinin bilgisayarında kalır |
Hattın Sessizliği Neden "Sorun Yok" Diye Okunuyor
Bir dağıtım hattı yalnızca taşıdığını bilir. Taşımadığı hakkında hiçbir şey söylemez, çünkü söyleyecek verisi yoktur. Sorun burada başlar: hattın raporu temiz göründüğünde bu, "üretimde başka bir şey olmadı" gibi okunur. Oysa raporun anlamı yalnızca "hattan başka bir şey geçmedi"dir.
Aynı okuma hatası denetimde de yapılır. "Yetkisiz değişiklik tespit edilmedi" satırı iki farklı anlama gelebilir: gerçekten olmadı, ya da bakılan yerde görünmüyor. Bunlar aynı satırla ifade edilir ve ayırt edilemez.
Hattaki Doğrulama ile Karar Aynı Şey Değil
Olgun ekipler hatta doğrulama adımları koyar: koşulsuz güncelleme engellenir, adlandırma kuralı kontrol edilir, betiğin idempotent olması zorunlu tutulur. Bu adımlar değerlidir ve bir kısmı yönetişim katmanının yaptığı işle örtüşür.
Örtüşmeyen kısım şudur: doğrulama teknik bir kapıdır, karar ise yönetişimsel bir kayıttır. Doğrulama "bu betik kuralı ihlal ediyor" der ve durur. Kayıt şunu söyler: bu betik şu kuralı tetikledi, tetiklendiği için şu ek onay istendi, onayı şu rol verdi, o gün yürürlükteki kural seti buydu ve karar şu gerekçeyle alındı. Aylar sonra sorulan soru ikincisidir.
Bir başka fark daha var: hattaki kural, hattın konfigürasyonunda durur ve zaman içinde değişir. Bugünkü kuralla altı ay önceki bir kararı açıklamaya çalışmak yanıltıcıdır. Kararın hangi kurala dayandığının, o günkü haliyle kararın yanında donmuş olması gerekir.
Yönetişim Hattı Yavaşlatır mı
Kötü kurgulanmış bir onay süreci yavaşlatır, bu doğru. Her değişikliği merkezi bir kurula göndermek de çerçevelere uygunluk değil, çerçeveden sapmadır: ITIL 4 bunu açıkça bir anti-desen olarak adlandırır ve gerekçesini de yazar. Kurul darboğaza dönünce insanlar etrafından dolaşır, değişiklikler incelenmeden geçer ve ortamda neyin değiştiğine dair görünürlük kaybedilir.
Doğru kurgu risk tabanlıdır. ITIL 4 üç değişiklik türü tanımlar ve standart değişikliğin prosedürünün önceden yetkilendirildiğini, örnek başına onay gerekmediğini söyler. Aynı çerçeve, değişiklik yetkilisinin bir kişi, bir ekip veya otomatik bir mekanizma olabileceğini de yazar. Yani kural motorunun karar vermesi çerçeveye aykırı değildir; çerçevenin öngördüğü şeydir.
Pratikte bu şu demek: düşük riskli, kural tetiklemeyen bir betik kimseyi beklemez. Kritik bir nesneye dokunan, koşulsuz güncelleme içeren veya geri alınamayan bir betik ek adım ister. Yavaşlayan tek şey riskli iştir ve amaç zaten budur.
Tek Bir Sayıyla Ölçün
Bu tartışmayı bitiren tek bir ölçüm var ve çoğu kurum bu sayıyı daha önce hiç hesaplamamıştır:
Geçen ay üretim veritabanınızda çalışan şema ve veri değiştiren ifadelerin yüzde kaçı dağıtım hattından geçti?
Sayıyı hesaplamak için veritabanının kendi kayıtlarına bakmak gerekir, hattın kayıtlarına değil. Hattın kaydı paydayı değil, yalnızca payı verir. Payda ancak veritabanı tarafından ölçülebilir.
Sayı yüzde yüze yakınsa yönetişim katmanına ihtiyacınız daha azdır ve bunu dürüstçe söyleriz. Sayıyı hiç bilmiyorsanız, önce onu ölçün. Çoğu kurumda bu sayı ilk kez hesaplandığında beklenenin altında çıkar ve tartışmanın tonu değişir.
Hattınız yerinde kalsın
Hattın taşımadığı yolların da aynı kayıt modeline nasıl girdiğini, mevcut kurulumunuz üzerinden gösterelim.
Demo Planlayın →Sık Sorulan Sorular
CI/CD hattımız veritabanı değişikliklerini de taşıyor. Neden ayrı bir yönetişim katmanı gereksin?
Hat yalnızca taşıdığını bilir; taşımadığı hakkında sessizdir ve bu sessizlik sorun yok diye okunur. Üretim veritabanına ulaşan işin bir kısmı hattan geçmez: acil düzeltme, tek satırlık veri düzeltmesi, yetki değişikliği, zamanlanmış bakım işleri, tedarikçi güncelleyicisi ve üretimden veri okuma talepleri. Ölçülmesi gereken tek sayı şudur: geçen ay üretimde çalışan şema ve veri değiştiren ifadelerin yüzde kaçı hattan geçti. Bu sayı yalnızca veritabanı tarafından hesaplanabilir.
Hattımızda zaten doğrulama adımları var. Koşulsuz UPDATE engelleniyor.
Bu değerli bir kontroldür ve bir kısmı yönetişim katmanıyla örtüşür. Örtüşmeyen kısım şudur: doğrulama teknik bir kapıdır, karar ise yönetişimsel bir kayıttır. Doğrulama bu betik kuralı ihlal ediyor der ve durur. Kayıt ise şunu söyler: bu betik şu kuralı tetikledi, bu yüzden şu ek onay istendi, onayı şu rol verdi ve o gün yürürlükteki kural seti buydu. Aylar sonra denetimde sorulan soru ikincisidir.
Liquibase veya Flyway kullanıyoruz. Bu yeterli değil mi?
Şema sürümleme araçları planlı şema değişikliğini sürümlemek ve ortam tutarlılığını korumak için doğru araçlardır ve kaldırılmalarını önermeyiz. Kapsamları dışında kalan şey planlı şema dışındaki her şeydir: veri düzeltmesi, yetki değişikliği, bakım işleri, acil müdahale ve üretimden veri okuma talepleri. Ayrıca bu sürümün üretimde çalışmasına kimin hangi risk değerlendirmesiyle karar verdiği bilgisi de bu araçların görev tanımında değildir.
Yönetişim katmanı teslimat hızımızı düşürür mü?
Kural risk tabanlı işlediğinde düşürmez. Kural tetiklemeyen düşük riskli bir betik kimseyi beklemez. Kritik bir nesneye dokunan, koşulsuz güncelleme içeren veya geri alınamayan bir betik ek adım ister. ITIL 4 standart değişikliğin prosedürünün önceden yetkilendirildiğini ve örnek başına onay gerekmediğini söyler; ayrıca değişiklik yetkilisinin bir kişi, bir ekip veya otomatik bir mekanizma olabileceğini de yazar. Her değişikliği merkezi bir kurula göndermek ise ITIL 4 tarafından açıkça anti-desen sayılır.
Doğru yazılmış bir betik neden üretimi durdurabilir?
Çünkü inceleme betiğin doğruluğuna bakar, üretimi durduran şey ise betiğin davranışıdır. Büyük ve boş olmayan bir tabloya varsayılan değerli kolon eklemek, çevrimdışı indeks yeniden oluşturmak, tek işlemde milyonlarca satır güncellemek veya bir kısıtı doğrulamak tamamen doğru olabilir ve yine de kilitlenmeye yol açabilir. İndeks veya istatistik silmek ise etkisini ertesi gün gösterir. Hiçbir ürün kilit süresini önceden söyleyemez; yapılabilecek olan riski içerikten üretmek, geri alma betiğini önceden hazırlamak ve etkilenen satır sayısını çalıştırma sonrası kaydetmektir.