Alerting e risposta agli incidenti

In DevOps, il monitoraggio ci aiuta a vedere che cosa sta accadendo. Ma vedere non basta: dobbiamo sapere quando qualcosa va storto!

Gli avvisi sono notifiche attivate quando vengono soddisfatte condizioni specifiche, che indicano un potenziale problema. Pensateli come le sirene d'allarme del vostro sistema.

Un sistema di avvisi efficace trasforma il monitoraggio passivo in una risoluzione proattiva dei problemi. È essenziale per:

• Rilevamento precoce: individuare i problemi prima che gli utenti ne risentano.
• Risoluzione più rapida: avvisare immediatamente il team corretto.
• Prevenzione delle interruzioni: affrontare i problemi minori prima che si aggravino.

Quando si attiva un avviso, spesso segnala un incidente. Un incidente è un'interruzione non pianificata di un servizio o una riduzione della qualità di un servizio.

Ne sono esempi il crash di un server, un database che non risponde o un improvviso aumento del tasso di errore di un'applicazione.

Gli avvisi vengono configurati in base a diverse metriche o ai log. Ecco alcuni trigger comuni:

• Soglie: utilizzo della CPU > 90% per 5 minuti.
• Tassi di errore: errori HTTP 500 > 1% delle richieste.
• Disponibilità: il servizio non restituisce alcuna risposta.
• Pattern nei log: comparsa di messaggi di errore specifici nei log.

Non tutti gli avvisi hanno la stessa urgenza. Li classifichiamo in base alla gravità per stabilire le priorità degli interventi:

• Critico: il servizio è inattivo o gravemente degradato. È necessario intervenire immediatamente.
• Avviso: si sta sviluppando un potenziale problema, che richiede presto attenzione.
• Informazione: evento non urgente, destinato esclusivamente a informare.

Una volta attivato un avviso, deve raggiungere le persone corrette. I canali di notifica comuni includono:

• Email: per avvisi meno urgenti o informativi.
• Chat (ad esempio Slack): utile per mantenere il team informato e diagnosticare i problemi in collaborazione.
• SMS/chiamata telefonica: per avvisi critici che richiedono attenzione immediata, spesso tramite strumenti di reperibilità come PagerDuty.

La risposta agli incidenti è il processo strutturato per gestire e risolvere gli incidenti. Un flusso tipico include:

1. Rilevamento: si attiva un avviso.
2. Valutazione iniziale: si valutano la gravità e l'impatto.
3. Diagnosi: si identifica la causa principale.
4. Risoluzione: si risolve il problema.
5. Ripristino: si ripristina la piena funzionalità del servizio.
6. Post-mortem: si trae insegnamento dall'incidente.

Un runbook è una guida dettagliata che descrive i passaggi per risolvere gli incidenti comuni. È fondamentale per:

• Coerenza: garantire che gli incidenti vengano gestiti in modo uniforme.
• Rapidità: accelerare i tempi di diagnosi e risoluzione.
• Trasferimento delle conoscenze: consentire ai nuovi membri del team di rispondere efficacemente.

Dopo aver risolto un incidente, è fondamentale svolgere una revisione post-incidente (o post-mortem). Si tratta di un'analisi senza colpe, incentrata sui seguenti aspetti:

• Che cosa è successo?
• Perché è successo?
• Che cosa avrebbe potuto evitarlo?
• Quali azioni possiamo intraprendere per prevenirne il ripetersi?

L'obiettivo è il miglioramento continuo, non l'attribuzione di colpe.

Quale delle seguenti descrive meglio lo scopo principale di un runbook nella risposta agli incidenti?

Abbiamo visto come gli avvisi fungano da allarme del sistema e si attivino in presenza di condizioni specifiche. Abbiamo inoltre imparato a conoscere i diversi livelli di gravità e i canali di notifica.

Comprendere il flusso di risposta agli incidenti e utilizzare i runbook sono aspetti fondamentali per gestire efficacemente i problemi. Infine, le revisioni post-incidente favoriscono l'apprendimento continuo e il miglioramento del sistema.