Birlikte çalıştığım her BES raporlama ekibinin aynı hikayesi var. EGM reddi bir Pazartesi sabahı düşüyor. Birisi Splunk veya ELK'yı açıyor, katılımcı ID'sini grep'liyor, üç gün önceye ait bir stack trace buluyor ve ardından pipeline'ın her aşamada doğru sandığı şeyi yeniden inşa etmek için sonraki on dört saati harcıyor. Düzeltme gönderildiğinde, uyum sorumlusu düzenleyiciyle çoktan üç görüşme yapmış, operasyon lideri ise bir yaş almış oluyor.
Rahatsız edici gerçek şu ki bu bir araç sorunu değil. Ekiplerin Grafana'sı var, Prometheus'u var, log agregasyonu var, DAG başarısızlıklarında uyarıları var. Sahip olmadıkları şey, pipeline'ın ne bildiğine ve bunu ne zaman bildiğine dair, düzenleyicinin önemsediği her zamansal sınırda hukuken savunulabilir bir kayıt.
Loglama Gözlemlenebilirlik Değildir, Gözlemlenebilirlik de Denetlenebilirlik Değildir
Bir GEV dosyası, katılımcının katkı döneminin önceki işverenin çıkış tarihiyle yanlış örtüşmesi nedeniyle reddedildiğinde, soru asla "pipeline başarısız mı oldu?" değildir. Başarısız olmadı. Çıktı üretti. Çıktı yanlıştı. Asıl soru şudur: O katılımcının durumu, düzenleyicinin doğru kabul edeceğinden ilk olarak hangi aşamada saptı ve buna hangi yukarı akış girdisi neden oldu?
Standart gözlemlenebilirlik yığınları üç soruyu iyi yanıtlar:
- Bir iş çalıştı mı?
- İstisna fırlattı mı?
- Ne kadar sürdü?
BES, HAYMER, FATCA, CRS ve devlet katkısı akışları farklı bir soru setine yanıt gerektirir:
- Her pipeline aşamasının sonunda kaydın tam durumu neydi?
- Hangi aşama, gerçeğin kaynağından sapmayı ilk olarak devreye soktu?
- Altı ay sonra, belirli bir bildirimdeki belirli bir alanı üreten tam girdi ve dönüşüm kümesini yeniden üretebilir miyim?
- Bir denetçiye, alım zaman damgası ile bildirim zaman damgası arasında loglanmamış hiçbir mutasyonun gerçekleşmediğini kanıtlayabilir miyim?
Çoğu ekip, adli bir yeniden inşa çalışması yapmadan bu soruların hiçbirini yanıtlayamaz.
Zamansal Sınır Sorunu
Emeklilik ve vergi raporlama pipeline'ları, işin kontrol edemediği zamansal sınırlarla tanımlanır. FATCA ve CRS'nin belirli bakiye tarihleri olan yıllık kesim tarihleri vardır. BES'in aylık katkı pencereleri vardır. HAYMER'ın kendine özgü mutabakat kadansı vardır. Devlet katkısı akışları, yukarıdakilerin hiçbiriyle örtüşmeyen bordro döngülerinde çalışır.
Pipeline bu sınırları sürekli olarak geçer. Ayın 3'ünde alınan, 5'inde dönüştürülen, 10'unda işveren verisiyle zenginleştirilen ve 15'inde bir bildirime dahil edilen bir katılımcı kaydı, en az dört zamansal bağlamdan geçmiştir. Bildirim reddedilirse, "bu kaydın 5'indeki durumu neydi?" sorusu neredeyse hiçbir zaman yalnızca loglardan yanıtlanamaz, çünkü loglar durumu değil olayları yakalar.
Event sourcing bunun bir kısmını çözer. Bitemporal tablolar daha fazlasını çözer. Ancak gördüğüm çoğu BES pipeline'ı bunların hiçbirini yapmaz. Bir çalışma tablosunu mutasyona uğratır, mutasyonu loglar ve devam eder. Düzenleyici bir alanın neden değiştiğini sorduğunda, cevap dönüşüm kodu üzerinde bir git blame ve log zaman damgalarının umutlu bir okumasıdır.
Gerçekten Yakalanması Gerekenler
Bu akışları birden fazla sigorta şirketinde paralel olarak çalıştırdıktan sonra, aynı asgari uygulanabilir denetim yüzeyi tekrar tekrar ortaya çıkıyor:
- Değişmez aşama anlık görüntüleri: her pipeline aşamasının sonunda, tam kayıt durumu; aşama tanımlayıcısı, girdi hash'i, dönüşüm sürümü ve duvar saati zaman damgasıyla birlikte yalnızca ekleme yapılabilen depolamaya yazılır. Diff değil. Tam durum.
- Alan bazında girdi kökeni (lineage): nihai bildirimdeki her alan için, kaynak sisteme, çıkarma zaman damgasına ve son değerini üreten belirli dönüşüme kadar çözümlenebilir bir zincir.
- Sınırlarda sapma tespiti: her zamansal sınırda kayıt durumunun bir önceki sınırla otomatik karşılaştırması ve bir alan yetkili bir yukarı akış olayı olmadan değiştiğinde yapılandırılmış uyarılar.
- Düzenleyiciye dönük yeniden oynatma (replay): herhangi bir geçmiş bildirimi, saklanan girdilerden ve sabitlenmiş dönüşüm sürümlerinden bayt bayt yeniden üretebilme yeteneği. Bunu yapamıyorsanız, bildirimi savunamazsınız.
Bunların hiçbiri egzotik değildir. Hepsi sonradan eklemek pahalıdır, baştan tasarlamak ucuzdur. Neredeyse hiç kimse baştan tasarlamıyor.
Uyarı Neden Yanlış Bir İlkeldir
Uyarı, kötü bir durumun neye benzediğini bildiğinizi varsayar. Emeklilik raporlamasında kötü durumlar düzenleyici tarafından tanımlanır ve tanımlar değişir. Geçen çeyrek geçerli olan bir alan, bu çeyrek bir genelge bir kodun yorumunu değiştirdiği için geçersiz olabilir. Gözlemlenebilirlik stratejiniz "bilinen-kötü koşullarda uyarı ver" ise, her zaman bir düzenleyici güncellemesinin bir adım gerisinde olacaksınız.
Savunulabilir konum bunun tam tersidir: her şeyi yakalayın, herhangi bir sorunun geriye dönük olarak sorulabileceği şekilde yapılandırın ve uyarıları zaten tamamlanmış bir denetim yüzeyi üzerinde bir kolaylık katmanı olarak ele alın. Uyum sorumlusu "Ocak ile Mart arasında bu alanı yanlış ayarlanmış kaç katılımcı vardı" diye sorduğunda, cevap bir proje değil, bir sorgu olmalıdır.
Pratik İlerleme Yolu
Halihazırda üretimde BES pipeline'ları çalıştıran ekipler için işe yarayan sonradan uygulama sırası:
- Önce yalnızca ekleme yapılabilen aşama anlık görüntüleri ekleyin. Lineage olmadan bile, her aşama sınırında tam duruma sahip olmak adli çalışmanın çoğunu ortadan kaldırır.
- Her dönüşümü sürüm sabitleyin. "Bu kayıtta zenginleştirme mantığının hangi sürümü çalıştı" sorusunu yanıtlayamıyorsanız, çıktıyı savunamazsınız.
- Ham girdileri süresiz olarak veya en azından en uzun düzenleyici zaman aşımının ötesinde saklayın. Sıkıştırma ucuzdur. Düzenleyici anlaşmazlıkları değildir.
- Replay yeteneğini ihtiyaç duymadan önce inşa edin. İlk kez ihtiyaç duyduğunuzda zaman baskısı altında olacaksınız ve iyi inşa edemeyeceksiniz.
Gözlemlenebilirliği bir operasyon panosu olarak değil bir uyum yüzeyi olarak ele alan ekipler, Pazartesi sabahlarını pipeline'larının Cuma günü neye inandığını yeniden inşa ederek geçirmeyen ekiplerdir. Geri kalan herkes, çok uzun bir haftaya bir ret uzaklıktadır.