Incident response e postmortem

Incident response e ruoli di incident command

Google SRE tratta l’incident response come un processo strutturato, non improvvisato. Il modello di incident command separa i ruoli per evitare confusione: l’Incident Commander (IC) coordina e decide ma non mette le mani sul fix; l’Operations Lead esegue le modifiche tecniche; il Communications Lead gestisce gli aggiornamenti a stakeholder e status page (comunicazione interna ed esterna distinte). Un documento di incidente vivo funge da single source of truth, con handoff espliciti al cambio turno.

La priorità durante l’incidente è la mitigazione — fermare l’impatto sull’utente — non la root cause analysis: capire il perché viene dopo, nel postmortem. Confondere queste due fasi è un errore classico d’esame.

On-call sostenibile e riduzione dell’MTTR

Un on-call sano è dimensionato per essere sostenibile: rotazioni con primary e secondary, escalation path chiari e un tetto al toil (lavoro manuale ripetitivo e automatizzabile), così che resti tempo anche per l’ingegneria. Gli alert che generano un page devono essere actionable e basati sui sintomi visti dall’utente — tipicamente burn-rate alert sul consumo dell’error budget di uno SLO — non su ogni spike di CPU o su cause interne: è così che si riduce l’alert fatigue.

L’MTTR (mean time to resolve) si abbassa agendo su detection e recovery. Observability solida con Cloud Monitoring, Cloud Logging, Error Reporting e Cloud Trace (latenza) accelera la diagnosi; playbook aggiornati rendono ripetibile la risposta; rollout progressivi (canary) contengono il blast radius; un rollback rapido con Cloud Deploy riporta subito a una versione buona. Ridurre l’MTTR non significa correre col fix a caldo: spesso il recupero più veloce è il rollback, non l’hotfix.

Change management sicuro e reliability testing

La maggior parte degli incidenti nasce da un change. Il change management sicuro punta su modifiche piccole e frequenti attraverso una pipeline: Cloud Build per la CI, Cloud Deploy per la CD con rollout progressivi, canary analysis e rollback automatico sulla regressione. Lo stato desiderato dell’infrastruttura va gestito come codice (GitOps) con Config Sync / Config Controller, così ogni modifica è revisionata, tracciata e reversibile.

Qui c’è il trade-off centrale dell’SRE: velocità di rilascio contro affidabilità, arbitrato dall’error budget (1 − SLO). Finché il budget non è esaurito si rilascia; quando si esaurisce, la error budget policy può imporre un freeze e spostare l’effort sulla reliability. Il reliability testing verifica che i meccanismi funzionino prima del disastro reale: disaster recovery testing (restore dei backup, failover, verifica di RTO/RPO), fault injection e wheel of misfortune per allenare l’on-call.

Il blameless postmortem

Il postmortem SRE è blameless: cerca le cause sistemiche — perché il sistema ha permesso l’errore — invece del colpevole, perché puntare il dito nasconde i problemi e distrugge la cultura del reporting. Va documentata la timeline, l’impatto, le cause e soprattutto gli action item concreti, con owner e tracciati fino alla chiusura: un postmortem senza follow-up è inutile. Non ogni incidente lo richiede: criteri comuni sono downtime visibile oltre soglia, perdita di dati, intervento manuale dell’on-call o fallimento del monitoring. Condividerlo ampiamente diffonde l’apprendimento.

Trappole tipiche d’esame

• Servizio down, la pressione spinge a trovare subito la causa → mitiga prima: durante l’incidente la priorità è ridurre l’impatto (rollback, failover); la root cause si analizza nel postmortem.
• “Chi ha causato l’incidente?” nel postmortem → blameless: il postmortem cerca cause sistemiche e action item, mai responsabili individuali.
• Troppi page notturni non azionabili → burn-rate alert sull’error budget: allerta sui sintomi/SLO che impattano l’utente, non su ogni metrica di risorsa, per tagliare l’alert fatigue.
• “Come recupero più in fretta da una release difettosa?” → rollback via Cloud Deploy, non hotfix: tornare a una versione nota abbassa l’MTTR più del fix a caldo.
• Team frenato dal timore di rompere la produzione → error budget policy: il budget (1 − SLO) decide quando rilasciare e quando congelare, sostituendo i veti soggettivi.
• DR “documentato” ma mai testato → disaster recovery testing: solo failover, restore e fault injection reali provano RTO/RPO; un piano non testato non è affidabilità.