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