Birlikte çalıştığım her BES veri ekibinin açıkça konuşmadığı bir anı vardır. EGM veya SEDDK, on katılımcı sertifika numarasından oluşan bir liste gönderir ve belirli bir alanın — genellikle bir devlet katkısı uygunluk bayrağı, belirli bir valör tarihindeki fon dağılımı veya bir giriş aidatı kesintisinin — arkasındaki tam hesaplama izini ister. Ekip, aylık gönderimin doğru olduğunu bilir. Mutabakat toplamları tuttu. Toplu raporlar tüm kontrollerden geçti. Yine de kimse, bir aylık tam veriye karşı pipeline'ı yeniden çalıştırıp çıktıyı grep'lemeden bu on kaydı talep üzerine yeniden üretemez.
Bu bir veri sorunu değildir. Bir mimari sorundur ve Türkiye'deki emeklilik ve sigorta şirketlerinde neredeyse evrenseldir.
Her Şeye İşlenmiş Batch Varsayımı
BES pipeline'ları neredeyse her zaman tek bir çalışma modu etrafında tasarlanır: tam katılımcı popülasyonunu işle, fon fiyatları ile join yap, devlet katkısı kurallarını uygula, hak kazanma hesapla, EGM dosyasını üret. Mantık, batch bağlamının var olduğu varsayımıyla yazılır — geçici tablolar doldurulmuş, referans anlık görüntüleri yüklenmiş, takvim tabloları join edilmiş, önceki ayın bakiyeleri staging'de hazır.
Bu bağlamı kaldırın, kod çalışamaz. Gördüğüm bazı somut örnekler:
- Fon içindeki tüm katılımcıları katkı tarihine göre sıralayan bir window fonksiyonuna bağlı bir devlet katkısı uygunluk hesaplaması. Bunu tek bir katılımcı için çalıştırın, sıralama anlamsızdır.
- DAG'deki önceki bir adım tarafından doldurulan session kapsamlı bir geçici tablodan okuyan bir fon getiri dağılımı. Bu adım hiçbir yerde çağrılabilir bir fonksiyon olarak mevcut değildir.
- Ara verme dönemlerini tespit etmek için popülasyondaki tüm sözleşme olaylarının türetilmiş bir tablosuna join yapan bir hak kazanma süresi hesaplaması. Tek kayıt yürütmesi null döndürür çünkü self-join'in eşleri yoktur.
- Orkestratör tarafından çalıştırma başlangıcında yazılan ve çalıştırma sonunda düşürülen batch seviyesindeki bir parametre tablosuna referans veren ayrılma hesaplamaları.
Pipeline doğrudur. Aynı zamanda kayıt seviyesinde tamamen opak'tır.
Düzenleyici Örneklemesi Altında Bu Neden Başarısız Olur
EGM ve SEDDK veri setlerini denetlemez. Kayıtları denetler. Adli metodolojileri açıkça küçük örnekler etrafında tasarlanmıştır — beş, on, yirmi katılımcı dosyası — çünkü amaç aritmetiği doğrulamak değil, mantığı izlemektir. Denetçi "bu katılımcı Mart ayında neden 24.10 TL yerine 23.47 TL devlet katkısı aldı" diye sorduğunda, beklenen cevap deterministik bir izdir: girdi değerleri, kural referansları, ara hesaplamalar, nihai çıktı.
Denetçinin genellikle aldığı yanıt ise:
- Aylık mutabakat toplamlarının bir ekran görüntüsü.
- "Batch bunu şu şekilde hesaplar" ifadesini içeren bir açıklama.
- Pipeline'ı yeniden çalıştırıp kaydı çıkarma sözü.
- Referans veriler o zamandan beri değiştiği için biraz farklı bir sayı üreten bir yeniden çalıştırma.
Rutin bir nokta kontrolünü bir bulguya dönüştüren şey bu son noktadır. Gönderilen tam sayıyı yeniden üretemiyorsanız, gönderiminizin yeniden üretilebilir olmadığını dolaylı olarak kabul etmişsinizdir. Ve düzenlenmiş bir emeklilik bağlamında yeniden üretilemezlik teknik bir sorun değildir — bir kontrol zayıflığıdır.
Kimsenin Yapmadığı Yeniden Üretilebilirlik Testi
Her BES veri liderine önerdiğim test şudur: geçen ayın gönderiminden on rastgele sertifika numarası seçin. Batch'i yeniden çalıştırmadan ve yalnızca üretimde var olan kodu kullanarak, bu on kayıt için her hesaplanan alanı yeniden üretin ve girdi değerlerini, kural sürümlerini ve ara adımları ortaya koyun.
Çoğu ekip bu testi ilk denemede geçemez. Başarısızlıklar tahmin edilebilir yerlerde kümelenir:
- Referans veri anlık görüntüleri sürümlenmemişti. Fon fiyatı tablosu o zamandan beri güncellendi.
- Kural parametreleri (katkı payı oranları, devlet katkısı tavan) tarih itibarıyla değerler olarak değil, mevcut değerler olarak saklanıyor.
- Ara hesaplama sonuçları kalıcı hale getirilmez. Yalnızca nihai alan gönderim tablosuna iner.
- Hesaplama mantığı yalnızca çalışmak için tam staging ortamını gerektiren bir stored procedure içinde mevcuttur.
Bunların hiçbiri egzotik sorunlar değildir. Kayıt seviyesinde açıklanabilirlik yerine verim ve mutabakat toplamları için optimize etmenin doğal sonucudurlar.
Kayıt Seviyesinde Denetlenebilirliğin Gerçekte Neye İhtiyacı Vardır
Düzenleyici örneklemesinden sağ çıkan bir BES pipeline'ı kurmak, tek kayıt yürütmesini sonradan akla gelen bir şey olarak değil, birinci sınıf bir kullanım durumu olarak ele almak demektir. Pratikte:
- Her kural için saf fonksiyonlar. Devlet katkısı uygunluğu, hak kazanma, fon dağılımı — her biri, batch bağlamına bağımlılık olmaksızın açık girdiler alan ve bir çıktı döndüren çağrılabilir bir fonksiyon olmalıdır. Batch pipeline, denetim aracının çağırdığı aynı fonksiyonu çağırır.
- Tarih itibarıyla referans veri. Bir hesaplamada kullanılan her parametre, oran ve eşik, herhangi bir geçmiş tarih için çözülebilir olmalıdır. Bu, üzerine yazılmış mevcut değer tabloları değil, bitemporal tablolar anlamına gelir.
- Kalıcı ara sonuçlar. Gönderimdeki her hesaplanan alan için, onu üreten ara değerler onun yanında saklanmalıdır — türetilebilir değil, saklanmalı. Depolama ucuzdur. Düzenleyici bulgular değildir.
- Deterministik kural sürümleme. Devlet katkısı mantığının hangi sürümü bu tarihte bu kayıt için çalıştı? Cevap bir arkeoloji projesi değil, bir lookup olmalıdır.
- Tek kayıt replay aracı. Bir analiste bir sertifika numarası ve bir tarih verin, sistem batch altyapısına dokunmadan tam izi üretmelidir.
Mimari değişim önemlidir. Kural mantığını, çoğu BES pipeline'ının birleştirdiği orkestrasyon mantığından ayırmak anlamına gelir. Çoğu ekibin yıllardır ertelediği referans veri sürümlemeye yatırım yapmak anlamına gelir. On milyon kaydı işleyen pipeline ile bir kaydı açıklayan aracın iki değil, aynı sistem olduğunu kabul etmek anlamına gelir.
Rahatsız Edici Yeniden Çerçeveleme
Denetlenebilirlik, ürettiğiniz bir rapor değildir. Onayladığınız bir kontrol değildir. Pipeline'ınızın, daha önce gönderdiğiniz herhangi bir tek kayıt için "bu sayı neden bu" sorusuna izole olarak ve olaydan sonra cevap verip veremeyeceğinin bir özelliğidir.
Cevap batch'i yeniden çalıştırmayı gerektiriyorsa, denetlenebilir bir pipeline'ınız yok demektir. Henüz düzgün şekilde denetlenmemiş bir pipeline'ınız var. Düzenleyicinin on kayıtlık örneklemesi verinizin bir stres testi değildir. Mimarinizin bir stres testidir. Türkiye'deki çoğu BES pipeline'ı bugün bunu geçemez ve bunları yöneten ekipler bunu bilir.
Çözüm, çıktı üzerinde daha fazla kontrol değildir. Çözüm, pipeline'ı baştan itibaren, tüm kayıtları açıkladığı kadar net bir şekilde tek bir kaydı da açıklayacak şekilde tasarlamaktır.