Pharos

Le pagine di stato hanno una brutta caratteristica: quasi tutte mentono a proprio favore. Quando una sonda smette di interrogare un servizio, perché il monitoraggio stesso è andato giù o è finito il periodo di conservazione, la maggior parte degli strumenti semplicemente non conta quel buco nelle statistiche. Il risultato è un grafico che mostra il 100 per cento di disponibilità su una finestra in cui nessuno ha misurato nulla. A questo si aggiungono le finestre di manutenzione che magicamente non intaccano mai la barra, e all'improvviso hai un pannello che sembra ottimo e non significa nulla.

Pharos lo abbiamo costruito al contrario. È uno strumento che metti in piedi con un solo comando, tieni sul tuo server e a cui si può davvero credere, perché quando non sa, lo dice. Non è l'ennesima dashboard cloud con abbonamento e conservazione altrui, ma un solo file che copi accanto al resto dei tuoi servizi e avvii. Tutto il resto di questo case study racconta come una sola decisione nella formula di calcolo della disponibilità cambi il carattere dell'intero prodotto.

Il monitoraggio classico conosce due stati: il servizio funziona o non funziona. È comodo finché non chiedi cosa succede quando il monitoraggio non guarda affatto. Perché allora lo strumento deve fare qualcosa con quel tempo, e la scelta predefinita cade quasi sempre nella stessa trappola: tratta il silenzio come un successo e lo somma di nascosto alla barra "up". È così che nascono quegli assurdi 100 per cento per un mese in cui in realtà metà dei dati non esiste.

Da noi ogni tratto di vita di un servizio ha tre stati, non due. Disponibile, guasto e senza osservazione. Il terzo è tutto il punto: è il tempo in cui non abbiamo raccolto dati, quindi non abbiamo il diritto di sostenere che andasse tutto bene. Invece di sommarlo verso l'alto, lo mostriamo direttamente come una parte distinta della finestra. Le finestre di manutenzione vengono contrassegnate, ma non cancellano i guasti dalla cronologia, separano soltanto ciò che era pianificato da ciò che era inatteso.

La suddivisione in tre stati sembra un dettaglio finché non la vedi su una finestra concreta. Prendi una giornata in cui un servizio è stato disponibile per la maggior parte del tempo, è caduto per un momento, e per un tratto nessuno lo ha sondato perché la macchina di monitoraggio si è riavviata da sola. Un contatore ingenuo somma il tempo disponibile con quello non osservato e sputa fuori una percentuale alta e vistosa. Un contatore onesto mostra meno e aggiunge che per un po' non sapeva nulla.

La stessa giornata, fatta passare per due formule diverse, dà due numeri completamente diversi. E non è cosmesi: è la differenza tra un report di cui un cliente può fidarsi e un report che sembra solo buono in riunione. Abbiamo scelto quello meno vistoso, perché è l'unico che significa qualcosa.

Il più grande problema pratico degli strumenti di stato è quanto bisogna mettere in piedi attorno a loro prima che mostrino qualcosa. Un database a parte, una coda, un worker, un pannello, un reverse proxy. Pharos va nella direzione opposta: tutto il monitoraggio, la cronologia, la pagina di stato e la gestione degli incidenti stanno in un unico eseguibile Go statico, e i dati li tiene un SQLite incorporato. Non c'è un database separato da mettere in piedi e sorvegliare, nessun runtime da installare. Copi il binario, lo avvii, e lavori.

Questa semplicità non è un risparmio sulle funzioni, ma un taglio deliberato della superficie di manutenzione. Meno parti mobili ci sono, meno cose possono rompersi alle tre di notte. Un deploy, una porta, un log da leggere quando qualcosa va storto.

Sotto un numero onesto deve esserci una fonte di dati onesta. Pharos interroga i tuoi servizi a intervallo fisso via HTTP e TCP, e registra ogni singolo risultato insieme al suo tempo di risposta e a un timestamp. Non facciamo medie al volo e non sovrascriviamo la cronologia, perché è proprio da questo flusso grezzo di campioni che vengono poi costruiti i tre stati. Se non c'è un campione per un dato intervallo, quell'intervallo è senza osservazione per definizione, non per impostazione predefinita.

Nota due cose in questo frammento. Il tempo senza osservazione viene escluso al denominatore, non sommato verso l'alto. E quando non c'è stata alcuna osservazione, la funzione restituisce NaN invece di un falso 100 per cento, perché l'assenza di dati è assenza di dati, non un successo.

Il classico scenario di guasto è così: qualcosa cade, qualcuno se ne accorge, e comincia il saltare tra il pannello di monitoraggio, la chat e la pagina di stato. Tre finestre, tre versioni della verità, e buone probabilità che lo stato pubblico si allontani da ciò che il team sa davvero. Pharos riduce tutto a un solo posto. Un incidente lo apri e lo gestisci da Discord, e la pagina di stato pubblica è solo un riflesso di ciò che il team scrive comunque.

Non c'è un secondo strumento da imparare e nessun rischio che lo stato vada per la sua strada, perché è la stessa realtà vista da due lati. Apertura, aggiornamenti e chiusura li sbrighi dove già siete, e la pagina si aggiorna da sola.

Ne è uscito uno strumento che puoi mettere su una piccola macchina accanto al resto dei tuoi servizi e a cui poi puoi smettere di pensare. Un file, un database incorporato, una porta. Il numero sulla pagina di stato significa esattamente ciò che dice, e quando il monitoraggio non sa qualcosa, non fa finta di saperlo. Per il cliente che guarda quella pagina, è la differenza tra la fiducia e un cartellone pubblicitario.

Il codice è aperto, quindi puoi leggere tutta questa formula da solo invece di crederci sulla parola. È probabilmente la cosa più onesta che uno strumento per contare onestamente la disponibilità possa dire di sé.