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