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

Jobbstatusen sier suksess, loggen viser en fullført kjøring, og dataene er utdaterte eller mangler. Den kombinasjonen betyr vanligvis at den planlagte jobben startet uten banen den trengte, og at noe lenger ned slukte feilen. En tidsplan som utløses i tide sier ingenting om hvorvidt nettverket var klart. Gapet mellom disse to fakta er der denne feilen lever.

Adgang hører til kjøringen, ikke til eksistensen av en cron-fil.

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

En planlegger noterer at en prosess startet og senere avsluttet; den aner ikke om prosessen nådde ressursen den eksisterer for. Et skript som behandler en mislykket tilkobling som et tomt resultat, eller fanger en feil og avslutter med null, vil se sunt ut for alltid. Symptomet er ikke en rød status; det er en plausibel status knyttet til manglende arbeid.

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

Kontroller tilkoblingen, ikke grensesnittnavnet

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

Definer også resultatet ved frakobling. Et vanlig hopp, et nytt forsøk innenfor et kort vindu og en operatørsynlig overskredet frist er tre forskjellige svar, og en tilbakevendende tidsplan 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 spesifikk: null fortsetter, koder fra én til 254 hopper over de gjenværende startkommandoene uten å markere enheten som mislykket, og 255 eller unormal avslutning feiler den. Det gir tre distinkte signaler, nyttige bare hvis kontrollens kontrakt bevisst tilordnes dem. Innstillinger som omdefinerer suksess kan endre bildet, så dokumenter tilordningen.

Det er registreringen 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 behandling av hver kontrollfeil som et stille hopp skjuler en ødelagt utrulling på ubestemt tid.

Beskytt hele kjøringen, ikke bare starten

En beredskapskontroll observerer verden før lansering; den overvåker ikke hver socket etterpå. Når en direkte bane 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.

Bestem 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 reservetrafikk.

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