Batch Replay Problemi: Mantık Hatası Düzeltildikten Sonra Geçmiş Emeklilik Verisini Yeniden İşlemek Neden Orijinal Bug'dan Daha Tehlikelidir?

Genç bir mühendis, katkı payı dağıtım mantığında bir bug buluyor. Düzeltme üç satır. Etkilenen batch, on bir gün boyunca 47.000 katılımcıyı kapsıyor. İçgüdü — neredeyse başka her domain'de makul olur — kodu düzeltmek, batch'i yeniden çalıştırmak ve yola devam etmektir.

BES'te bu içgüdü, sınırlı bir defect'i çok çeyreklik bir mutabakat projesine dönüştüren şeydir.

Neden Replay Düzeltme Değildir

Data pipeline'larının çoğunda replay, tasarım gereği idempotent'tir. Girdiyi yeniden işlersiniz, çıktının üzerine yazarsınız ve downstream consumer'lar düzeltilmiş görüntüyü alır. Zihinsel model şudur: pipeline bir fonksiyondur ve biz onu düzeltilmiş versiyonuyla yeniden değerlendiriyoruz.

BES pipeline'ları fonksiyon değildir. Onlar, hukuken bağlayıcı bir zincire olay yayan event emitter'lardır.

Orijinal batch çalıştığında, sadece bir sayı üretmedi. Şunları üretti:

• Hazine'ye sunulmuş bir devlet katkısı talebi
• Katılımcının o değerleme tarihindeki fon dağılımını kaydeden bir EGM bildirimi
• O gün fondaki diğer tüm katılımcıları fiyatlayan bir NAV
• Hesaplara kredilendirilmiş ve sonraki günlerin hesaplamalarına baz oluşturan birim adetleri
• Bu birim adetleri üzerinden gerçekleşen çıkışlara ilişkin vergi kesinti olayları

Bunların her biri; kendi saklayıcısı, kendi audit trail'i ve halihazırda buna göre işlem yapmış olan kendi tarafı bulunan ayrı bir hukuki artefakttır. Batch'i yeniden çalıştırmak bu artefaktları düzeltmez. Onların ikinci, çelişen bir versiyonunu oluşturur.

Somut Bir Örnek

Bug'ın, işveren katkı eşleştirme bileşeninin on bir gün boyunca %0,4 eksik dağıtılmasına neden olduğunu varsayalım. Düzeltme doğru. Replay basit. Çıktı artık doğru birim adetlerini gösteriyor.

Bu replay'in az önce yaptığı şey şudur:

1. Devlet katkısı uyumsuzluğu. %25 devlet katkısı, orijinal (daha düşük) katkı tutarı üzerinden zaten hesaplanmış ve talep edilmişti. Hazine bunu ya ödedi ya da ödeme takvimine aldı. Yeniden çalıştırılmış rakam farklı bir devlet katkısı ima ediyor — ancak kapatılmış bir dönem için devlet katkısı talebini resmi bir düzeltme bildirimine gitmeden geriye dönük olarak artıramazsınız ve katılımcı düzeyindeki toplamlar EGM'de kayıtlı olanlarla uyuşmuyorsa EGM dosyayı reddedecektir.

2. NAV kontaminasyonu. Bu on bir günün her birindeki fon NAV'ı, buggy dağıtımları da içeren toplam tedavüldeki birim sayısı kullanılarak hesaplandı. O fondaki diğer her katılımcı bu NAV'a göre fiyatlandı. Şimdi birim adetlerini geriye dönük olarak değiştirirseniz, geçmiş NAV'lar birim kütüğüyle tutarsız hale gelir. İki seçeneğiniz var, ikisi de kötü: NAV'lara dokunmayıp birim × NAV'ın artık fon AUM'una uymadığını kabul etmek ya da NAV'ları yeniden hesaplayıp o on bir gün boyunca işlem yapan her katılımcı için bir düzeltme kaskadı tetiklemek.

