Bu Aracı Kendimiz Yazsak Olmaz mı?

Yetkin bir yazılım ekibi olan her kurumda bu soru sorulur ve sorulması doğrudur: "Bunu biz de yazarız, neden dışarıdan alalım?" Cevabımız hiçbir zaman "yazamazsınız" olmadı. Bu yazı, kararı verirken gerçekten bakılması gereken kalemleri sıralıyor. Bazı kurumlarda cevap "yazın" olacaktır ve bunu dürüstçe söylüyoruz.

Yazabilirsiniz, Soru O Değil

Bir bankanın veya büyük bir kurumun yazılım ekibi bu aracı yazabilir. Nitekim Türkiye'de birkaç büyük kurum bunu yapmış ve kendi iç değişiklik yönetimi platformunu kurmuştur. Bu platformların bazıları yüzden fazla doğrulama kuralı çalıştırıyor, seviyelere ayırıyor ve kurumsal bilet sistemiyle entegre çalışıyor. Yani soru yetkinlik sorusu değil.

Gerçek soru şudur: bu sizin çekirdek işiniz mi ve önümüzdeki beş yıl boyunca bakımını üstlenmeye hazır mısınız?

Görünen İş: Bir Form ve Bir Onay Adımı

İlk tahmin genellikle şöyledir: bir talep formu, betiğin yapıştırılacağı bir alan, bir onay adımı, bir çalıştırma düğmesi ve bir log tablosu. Bu, iki ile üç aylık bir iştir ve gerçekten de öyledir. Sorun tahminin yanlış olması değil, tahminin işin yalnızca görünen kısmını kapsamasıdır.

Görünmeyen İş: Yedi Kalem

1. Gerçek dilbilgisiyle ayrıştırma

Kural yazmanın kolay yolu metin arama ve düzenli ifadedir. Çalışmaz. Bir yorum satırının içindeki DELETE ile gerçek bir DELETE aynı görünür. Dizge içindeki tablo adı gerçek tablo adı sanılır. Alt sorgu, ortak tablo ifadesi, birleştirme, dinamik SQL: hepsi metin aramasını yanıltır. Güvenilir kural için ifadenin sözdizim ağacını çıkarmak gerekir ve bu, veritabanı motoru başına ayrı bir ayrıştırıcı demektir. Üç motoru yönetiyorsanız üç ayrı ayrıştırıcı bakımı üstlenmişsiniz demektir.

2. Bulgunun nesneye bağlanması

"Bu betikte koşulsuz güncelleme var" demek yetmez. Hangi tabloda olduğunu söylemeniz gerekir, çünkü kritik nesne listesiyle eşleşme buradan çıkar. Çok ifadeli bir betikte her bulgunun kendi nesnesine bağlanması, ayrıştırıcının üstüne yazılan ayrı bir katmandır.

3. Kuralın o günkü halinin dondurulması

Kural setleri değişir. Altı ay önce verilmiş bir kararı bugünkü kuralla açıklamak yanıltıcıdır ve denetimde kabul edilmez. Kararın yanında, o gün yürürlükte olan kural setinin donmuş bir kopyası durmalıdır. Bu, veri modelinde baştan düşünülmesi gereken bir tasarım kararıdır; sonradan eklemek geçmiş kayıtları kurtarmaz.

4. Kurcalanamaz denetim izi

Bir log tablosu denetim izi değildir. Denetçi "bu kaydın değiştirilmediğini kanıtlayın" der. Kaydı tutan ekibin veritabanı yetkisi olduğu sürece tablo tek başına bunu kanıtlayamaz. Kaydın motorun değiştirmeye izin vermediği bir yerde tutulması, özetinin düzenli olarak dışarıdaki kilitli bir depoya yazılması, dışa verilen paketlerin imzalanması ve imza anahtarının yönetimi, bütün bunların denetçi tarafından bağımsız doğrulanabilmesi: hepsi ayrı ayrı tasarlanması gereken konulardır. En sık yapılan hata, uygulamanın kendi hesapladığı anahtarsız bir özet zinciri kurmaktır; veritabanına yazabilen biri zinciri baştan hesaplayabileceği için o zincir hiçbir şey kanıtlamaz.

5. Hassas veri tespiti ve maskeleme

