Avvisi interattivi
Finora in questo modulo abbiamo esplorato i modi per considerare e misurare l'affidabilità dei nostri sistemi e per interagire con essa. Esiste tuttavia anche un modo in cui tale affidabilità interagisce con noi: gli avvisi. È facile configurare Monitoraggio di Azure e altri strumenti per inviare avvisi in base a diverse metriche e segnali, tra cui gli indicatori SLI e gli obiettivi SLO descritti in precedenza. Azure può anche inviare avvisi in base ai problemi dei servizi tramite la funzionalità Integrità dei servizi di Azure.
Con la capacità di inviare facilmente avvisi si presenta un potenziale rischio. È a questo punto che la parola sostenibilità rientra nel quadro della definizione di SRE che abbiamo visto prima:
Site Reliability Engineering è una disciplina di progettazione dedicata ad aiutare le organizzazioni a raggiungere in modo sostenibile il livello di affidabilità appropriato nei propri sistemi, servizi e prodotti.
Gli avvisi sono progettati per notificare quando si verifica un problema relativo ai sistemi. Tuttavia, una configurazione degli avvisi non corretta può compromettere l'obiettivo della creazione di una procedura operativa sostenibile. Tutto il lavoro effettuato per introdurre gli indicatori SLI e gli obiettivi SLO nell'organizzazione può essere compromesso se si traduce in un numero eccessivo di avvisi per il personale. Il sovraccarico degli avvisi è un problema ben noto nella community delle operazioni. L'obiettivo di questa unità è evitare che si diffonda nella propria organizzazione.
Un elemento chiave che contribuisce al sovraccarico degli avvisi è dato dagli avvisi con cui non è possibile interagire. Si apprenderà come evitare di crearli.
Che cosa sono (e non sono) gli avvisi
Per comprendere il motivo per cui gli avvisi non corretti possono creare un problema, è necessario considerare lo scopo degli avvisi e il modo in cui si differenziano dagli altri segnali operativi.
Gli avvisi interattivi non sono:
Log: gli avvisi non sono record di eventi. Questo è un compito dei log. Se si intende semplicemente registrare un evento, occorre scriverlo in un file di log e non in un cercapersone.
Notifiche: gli avvisi non sono pensati per annunciare eventi non critici, come il completamento di una build software. Non è necessario interrompere qualcuno, interrompendone la concentrazione, solo per comunicare una notizia.
Heartbeat: gli avvisi non devono essere usati come promemoria del fatto che il sistema è ancora in esecuzione. Abbiamo visto situazioni in cui le persone sostengono: "Se non ricevo sul cercapersone almeno un messaggio ogni ora dal sistema, mi rendo conto che c'è un problema e che devo occuparmene". Si tratta di un'idea terribile.
Gli avvisi interattivi vengono usati per le situazioni in cui è necessario che un utente effettui un'indagine su un problema e intervenga per correggerlo. Gli avvisi devono essere comunicazioni del fatto che si è verificato un evento eccezionale o imprevisto che richiede l'attenzione di un utente.
Se l'evento è qualcosa che il sistema è in grado di gestire tramite processi automatizzati, ad esempio il ridimensionamento delle risorse entro un limite preimpostato, non è necessario un avviso. Il sistema deve semplicemente gestirlo e scrivere una riga in un log. Non dovrebbe inviare un messaggio sul cercapersone alle due di notte per indicare che si è verificata una situazione che è stata gestita correttamente.
Creare avvisi interattivi
Perché un avviso risulti interattivo, deve essere caratterizzato da:
Semplicità: un avviso non deve richiedere al destinatario di risolvere un enigma per sapere cosa fare. Se l'avviso è troppo complesso, la persona che è stata svegliata in piena notte perderà tempo prezioso solo per cercare di comprenderne il significato.
Ambito: una delle prime cose che il destinatario del messaggio dovrà fare per poter eseguire una valutazione efficace è determinare l'ambito del problema. Il problema si verifica con un solo server? Un servizio? Un'intera area? Tutto il mondo? Per agevolare il destinatario, inserire queste informazioni nell'avviso.
Contesto: cosa deve sapere il destinatario dell'avviso per iniziare a occuparsi del problema? Esaminiamo più a fondo questa parte.
Specificare il contesto nell'avviso
Di seguito sono riportati alcuni elementi che un avviso interattivo deve sempre includere, affinché i destinatari dispongano del contesto necessario:
Da dove proviene l'avviso? Molte organizzazioni usano contemporaneamente più sistemi di monitoraggio e dispongono di numerosi sistemi interconnessi. Un avviso in cui è indicato "Questo avviso relativo al sistema di retribuzioni THX-1138 è stato inviato dalla sottoscrizione di Monitoraggio di Azure: prod" può consentire di risparmiare una notevole quantità di tempo.
Quale aspettativa è stata violata? Un avviso che descrive semplicemente la situazione corrente non è utile quanto potrebbe essere. Confrontare il messaggio "Il server di database è in esecuzione all'80% del carico" con "Il server di database è stato in esecuzione all'80% del carico nelle ultime due ore, mentre doveva essere a un livello inferiore al 60% del carico".
Perché si tratta di un problema (per il cliente)? Le informazioni sull'effetto o sull'impatto che la situazione ha avuto o potrebbe avere per il cliente consentono di determinare l'importanza e di misurare adeguatamente la reazione.
Quali sono i passaggi successivi da eseguire? Se possibile, l'avviso deve includere le operazioni che il destinatario deve eseguire, attraverso un puntatore a una guida alla risoluzione dei problemi o ad altra documentazione con informazioni utili per la diagnosi e la risoluzione del problema.
L'inclusione di un contesto utile e l'uso di avvisi interattivi possono rendere più sostenibili le procedure operative e più semplice la risposta agli avvisi.