죽여도 다시 뜬다

배치가 잘못된 결과를 만들고 있어서 급히 멈춰야 했다. 프로세스를 찾아 종료했는데 몇 분 뒤에 다시 떠 있었다.

Open Table of contents

스케줄러가 다시 띄운다

이 배치는 상주 프로세스가 아니라 스케줄러가 주기적으로 실행하는 것이었다. 매분 스케줄러가 돌고 조건이 맞으면 그 배치를 띄운다.

그러니 죽여도 다음 주기에 다시 뜨고 그것도 고치지 않은 옛 코드로 뜬다. 프로세스를 죽이는 행위 자체가 이 구조에서는 아무 효과가 없다.

실제 정지 조건은 수정한 코드를 배포하는 것이었다. 새 코드가 올라가면 그때부터 올바르게 돈다.

급하면 스케줄 등록을 임시로 비활성화하고 배포 뒤에 되돌린다. 무엇이 이 프로세스를 띄우는지를 먼저 찾아야 무엇을 막아야 하는지가 정해진다.

여기서 큰 실수를 할 뻔했는데 급한 마음에 잘못된 결과의 복구를 먼저 하려 했다. 복구를 돌려도 다음 주기에 옛 코드가 다시 떠서 복구분을 덮는다.

순서는 스케줄 비활성화나 수정 배포가 먼저이고 그다음이 대상 서버 반영 확인이며 복구가 마지막이다. 배포했다고 모든 서버에 반영된 것이 아니므로 확인 단계를 빼면 일부 서버에서 같은 일이 반복된다.

기존 복구 도구를 쓰려 했는데 이 유형을 안 고쳤다. 진단이 파일의 존재만 보고 정상으로 판정해서 내용이 잘못된 것을 걸러 내지 못했다.

교정 쪽은 특정 이력이 있는 대상에만 걸리는 게이트에 묶여 있었는데 이번 대상은 작업이 성공으로 기록돼 있어 그 게이트를 못 탔다. 진단은 통과시키고 교정은 대상이 아닌 두 겹으로 빗나가서 결국 게이트 없이 직접 교정을 거는 방식으로 갔다.

프로세스를 확인하는 과정에도 함정이 있었다. 검색 명령의 인자에 그 문자열이 들어 있어서 검색이 자기 자신을 매칭하고 있었다.

그러면 없는데도 항상 결과가 나오므로 판정이 오염된다. 자기를 제외하는 패턴으로 다시 세어 보니 앞서 종료했다고 생각한 서버에 프로세스가 다시 떠 있었다.