화면에만 남은 미처리

취소 대기가 쌓이고 자동 취소 안내만 뜨는데 처리가 안 된다는 문의가 들어왔다. 문장만 보면 연동 장애로 읽히는 내용이었다.

Open Table of contents

하위 상태만 본 첫 판정

한두 건이 아니라고 해서 두 달치를 전수로 확인했다. 취소 테이블을 보니 대상이 전부 요청 상태로 남아 있었다.

그것만 보면 미처리가 맞고 다음 단계는 연동 로그를 뒤지는 것이다. 그런데 그 상태가 정말 처리가 안 됐다는 뜻인지는 아직 확인한 것이 아니었다.

주문과 옵션의 상태를 함께 조회하니 둘 다 취소 완료였다. 실제 취소와 환불은 끝났고 취소 레코드의 표시만 안 바뀐 상태였다.

여기서 조사 방향이 갈렸다. 연동 장애로 들어갔으면 로그를 뒤지고 재전송하고 채널에 문의하는 데 시간을 쓰고도 이미 완료된 것을 확인했을 것이다.

한 건만 봤으면 이상한 건이라고 넘겼을 텐데 전수로 보니 전부 같은 모양이었다. 대상 전부가 같은 패턴이면 개별 사고가 아니라 하나의 원인이다.

채널별로도 나눠 봤는데 전부 같은 패턴이라 채널과 무관했다. 그러면 각 채널 연동이 아니라 우리 쪽 공통 로직으로 범위가 좁혀진다.

관련 수집 데이터가 있는 건과 없는 건이 섞여 있었는데 둘 다 같은 잔존 패턴이었다. 그 유무가 원인이 아니므로 용의자 하나를 지웠다.

하위 상태 하나로 판단해서 방향을 틀었으면 조사 전체가 헛돌았고 그것을 막은 것은 쿼리 하나였다. 취소 미처리 문의를 받으면 상위 상태를 함께 확인한다는 순서를 절차에 적었다.

할 일이 두 갈래로 나왔는데 쌓인 잔존 건의 표시를 정리하는 것과 상태 전환이 왜 안 도는지를 코드에서 찾는 것이었다. 앞의 것만 하면 계속 쌓여 다시 문의가 오고 뒤의 것만 하면 지금 쌓인 것이 안 없어진다.

이 판정으로 답변의 성격도 달라졌다. 연동 장애를 조사 중이라는 답은 불안을 남기고 실제 취소와 환불은 완료됐으며 표시만 정리하면 된다는 답은 그 자리에서 해소가 된다.