한 채널의 DUPLICATE_ATTRIBUTE 오류를 정리하는 캠페인을 돌려 7천 건이 넘는 건을 처리했다. 기록을 남기려고 정리하다가 이것이 종결이 아니라는 것을 확인했다.
Table of contents
Open Table of contents
원인 — 코드에 있던 원인
이 오류의 원인을 다시 봤다. LegacyProductUpdater 가 수정할 때마다 속성을 mode=create 로 재전송하고 있었다.
마켓 입장에서는 이미 있는 속성을 또 등록하려는 것이 되어 DUPLICATE_ATTRIBUTE 가 난다. 새 경로의 OpenApiClient 도 마찬가지였으므로 데이터 문제가 아니라 코드 문제였다.
미배포인 근본 수정
이것을 고치는 작업이 따로 있었는데 PUT /attributes 엔드포인트로 전환하는 것이었다. git log origin/master 로 배포 상태를 확인하니 아직 배포되지 않았다.
지금 코드는 여전히 수정할 때마다 중복 오류를 만든다는 뜻이다. 그러면 내가 한 캠페인은 밀린 것을 치운 드레인이고 원인은 그대로 남아 있다.
검증 — 숫자로 실증한 유입
이것이 추측이 아니라는 것을 숫자로 확인했다. 1차 캠페인의 스냅샷을 찍은 시점 이후로 created_at 이 그보다 뒤인 새 오류가 스무 건 남짓 추가 발생해 있었다.
products 를 수정할 때마다 그 상품의 product_options 가 다시 오류가 나고 있었다. 숫자로 확인하니 재발할 것이라는 예상이 재발하고 있다는 관측이 됐다.
조치 — 바꾼 보고 문구
두 가지 방법이 있었는데 원래대로 처리 완료와 잔존 0건만 보고하는 것과 근본 원인 미수정과 유입 진행 중을 덧붙이는 것이다. 뒤쪽을 골랐다. 이유는 잔존 0 만 쓰면 읽는 사람이 끝난 줄 알아서다. 대신 완료 보고가 완료처럼 안 읽히는 것을 감수했다. 스냅샷 이후 신규가 실제로 발생했다는 것도 덧붙였다.
같은 작업이 주기적으로 재발한다고 봐야 한다는 문장도 넣었다. 잔존 0만 쓰면 읽는 사람이 끝난 줄 알고 아무도 원인을 안 고친다.
후속 캠페인에 착수하기 전에 PUT /attributes 전환의 배포 여부를 먼저 확인한다는 것도 적었다. 배포됐으면 그 캠페인이 마지막이 되고 안 됐으면 또 드레인이므로 같은 작업을 반복하기 전에 조건이 바뀌었는지를 봐야 한다.
판단 기준 — 기록 위치와 두 용어
이 내용을 어디에 남길지도 정했다. 개요와 링크만 있는 README.md 가 아니라 처리 내역이 누적되는 INCIDENTS.md 가 정본이다.
상위 페이지에 쓰면 개요가 길어지고 다음 사람이 처리 내역을 찾을 때 거기를 안 본다. 기록은 그 종류의 기록이 이미 쌓이는 곳에 남기고 새 자리를 만들지 않는다. 그리고 작업을 보고할 때 원인을 없앤 수정인지 결과를 치운 드레인인지를 밝히기로 했는데 드레인도 필요한 작업이지만 수정처럼 보고하면 아무도 원인을 안 고치기 때문이다.
정리
- 잔존 0이 종결이 아니고 원인이 남아 있으면 재발한다
- 원인이 데이터가 아니라
mode=create같은 코드면 데이터 정리는 드레인이다 - 근본 수정의 배포 여부를
git log origin/master로 확인한다 - 유입이 진행형인지를 숫자로 확인한다
- 보고에 종결이 아니라는 것을 명시한다
- 같은 작업을 반복하기 전에 조건이 바뀌었는지 본다
- 기록은
INCIDENTS.md처럼 그 종류가 이미 쌓이는 곳에 남긴다 - 드레인과 수정을 구분해 보고한다