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