도는 디렉터리와 고치는 디렉터리

한 채널의 주문 수집이 사흘째 멈췄다는 긴급 건이 왔다. 그 수집이 어디서 도는지부터 찾아야 했다.

Open Table of contents

아는 곳에 없다는 단서

주 시스템 둘의 스케줄러에 그 항목이 없었고 작업 서버 네 대에도 프로세스와 로그가 없었다. 어디 있는지를 계속 묻는 대신 내가 아는 곳에는 없다는 것으로 정리했다.

아는 배포 구조 안에 없다는 사실 자체가 그것이 구조 밖에 있다는 단서였다. 그러면 남은 후보는 다른 목적으로 쓰던 서버들이다.

다른 용도로 쓰던 인터페이스 서버에 들어가 보니 그 앱 안에 스케줄러가 얹혀 있었다. 전혀 다른 목적의 앱에 이 채널 수집이 붙어 있었다.

연동을 만들 때 새 배포 대상을 만드는 것보다 얹는 편이 빨랐을 것으로 보인다. 문제는 배포 구조 밖에 있으면 감시 대상에서도 빠져서 사흘이 지나서야 알게 된다는 점이었다.

그 서버에 비슷한 디렉터리가 둘 있었고 하나에는 운영을 뜻하는 접미사가 붙어 있었다. 스케줄러 코드도 그쪽에 있고 최근에 고친 흔적도 그쪽이었다.

실행 중인 프로세스의 작업 디렉터리를 확인하니 접미사가 없는 쪽이었다. 이름이 운영본을 뜻하지 않으므로 프로세스가 실제로 어디서 떴는지를 봐야 했다.

접미사가 붙은 쪽만 고쳤으면 저장도 되고 커밋도 되지만 재시작해도 옛 코드가 그대로 돈다. 고쳤는데 왜 안 되는지를 다시 조사하게 되는 종류였다.

같은 이유로 그쪽 코드에서 읽은 스케줄 주기도 구동본과 같다는 보장이 없다. 그래서 보고에 그 값을 어느 디렉터리에서 읽었는지와 구동본과 일치한다는 보장이 없다는 것을 함께 적었다.

멈췄다는 판정도 프로세스 상태가 아니라 결과 테이블의 일자별 건수로 했다. 프로세스가 떠 있어도 적재가 0일 수 있고 죽어 있어도 다른 경로로 들어왔을 수 있다.

어느 날부터 0인지는 집계에서만 나온다. 로그 위치도 구동 디렉터리를 따라가므로 다른 쪽에서 찾으면 옛 기록만 나온다.