Birlikte çalıştığım her BES operasyon ekibinin bu konuda bir hikayesi vardır. EGM veya SEDDK'dan bir yazı gelir. Rakam istemez — rakamlar zaten sunulmuştur. İstenen şey akıl yürütmedir: hangi sözleşme versiyonları dahil edildi, belirli bir katılımcı neden o şekilde sınıflandırıldı, o belirli referans tarihinde devlet katkısı eşleştirme hesaplaması nasıl görünüyordu, hangi referans tabloları aktifti ve çalıştırmayı kim onayladı.
Ve aylar önce mutlulukla sunumu üreten pipeline, bunların hiçbirine bir sprint olmadan yanıt veremez.
Regülatörün gerçekte istediği şey
Yanlış anlaşılma tam burada başlar. Uyum ekipleri, bir regülasyon kanıt talebinin bir veri talebi olduğunu varsayar. Değildir. Bir savunma talebidir. Regülatör zaten sunduğunuz rakamlara sahiptir. Yeniden inşa etmek istedikleri şudur:
- Sunum kesim tarihindeki tam girdi anlık görüntüsü — aynı tabloların bugünkü versiyonu değil
- Çalıştırma anında aktif olan her dönüşümün, kuralın ve arama tablosunun versiyonu
- Ham sözleşme veya katkı kaydından sunulan agregata kadar tüm veri soy ağacı
- İstisna kararları: hangi kayıtlar hariç tutuldu, bastırıldı, yeniden sınıflandırıldı ve hangi kurala göre
- İnsan onay zinciri ve buna eklenen mutabakat kanıtı
Bu bir pakettir, sorgu sonucu değil. Ve çoğu BES pipeline'ı sorgu sonucunu üretmek ve paketi atmak üzere tasarlanmıştır.
Yeniden inşa sprint'i neden yaşanır
Türk bir emeklilik şirketindeki tipik bir BES sunum pipeline'ını gözden geçirin. Katkı verisi operasyonel sistemden akar, yavaş değişen bir boyuttan katılımcı statüsüyle zenginleştirilir, devlet katkısı eşleştirme kuralları tablosuyla birleştirilir, hak ediş ve uygunluk mantığı uygulanır ve regülatöre giden agregat üretilir. Pipeline çalışır. Çıktı dosyalanır. Bitti.
Üç ay sonra talep gelir. Şimdi ekip şunları keşfeder:
- Kaynak katkı tablosu günlük yüklemelerle üzerine yazılmıştır. Başka nedenlerle biri yedek almadığı sürece, sunum tarihindeki anlık görüntü kaybolmuştur.
- Eşleştirme kuralları tablosu o zamandan beri iki kez güncellenmiştir. Operasyonel olarak yenilenen bir referans şemasında yaşadığı için kimse versiyonlamamıştır.
- Dönüşüm SQL'i bir zamanlayıcıda ama zamanlayıcı yalnızca en son versiyonu tutmuş. Sunum tarihinde çalışan mantık, birinin bulması gereken bir Git commit'inde — commit edilmişse ve doğrudan production'da patch'lenmemişse tabii.
- İstisna log'u var ama sunum çalıştırma ID'sine hiç geri bağlanmamış, dolayısıyla hangi istisnaların hangi sunuma uygulandığını bulmak zaman damgası tahmini gerektiriyor.
- Onay e-posta üzerinden yapılmış.
Böylece üç kişilik bir ekip, çalıştırma günü kısa süreliğine var olan bir şeyi yeniden inşa etmek için iki-üç hafta harcar.
Tasarım hatası: sonradan akla gelen kanıt
Kök neden mimaridir. Pipeline'lar sunumu üretmek için inşa edilir ve kanıt, log'lardan, yedeklerden ve Git geçmişinden sonra bir araya getirilebilecek bir şey olarak ele alınır. Bu varsayım, bu alt katmanlardan herhangi biri döndürüldüğü, yenilendiği veya çöp toplandığı anda kırılır — ki toplanacaklardır çünkü kanıt saklama olarak tasarlanmamışlardır.
Pipeline yanlış çıktı için optimize edilmiştir. Agregat dosyayı teslim edilen ürün olarak ele alır. Regülatör ise agregatın savunulabilirliğini teslim edilen ürün olarak ele alır.
Savunma paketini birinci sınıf bir eser olarak ele almak
Çözüm daha fazla loglama değildir. Daha fazla loglama daha fazla arkeoloji üretir, daha az değil. Çözüm, savunma paketini her sunum çalıştırmasının zorunlu bir çıktısı haline getirmektir; aynı iş tarafından, aynı transaction içinde, sunulan dosyanın kendisiyle aynı kesinlikle üretilmelidir.
Somut olarak, her sunum çalıştırması şunları içeren bir paket üretmelidir:
- Fiziksel olarak dondurulmuş girdi anlık görüntüleri. Değişecek bir tabloya işaretçi değil. Kullanılan her kaynak veri kümesinin, çalıştırma ID'sine anahtarlanmış değişmez bir konumda saklanan materyalize edilmiş bir kopyası.
- Kural ve referans tablosu anlık görüntüleri — çalıştırma anında her arama, eşleme ve parametre tablosunun tam içeriği. Katkı eşleştirme oranları, hak ediş takvimleri, fon dağılım tabloları, katılımcı sınıflandırma kuralları.
- Kod parmak izi. Her dönüşüm script'inin Git commit hash'i, artı gerçekten çalıştırılan serileştirilmiş SQL veya kodun kendisi. Referans değil — metin.
- Veri soy ağacı ham kayıtlardan sunulan agregatlara kadar, sonradan yeniden inşa edilen değil, pipeline'ın kendisi tarafından üretilen.
- İstisna defteri bu çalıştırma ID'sine özgü: neyin düşürüldüğü, neyin yeniden sınıflandırıldığı, hangi kuralın tetiklendiği, kaydın öncesi ve sonrası neye benzediği.
- Mutabakat kanıtı — checksum'lar, satır sayıları, kaynak-doğruluk sistemine bağlanma, otomatik olarak üretilip pakete eklenmiş.
- Onay kaydı kullanıcı, zaman damgası ve onayladıkları belirli paket hash'i ile birlikte. Onay sistem dışında gerçekleşirse, var sayılmaz.
Paket bir kez yazılır, değişmez şekilde saklanır ve sunum referansına göre indekslenir. Regülatör sorduğunda, alırsınız. Yeniden inşa etmezsiniz.
Bunun maliyeti ve tasarrufu
Duyduğum itiraz, bunun her çalıştırmaya ek yük getirdiği yönündedir. Getirir. Girdileri ve referans tablolarını anlık görüntülemek depolama maliyeti yaratır. Soy ağacı üretmek işlem maliyeti yaratır. Onayı sistem içinde zorunlu kılmak süreç değişikliği maliyeti yaratır.
Bunu kıdemli kişileri yol haritası işinden çeken üç haftalık bir yeniden inşa sprint'inin maliyetiyle karşılaştırın; artı yeniden inşanın sunulan şeyle tam olarak eşleşmeyen bir paket üretme riski — ki bu, paketin hiç olmamasından çok daha kötü bir regülasyon pozisyonudur. Tutarlı bir şekilde savunamayacağınız bir sunum, hızlı savunamayacağınız bir sunumdan daha kötüdür.
Depolama ucuzdur. SEDDK'ya yeniden inşa edilmiş kanıtınızın neden orijinal sunumunuzla eşleşmediğini açıklamak değildir.
Zaten sorunu yaşıyorsanız nereden başlamalı
Bunu okuyan çoğu ekibin ardında zaten yıllarca süren savunulmamış sunumlar var. Eski çalıştırmalar için kanıt geriye dönük eklemek gerçekçi değildir. Gerçekçi olan:
- Bir çizgi çekin. Bir sonraki sunum döngüsünden itibaren her çalıştırma bir paket üretir.
- Önce en yüksek frekanslı, en yüksek denetim baskısı olan sunumu seçin. Örüntüyü orada kanıtlayın.
- Tam soy ağacını inşa etmeden önce bile, referans tablo anlık görüntülerini derhal dondurun. Referans tablo kayması, yeniden inşa başarısızlığının en büyük tek kaynağıdır.
- Onayı sisteme taşıyın. E-posta onayları bir denetimi atlatamaz.
Rakamı üreten pipeline ile rakamı savunan pipeline aynı pipeline'dır. Bunu kabul ettiğinizde, mimari kendiliğinden gelir.