Monitoring i status

Quasi ogni pagina di stato in cui ti imbatti mostra bei numeri. 100 per cento di uptime, tutto verde, nemmeno un graffio. Il problema è che quei numeri il più delle volte non significano "tutto ha funzionato", ma "nessuno stava guardando". L'assenza di dati viene contata come un successo, e il cliente riceve un bel quadretto senza riscontro nella realtà.

Abbiamo costruito un monitoraggio che fa qualcosa di più difficile di un bel grafico: dice la verità, anche quando la verità è scomoda. Quando non sappiamo come si è comportato un servizio, il risultato deve essere "non lo so", e non "va tutto bene". A questo si aggiungono una pagina di stato pubblica con una cronologia onesta e la gestione degli incidenti condotta dove il team già siede. Questo caso di studio parla di come calcolare la disponibilità senza ingannare se stessi.

Il meccanismo della tipica bugia di una pagina di stato è banale. Se in un dato periodo la sonda non ha raccolto alcun campione e tu conti comunque quel periodo come sano, il tuo uptime avrà sempre un aspetto eccellente. Meno spesso guardi, meglio ne esci, il che è assurdo: uno strumento per sorvegliare la disponibilità ti premia per il fatto di non sorvegliare.

L'effetto è comodo e falso. Un grafico verde rassicura il team e il cliente, anche se sotto poteva esserci un'ora di cui nessuno sa nulla. Noi volevamo esattamente l'atteggiamento opposto: "non lo so" deve significare "non lo so", e non essere silenziosamente arrotondato a "tutto funziona".

Tutta l'onestà di questo monitoraggio nasce da un'unica decisione: un campione ha tre stati possibili e non due. Non solo "up" e "down", ma anche "unknown" per il tempo in cui semplicemente non c'è stata osservazione. Questa distinzione è il cuore di tutto il resto.

Nella disponibilità entrano esclusivamente i campioni effettivamente raccolti, cioè quelli "up" e "down". Gli stati "unknown" vengono messi da parte, perché non si devono fingere né in un senso né nell'altro. Se in un periodo non c'è stata alcuna osservazione, il risultato non è 100 per cento e non è zero. Il risultato è vuoto, ed è esattamente così che lo mostra la pagina di stato.

Una trappola a parte sono le interruzioni pianificate. È allettante contare una finestra di manutenzione come tempo sano, perché in fondo "era una pausa pianificata, non un guasto". Solo che allora il grafico mente di nuovo, solo in modo più sottile: finge che il servizio fosse in funzione quando era deliberatamente assente.

Siamo andati per una via di mezzo che è onesta in entrambe le direzioni. Le finestre di manutenzione sono contrassegnate a parte e non contano come tempo di inattività, perché non è un guasto. Ma non fingono nemmeno che in quel periodo tutto fosse in funzione. Nel grafico si vede un'interruzione contrassegnata come manutenzione, e non uno sfondo verde artificiale. È lo stesso principio che governa l'intero progetto: non arrotondiamo a nostro favore.

Un monitoraggio che si limita a contare è metà del lavoro. L'altra metà inizia nel momento in cui qualcosa cade davvero. Qui si commette l'errore classico: la gestione dell'incidente viene spinta in uno strumento separato in cui nessuno vuole autenticarsi nel mezzo dell'incendio. Noi siamo andati dove il team già si trova, cioè su Discord.

Il flusso è breve e non richiede alcun cambio di contesto. Un cambiamento di stato di un servizio fa scattare una notifica. Un incidente si apre e si aggiorna direttamente dal canale, senza autenticarsi in un altro pannello. La pagina di stato pubblica mostra ai clienti lo svolgimento e la chiusura, in modo chiaro e senza abbellire, onestamente quanto i numeri di uptime.

Il numero sulla pagina significa esattamente ciò che dice. Quando indica 99.5 per cento, è il 99.5 per cento di osservazioni reali, e non un artefatto del fatto che la sonda ha dormito per mezza giornata. Il cliente guarda la pagina di stato e vede una cronologia onesta: disponibilità, tempi di inattività e finestre di manutenzione tenuti separati, e non un verde eterno che non significa nulla.

Quando qualcosa cade, il team conduce l'incidente dal posto in cui già si trova, senza autenticarsi in un altro strumento nel momento peggiore possibile. Il tutto si attiene a un principio che sembra modesto ed è raro: un monitoraggio a cui si può credere, perché ammette ciò che non sa invece di dipingere di verde le lacune.