Separate i controlli di salute della VPN da quelli dell’applicazione

Il processo del tunnel può essere in esecuzione mentre la connessione protetta è inutilizzabile, e una pagina web che fallisce non è prova che il tunnel si sia rotto. Quando una sola sonda rappresenta tutte le altre, una politica di riavvio riavvia il componente sbagliato e la chiama automazione. Ogni controllo qui sotto nomina il livello che osserva, l’azione che il suo fallimento attiva e la prova che l’azione ha funzionato. L’ultimo passo trasforma l’intero insieme in una pagina che qualcuno può seguire alle tre del mattino.

Passo 1: nominate il livello che ogni controllo osserva

Chiedete che cosa può vedere davvero ogni sonda prima di scriverne una. La vitalità dimostra che il demone è attivo, una stretta di mano o un elenco di peer dimostra che la relazione esiste, una richiesta instradata dimostra la consegna e una risoluzione dimostra la risoluzione dei nomi. Falliscono esattamente in quest’ordine e nessuna implica la successiva. Un controllo di processo verde accanto a un tunnel morto è il caso normale, non una contraddizione.

Scrivete i quattro controlli in quest’ordine, con il comando esatto e l’output atteso per ciascuno. Una sonda di cui non sapete enunciare l’output atteso sarà letta in modo diverso da ogni operatore che vede l’avviso. Mettete lo stesso elenco nel testo dell’avviso, non solo nel runbook, così che la persona svegliata di notte incontri il livello prima del sintomo. Tenete ogni comando pronto da copiare sull’host che lo esegue.

Poi aggiungete il controllo dell’applicazione come quinto elemento, separato. Una pagina il cui servizio account è inattivo non giustifica un riavvio del tunnel.

Passo 2: legate ogni fallimento a una sola azione

Per ogni controllo decidete che cosa si riavvia, che cosa resta bloccato e che cosa avvisa una persona. Un fallimento del livello tunnel può giustificare un riavvio del tunnel; un fallimento del resolver punta all’integrazione DNS sul client; un fallimento del livello applicazione non dovrebbe quasi mai toccare il tunnel.

Dite che cosa un fallimento non deve fare, perché i valori predefiniti pericolosi sono quelli permissivi. Uno stato non sano non deve mai diventare un permesso per il traffico applicativo diretto, dato che una via di riserva che aggira il tunnel in silenzio elimina la ragione per cui il tunnel esiste. Restringete anche le azioni: riavviare un componente condiviso perché una destinazione è lenta trasforma un problema locale in un problema di tutta la flotta. Distrugge anche la prova che vi serviva per trovare la causa.

Passo 3: mantenete le sonde innocue ed economiche

Usate richieste piccole e di sola lettura: una risorsa statica, un endpoint di salute che riporta la propria dipendenza o una connessione TCP a una porta che controllate. Evitate credenziali, navigazione privata e qualsiasi cosa che modifichi lo stato a ogni intervallo, perché una sonda che scrive è un test di carico programmato.

Registrate la destinazione, l’attesa di rotta e il timeout di ogni sonda. L’attesa di rotta è il campo che le persone omettono, ed è ciò che separa un fallimento del tunnel da un errore di instradamento quando leggete l’avviso più tardi. Derivate l’intervallo e la soglia di fallimento dal tempo di ripristino che promettete, e mantenete il timeout più breve dell’intervallo. Una sonda ancora in esecuzione quando parte la successiva segnala un fallimento due volte e sembra un lampeggio.

Passo 4: rompete ogni livello e guardate se la sonda giusta diventa rossa

Fermate il processo del tunnel e confermate che il controllo di processo fallisce mentre il DNS può ancora rispondere dalla cache. Cambiate una rotta e confermate che la richiesta instradata fallisce mentre il processo e la stretta di mano restano sani. Rompete solo il DNS e confermate che il controllo dell’applicazione segnala una risoluzione invece di un errore di tunnel. Se due sonde si muovono sempre insieme, avete meno controlli di quanto pensiate.

Provate la direzione di ripristino con la stessa disciplina. Dopo aver ripristinato il livello, la sonda dovrebbe rientrare senza un riavvio manuale, e l’azione che è scattata non dovrebbe lasciare alcuna deviazione dietro di sé. Osservate un ciclo completo prima di fidarvi dello stato verde, perché una sonda che rientra solo a mano nasconde un percorso di ripristino rotto.

Passo 5: mettete il runbook dove punta l’avviso

Una pagina con cinque righe porta l’intero progetto: livello, comando, risultato atteso, azione in caso di fallimento, responsabile. Aggiungete una riga per sonda su ciò che deliberatamente non verifica. È quella riga che impedisce alla persona successiva di aggiungere un sesto controllo che misura tutto e non distingue nulla. Collegate la pagina dal testo dell’avviso, altrimenti nessuno la aprirà mentre l’incidente è in corso.

Nei deployment a container, una condizione di dipendenza dà forma all’avvio e a nient’altro. La documentazione sull’ordine di avvio e sulla condizione di salute di Compose descrive come la prontezza determina l’ordine in cui i servizi partono; nulla di tutto ciò applica poi una politica di uscita, e nulla di tutto ciò fallisce chiuso quando il tunnel cade. L’applicazione continua richiede una propria politica e una propria sonda, scritte sulla stessa pagina.

Il runbook è finito quando il livello giusto si riprende senza che nessuno legga un sito non disponibile come un tunnel rotto. Questo mette alla prova il documento, non il tunnel.