Il tuo team di ingegneri sta vivendo un affaticamento da allerta? Poni queste 8 domande

L'esaurimento degli avvisi è un problema comune tra i team di progettazione che gestiscono le operazioni e mantengono l'infrastruttura.

Il problema di solito deriva da un approccio casuale alla scrittura di avvisi man mano che i team crescono e iniziano a utilizzare più infrastrutture di complessità crescente. Questo è abbastanza normale: man mano che un'azienda o un team crescono, spesso ci vuole tempo prima che una cultura dell'osservabilità e solide pratiche di allerta prendano forma.

È facile creare avvisi troppo sensibili, troppo rumorosi e troppo cauti. All'inizio, tutto sembra allerta semplicemente perché è meglio stare attenti e massimizzare il segnale di produzione nelle prime fasi di un prodotto.

"Con l'aumento del numero e della complessità delle funzionalità e dell'infrastruttura, il miglioramento degli avvisi è solitamente in fondo all'elenco delle priorità"

Naturalmente, questo approccio non è scalabile molto bene, ma con l'aumento del numero e della complessità delle funzionalità e dell'infrastruttura, il miglioramento degli avvisi è solitamente in fondo all'elenco delle priorità. Il risultato sono molti avvisi semi-significativi, rumore, cambio di contesto e multitasking per l'ingegnere di turno. In casi estremi, i compagni di squadra si esauriscono, gli avvisi vengono ignorati e il tuo team di guardia passa dal miglioramento della qualità del servizio alla lotta agli incendi costantemente senza alcun impatto significativo.

Come tutte le aziende, Intercom non è immune da queste inefficienze. Quindi abbiamo ideato un processo relativamente leggero per combattere la stanchezza da allerta.

Come pensiamo alla strategia di allerta

Il concetto di "disciplina degli avvisi" è al centro del controllo degli avvisi. Come il lavoro sulle funzionalità, gli avvisi e la strategia di avviso dovrebbero essere affrontati in modo deliberato e strutturato. A differenza del lavoro sulle funzionalità, tuttavia, non è qualcosa che può essere ben pianificato in anticipo.

Dopotutto, è altamente improbabile che tu sia in grado di prevedere lo stato operativo e la rumorosità della tua nuova funzionalità prima di spedirla. È necessario monitorare gli avvisi in modo regolare e pianificato in modo che il lavoro di allerta non raggiunga livelli insostenibili.

8 domande da porre durante la valutazione degli avvisi del tuo team

Abbiamo introdotto sessioni di revisione degli avvisi regolari per i team che si occupano di avvisi frequenti. Inizialmente si verificavano una o più volte per ciclo di progettazione di sei settimane, ma sono diventate più distanziate man mano che lo stato degli avvisi e dei monitor è migliorato a un livello più gestibile.

Ogni sessione di revisione degli avvisi inizia con un elenco ordinato di avvisi che sono stati attivati ​​nel periodo precedente, ordinati in base alla frequenza di attivazione. Utilizziamo la piattaforma PagerDuty come fonte di avviso e le sue funzionalità di analisi ci forniscono le informazioni di cui abbiamo bisogno per suddividere la frequenza e la risposta degli avvisi. Gli avvisi che contribuiscono maggiormente al rumore generale (ossia gli incendi più frequenti) vengono esaminati per primi.

Ogni avviso viene quindi passato attraverso una lista di controllo di domande:

1. L'avviso è ancora rilevante?

Eventuali avvisi attivati ​​da sistemi obsoleti o non mantenuti non dovrebbero infastidire il tecnico di guardia e dovrebbero essere immediatamente rimossi.

2. L'avviso è perseguibile?

Se un tecnico di guardia riceve l'avviso, può fare qualcosa in questo momento per correggere o migliorare la causa sottostante? Se l'avviso non è perseguibile e utile, dovrebbe essere rimosso. Un riepilogo settimanale dei problemi o del calo delle prestazioni potrebbe essere una posizione migliore per le informazioni all'interno dell'avviso.

3. Le informazioni nell'avviso sono immediatamente utili anche se non perseguibili?

Possiamo dividere le informazioni di avviso in due grandi categorie.

• Segnali: questi avvisi avvertono di un sistema che funziona al limite, ma non significano necessariamente che il servizio è interessato. Un esempio potrebbe essere uno dei tuoi server in esecuzione al 100% della CPU. Se il servizio continua a funzionare correttamente, il servizio di guardia dovrebbe dedicare tempo prezioso alle indagini? Dopotutto, il tuo server sta funzionando al miglior rapporto costo-lavoro!
• Sintomi: questi avvisi vengono attivati ​​quando l'esperienza del cliente è influenzata. Un esempio qui potrebbe essere il numero di 5XX errori HTTP che il tuo servizio sta restituendo ai chiamanti.

