몇몇 업체의 상품 수정이 계속 실패한다는 이야기가 있었고 보정을 넣은 뒤에도 세 건이 남아 있었다. 남은 건들의 channel_jobs.last_error 가 전부 같은 메시지라 원인이 하나일 가능성이 높아 보였다.
Table of contents
Open Table of contents
증상 — 등록은 되고 수정만 안 되는 상태
이상한 지점은 같은 업체의 create 작업이 전부 성공하고 있다는 것이었다. 등록이 되는데 수정이 안 되면 자격 자체는 살아 있다는 뜻이 된다.
처음에는 전체 실패율만 보고 가끔 실패하는 문제로 분류했다. 그 시야에서는 등록과 수정이 한 덩어리로 합쳐져 패턴이 지워진다.
작업 타입별로 나눠 센 결과
GROUP BY job_type, status 로 다시 세니 create 만 성공하고 update 와 suspend 는 대부분 실패하는 형태가 드러났다. 합쳐서 보면 실패율 몇십 퍼센트로만 보이던 것이 유형으로 갈렸다.
나눠 세지 않으면 원인이 하나인 문제도 산발적 실패처럼 보인다. 집계 축을 하나 바꾼 것이 이 조사에서 가장 큰 전환이었다.
원인 — 소유 검증이 걸리는 지점
외부 시스템 규칙을 확인하니 인증 토큰 안의 site_id 로 상품 소유를 검증하고 있었다. create 는 아직 상품이 없어 검증할 대상 자체가 없으므로 통과한다.
반면 update 와 suspend 는 기존 상품을 조회하고 그 조회에서 소유 검증이 걸린다. 다른 사이트의 상품으로 판정되면 404 응답이 오고 그것이 상품번호를 확인하라는 메시지로 전달되고 있었다.
검증 — 대조군과 반례
가설을 세우고 같은 업체의 상품 가운데 partners.site_id 가 토큰과 일치하는 건을 찾아 대조군으로 삼았다. 그쪽은 수정 실패가 하나도 없었으므로 다른 이유일 수 있다는 여지가 닫혔다.
세 건 중 하나는 site_id 가 일치하는데도 실패했고 메시지도 달라 다른 원인이었다. 반례를 찾으면 원인의 범위가 좁아지므로 그 건은 이 계열에서 제외한다고 결론에 명시했다.
조치 — 부류로 처리해야 하는 규모
문의 온 세 건을 고치면 끝인지 확인하려고 partners.site_id 가 토큰과 다른 대상을 전부 셌다. 스물다섯 업체의 천 건이 넘는 channel_products 가 동일한 상태였다.
지금 문의가 없을 뿐 그 업체들이 수정을 시도하면 모두 실패한다. 두 가지 방법이 있었는데 문의 온 세 건만 고치는 것과 스물다섯 업체의 site_id 를 한 번에 맞추는 것이다. 뒤쪽을 골랐다. 이유는 조사에서 부류가 드러났는데 건별로 대응하면 같은 문의가 스물두 번 더 와서다. 대신 문의하지 않은 업체의 설정을 사전 고지 없이 바꾸는 것이라 변경 전후 값을 partner_changes 에 남기는 것을 감수했다.
정리
- 등록 성공만 보고 설정이 맞다고 판단하지 않는다
- 소유 검증은 조회를 동반하는 작업에서만 걸린다
- 설정이 틀려도 절반은 성공하므로 늦게 드러난다
- 실패를
job_type별로 나눠 세면 패턴이 드러난다 - 올바른 조건의 대조군이 0건이어야 가설이 선다
- 반례는 원인의 범위를 좁힌다
- 반례를 묶어 버리면 그 건은 안 고쳐진다
- 같은 조건의 잠재 대상을 세어 부류로 처리한다