중지했는데 계속 주문이 들어온다는 문의를 받고 우리 쪽 products.status 를 보니 SUSPENDED 가 맞았다. 그런데 그 중지가 외부에는 나가지 않은 상태였다.
Table of contents
Open Table of contents
원인 — 내부 상태와 외부 전송의 두 플래그
ProductSuspender 를 보니 서로 다른 두 플래그를 각각 확인하고 있었는데 can_update_status 는 내부 상태를 바꿔도 되는지이고 channel_accounts.sync_enabled 는 외부로 보내도 되는지였다. 두 조건이 한 흐름 안에 나란히 있지만 서로 독립적으로 판정된다.
can_update_status 만 켜져 있으면 내부는 SUSPENDED 로 바뀌고 외부에는 아무것도 나가지 않는다. 화면에서는 중지로 보이므로 관리자 입장에서는 처리가 끝난 것으로 읽힌다.
주의 — 절반만 통과하는 상태
이 구조에서는 완전히 된 것과 완전히 안 된 것 사이에 절반만 진행된 상태가 존재한다. 그리고 그 상태가 겉으로는 완료와 구분되지 않는다.
한 동작에 통과 지점이 여럿이면 그중 일부만 통과한 상태가 만들어지고 그 상태를 표시할 자리가 없으면 완료로 보인다. 문의가 반복되는 원인이 그 표시의 부재에 있었다.
조치 — 진단 1단계가 하는 일
중지가 외부에 안 나간다는 문의를 받으면 두 플래그를 함께 조회하는 것을 첫 단계로 뒀다. 두 가지 방법이 있었는데 문의마다 두 표를 따로 보는 것과 products 와 channel_accounts 를 JOIN 한 조회를 하나 만들어 두는 것이다. 뒤쪽을 골랐다. 이유는 따로 보면 두 번째 플래그를 빼먹는 날이 반드시 와서다. 대신 조인이 길어져 쿼리를 읽기 어려운 것을 감수했고 한 번 만들어 두니 이후로 계속 쓰였다.
다만 이번 건은 두 값이 모두 정상이었고 게이트가 원인이 아니었다. 이 확인은 원인을 찾는 단계가 아니라 후보를 지우는 단계인데 그것을 헷갈리면 정상이니 문제없다는 결론으로 끝내게 된다.
배경 — 게이트가 둘인 이유
왜 이렇게 나뉘어 있는지 짐작해 보면 단계적 도입을 위한 구조로 보인다. 어떤 거래처는 우리 시스템에서 관리만 하고 외부 전송은 자기 쪽에서 하므로 sync_enabled 를 꺼 둔다.
그 자체는 합리적인 설계이고 문제는 그 구분이 어디에도 드러나지 않는다는 점이었다. 상태 아래에 sync_enabled 가 꺼져 있다는 한 줄만 있어도 문의가 생기지 않는다.
검증 — 배제한 것을 적는 값
조사 결과를 정리하면서 원인만이 아니라 확인했지만 원인이 아니었던 것들도 함께 적었다. 두 플래그가 정상이라는 것과 전송 코드가 존재한다는 것과 channel_jobs 생성 이력이 없다는 것이 INVESTIGATION.md 의 그 목록이었다.
배제 목록이 있으면 다음에 비슷한 문의가 왔을 때 그 부분을 다시 파지 않는다. 그리고 내 결론이 틀렸을 때 어느 단계에서 틀렸는지를 되짚을 수 있는 근거도 된다.
정리
- 한 동작에 통과 지점이 여럿이면 절반만 통과한 상태가 생긴다
- 내부 상태와 외부 전송이 다른 플래그로 통제될 수 있다
- 그 상태를 표시할 자리가 없으면 완료로 보인다
- 진단 1단계로 두 값을 함께 조회한다
- 이 확인은 원인 찾기가 아니라 후보 지우기다
- 정상이면 문제없음이 아니라 다른 데를 보라는 뜻이다
- 상태 옆에 전송 설정을 한 줄 표시하면 문의가 줄어든다
- 배제한 것을 적으면 다음 조사가 그 부분을 다시 안 판다