Her çeyrekte İstanbul'daki emeklilik ve sigorta şirketlerinde aynı örüntünün tekrarlandığını görüyorum. BES pipeline dev ortamında yeşil çalışıyor. Birim testler geçiyor. Örnek XML'ler şemaya karşı doğrulanıyor. Biri onay veriyor. Sonra gönderim penceresi açılıyor, gerçek veri seti akmaya başlıyor ve EGM son regülasyon değişikliğinden bu yana kimsenin görmediği bir red kodu döndürüyor. Saat 22:00, son teslim yarın ve üç kişi bir PDF'ten bir doğrulama kuralını tersine mühendislikle çözmeye çalışıyor.
Bu kötü şans değil. Bu, başarısızlığın maliyetli hale gelmesinden önce başarısız olacak şekilde hiç tasarlanmamış bir pipeline'dır.
Bir BES pipeline'ında "test edildi" genellikle ne anlama gelir
Bir ekip bana regülasyon raporlamasının test edildiğini söylediğinde, neredeyse her zaman şunu kastediyorlar:
- Dönüşüm mantığı üzerinde birim testler (katkı dağıtımı, fon değişikliği yönetimi, hak ediş)
- Birkaç örnek XML'e karşı şema doğrulaması
- Kaynak defterle eşleşen mutabakat toplamları
- Örnek bir katılımcıya manuel göz atma
Hepsi faydalı. Hiçbiri bir gönderimi simüle etmiyor. Bir gönderim bir dosya değildir — kendi durumuna sahip, geçen ay ne gönderdiğinize dair kendi fikri olan ve kendi red semantiği bulunan bir regülatör sistemiyle yapılan bir konuşmadır. HAYMER, birim testlerinizin geçip geçmediğini umursamaz. Bugün raporladığınız TCKN'nin dosyasındaki kimlikle eşleşip eşleşmediğini, fon kodunun bu sabah yüklediği referans tablonun sürümünde var olup olmadığını ve kümülatif katkı rakamlarınızın 30 gün önce ona söylediklerinizle mutabık olup olmadığını umursar.
Bunların hiçbiri örnek veriyle test edilebilir değildir.
Örnek veri neden yalan söyler
Örnek veri seçilmiştir. Geliştiricinin düşündüğü vakaları temsil eder. Production verisi ise kimsenin düşünmediği vakaları temsil eder:
- Döngü ortasında işveren değiştiren ve şimdi iki sponsor kodu altında görünen katılımcılar
- T gününde başlatılıp T+2'de valörlenen, raporlama sınırını aşan fon transferleri
- Standart olay akışını atlayan operasyon tarafından girilen manuel düzeltmeler
- Kimliği gönderimden üç gün önce bir MERNIS yenilemesi aracılığıyla güncellenen katılımcılar
- Birisi haritayı güncellemeden yeni bir fon yüklediği için referans tablosunun bilmediği bir para biriminde kaydedilen katkılar
200 kayıtlık bir örnek bunların hiçbirini ortaya çıkarmaz. 400.000 kayıtlık bir production snapshot'ı bunların hepsini, her döngüde, farklı kombinasyonlarda ortaya çıkarır. Pipeline'ınız gerçek production hacmini gerçek regülatör yanıt formatına karşı hiç işlememişse, test edilmiş bir pipeline'ınız yoktur. Bir hipoteziniz vardır.
Birinci sınıf bir teslimat olarak prova
Sorunsuz gönderim yapan firmalar daha akıllı değildir. Provayı isteğe bağlı bir QA faaliyeti olarak değil, zorunlu bir aşama olarak ele alırlar. Somut olarak:
- Production-eşdeğeri snapshot: Gerçek gönderim veri setinin maskelenmiş ama yapısal olarak eksiksiz bir kopyası, bilinen bir kadansta yenilenir. Örnek değil. Sentetik değil. Gerçek şekil, gerçek hacim, gerçek uç durumlar.
- Bir simülatör veya sandbox endpoint'i: EGM ve benzer kurumlar test endpoint'leri bir sebeple yayınlar. Kullanın. Belirli bir rapor için hiçbiri yoksa, yayınlanan kural kitabına dayalı olarak aynı red kodlarını uygulayan bir dahili mock oluşturun.
- Pencere açılmadan en az 5 iş günü önce sandbox'a karşı uçtan uca yürütme: Şema doğrulayıcı değil. Red ayrıştırma yolu dahil, gerçek gönder-al-onayla döngüsü.
- Bir red yeniden oynatma test düzeneği: Her geçmiş red kodu, her pipeline build'ine karşı çalışan bir test paketinde yaşamalıdır. HAYMER sizi Mart'ta X koduyla reddettiyse, X kodu regresyon paketinizde kalıcı bir demirbaş olmalıdır.
Bunun gerçekleşmemesinin organizasyonel nedeni
Teknik iş zor değil. Çoğu ekibin bunu atlamasının nedeni, provaların sorunları ortaya çıkarması ve ortaya çıkan sorunların birinin sahiplenmesini gerektirmesidir. Prova, referans veri uyuşmazlıkları olan 1.200 katılımcıyı ortaya çıkarırsa, operasyondan birinin 1.200 kaydı düzeltmesi gerekir. Bir mantık boşluğunu ortaya çıkarırsa, mühendislikten birinin yamalaması gerekir. Her ikisi de planda olmayan zamana mal olur.
Bu yüzden prova önceliği düşürülür, pipeline yayına çıkar ve sorun "düzeltmek için beş günümüz var"dan "düzeltmek için beş saatimiz var"a taşınır. Maliyet ortadan kalkmaz. Mümkün olan en kötü pencerede, mümkün olan en kötü görünürlükle, mümkün olan en kötü izleyicinin önünde yoğunlaşır.
Aslında ne inşa etmeli
Bir BES raporlama pipeline'ından sorumluysanız ve aşağıdakilerin hepsine evet yanıtı veremiyorsanız, bir prova sorununuz vardır:
- İstek üzerine, dün geceki production snapshot'ına karşı tam gönderim pipeline'ını çalıştırabiliyor musunuz?
- Bu çalıştırma sadece diskte bir dosyayla değil, bir sandbox'tan veya yüksek doğrulukta bir mock'tan gelen gerçek bir onayla mı sonlanıyor?
- Tüm geçmiş red kodları regresyon testleri olarak kodlanmış mı?
- Prova, her gönderim penceresinden N gün önce otomatik olarak çalışacak şekilde planlanmış mı ve sonuçlar isim verilmiş bir sahip tarafından inceleniyor mu?
- Prova başarısız olduğunda, gerçek pencere açılmadan önce iyileştirme için tanımlanmış bir SLA var mı?
Regülasyon raporlamasında hayatta kalan pipeline'lar en temiz koda sahip olanlar değildir. "Bir şey yanlış" ile "bunun farkındayız" arasındaki geri bildirim döngüsü en kısa olanlardır. Son teslim tarihinden beş gün önce güvenli bir şekilde başarısız olamayan bir pipeline, beş saat önce maliyetli bir şekilde başarısız olacaktır. Bu bir tasarım kararıdır, ekip bunu verdiğinin farkında olsa da olmasa da.