어제 배포 때문에 취소 주문이 안 처리되는 것 같다는 이야기가 왔고 문제 주문 번호 네 개를 받았다. 그 번호로 order_no 와 channel_order_no 등 연동 관련 컬럼을 전부 뒤졌는데 하나도 안 나왔다.
Table of contents
Open Table of contents
배경 — 받은 번호로는 안 나오는 조회
여러 테이블에서 LIKE '%1234%' 부분 일치로 찾아도 결과가 없었다. 오타나 조회 실수가 아니라면 그 번호가 우리 데이터에 없다는 뜻이다.
외부 제휴사가 통보하는 번호와 우리가 저장하는 번호가 다른 체계였다. 둘을 잇는 매핑이 어디에도 없었으므로 못 찾겠다가 아니라 그 번호로는 못 찾는 것이 맞았다.
조치 — 원래 물음으로 돌아가기
두 가지 방법이 있었는데 제휴사에 우리 번호와의 대응을 물어 네 건을 특정하는 것과 받은 물음이 무엇이었는지로 돌아가는 것이다. 뒤쪽을 골랐다. 이유는 제휴사 회신은 하루 이상 걸리는데 물음은 이 네 건이 왜 안 됐느냐가 아니라 어제 배포 때문이냐였기 때문이다. 대신 그 네 건 자체는 끝까지 특정하지 못하는 것을 감수했다.
그러면 개별 행을 특정할 필요가 없고 배포 이후에 이런 것이 늘었는지만 답하면 된다. 행을 못 찾는다는 사실이 답을 못 낸다는 뜻은 아니었다.
검증 — 집계로 바꾼 접근
특정 행 대신 order_cancels 의 PENDING 건을 GROUP BY HOUR(created_at) 으로 묶어 셌다. 문제의 공급사만 따로도 셌는데 그 테이블이 seller_id 를 직접 갖고 있어 조인 없이 걸러졌다.
전체 채널의 적체와 해당 공급사의 적체를 나란히 놓으니 두 시계열이 나왔다. 그 둘과 배포 시각 하나를 함께 보면 판정이 된다.
원인 — 최고 시점 하나가 만드는 반례
해당 공급사의 MIN(created_at) 이 배포 시각보다 여러 시간 앞서 있었다. 배포가 원인이면 배포 이후에만 생겨야 하므로 앞에 있으면 그 가설은 거짓이다.
무엇 때문이라는 가설은 그 시점 이전에 같은 증상이 하나만 있어도 무너진다. 그래서 판정에는 최솟값 하나면 충분했고 전수 집계는 규모를 보고하려고 따로 냈다.
주의 — 전체를 함께 세는 이유
해당 공급사만 봤으면 수십 건이 밀렸다는 사실까지만 나오고 그것이 많은지 적은지 알 수 없다. 전 채널을 같이 세니 같은 구간에 수백 건이 있었고 한 채널의 문제가 아니라 전체 현상이었다.
한 대상을 조사할 때 전체를 함께 세면 그 대상이 특이한지 아닌지가 그 자리에서 나온다. 이것을 안 하면 이 채널이 문제라는 잘못된 결론으로 간다.
정리
- 외부가 통보하는 번호가 내부에 그대로 저장되지 않을 수 있다
- 못 찾는다는 것이 답을 못 낸다는 뜻은 아니다
- 막히면 받은 물음이 무엇이었는지로 돌아간다
- 행을 특정할 필요가 없는 물음일 수 있다
- 무엇 때문이라는 가설은 그 이전의 한 건으로 무너진다
- 판정은 최솟값 하나로 하고 규모는 집계로 따로 낸다
- 한 대상을 볼 때 전체를 함께 세어 특이한지를 본다
- 조사에서 알게 된 식별자와 우회 경로를
INVESTIGATION.md에 남긴다