여러 대에 걸린 배치 스케줄이 배정표대로 등록돼 있는지 점검하면서 표가 아니라 각 기계의 실제 등록 상태를 조회했다. 네 대를 훑는 동안 backup.sh 헤더의 주석 하나가 표와 어긋나는 것을 발견했다.
Table of contents
Open Table of contents
배경 — 표가 아니라 기계에 묻기
SCHEDULE.md 에는 머신마다 몇 시에 무엇을 돌리는지 적혀 있지만 그것이 맞는지는 기계에 물어야 안다. Linux 는 crontab -l 로 macOS 는 launchctl list 로 Windows 는 schtasks /query 로 각각 등록 목록을 뽑았다.
문서를 문서로 확인하면 순환이므로 문서에서 기계로 그리고 소스로 내려가야 한다. 표만 봤다면 전부 맞다고 판정하고 끝냈을 자리였다.
문제 — 없는 작업을 찾게 만든 주석
주석에는 prune 작업 외부 스케줄을 이 스크립트가 관리하지 않는다는 문장이 있었다. 그것을 읽고 별도 prune 작업이 어딘가 있어야 한다고 이해했는데 네 대 어디에도 없었다.
네 대 모두가 같은 항목을 빠뜨렸다고 보기는 어려운 상황이었다. 그래서 그 작업이 무엇을 부르는지부터 소스에서 확인하기로 했다.
원인 — 존재하지 않던 실행 모드
소스에서 --prune-only 플래그를 찾으니 아예 없었고 --mode 는 backup 과 verify 와 restore 셋뿐이었다. 삭제만 수행하는 모드가 없으므로 그런 작업을 걸 방법 자체가 없었다.
prune() 은 verify 모드 안에서 검증이 끝난 뒤에 이어서 호출되고 있었다. 즉 정리는 매일 도는 검증 스케줄에 딸려 돌고 있어 별도 작업이 필요 없는 구조였다.
조건부 안내를 필수로 읽은 오독
주석 원문을 다시 읽으니 외부에 별도로 두는 경우라는 조건절이 앞에 있었다. 만약 외부에 둔다면 그것은 이 스크립트가 관리하지 않는다는 뜻이었다.
나는 그것을 외부에 두어야 하고 그것은 이 스크립트 밖이라는 뜻으로 읽었다. 조건부 안내를 필수 구성으로 읽으면 존재하지 않는 작업을 찾아 헤매게 된다. 두 가지 방법이 있었는데 주석은 두고 SCHEDULE.md 에 설명을 더하는 것과 주석 자체를 오해 지점을 닫는 문장으로 고치는 것이다. 뒤쪽을 골랐다. 이유는 다음 사람도 표가 아니라 스크립트 헤더를 먼저 읽어서다. 대신 주석 한 줄 때문에 네 대에 backup.sh 를 다시 내보내야 하는 것을 감수했다.
시각 오프셋에 있던 이유
주석이 말한 일 분 뒤라는 오프셋의 근거도 소스 두 곳의 주석에서 확인했다. 업로드를 수행하는 컨테이너와 prune() 이 docker run -v 로 같은 볼륨을 공유하고 있었다.
같은 분에 돌리면 업로드가 쓰는 중인 파일을 정리가 지울 수 있으므로 순서를 보장하려고 미룬 것이었다. 이유를 알고 나니 굳이 외부에 두겠다면 그 머신의 업로드 시각 기준으로 밀어야 한다는 규칙이 명확해졌다.
정리
- 배정표가 아니라
crontab -l같은 기계의 실제 등록 상태를 본다 - 문서를 문서로 확인하는 것은 순환이다
- 조건부 안내를 필수 구성으로 읽으면 없는 작업을 찾는다
- 주석이 애매하면 소스로 역추적한다
- 플래그가 아예 존재하지 않을 수도 있다
- 후처리는 앞 단계의 스케줄에 딸려 도는 경우가 있다
- 시각 오프셋에는 자원 공유 같은 이유가 있다
- 오해한 주석은 오해 지점을 닫는 문장으로 고친다