정산에서 주문 정보가 매칭되지 않은 건이 쌓여 있었고 실패 사유가 하나로 몰려 있었다. 3천 6백여 건의 매칭을 직접 확정해 넣고 재처리를 돌렸다.
Table of contents
Open Table of contents
완료가 0건이었던 결과
돌리고 나서 결과를 보니 완료가 하나도 없었다. 매칭이 잘못됐나 싶었다.
전후를 비교하니 다른 것이 보였는데 원래 사유였던 미확인 주문이 0건으로 떨어져 있었다. 그러면 그 건들이 어디로 갔는지를 봐야 했다.
다음 게이트로 이동한 건들
전체 사유 분포를 보니 수익율 미달과 마이너스 수익과 처리 불가 상태로 나뉘어 있었고 합이 처리한 건수와 정확히 같았다. 매칭에 성공한 건들이 다음 단계로 넘어가 거기서 다른 사유에 걸린 것이었다.
정산이 매칭과 처리 가능 여부와 취소 여부와 수익 부호와 수익율 기준으로 이어지는 다단계 게이트였다. 매칭이 안 되던 동안에는 뒤쪽 조건까지 가지도 못했으므로 첫 관문을 통과하자 뒤의 조건들이 처음으로 평가된 것이다.
틀린 판정 기준
여기서 내 오류가 정리됐다. 완료 건수가 늘었는지를 판정 기준으로 잡은 것이 틀렸다.
맞는 기준은 내가 고친 사유가 해소되고 후속 사유로 이동했는지다. 내가 한 일은 첫 관문을 고치는 것이고 나머지는 원래 있던 조건이므로 완료 건수로 재면 전건 성공인데도 실패로 읽게 된다.
대응 주체가 다른 후속 사유
후속 사유로 넘어간 건들은 성격이 달랐다. 수익율 미달과 마이너스 수익은 매칭 문제가 아니라 수익성 문제라 사업 판단이 필요하다.
처리 불가 상태는 주문 상태 문제라 운영 쪽 일이다. 매칭 로직을 더 파도 소득이 없고 내 작업의 성공과 그 건의 완료를 구분해야 이것이 보인다.
보류와 실패의 구분
분포에서 하나 더 알게 됐다. 같은 안 됨인데 조건이 바뀌면 다시 처리될 수 있는 보류와 그 건은 처리 못 하는 실패로 갈린다.
수익 관련 사유는 실패가 아니라 보류로 들어가므로 둘을 합쳐 실패로 보고하면 과장이 된다. 작업 전에 잔존 건수를 예측해 뒀는데 실측과 정확히 맞아서 예측과 실측의 일치가 작업이 의도대로 됐다는 증거가 됐다. 커맨드는 채널별로 나눠 돌리고 전후 상태를 집계했는데 그것이 없으면 무엇이 어디로 갔는지 알 수 없다.
정리
- 다단계 게이트에서 한 단계 해소가 완료를 뜻하지 않는다
- 성공 판정을 최종 완료 건수로 잡으면 전건 성공을 실패로 읽는다
- 판정 기준은 내가 고친 사유가 해소되고 후속으로 이동했는지다
- 후속 사유는 대응 주체가 다르므로 더 파도 소득이 없다
- 보류와 실패를 구분하고 합쳐서 보고하지 않는다
- 작업 전에 잔존을 예측하면 실측과 대조할 수 있다
- 예측과 실측이 맞으면 의도대로 됐다는 증거가 된다
- 커맨드는 대상별로 나눠 돌리고 전후를 집계한다