Üretimden veri okuma tarafını da yönetmek istiyorsanız iş büyür. Kolonun hassas olup olmadığına yalnız ada bakarak karar veremezsiniz; içeriğin doğrulanması gerekir. Kimlik numarası biçimsel olarak doğru mu, kart numarası sağlama basamağını tutuyor mu, hesap numarası geçerli mi. Sonra maskeleme biçimi, kısmi maskeleme, maskesiz talep için ek onay, sonucun nasıl teslim edileceği, teslim paketinin şifrelenmesi ve parolanın nasıl iletileceği gelir. Bu tek başına bir üründür.

6. Geri alma betiği üretimi

Şema ve prosedür değişikliklerinde geri alma betiği, nesnenin sunucudaki güncel tanımından üretilebilir. Bunun için hedef sunucudan tanım çekmek, her motorun kendi meta veri yapısını bilmek ve ifade biçimlerini doğru üretmek gerekir. Veri değiştiren ifadelerde ise tam geri alma üretilemez ve bunu dürüstçe söyleyen bir tasarım gerekir. Sahte güven veren bir geri alma düğmesi, hiç olmamasından daha tehlikelidir.

7. Yetki, roller ve görevler ayrılığı

Onaylayan kişi kendi talebini çalıştırabilir mi? Kendi talebini onaylayabilir mi? Bir rol, kendinden düşük bir rolün kapatması gereken adımı atlayabilir mi? Acil durumda hangi adımlar atlanabilir ve atlanan adım nasıl kayda geçer? Bu soruların her birinin bir varsayılanı, bir sunucu bazlı istisnası ve bir denetim kaydı olması gerekir. En önemlisi: yetki kontrolünün ekranda değil sunucuda uygulanması ve yetki çekildiğinde etkisinin anında olması gerekir.

Asıl Maliyet Yazmak Değil, Yaşatmak

İç araçların ilk sürümü genellikle iyi çıkar. Sıkıntı üçüncü yılda başlar:

• Veritabanı motoru yeni bir sürüme geçer ve ayrıştırıcı yeni sözdizimini tanımaz.
• Aracı yazan iki kişiden biri ayrılır, diğeri başka bir projeye geçer.
• Yeni bir düzenleme gelir ve rapor formatı değişmesi gerekir; sırada bekleyen iş vardır.
• Araç kurum içi bir ürün haline geldiği için kendi güvenlik incelemesine, kendi sürüm yönetimine ve kendi dokümantasyonuna ihtiyaç duyar.
• İkinci bir veritabanı motoru kapsama girer ve iş baştan başlar.

Karar verirken bakılması gereken rakam ilk geliştirme maliyeti değil, üç yıllık toplam sahip olma maliyetidir: geliştirme, bakım, iki kişilik bilgi yoğunlaşmasının riski, güvenlik incelemesi ve dokümantasyon.

Denetçinin İç Araca Sorduğu İki Soru

İç geliştirilen bir yönetişim aracı, denetimde bağımsız bir ürüne göre bir dezavantaj taşır ve bunu bilmek gerekir.

Birinci soru: "Bu aracın kayıtlarını tutan sistem ile o kayıtları üretenler aynı ekip mi?" İç araçta cevap genellikle evettir. Aracı yazan ekip, aracın veritabanına da erişebilir. Görevler ayrılığı ilkesi tam burada zorlanır. Cevabı, kaydın kriptografik olarak ve tercihen ayrı bir yerde korunmasıdır; bu da yukarıdaki dördüncü kaleme geri döner.

İkinci soru: "Kuralların değiştirildiğine dair kayıt var mı?" Bir kontrolü zayıflatmak da bir olaydır ve kayda geçmesi gerekir. Kural setinin kendisi bir yapılandırma tablosunda duruyorsa ve o tabloya yapılan değişiklik kayıt bırakmıyorsa, kontrolün gücü ölçülemez.

Kendi Aracınızı Yazmanın Doğru Olduğu Durumlar

Dürüst olalım. Şu üç durumda kendi aracınızı yazmak makul bir karardır:

• Tek bir veritabanı motoru kullanıyorsanız ve şema dışı iş neredeyse hiç yoksa. Kapsam dar olduğunda maliyet de dardır.
• Zaten bir iç geliştirme platformunuz varsa ve bu, o platformun doğal bir modülüyse. Sıfırdan bir ürün değil, mevcut bir ürüne eklenen bir parçadır.
• Kurumsal süreciniz o kadar özgünse ki hiçbir hazır ürün onu modelleyemiyorsa. Bu nadirdir ama gerçektir.

