Quando la sentinella muore: perché il silenzio non è una buona notizia

Hai configurato gli avvisi. Sono passate settimane e non è arrivata una sola mail.

Le spiegazioni sono due. O davvero non è successo nulla, o il sistema di avvisi ha smesso di funzionare e tu non lo sai. Da fuori le due sembrano identiche.

E la mente umana tende a leggere il silenzio come una buona notizia. Proprio per questo questo tipo di guasto vive per mesi senza essere notato.

Questo è un problema diverso da un controllo che tace

Altrove in questa wiki abbiamo scritto: quando un controllo non riesce a leggere i suoi dati non deve tacere, deve dire che non è riuscito a leggere.

Quello che descriviamo qui sta un gradino più su. Là taceva un controllo dentro una sentinella funzionante. Qui la sentinella stessa non c'è più. Non resta nessuno a parlare, quindi nemmeno nessuno a dire "non sono riuscito a leggere".

Come una sentinella muore in silenzio

Il servizio si ferma. Un aggiornamento, un crollo, memoria insufficiente. Ciò che dovrebbe avvisarti è proprio ciò che si è fermato.

Il percorso della posta si rompe. Cambia una password, un fornitore blocca, l'indirizzo rimbalza. La sentinella continua a lavorare, scrive i suoi messaggi, e nessuno ti arriva. È il caso più ingannevole, perché dal lato server tutto sembra sano.

Qualcuno spegne e dimentica. Le notifiche vengono spente temporaneamente mentre si indaga su qualcosa. Il problema si risolve. Le notifiche restano spente.

La macchina si spegne. Il caso estremo: non c'è nulla di rotto, semplicemente è tutto silenzioso.

I quattro hanno una cosa in comune: nessuno produce un messaggio. E se il tuo modo di accorgerti di un guasto è ricevere un messaggio, allora i guasti che non producono messaggi ti sono invisibili.

La soluzione ha un'altra forma: non un allarme, un battito

Bisogna invertire la direzione.

Un allarme dice: parla quando qualcosa non va. Un battito dice: di "sono vivo" a intervalli regolari anche quando non succede nulla. Poi qualcuno deve accorgersi quando quel dire si interrompe.

La differenza conta. Un allarme è un messaggio su un problema; un battito è un messaggio sul messaggero stesso. Rispondono a domande diverse e nessuno sostituisce l'altro.

Una volta che c'è un battito, il significato del silenzio cambia. Il silenzio ora porta informazione: qualcosa che dovrebbe parlare non parla.

Chi se ne accorge deve stare fuori dalla macchina sorvegliata

È la parte su cui vale la pena fermarsi. Una macchina non può annunciare la propria morte.

Il posto che valuta il battito deve stare fuori dal server sorvegliato: un'altra macchina, un telefono, un punto esterno. Un controllo che gira dentro il server si spegne insieme al server e non dice niente a nessuno.

Basta anche la versione casalinga più semplice: che il server lasci un segno da qualche parte ogni ora, e tu guardi l'età di quel segno. Non serve un impianto complicato; l'unica cosa che serve è che la valutazione avvenga altrove.

Il battito ha una trappola tutta sua

Qui c'è un errore di progetto sottile, e la maggior parte degli impianti ci cade: legare il battito al calendario di qualcosa che l'utente può spegnere.

Poniamo che condivida la temporizzazione con il riepilogo giornaliero. L'utente spegne il riepilogo, perché gli sembrava troppo. Il battito si interrompe con lui. La parte esterna vede il segnale fermarsi e lancia un allarme "nessuna notizia dal tuo server" mentre non sta succedendo assolutamente nulla.

Il risultato lo immagini: l'utente si spaventa una volta per niente e la seconda volta spegne l'allarme. Un falso allarme prodotto dal tuo stesso meccanismo di sicurezza distrugge la fiducia in quel meccanismo più in fretta che non averlo affatto.

La regola: il battito deve avere il proprio calendario, e non appoggiarsi a nulla di spegnibile.

La stessa forma, altrove

Nell'articolo sui lavori di backup di questa wiki abbiamo scritto: non guardare lo stato del lavoro, guarda l'età del backup più recente.

La stessa forma ricompare qui: non chiedere al sistema di avvisi se funziona, guarda l'età dell'ultimo segnale. Uno stato è un'affermazione, un'età è una misura.

E infine, l'unica cosa da fare il giorno dell'installazione: provoca di proposito un guasto e guarda arrivare la mail. Un allarme non provato non è un meccanismo, è una speranza.

Cosa fa Atlas

Atlas Watch invia un riepilogo giornaliero, segnala subito le situazioni critiche senza aspettare il riepilogo, e accanto a questi emette un segnale orario "sono vivo".

Quello che vale la pena raccontare è a cosa quel segnale non è legato.

Il segnale non si appoggia né al calendario del riepilogo giornaliero né a quello dell'allarme. Entrambi hanno impostazioni proprie e l'utente può spegnerli. Se il segnale dipendesse da loro, nel momento in cui l'utente spegne il riepilogo si interromperebbe anche il segnale, e dall'altra parte si direbbe "nessuna notizia da questo server" mentre non succede nulla. Per questo il segnale ha il proprio calendario.

Il secondo dettaglio segue lo stesso ragionamento: finché l'impostazione di notifica è spenta, il file di temporizzazione del segnale non viene scritto affatto. Quindi non resta uno stato intermedio "acceso ma non funzionante"; o il segnale c'è o non c'è.

Il percorso di notifica è tuo: definisci il tuo server di posta, e la mail parte dal tuo server. Mandare un segnale a un punto esterno è un'aggiunta facoltativa, e il prodotto non ne dipende per funzionare.

La lezione generale: un meccanismo di sicurezza non deve appoggiarsi alle parti spegnibili di ciò che protegge. Se lo fa, muore in silenzio insieme a esso.