En planlagt jobb som kjørte uten VPN ser bra ut

Jobbstatusen sier suksess, loggen viser en fullført kjøring, og dataene er utdaterte eller borte. Kombinasjonen betyr som regel at den planlagte jobben startet uten veien den trengte, og at noe lenger ned svelget feilen. En timeplan som utløses i tide sier ingenting om nettverket var klart. Mellomrommet mellom disse to fakta er der denne feilen bor.

Adgang hører til kjøringen, ikke til at en cron-fil finnes.

En grønn kjøring er ikke en fullført jobb

En planlegger noterer at en prosess startet og senere gikk ut; den har ingen anelse om prosessen nådde ressursen den finnes for. Et skript som behandler en mislykket forbindelse som et tomt resultat, eller fanger en feil og avslutter med null, vil se frisk ut for alltid. Symptomet er ikke en rød status; det er en troverdig status festet til arbeid som mangler.

Navngi hva kjøringen faktisk trenger før dere bestemmer hvordan den skal sjekkes. En sikkerhetskopi kan trenge privat DNS og et autentisert endepunkt, ikke bare en tunnelprosess.

Sjekk forbindelsen, ikke grensesnittnavnet

Et grensesnitt kalt tun0 kan finnes uten økten som betyr noe, og en annen forbindelse kan eie navnet. Sjekk det konkrete objektet jobben er avhengig av: én profilidentitet, én tjenesteinstans eller en liten godkjent operasjon mot ressursen. Hold sjekken tidsbegrenset, og hold påloggingsinformasjon utenfor prosessargumenter og diagnostiske logger.

Definer også resultatet ved frakobling. Et vanlig hopp, et nytt forsøk innen et kort vindu og en operatørsynlig overskredet frist er tre forskjellige svar, og en gjentakende timeplan velger ikke mellom dem.

Hopp og feil er forskjellige resultater

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

I en systemd-utrulling kjører ExecCondition= den kontrollen før arbeidslasten. Utgangsatferden er spesiell: null fortsetter, koder fra én til 254 hopper over de gjenværende startkommandoene uten å merke enheten som mislykket, og 255 eller unormal avslutning feiler den. Det gir tre ulike signaler, nyttige bare hvis kontraktens kontroll bevisst er knyttet til dem. Innstillinger som omdefinerer suksess kan endre bildet, så dokumenter tilordningen.

Det er føringen av hopp som gjør designet ærlig. En hoppet kjøring som ikke vises noe sted, kan ikke skilles fra en kjøring som lyktes, og å behandle hver kontrollfeil som et stille hopp skjuler en ødelagt utrulling på ubestemt tid.

Vern hele kjøringen, ikke bare starten

En beredskapskontroll observerer verden før lansering; den overvåker ikke hver socket etterpå. Når en direkte vei aldri er akseptabel for denne jobben, fest en godkjent utgangspolicy som håndheves kontinuerlig og dekker DNS, IPv6 og tunnelens egen transport. Å bytte vertens globale IPv6-tilstand er ikke en erstatning for en policy begrenset til jobben.

Avgjør om en ny hendelse kan overlappe en jobb som fortsatt kjører, hold den regelen hos eieren av arbeidslasten, og gjør nytt forsøk trygt for dataoperasjonen. Å stoppe en jobb ved frakobling begrenser arbeidet uten å garantere noe om reserverutrafikk.

Godta arbeidsflyten i tre tilfeller: klar vei, utilgjengelig vei og tap midt i kjøringen. Alt mindre tester timeplanen, ikke jobben.