İç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 →