Ett schemalagt jobb som kördes utan VPN ser bra ut

Jobbstatusen säger framgång, loggen visar en slutförd körning, och data är inaktuella eller saknas. Den kombinationen betyder oftast att det schemalagda jobbet startade utan den väg det behövde, och att något längre ned svalde felet. Ett schema som utlöses i tid säger ingenting om huruvida nätverket var redo. Gapet mellan dessa två fakta är där detta fel lever.

Tillträde hör till körningen, inte till att en cron-fil finns.

En grön körning är inte ett slutfört jobb

En schemaläggare noterar att en process startade och senare avslutades; den har ingen aning om processen nådde resursen den finns för. Ett skript som behandlar en misslyckad anslutning som ett tomt resultat, eller fångar ett fel och avslutar med noll, kommer att se friskt ut för alltid. Symtomet är inte en röd status; det är en trovärdig status fäst vid arbete som saknas.

Namnge vad körningen faktiskt behöver innan ni bestämmer hur den ska kontrolleras. En säkerhetskopia kan behöva privat DNS och en autentiserad slutpunkt, inte bara en tunnelprocess.

Kontrollera anslutningen, inte gränssnittsnamnet

Ett gränssnitt som heter tun0 kan finnas utan sessionen som betyder något, och en annan anslutning kan äga det namnet. Kontrollera det specifika objekt som jobbet beror på: en profilidentitet, en tjänstinstans eller en liten godkänd operation mot resursen. Håll kontrollen tidsbegränsad och håll inloggningsuppgifter utanför processargument och diagnostikloggar.

Definiera också resultatet vid frånkoppling. En vanlig överhoppning, ett nytt försök inom ett kort fönster och en operatörssynlig missad deadline är tre olika svar, och ett återkommande schema väljer inte mellan dem.

Överhoppningar och fel är olika resultat

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

I en systemd-distribution kör ExecCondition= den kontrollen före arbetslasten. Dess utbeteende är specifikt: noll fortsätter, koder från ett till 254 hoppar över de återstående startkommandona utan att markera enheten som misslyckad, och 255 eller onormal avslutning får den att misslyckas. Det ger tre distinkta signaler, användbara bara om kontrollens kontrakt medvetet mappas till dem. Inställningar som omdefinierar framgång kan ändra bilden, så dokumentera mappningen.

Det är registreringen av överhoppningar som gör designen ärlig. En överhoppad körning som inte visas någonstans går inte att skilja från en körning som lyckades, och att behandla varje kontrollfel som en tyst överhoppning döljer en trasig distribution på obestämd tid.

Skydda hela körningen, inte bara starten

En beredskapskontroll observerar världen före lansering; den övervakar inte varje socket efteråt. När en direkt väg aldrig är acceptabel för detta jobb, fäst en godkänd utgående policy som tillämpas kontinuerligt och täcker DNS, IPv6 och tunnelns egen transport. Att växla värdens globala IPv6-läge ersätter inte en policy begränsad till jobbet.

Bestäm om en ny händelse får överlappa ett jobb som fortfarande körs, håll den regeln hos ägaren av arbetslasten, och gör nytt försök säkert för dataoperationen. Att stoppa ett jobb vid frånkoppling begränsar arbetet utan att garantera något om reservtrafik.

Acceptera arbetsflödet i tre fall: klar väg, otillgänglig väg och förlust mitt i körningen. Allt mindre testar schemat, inte jobbet.