Gestione Incidenti — Cheat Sheet

Tag: incident-management, sre, itil, post-mortem, sla, slo, on-call

Livello: intermedio

TL;DR: Guida rapida alla gestione degli incidenti in produzione: identificazione, triage, mitigazione immediata, e stesura del post-mortem rigorosamente blameless.

Concetti chiave

Incidente: Interruzione non pianificata o degrado della qualita' di un servizio IT, spesso una violazione di SLA o SLO.

MTTA / MTTR: Mean Time To Acknowledge (tempo medio di presa in carico) e Mean Time To Resolve (tempo medio di risoluzione).

Triage: Valutazione iniziale della gravita' (Severity o SEV) in base all'impatto sul business e sul numero di utenti coinvolti.

Mitigazione vs Risoluzione: La priorita' e' sempre ripristinare il servizio (es. rollback), la ricerca della causa radice (RCA) avviene dopo.

Blameless Post-Mortem: Documento redatto post-incidente focalizzato sui fallimenti del sistema, non sugli errori umani, per prevenire ricadute.

Incident Commander (IC): Figura che coordina la risposta, comunica con gli stakeholder e delega i compiti operativi agli ingegneri.

On-call: Turnazione del team per garantire supporto continuo. Richiede playbook precisi e chiare policy di escalation.

Domande tipiche e risposte pronte

Q: Qual e' la prima cosa che fai quando scatta un alert critico in produzione?R: Verifico l'impatto reale per definire la Severity. Se confermata, apro una war room, comunico lo stato e cerco un'azione di mitigazione immediata.

Q: Qual e' la differenza tra mitigazione e root cause analysis?R: La mitigazione ripristina il servizio fermando l'emorragia. La root cause analysis (RCA) si fa dopo a mente fredda per indagare le cause.

Q: Come strutturi un buon post-mortem?R: Includo timeline, impatto, root cause, azioni di mitigazione e, soprattutto, gli action item per evitare recidive. Il tutto con approccio blameless.

Insidie e errori comuni

Iniziare a fare debugging profondo con il sistema ancora down, invece di applicare subito un rollback o uno scale-up.

Mancanza di comunicazione esterna: il team tecnico lavora in silenzio, generando panico e interruzioni continue da parte del management.

Post-mortem usati per puntare il dito contro un individuo, distruggendo la sicurezza psicologica del team.

Alert fatigue: troppi allarmi non azionabili o falsi positivi portano a ignorare le vere emergenze.

Snippet e comandi

# Esempio di comandi di mitigazione rapida in Kubernetes

# Controllo rapido stato pod per namespace
kubectl get pods -n production --sort-by=.metadata.creationTimestamp

# Lettura log degli ultimi 5 minuti per identificare errori recenti
kubectl logs <pod-name> -n production --since=5m -f

# Rollback immediato dell'ultimo deployment per mitigare una release fallata
kubectl rollout undo deployment/<nome-deploy> -n production

# Riavvio rapido del deployment in caso di stallo senza un nuovo commit
kubectl rollout restart deployment/<nome-deploy> -n production

Da ripassare

[ ] Modello di Incident Response di PagerDuty (basato su standard FEMA).

[ ] Correlazione tra incidenti, consumo dell'error budget e conseguenze sulle policy di deploy.

Riferimenti

Google SRE Book (Capitolo 11: Being On-Call, Capitolo 15: Postmortem Culture).

PagerDuty Incident Response Documentation.