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. Anahtarlı bir zincir, anahtarın nerede saklandığı, anahtar rotasyonunda zincirin ne olacağı, ayrı bir veritabanında mühürlü ikinci kopya ve bunların doğrulanması: hepsi ayrı ayrı tasarlanması gereken konulardır. 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.

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.