Jobbstatusen seier suksess, loggen viser ei fullført køyring, og dataa er utdaterte eller manglar. Den kombinasjonen tyder vanlegvis på at den planlagde jobben starta utan banen han trong, og at noko lenger nede slukte feilen. Ein tidsplan som utløyser i tide seier ingenting om nettverket var klart. Gapet mellom desse to fakta er der denne feilen lever.

Tilgang høyrer til køyringa, ikkje til eksistensen av ei cron-fil.

Ei grøn køyring er ikkje ein fullført jobb

Ein planleggjar noterer at ein prosess starta og seinare avslutta; han anar ikkje om prosessen nådde ressursen han finst for. Eit skript som handsamar ei mislukka tilkopling som eit tomt resultat, eller fangar ein feil og avsluttar med null, vil sjå sunt ut for alltid. Symtomet er ikkje ein raud status; det er ein truverdig status knytt til manglande arbeid.

Namngje kva køyringa faktisk treng før de avgjer korleis ho skal kontrollerast. Ein sikkerheitskopi kan trengje privat DNS og eit autentisert endepunkt, ikkje berre ein tunnelprosess.

Kontroller tilkoplinga, ikkje grensesnittnamnet

Eit grensesnitt kalla tun0 kan finnast utan økta som betyr noko, og ei anna tilkopling kan eige det namnet. Kontroller det konkrete objektet jobben er avhengig av: éin profilidentitet, éin tenesteinstans eller ein liten godkjend operasjon mot ressursen. Hald kontrollen tidsavgrensa, og hald påloggingsinformasjon utanfor prosessargument og diagnostiske loggar.

Definer òg resultatet ved fråkopling. Eit vanleg hopp, eit nytt forsøk innanfor eit kort vindauge og ein operatørsynleg overskriden frist er tre ulike svar, og ein tilbakevendande tidsplan vel ikkje mellom dei.

Hopp og feil er ulike resultat

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

I ei systemd-utrulling køyrer ExecCondition= den kontrollen før arbeidslasta. Utgangsåtferda er særeigen: null held fram, kodar frå éin til 254 hoppar over dei gjenverande startkommandoane utan å merke eininga som mislukka, og 255 eller unormal avslutning feilar henne. Det gjev tre distinkte signal, nyttige berre dersom kontrakten til kontrollen med vilje er knytt til dei. Innstillingar som omdefinerer suksess kan endre biletet, så dokumenter tilordninga.

Det er registreringa av hopp som gjer designet ærleg. Ei hoppa køyring som ikkje viser seg nokon stad, kan ikkje skiljast frå ei køyring som lukkast, og handsaming av kvar kontrollfeil som eit stille hopp skjuler ei øydelagd utrulling på ubestemd tid.

Vern heile køyringa, ikkje berre starten

Ein beredskapskontroll observerer verda før lansering; han overvakar ikkje kvar socket etterpå. Når ein direkte bane aldri er akseptabel for denne jobben, fest ein godkjend utgangspolicy som vert handheva kontinuerleg og dekkjer DNS, IPv6 og den eigne transporten til tunnelen. Å byta verten sin globale IPv6-tilstand er ikkje ei erstatning for ein policy avgrensa til jobben.

Avgjer om ein ny hending kan overlappe ein jobb som framleis køyrer, hald den regelen hos eigaren av arbeidslasta, og gjer nytt forsøk trygt for dataoperasjonen. Å stoppe ein jobb ved fråkopling avgrensar arbeidet utan å garantere noko om reservelast.

Godta arbeidsflyten i tre tilfelle: klar bane, utilgjengeleg bane og tap midt i køyringa. Alt mindre testar tidsplanen, ikkje jobben.

Relaterte artiklar