VPN 없이 실행된 예약 작업은 멀쩡해 보인다

작업 상태는 성공이라고 하고, 로그는 완료된 실행을 보여 주며, 데이터는 오래되었거나 없다. 이 조합은 보통 예약 작업이 필요한 경로 없이 시작되었고 하류의 무언가가 실패를 삼켰다는 뜻이다. 제때 실행되는 일정은 네트워크가 준비되었는지에 대해 아무 말도 하지 않는다. 이 두 사실 사이의 틈이 바로 이 실패가 사는 곳이다.

허용은 실행에 속하지, cron 파일의 존재에 속하지 않는다.

초록 실행은 완료된 작업이 아니다

스케줄러는 프로세스가 시작되고 나중에 종료되었다고 기록할 뿐, 그 프로세스가 존재 목적인 리소스에 도달했는지는 모른다. 실패한 연결을 빈 결과로 취급하거나 오류를 잡아 영으로 종료하는 스크립트는 영원히 건강해 보일 것이다. 증상은 빨간 상태가 아니라 빠진 작업에 붙은 그럴듯한 상태다.

어떻게 검사할지 정하기 전에 실행이 실제로 무엇을 필요로 하는지 이름 붙여라. 백업에는 사설 DNS와 인증된 엔드포인트가 필요할 수 있으며, 단순한 터널 프로세스로는 부족하다.

연결을 검사하고, 인터페이스 이름을 검사하지 마라

tun0라는 이름의 인터페이스는 중요한 세션 없이도 존재할 수 있고, 다른 연결이 그 이름을 가질 수도 있다. 작업이 의존하는 특정 객체를 검사하라: 하나의 프로필 정체성, 하나의 서비스 인스턴스, 또는 리소스에 대한 작은 승인된 작업이다. 검사는 시간으로 제한하고 자격 증명은 프로세스 인자와 진단 로그 밖에 두라.

연결이 끊겼을 때의 결과도 정의하라. 평범한 건너뛰기, 짧은 창 안의 재시도, 운영자에게 보이는 놓친 기한은 세 가지 다른 답이며, 반복 일정은 그중에서 고르지 않는다.

건너뛰기와 실패는 다른 결과다

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

systemd 배포에서는 ExecCondition= 가 워크로드 전에 그 검사기를 실행한다. 종료 동작은 특정하다: 영은 계속하고, 하나에서 254까지의 코드는 유닛을 실패로 표시하지 않고 남은 시작 명령을 건너뛰며, 255 또는 비정상 종료는 유닛을 실패시킨다. 이는 세 가지 다른 신호를 주며, 검사기의 계약이 의도적으로 그것들에 매핑될 때만 유용하다. 성공을 재정의하는 설정은 그림을 바꿀 수 있으므로 매핑을 문서화하라.

건너뛰기를 기록하는 것이 설계를 정직하게 만든다. 어디에도 나타나지 않는 건너뛴 실행은 성공한 실행과 구별되지 않으며, 모든 검사기 오류를 조용한 건너뛰기로 취급하는 것은 망가진 배포를 끝없이 숨긴다.

실행 전체를 지켜라, 시작만이 아니라

준비 검사는 시작 전에 세상을 관찰할 뿐, 이후 모든 소켓을 감시하지는 않는다. 이 작업에 직접 경로가 결코 허용될 수 없다면, DNS, IPv6, 터널 자체의 전송을 지속적으로 포괄해 강제하는 승인된 이그레스 정책을 붙여라. 호스트의 전역 IPv6 상태를 바꾸는 것은 작업에 한정된 정책을 대신하지 못한다.

새 이벤트가 아직 실행 중인 작업과 겹칠 수 있는지 결정하고, 그 규칙을 워크로드 소유자에게 두며, 데이터 작업에 대해 재시도를 안전하게 만들어라. 연결이 끊길 때 작업을 멈추는 것은 작업을 제한하지만 대체 트래픽에 대해 아무것도 보장하지 않는다.

세 가지 경우로 워크플로를 받아들여라: 준비된 경로, 사용할 수 없는 경로, 실행 중 손실이다. 그보다 못한 것은 일정을 시험하지, 작업을 시험하지 않는다.