Riduci gli avvisi non significativi tramite un processo di ottimizzazione continua

  • 6 minuti

In questa unità, vengono illustrati i processi che è possibile implementare per monitorare l'affidabilità di un sito. Vengono inoltre fornite informazioni sull'ottimizzazione continua degli avvisi per ridurre gli avvisi significativi.

Monitoraggio e avvisi

Il monitoraggio e l'invio di avvisi consentono a un sistema di informare gli utenti che si è verificato o che si sta per verificare un errore. Se qualcuno deve analizzare il problema, l'avviso deve fornire informazioni pertinenti in modo da sapere da dove cominciare.

Quando si esaminano gli avvisi esistenti o si scrivono nuove regole per gli avvisi, tenere conto di queste linee guida per garantire solo avvisi rilevanti e una rotazione più efficiente del personale:

  • Gli avvisi che attivano l'intervento umano devono essere urgenti, importanti, orientati all'azione e reali.
  • Per l'assistenza, gli avvisi devono rappresentare problemi imminenti o in corso.
  • Rimuovere avvisi fastidiosi. Il monitoraggio eccessivo è un problema più difficile da risolvere rispetto al monitoraggio insufficiente.
  • Classificare il problema in una delle categorie seguenti:
    • Disponibilità e funzionalità di base.
    • Latenza.
    • Correttezza.
    • Problemi di funzionalità specifiche.
  • I sintomi sono un modo migliore per catturare i problemi in maniera esauriente e con uno sforzo minore.
  • È possibile includere informazioni basate sulla causa nelle pagine dedicate ai sintomi o nei dashboard, ma evitare di generare avvisi direttamente sulle cause.
  • Maggiore è il numero di stack di servizio, più facilmente si riuscirà a rilevare problemi distinti con un'unica regola. Ma non bisogna eccedere fino a non riuscire più a distinguere cosa sta effettivamente accadendo.
  • Se si desidera una rotazione su chiamata non interattiva, mettere a punto un sistema di gestione dei problemi che richieda una risposta tempestiva ma non immediata.

Monitorare gli utenti

Il monitoraggio per gli utenti è detto anche monitoraggio basato sui sintomi. Ciò è in contrasto con il monitoraggio basato su cause. Agli utenti non interessa se il push dei dati non riesce, ma se i risultati sono aggiornati.

In generale, agli utenti interessa:

  • Disponibilità e correttezza di base: tutto ciò che interrompe il servizio principale in qualche modo deve essere classificato come indisponibilità.
  • Latenza: le pagine devono essere caricate rapidamente.
  • Completezza, aggiornamento e durabilità: i dati degli utenti devono essere sicuri, dovrebbero tornare tempestivamente e gli indici di ricerca devono essere aggiornati.
  • Tempo di attività: anche se il servizio è temporaneamente non disponibile, gli utenti devono avere completa fiducia che il servizio tornerà operativo presto.
  • Funzionalità: Ai vostri utenti interessa che tutte le funzionalità del servizio funzionino. Monitorare qualsiasi elemento che costituisca un aspetto importante del servizio, anche se non è una funzionalità di base.

Esiste una differenza sottile ma importante tra la mancata disponibilità dei server di database e la mancata disponibilità dei dati degli utenti. Mentre il primo è una causa immediata, il secondo è un sintomo.

Importanza degli avvisi basati sulla causa

Talvolta non è presente alcun sintomo che determini la generazione di un avviso, ma è comunque necessario essere informati di una situazione specifica. Un esempio può essere la memoria insufficiente. Occorrono regole che segnalino un problema imminente prima che possa causare un sintomo. In questo caso, è possibile scrivere una regola che consenta di ricevere un avviso se si verifica questa condizione.

È opportuno, tuttavia, non scrivere regole basate su cause che generino avvisi di chiamata per sintomi che è possibile rilevare in altri modi.

Ticket, report ed e-mail

