동시에 실패했다고 원인이 같지 않다

여러 거래처의 데이터 수집이 동시에 실패했다. 동시에 났으니 공통된 무언가가 문제일 것으로 보고 공통 수집기를 의심했다.

Open Table of contents

공통 컴포넌트를 의심한 근거

그 수집기의 변경 이력을 보니 최근 배포가 없었다. 그러면 외부가 일제히 바뀐 것인지 따져 봤는데 여러 거래처가 같은 날 인터페이스를 바꿀 이유가 없다.

양쪽 다 성립하지 않으면 전제 쪽을 의심해야 한다. 동시에 실패했다는 사실에서 원인이 하나라는 결론이 자동으로 나오지는 않는다.

실패 지점의 필드 하나를 골라 그 값이 어디서 채워지는지 검색했다. 공통 수집기가 아니라 거래처마다 있는 자체 클라이언트에서 채우고 있었다.

거래처마다 상대가 주는 필드명이 달라서 매핑도 각자 달랐다. 생산자가 여럿이면 동시 실패의 원인도 여럿일 수 있고 그것은 출처를 따라가야만 드러난다.

더 보니 형식 처리도 클라이언트마다 달랐다. 어떤 것은 형식을 맞춰 넘기고 어떤 것은 다른 변환 함수를 쓰고 어떤 것은 원본을 거의 그대로 넘겼다.

그 값을 받는 공통 팩토리는 하나의 엄격한 형식을 기대하고 있었다. 각자 다른 편차가 한 지점에서 같은 방식으로 걸린 것이었다.

정리하면 공통 컴포넌트가 바뀌어서가 아니라 공통 컴포넌트가 여러 편차를 못 견뎌서였다. 동시에 실패한 것은 그 지점이 하나이기 때문이다.

공통 원인이면 그 하나를 고치면 끝나지만 공통 지점이면 그 지점을 관용적으로 바꿔도 각자의 이유는 남는다. 지금은 통과해도 다음 편차가 오면 같은 자리에서 다시 걸린다.

이것을 알고 나니 조사 범위가 바뀌어서 볼 곳이 각 클라이언트의 매핑과 공통 팩토리의 파싱으로 좁혀졌다. 레거시 공통 수집기는 이 경로와 무관하다는 것도 함께 확정됐다.

볼 필요 없는 곳을 확정하는 것도 조사의 결과이고 나중에 그쪽을 손볼 때 이 경로에 영향이 없다는 근거가 된다.