자동화가 조용히 죽었는지 보는 점검 6가지

천옥시스템이 매시간 실제로 돌리는 점검에서, 프로그램 없이도 확인할 수 있는 것만 골랐습니다. 전부 저희가 한 번씩 당하고 나서 넣은 항목입니다.

1. 예약 작업이 “돌았다”가 아니라 어떻게 끝났는지를 본다

작업 스케줄러는 실행만 하고 결과는 알려주지 않습니다. 마지막 실행 결과가 0이 아닌 값이면 실패인데, 화면에는 여전히 “준비”라고 떠 있습니다.

저희는 30개 작업 중 28개가 출력을 아무 데도 안 남기고 있었습니다. 죽은 이유를 몰라서 매번 손으로 재현했습니다.

→ 작업마다 로그 파일을 붙입니다. 로그가 없는 자동화는 고장 나도 원인을 못 찾습니다.

2. “성공”이라고 적힌 것을 한 번 되읽는다

보냈다는 기록과 실제로 있는 것은 다릅니다.

발행 허브가 30일 멈춰 있는 동안 리포트에는 성공 표시가 찍혔습니다. 도달 1,708회로 세던 숫자 중 514회는 우리 글이 아예 없는 페이지였습니다. 로그에 번호만 있으면 세도록 짜여 있었기 때문입니다.

→ 보낸 뒤 그 화면을 다시 열어 확인합니다. 확인을 못 했으면 성공이 아니라 실패로 적습니다.

확인 실패를 기록하지 않으면, 다음 실행이 같은 것을 또 보냅니다. 저희는 그렇게 같은 글을 6번 발행했습니다.

3. 오늘 나간 게 0건인지를 매일 센다

고장은 에러로 오지 않고 침묵으로 옵니다.

크롬이 죽은 채 나흘이 지나 예약 작업 13개가 전멸했습니다. 그동안 아무 에러도 안 났습니다.

→ “오늘 처리 건수”를 하루 한 번 확인합니다. 0이면 그것 자체가 경보입니다.

4. 화면에 뜬 숫자가 언제 것인지 확인한다

숫자가 틀린 것보다, 오래된 숫자를 최신인 줄 아는 것이 더 위험합니다.

상태 숫자가 하루 넘게 갱신되지 않은 채로 보고를 냈습니다. 판단은 그 옛 숫자 위에서 이루어졌습니다.

→ 모든 지표 옆에 갱신 시각을 같이 적습니다. 시각이 없는 숫자는 근거로 쓰지 않습니다.

5. 로그인이 살아 있는지를 따로 잰다

자동화가 멈추는 원인 1위는 코드가 아니라 로그인 만료입니다.

하루에 세 번 로그인이 풀렸습니다. 원인은 프로그램을 강제 종료해서 쿠키가 저장되지 않은 것이었습니다.

→ 로그인 상태를 확인하는 점검을 따로 둡니다. 그리고 프로그램을 강제로 죽이지 않습니다 — 정상 종료해야 로그인이 유지됩니다.

6. 검사기가 거짓말하는지 검사한다

마지막이자 제일 자주 놓치는 항목입니다.

저희 검사기가 결제 페이지 16곳을 “필수 문구 없음”으로 매일 찍고 있었습니다. 열어 보니 16곳 모두 문구가 있었고, 표현만 달랐습니다. 반대로 멀쩡한 채널을 “발행 금지”로 표시해 나흘 동안 세워둔 적도 있습니다.

→ 검사기에 정상인 것을 한 번 넣어 봅니다. 정상이 정상으로 나오는지 안 보면, 검사는 방향까지 뒤집힙니다.

빨간 줄이 매일 뜨면 사람이 곧 안 봅니다. 거짓 경보를 내는 검사는 없는 것과 같습니다.

한 줄로 줄이면

이 점검을 대신 돌려드리기도 합니다