Cos'è una pagina di stato e cosa deve contenere

Cosa mettere su una pagina di stato

Una pagina di stato ha tre livelli, e la maggior parte del valore sta nei primi due.

Il livello superiore è lo stato attuale di ogni componente che elenchi. I componenti sono le parti che un cliente sa distinguere: il sito web, l'API, la dashboard, gli accessi, il flusso di pagamento, il backend di un'app mobile. Lo stato è di solito una scala breve invece che un binario, così puoi dire "degradato" per un servizio lento ma che risponde, invece di scegliere tra un segno di spunta verde che è sbagliato e una croce rossa che è peggio.

Il livello intermedio è il flusso degli incidenti. Ogni incidente è una voce breve con un orario di inizio, una descrizione semplice di cosa noteranno i clienti, e aggiornamenti aggiunti man mano che la situazione cambia, terminando con una nota di risoluzione. Gli incidenti passati restano visibili, ed è questo che trasforma la pagina in un registro invece che in un semplice interruttore.

Il livello inferiore è la cronologia: l'uptime negli ultimi 30 o 90 giorni per componente. È la parte meno urgente ed è quella letta più spesso da chi ti sta valutando.

Pubblica o privata

Una pagina di stato pubblica è aperta a chiunque abbia il link, ed è la scelta giusta quando i tuoi clienti sono il grande pubblico o quando pubblichi un SLA. Assorbe inoltre il traffico durante un'interruzione da parte di persone che non sono affatto clienti.

Una pagina di stato privata è riservata a clienti che hanno effettuato l'accesso o a un pubblico interno. I team la usano quando l'elenco dei componenti esporrebbe l'architettura interna, quando gli incidenti coinvolgono clienti enterprise nominati, oppure quando la pagina copre sistemi interni che nessun estraneo dovrebbe poter elencare. Il compromesso è che chiunque non possa raggiungerla contatterà comunque l'assistenza.

Qualunque tu scelga, ospita la pagina lontano dall'infrastruttura di cui riferisce. Una pagina di stato che va giù insieme al servizio è peggio di nessuna pagina di stato, perché il suo silenzio durante un'interruzione viene letto come un'affermazione che va tutto bene.

Scrivere un incidente

Una voce di incidente si scrive per un cliente, non per gli ingegneri che lo stanno risolvendo. Questo significa il sintomo prima, la causa dopo, se mai viene menzionata.

1. Apri l'incidente non appena hai confermato il problema, anche se non ne conosci ancora la causa. "Stiamo indagando su segnalazioni di errori nel checkout" pubblicato al secondo minuto vale più di una spiegazione completa al novantesimo.
2. Dì cosa vedrà un cliente e cosa può fare al riguardo, includendo una soluzione temporanea se ce n'è una.
3. Aggiorna con un ritmo che dichiari in anticipo, e pubblica l'aggiornamento anche quando è "nessun cambiamento per ora". Il silenzio viene letto come abbandono.
4. Chiudi con un orario di risoluzione e, per qualsiasi cosa lunga o grave, una breve nota su cosa è successo dopo.

Fai corrispondere lo stato del componente all'incidente. Un incidente aperto su un componente che mostra ancora verde è il modo più veloce per perdere la fiducia nella pagina. Se il guasto sottostante è un server che rifiuta le richieste, 503 Service Unavailable è la risposta che i tuoi clienti probabilmente ti stanno citando.

Manutenzione pianificata

I lavori pianificati vanno sulla stessa pagina, annunciati in anticipo con una finestra temporale e un impatto previsto. Pubblicarla in anticipo trasforma un'interruzione in un appuntamento: i clienti che hanno visto l'avviso non aprono ticket, e quelli che non l'hanno visto possono almeno trovare la spiegazione mentre sta accadendo.

Distingui la manutenzione da un incidente visivamente e nel registro, e mantieni onesta la finestra annunciata. Una finestra di manutenzione che sfora regolarmente abitua le persone a ignorare la prossima.

Perché riduce il carico sull'assistenza

Durante un'interruzione la coda dell'assistenza si riempie con una domanda posta molte volte. Una pagina di stato risponde una volta sola, a un indirizzo a cui puoi rimandare dal tuo risponditore automatico dell'assistenza, dallo stato di errore della tua app e dai tuoi account social. Questo trasforma un'ora di smistamento ripetitivo in un link.

L'effetto secondario riguarda la fiducia. Pubblicare gli incidenti costa meno di quanto sembri, perché i clienti che hanno notato l'interruzione sanno già che è successa. Quello su cui ti giudicano è se glielo hai detto.

Da dove viene lo stato

Una pagina di stato vale quanto il monitoraggio che c'è dietro. Se un essere umano deve notare un'interruzione prima che la pagina cambi, la pagina sarà sempre in ritardo rispetto ai clienti che la leggono, quindi gli stati dei componenti dovrebbero essere guidati da controlli che girano continuamente dall'esterno della tua rete. HostTracker ospita pagine di stato alimentate dal proprio monitoraggio, che controlla da oltre 300 postazioni in 158 città su 13 tipi di monitor, così che lo stato di un componente segua i risultati dei controlli invece che qualcuno che si ricorda di aggiornarlo. Per come sono fatti quei controlli, vedi la guida al controllo HTTP, e il resto della sezione dei concetti di monitoraggio per i termini correlati.