출금 취소 대기가 쌓이고 자동 취소 안내만 뜨는데 처리가 안 된다는 문의가 CS 로 들어왔다. 문장만 보면 지갑 노드 연동 장애로 읽히는 내용이었다.
Table of contents
Open Table of contents
증상 — 하위 상태만 본 첫 판정
한두 건이 아니라고 해서 두 달치를 전수로 확인했다. withdraw_cancel_requests 를 보니 대상이 전부 status = 'REQUESTED' 로 남아 있었다.
그것만 보면 미처리가 맞고 다음 단계는 노드 호출 로그를 뒤지는 것이다. 그런데 그 상태가 정말 처리가 안 됐다는 뜻인지는 아직 확인한 것이 아니었다.
검증 — 상위 상태가 뒤집은 결론
withdrawals 와 balance_ledger 를 JOIN 으로 함께 조회하니 출금은 CANCELED 이고 잔고 복구 행도 있었다. 실제 취소와 잔고 복구는 끝났고 취소 요청 레코드의 표시만 안 바뀐 상태였다.
여기서 조사 방향이 갈렸다. 노드 연동 장애로 들어갔으면 로그를 뒤지고 재전송하고 노드 운영사에 문의하는 데 시간을 쓰고도 이미 완료된 것을 확인했을 것이다.
전수라서 보인 공통 패턴
한 건만 봤으면 이상한 건이라고 넘겼을 텐데 전수로 보니 전부 같은 모양이었다. 대상 전부가 같은 패턴이면 개별 사고가 아니라 하나의 원인이다.
BTC·ETH·원화로 나눠 봤는데 전부 같은 패턴이라 코인과 무관했다. 그러면 각 노드 연동이 아니라 우리 쪽 공통 로직으로 범위가 좁혀진다.
조사 방향을 틀지 않았다
노드에 txid 조회 기록이 있는 건과 없는 건이 섞여 있었는데 둘 다 같은 잔존 패턴이었다. 그 유무가 원인이 아니므로 용의자 하나를 지웠다.
하위 상태 하나로 판단해서 방향을 틀었으면 조사 전체가 헛돌았고 그것을 막은 것은 JOIN 쿼리 하나였다. 출금 취소 미처리 문의를 받으면 withdrawals 상태를 함께 확인한다는 순서를 CS 절차에 적었다.
조치 — 증상 해소와 원인 제거
할 일이 두 갈래로 나왔는데 쌓인 잔존 건의 status 를 정리하는 것과 상태 전환이 왜 안 도는지를 코드에서 찾는 것이었다. 앞의 것만 하면 계속 쌓여 다시 문의가 오고 뒤의 것만 하면 지금 쌓인 것이 안 없어진다.
순서는 두 가지 길 중에서 원인 제거 쪽을 먼저 골랐다. 이유는 표시를 먼저 정리하면 그 사이 새로 쌓인 건이 다시 섞여 전수 대조를 또 해야 해서다. 대신 문의한 회원의 화면이 며칠 더 취소 대기로 보이는 것을 감수했다. 이 판정으로 답변의 성격도 달라졌다. 노드 장애를 조사 중이라는 답은 불안을 남기고 실제 취소와 잔고 복구는 완료됐으며 표시만 정리하면 된다는 답은 그 자리에서 해소가 된다.
정리
- 하위 상태만 보면 미처리로 보인다
withdrawals상위 상태를 함께 확인해야 실제로 끝났는지 알 수 있다- 완료 상태면 조사 방향을 노드 연동 쪽으로 틀지 않는다
- 전수로 봐야 공통 패턴이 보인다
- 대상 전부가 같은 모양이면 개별 사고가 아니다
- 코인과 무관하면 우리 쪽 공통 로직 문제다
- 관련 데이터의 유무가 무관하면 용의자를 지운다
- 증상 해소와 원인 제거를 둘 다 하되 원인부터 한다