Një punë e planifikuar që u ekzekutua pa VPN duket në rregull

Statusi i punës thotë sukses, regjistri tregon një ekzekutim të përfunduar, dhe të dhënat janë të vjetra ose mungojnë. Ky kombinim zakonisht do të thotë që puna e planifikuar filloi pa rrugën që i nevojitej, dhe diçka më poshtë e gëlltiti dështimin. Një orar që aktivizohet në kohë nuk thotë asgjë për atë nëse rrjeti ishte gati. Hendeku midis këtyre dy fakteve është vendi ku jeton ky dështim.

Pranimi i përket ekzekutimit, jo ekzistencës së një skedari cron.

Një ekzekutim i gjelbër nuk është punë e përfunduar

Planifikuesi shënon se një proces filloi dhe më vonë doli; ai nuk ka asnjë ide nëse ai proces arriti burimin për të cilin ekziston. Një skript që e trajton një lidhje të dështuar si rezultat bosh, ose kap një gabim dhe del me zero, do të duket i shëndetshëm përgjithmonë. Simptoma nuk është një status i kuq; është një status i besueshëm i lidhur me punë që mungon.

Emërtoni çfarë i nevojitet vërtet ekzekutimit përpara se të vendosni si ta kontrolloni. Një kopje rezervë mund të ketë nevojë për DNS privat dhe një pikë fundore të vërtetuar, jo vetëm një proces tuneli.

Kontrolloni lidhjen, jo emrin e ndërfaqes

Një ndërfaqe e quajtur tun0 mund të ekzistojë pa sesionin që ka rëndësi, dhe një lidhje tjetër mund ta zotërojë atë emër. Kontrolloni objektin specifik nga i cili varet puna: një identitet profili, një shembull shërbimi, ose një operacion i vogël i miratuar ndaj burimit. Mbani kontrollin të kufizuar në kohë, dhe mbani kredencialet jashtë argumenteve të procesit dhe regjistrave diagnostikues.

Përcaktoni gjithashtu rezultatin e shkëputjes. Një kalim i zakonshëm, një provë e përsëritur brenda një dritareje të shkurtër dhe një afat i humbur i dukshëm për operatorin janë tre përgjigje të ndryshme, dhe një orar i përsëritur nuk zgjedh midis tyre.

Kalimet dhe dështimet janë rezultate të ndryshme

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

Në një implementim systemd, ExecCondition= ekzekuton atë kontrollues përpara ngarkesës së punës. Sjellja e daljes është specifike: zero vazhdon, kodet nga një në 254 kalojnë komandat e mbetura të nisjes pa e shënuar njësinë si të dështuar, dhe 255 ose një përfundim jonormal e dështon atë. Kjo jep tre sinjale të dallueshme, të dobishme vetëm nëse kontrata e kontrolluesit është hartuar qëllimisht mbi to. Cilësimet që ripërcaktojnë suksesin mund ta ndryshojnë pamjen, prandaj dokumentoni hartëzimin.

Regjistrimi i kalimeve është ai që e bën dizajnin të ndershëm. Një ekzekutim i kaluar që nuk shfaqet askund nuk dallohet nga një ekzekutim që pati sukses, dhe trajtimi i çdo gabimi të kontrolluesit si një kalim i heshtur fsheh pafundësisht një implementim të prishur.

Mbrojeni të gjithë ekzekutimin, jo vetëm nisjen

Një kontroll gatishmërie vëzhgon botën përpara lëshimit; ai nuk mbikëqyr çdo socket më pas. Kur një rrugë e drejtpërdrejtë nuk është kurrë e pranueshme për këtë punë, bashkëngjitni një politikë dalëse të miratuar që zbatohet vazhdimisht dhe mbulon DNS, IPv6 dhe transportin e vetë tunelit. Ndryshimi i gjendjes globale të IPv6 të hostit nuk zëvendëson një politikë të kufizuar në punë.

Vendosni nëse një ngjarje e re mund të mbivendoset me një punë që ende po ekzekutohet, mbani atë rregull te pronari i ngarkesës së punës, dhe bëni provën e përsëritur të sigurt për operacionin e të dhënave. Ndërprerja e një pune në shkëputje kufizon punën pa garantuar asgjë për trafikun rezervë.

Pranoni rrjedhën e punës në tre raste: rrugë gati, rrugë e padisponueshme, dhe humbje në mes të ekzekutimit. Çdo gjë më pak teston orarin, jo punën.