Gli avvisi che richiedono attenzione presto, ma non subito, sono avvisi subcritici. Di seguito sono riportati alcuni suggerimenti per la registrazione di avvisi subcritici da esaminare in un secondo momento:

  • I sistemi di rilevamento di bug o ticket possono essere utili per questo tipo di avviso: un avviso può aprire un bug, purché lo stesso avviso venga inserito correttamente in un singolo ticket o bug. Questi bug possono quindi essere sottoposti a un processo di valutazione di cui incaricare qualcuno. È importante che questi tipi di problemi vengano gestiti prima che diventino critici. Considerare la quantità di tempo che i membri del team di lavoro possono dedicare alla correzione del bug.
  • Un report giornaliero (o più frequente) può essere utile: Scrivere avvisi sottocritici di lunga durata, ad esempio se la capacità occupata del database è superiore al 90%, in un report che mostra tutti gli avvisi attivi. Assegnare a qualcuno una valutazione giornaliera di questo report.
  • Ogni avviso deve essere monitorato tramite un sistema del flusso di lavoro: ciò garantisce che vengano visualizzati e risolti.

In generale, creare un sistema che promuova la responsabilità dei tempi di risposta, ma che non abbia i costi elevati di un intervento umano immediato.

Playbook

I playbook, talvolta detti runbook, costituiscono una parte importante di un sistema di avvisi. Prevedere nel playbook una voce che spieghi cosa fare per ogni avviso o famiglia di avvisi che descrive un sintomo.

Rilevamento e responsabilità

Se un utente riceve un avviso e stabilisce che in realtà non si è verificato alcun errore, significa che è necessario rimuovere la regola, abbassarla di livello o raccogliere i dati in altro modo. Gli avvisi con una precisione inferiore al 50% devono essere considerati inefficienti. Anche quelli che attivano falsi positivi il 10% delle volte meritano una rivalutazione.

Una revisione settimanale di tutti gli avvisi di chiamata attivati e un'analisi trimestrale delle statistiche degli avvisi possono essere utili per scoprire modelli che vengono persi quando ci si concentra sui singoli avvisi.

Quando cercare l'eccezione alla regola?

Di seguito sono riportati alcuni motivi per cui potrebbero non essere seguite le linee guida precedenti:

  • Hai una causa nota che si trova effettivamente al di sotto del rumore tra i tuoi sintomi: ad esempio, se il tuo servizio ha una disponibilità di 99.99%, ma hai un evento comune che causa lo 0.001% di richieste a fallire, non puoi generare un avviso come sintomo perché si trova tra il rumore, ma puoi intercettare la causa dell'evento.

  • Non è possibile monitorare il punto di ingresso perché si perde la risoluzione dei dati: ad esempio, si tollera la lentezza di alcuni endpoint, come la convalida della carta di credito. Durante i bilanciamenti del carico, questa distinzione può essere persa. Sarà necessario scorrere lo stack e generare l'avviso dal punto più elevato in cui si riesce a percepire la distinzione.

  • I sintomi non compaiono fino a quando non è troppo tardi: ad esempio, hai esaurito la quota. È necessario avvisare qualcuno prima che sia troppo tardi, ma in alcuni casi ciò significa trovare prima la causa dell'avviso. Se, ad esempio, la quota usata è già superiore all’80%, si esaurirà in meno di 4 ore mantenendo il tasso di occupazione dell'ultima ora.

    Dovrebbe essere possibile, tuttavia, trovare una causa simile anche in una situazione meno urgente. Quando, ad esempio, la quota è superiore al 90% e si esaurirà in meno di 4 giorni al tasso di crescita dell'ultimo giorno. Questo insieme di circostanze includerà la maggior parte dei casi. Questo problema quindi può essere gestito come ticket, avviso e-mail o report giornaliero dei problemi, anziché come escalation di emergenza che rappresenta un avviso.

  • La configurazione dell'avviso è più complessa dei problemi che si sta tentando di rilevare: l'obiettivo deve essere quello di passare a sistemi semplici, affidabili e autoprotezione.