3. Halihazırda fiyatlanmış çıkış olayları. Etkilenen pencere sırasında veya sonrasında çıkış yapan, fon değiştiren veya kısmi çekim alan her katılımcı; orijinal NAV'larda orijinal birim adetleri üzerinden işlem gördü. Bu olaylar kapandı. Vergi kesildi ve ödendi. Altta yatan birimleri yeniden hesaplamak, bu çıkışların teknik olarak yanlış fiyattan yürütüldüğü anlamına gelir; bu bir bug fix değildir — kapanmış finansal işlemlerin geri çevrilmesidir.

4. Downstream gün bağımlılıkları. 12. günün hesaplaması, girdi olarak 11. günün kapanış birimlerini kullandı. 13. gün, 12. günü kullandı. 1–11. günleri düzeltilmiş mantıkla yeniden çalıştırırsanız, 12. günden bugüne kadar olan günleri de yeniden çalıştırmadıkça hiçbir şeyi düzeltmiş olmazsınız; bu da o zamandan bu yana her günün yeniden hesaplanması ve o günlerin her birinden kaynaklanan her downstream artefaktın mutabakatının yapılması gerektiği anlamına gelir.

Orijinal bug, on bir gün boyunca 47.000 katılımcıyı %0,4 oranında etkiledi. Replay ise, o zamandan bu yana etkilenen her fondaki her katılımcıyı her gün için ve orijinal rakamlara dayalı bildirim almış her karşı tarafı etkiliyor.

Sürekli Gördüğüm Örüntü

Ekipler bunu hafife alıyor çünkü test ortamlarında hukuki downstream yok. Test'te replay çalışır. Test'te düzeltilmiş çıktı, düzeltilmiş çıktıdır. Ne Hazine, ne EGM, ne saklayıcı, ne de orijinalin kopyasını elinde tutan vergi otoritesi vardır.

Production farklıdır; kodun farklı davrandığından değil, production sizin kontrol etmediğiniz taraflarca tutulan bir hafızaya sahip olduğu için. Bir devlet katkısı talebi bir kez gönderildikten, bir NAV bir kez yayımlandıktan, birimler bir kez kredilendirilip üzerinden işlem yapıldıktan sonra — bu olaylar sizin pipeline'ınızın dışında var olur ve yeniden çalıştırılamaz.

Gerçekte İşe Yarayan Şey

Audit'ten sağ çıkan düzeltme örüntüsü replay değildir. Açık ayarlama olaylarıyla ileriye yönelik düzeltmedir:

• Geçmiş çıktılara dokunmayın. Doğru olsun ya da olmasın, olanların kaydı onlardır.
• Buggy çıktı ile doğru çıktı arasındaki farkı katılımcı düzeyinde hesaplayın.
• Farkı; kendi işlem tipi, kendi audit referansı ve EGM'ye overwrite yerine düzeltme olarak sunulan kendi bildirimi olan, tarihli bir ayarlama olayı olarak kaydedin.
• Devlet katkısı farkını, orijinal dönemi yeniden göndererek değil, resmi düzeltme kanalı üzerinden ele alın.
• Geçmiş NAV'lara dokunmayın. Ayarlama; orijinal defect'e bağlanmış belgelenmiş bir neden koduyla, bugünün NAV'ında yeni bir birim kredisi olarak akar.

Bu daha çirkin. Katılımcının hesap geçmişinde görünür bir iz bırakır. Operasyonel onay gerektirir ve çoğu zaman katılımcıya bir bildirim yapılmasını gerektirir. Replay'den on kat daha yavaştır.

Aynı zamanda, ilkinden daha büyük bir ikinci problem yaratmayan tek yaklaşımdır.

Kural

Çıktınızın başka birinin resmi kayıt girdisi olduğu sistemlerde replay teknik bir operasyon değildir. Geçmişin, geçmişin söylediği şekilde gerçekleşmediğine dair hukuki bir iddiadır.

İleriye doğru düzeltin. Açıkça ayarlayın. Tarihi olduğu gibi bırakın — tarih yanlış olsa bile.