Buna karşılık şu üç durumda hazır ürün belirgin biçimde daha ucuza gelir: birden fazla veritabanı motoru varsa, üretimden veri okuma tarafı da yönetilecekse ve düzenleyici denetime tabi bir kurumsanız.

Kararı Verirken Sorulacak Beş Soru

• Kaç veritabanı motorunu kapsayacak ve her biri için ayrı ayrıştırıcı bakımını kim üstlenecek?
• Üretimden veri okuma tarafı kapsamda mı? Kapsamdaysa maskeleme ve teslim tarafını da yazacak mısınız?
• Denetim kaydının değiştirilmediğini, kaydı tutan ekipten bağımsız olarak nasıl kanıtlayacaksınız?
• Aracı yazan iki kişi bir yıl içinde ayrılırsa ne olur?
• Üç yıllık toplam maliyeti bir kağıda döktünüz mü, yoksa yalnız ilk sürümün süresini mi konuşuyorsunuz?

Beş soruya da rahat cevap verebiliyorsanız yazın. Cevap veremediğiniz iki soru varsa, en azından karşılaştırmayı yapın.

Sık Sorulan Sorular

Veritabanı değişiklik yönetişimi aracını kendimiz yazabilir miyiz?

Yetkin bir yazılım ekibi bunu yazabilir ve Türkiye'de birkaç büyük kurum yazmıştır. Soru yetkinlik sorusu değil, kapsam ve bakım sorusudur. Görünen iş bir talep formu, bir onay adımı ve bir log tablosudur; iki üç aylık bir iştir. Görünmeyen iş ise gerçek dilbilgisiyle ayrıştırma, bulgunun nesneye bağlanması, kuralın o günkü halinin dondurulması, kurcalanamaz denetim izi, hassas veri tespiti ve maskeleme, geri alma betiği üretimi ile görevler ayrılığı kurallarıdır.

SQL kurallarını düzenli ifadeyle yazsak yetmez mi?

Yetmez. Yorum satırı içindeki bir DELETE ile gerçek bir DELETE metin aramasında aynı görünür. Dizge içindeki tablo adı gerçek tablo adı sanılır. Alt sorgu, ortak tablo ifadesi, birleştirme ve dinamik SQL metin aramasını yanıltır. Güvenilir kural için ifadenin sözdizim ağacını çıkarmak gerekir ve bu, veritabanı motoru başına ayrı bir ayrıştırıcı bakımı demektir.

Log tablosu tutmak denetim izi için yeterli mi?

Değil. Denetçi kaydın değiştirilmediğinin kanıtlanmasını ister. Kaydı tutan ekibin veritabanı yetkisi olduğu sürece tablo bunu tek başına kanıtlayamaz. En sık yapılan hata anahtarsız bir özet zinciri kurmaktır; veritabanına yazabilen biri zinciri baştan hesaplayabileceği için o zincir hiçbir şey kanıtlamaz. Gereken şey motorun değiştirmeye izin vermediği bir defter (örneğin SQL Server ledger tablosu), özetinin dışarıda kilitli bir depoya düzenli yazılması ve denetçinin bunu kendi ortamında doğrulayabilmesidir.

İç geliştirilen bir aracın denetimde dezavantajı var mı?

Bir dezavantajı vardır. Denetçi genellikle iki şey sorar. Birincisi, kayıtları üreten ekip ile o kayıtları tutan sistemi işleten ekibin aynı olup olmadığıdır; iç araçta cevap çoğu zaman evettir ve görevler ayrılığı burada zorlanır. İkincisi, kuralların değiştirildiğine dair kayıt olup olmadığıdır. Bir kontrolü zayıflatmak da bir olaydır ve iz bırakmalıdır.

Hangi durumlarda kendi aracımızı yazmak daha doğru olur?

Üç durumda makul bir karardır: tek bir veritabanı motoru kullanıyorsanız ve planlı şema dışı iş neredeyse hiç yoksa, zaten bir iç geliştirme platformunuz varsa ve bu onun doğal bir modülüyse, ya da kurumsal süreciniz hiçbir hazır ürünün modelleyemeyeceği kadar özgünse. Buna karşılık birden fazla veritabanı motoru varsa, üretimden veri okuma tarafı da yönetilecekse ve düzenleyici denetime tabiyseniz hazır ürün belirgin biçimde daha ucuza gelir.