추천인 보상 정산 대상에서 빠진 건이 있는데 왜 빠졌는지를 알아낼 방법이 없었다. 대상 여부를 판정하는 isEligible() 이 boolean 만 돌려주고 있었기 때문이다.
Table of contents
Open Table of contents
증상 — 조용히 건너뛰던 다섯 조건
판정 함수 안에는 체결 상태와 최소 금액과 정산 여부와 추천인 존재와 차단 목록까지 조건이 다섯 있었다. 그중 어느 조건에 걸려서 빠졌는지는 밖에서 알 방법이 없었다.
건너뛴 사실 자체도 안 남으니 처리가 안 됐다는 것만 한참 뒤에 CS 문의로 드러났다. 조건이 여럿인 판정에서 참과 거짓만 돌려주면 원인이 통째로 사라진다.
조치 — 이유를 값으로 돌려주게 바꾼 뒤
판정이 boolean 대신 SkipReason 열거형을 돌려주게 바꾸고 건너뛴 건과 사유를 함께 기록하게 했다. 두 가지 방법이 있었다. 사유를 로그에만 찍어 Kibana 에서 세는 것과, reward_skips 테이블을 따로 두어 batch_date·member_id·reason 을 담는 것이다. 뒤쪽을 골랐다. 이유는 로그로는 특정 사유의 회원 목록을 재처리 입력으로 그대로 쓰기 어려워서다. 대신 테이블 하나가 늘고 매일 수천 행이 쌓이는 것을 감수했다.
숫자만이 아니라 어느 건이 어떤 사유로 빠졌는지가 남는다. 그러면 WHERE reason = 'REFERRER_MISSING' 으로 특정 사유의 목록을 그대로 뽑아 열어 볼 수 있다.
검증 — 이유별로 세니 봐야 할 것이 드러났다
GROUP BY reason 으로 집계해 보니 대부분은 NOT_MATURED 거나 ALREADY_SETTLED 인 정상 건너뜀이었다. 그중 REFERRER_MISSING 이 수십 건 섞여 있었다.
있어서는 안 되는 조합이 그 집계에서 처음 드러났고 열어 보니 추천인이 탈퇴하면서 referrer_id 참조가 끊긴 데이터 문제였다. 이유를 안 남기던 동안에는 그 존재 자체를 몰랐다.
판단 기준 — 정상 건너뜀과 봐야 할 건너뜀
사유를 정상적으로 건너뛰는 것과 확인이 필요한 것으로 갈랐다. 앞의 것은 매일 수천 건이라 알림에 넣으면 뒤의 것이 그 안에 묻힌다.
BLOCKED 회원의 건은 담당에게 물어보니 건너뛰면 안 되는 것이었다. 정산은 하되 지급을 보류해야 했는데 건너뛰면 정산 자체가 없어서 나중에 찾을 수도 없다.
목록으로 다시 처리하기
데이터 원인을 고친 뒤에는 그 건들만 골라 다시 돌려야 했다. reward_skips 에서 member_id 를 뽑아 그것만 다시 처리하게 했다.
전체를 다시 돌리면 이미 정산한 것까지 건드린다. SkipReason 을 열거형으로 두어 조건이 늘 때 목록에 넣지 않으면 switch 에서 컴파일 단계에 걸리게 해 뒀다.
정리
- 조용히 건너뛰면 왜 처리가 안 됐는지 모른다
- 조건이 여럿인 판정에서
boolean만 돌려주면 원인이 사라진다 SkipReason을 값으로 돌려주고 건너뛴 건과 함께reward_skips에 남긴다- 이유별로 세면 있어서는 안 되는 조합이 드러난다
- 정상 건너뜀과 확인이 필요한 것을 갈라야 묻히지 않는다
- 숫자만이 아니라 어느 건이 빠졌는지 남긴다
- 그 목록으로 다시 처리하고 전체를 다시 돌리지 않는다
- 이유를 남기면 그 처리가 맞는지 물어볼 수 있다