Queste due categorie funzionano meglio in tandem. Una persona di guardia dovrebbe reagire e risolvere i sintomi e guardare i segnali solo come un'ulteriore fonte di informazioni.

4. Se l'avviso è perseguibile e di paging, è necessario gestirlo immediatamente?

Se il problema non deve essere gestito immediatamente, non dovrebbe svegliare nessuno nel cuore della notte. Il team dovrebbe decidere modi alternativi per far emergere le informazioni nell'avviso in queste situazioni, ad esempio una notifica Slack o dashboard o un'attività aperta in un meccanismo di rilevamento dei problemi.

5. Se è utilizzabile, esiste un runbook o un collegamento per la risoluzione dei problemi? I passaggi sono abbastanza chiari per essere seguiti da qualsiasi ingegnere del team?

Una delle peggiori esperienze di essere un ingegnere di guardia, specialmente se nuovo, è la quantità di conoscenza tribale che si accumula nei team di ingegneri nel tempo. È intimidatorio saltare su un incidente di produzione di alta gravità solo per rendersi conto che non hai familiarità con quell'area del sistema e non è ben documentato.

" Mantenere le informazioni di risoluzione dei problemi degli avvisi chiare, semplici e aggiornate contribuisce notevolmente a ridurre il tempo medio per mitigare e recuperare da un incidente "

Anche se hai l'esperienza, potresti aver scritto il codice così tanto tempo fa che non ricordi chiaramente cosa dovrebbe fare. Mantenere le informazioni sulla risoluzione dei problemi degli avvisi chiare, semplici e aggiornate contribuisce notevolmente a ridurre il tempo medio per mitigare e recuperare da un incidente (MTTM e MTTR).

6. Se è perseguibile, esiste un collegamento alla dashboard e mostra tutte le potenziali cause note?

I dashboard sono un ottimo modo per far emergere grandi quantità di informazioni di sistema contemporaneamente, il che significa che gli ingegneri non devono scavare in vari registri, metriche e tracce per capire la causa di un problema. L'aggregazione dei dati in una dashboard e la fornitura del collegamento come parte dell'avviso consentono una risoluzione dei problemi molto più rapida.

7. L'avviso è troppo sensibile o non sufficientemente specifico? Trarrebbe vantaggio dalla desensibilizzazione o dalla modifica dell'ambito?

Molti avvisi sono utili ma calibrati in modo errato. Potrebbero essere troppo ampi e non sparare ogni volta che dovrebbero, o troppo specifici e sparare più volte per lo stesso incidente, il che si aggiunge al rumore.

8. Infine, un essere umano deve fare la bonifica?

In un certo senso, tutto il codice del computer automatizza qualcosa che un essere umano può fare. Allora perché non automatizzare la risoluzione dei problemi che attivano gli avvisi? Mentre alcuni avvisi più spinosi sarebbero difficili da correggere automaticamente, come un bug nel codice o un problema di prestazioni nel sistema, le azioni automatizzate possono risolvere molti problemi comuni.

Ciò è particolarmente vero se stai utilizzando una piattaforma cloud come AWS e puoi eseguire il provisioning dell'infrastruttura senza doversi preoccupare di richiedere hardware aggiuntivo. Ad esempio, se un nodo nel cluster di ricerca mostra dischi guasti, perché non sostituirlo automaticamente? Se il servizio ha poche risorse di calcolo a causa dell'aumento del traffico, perché non aumentare la scalabilità e aggiungere VM o container aggiuntivi? I dettagli della riparazione possono quindi essere inviati al team tramite canali non di avviso in modo che possano esaminarli a loro piacimento.

Hai risposto "no" a qualcuna di queste domande?

Rispondere no a una di queste domande solleva un compito ad alta priorità per il team per svolgere un po' di lavoro per migliorare l'avviso, sia che ciò significhi interromperne il paging, migliorare i passaggi di risoluzione dei problemi, automatizzarlo o semplicemente risolvere il problema di sistema sottostante.

Il punto cruciale dell'approccio è farlo in modo regolare e pianificato. Mantiene bassi i livelli di rumore e i tuoi tecnici operativi e di turno sono felici e produttivi. Possono concentrarsi sul miglioramento della qualità e sulla fornitura di impatto invece che sulla lotta antincendio.

Sei interessato al modo in cui lavoriamo in Intercom? Ci piacerebbe parlare con te: dai un'occhiata ai nostri ruoli di ingegneria aperti.