Un'attività pianificata che è girata senza la VPN sembra a posto

Lo stato dell'attività dice successo, il registro mostra un'esecuzione completata e i dati sono obsoleti o assenti. Questa combinazione di solito significa che l'attività pianificata è partita senza il percorso che le serviva, e che qualcosa più a valle ha inghiottito il guasto. Una pianificazione che scatta in orario non dice nulla sul fatto che la rete fosse pronta. Il divario tra questi due fatti è il luogo in cui vive questo guasto.

L'ammissione appartiene all'esecuzione, non all'esistenza di un file cron.

Un'esecuzione verde non è un'attività completata

Un pianificatore annota che un processo è partito e poi è uscito; non ha idea se quel processo abbia raggiunto la risorsa per cui esiste. Uno script che tratta una connessione fallita come un risultato vuoto, o che cattura un errore ed esce con zero, sembrerà sano per sempre. Il sintomo non è uno stato rosso; è uno stato plausibile attaccato a lavoro mancante.

Nominate ciò di cui l'esecuzione ha davvero bisogno prima di decidere come verificarla. Un backup può aver bisogno di DNS privato e di un endpoint autenticato, non solo di un processo tunnel.

Verificate la connessione, non il nome dell'interfaccia

Un'interfaccia chiamata tun0 può esistere senza la sessione che conta, e un'altra connessione può possedere quel nome. Verificate l'oggetto preciso da cui dipende l'attività: un'identità di profilo, un'istanza di servizio o una piccola operazione approvata contro la risorsa. Tenete la verifica limitata nel tempo e tenete le credenziali fuori dagli argomenti del processo e dai registri diagnostici.

Definite anche il risultato della disconnessione. Un salto ordinario, un nuovo tentativo entro una finestra breve e una scadenza mancata visibile all'operatore sono tre risposte diverse, e una pianificazione ricorrente non sceglie tra loro.

I salti e i guasti sono risultati diversi

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

In un deployment systemd, ExecCondition= esegue quel verificatore prima del carico di lavoro. Il suo comportamento in uscita è specifico: zero continua, i codici da uno a 254 saltano i comandi di avvio rimanenti senza marcare l'unità come fallita, e 255 o una terminazione anomala la fanno fallire. Questo dà tre segnali distinti, utili solo se il contratto del verificatore è mappato deliberatamente su di essi. Le impostazioni che ridefiniscono il successo possono cambiare il quadro, quindi documentate la mappatura.

È la registrazione dei salti che rende onesto il progetto. Un'esecuzione saltata che non appare da nessuna parte è indistinguibile da un'esecuzione riuscita, e trattare ogni errore del verificatore come un salto silenzioso nasconde indefinitamente un deployment rotto.

Proteggete l'intera esecuzione, non solo l'avvio

Una verifica di prontezza osserva il mondo prima del lancio; non sorveglia ogni socket dopo. Quando un percorso diretto non è mai accettabile per questa attività, allegate una politica di uscita approvata applicata in modo continuo e che copra DNS, IPv6 e il trasporto proprio del tunnel. Cambiare lo stato IPv6 globale dell'host non sostituisce una politica limitata all'attività.

Decidete se un nuovo evento può sovrapporsi a un'attività ancora in corso, tenete quella regola presso il proprietario del carico di lavoro e rendete sicuro il nuovo tentativo per l'operazione sui dati. Fermare un'attività alla disconnessione limita il lavoro senza garantire nulla sul traffico di riserva.

Accettate il flusso di lavoro in tre casi: percorso pronto, percorso non disponibile e perdita durante l'esecuzione. Qualcosa di meno mette alla prova la pianificazione, non l'attività.