Gestione degli Incidenti

Una chiara classificazione della gravità consente risposte adeguatamente proporzionate senza mobilitare eccessivamente le risorse per problemi minori. Framework standard: SEV-1 (Critico) — completa indisponibilità del servizio che colpisce tutti o la maggior parte dei clienti; richiede un'escalation immediata alla leadership ingegneristica, notifica ai dirigenti e aggiornamento della pagina di stato pubblica entro 15 minuti. SEV-2 (Maggiore) — significativa degradazione di una funzionalità o un sottoinsieme di clienti impossibilitati a utilizzare la funzionalità principale; richiede una risposta dell'ingegneria di guardia e un aggiornamento della pagina di stato entro 30 minuti. SEV-3 (Minore) — degradazione limitata della funzionalità che colpisce un piccolo sottoinsieme di clienti o una funzionalità non critica; gestita durante l'orario lavorativo con un tempo di risoluzione target. SEV-4 (Informativo) — problemi estetici o degradazione minore dell'UX con una chiara soluzione alternativa disponibile; tracciato come un bug, risolto nel normale ciclo di sviluppo. Support Ops forma gli agenti a classificare correttamente gli incidenti e a escalare immediatamente i SEV-1 e SEV-2 al team di ingegneria di guardia.

La comunicazione degli incidenti rivolta ai clienti richiede velocità, onestà e una profondità tecnica appropriata per ogni pubblico. Tempistica: entro 15 minuti dal rilevamento dell'incidente, pubblicare un aggiornamento sulla pagina di stato pubblica che riconosca il problema (anche se l'indagine è appena iniziata — "Siamo a conoscenza di un problema che interessa [Funzionalità X] e stiamo indagando"). Ogni 30 minuti durante gli incidenti attivi, aggiornare la pagina di stato con i progressi dell'indagine. Una volta risolto, pubblicare un aggiornamento di chiusura che includa: cosa è successo (brevemente), quando è iniziato e finito, e cosa è stato fatto per risolverlo. Entro 72 ore, pubblicare un riepilogo della revisione post-incidente per gli incidenti SEV-1 e SEV-2, che copra la causa principale, la tempistica e le future misure di prevenzione. I team di supporto che gestiscono il volume di ticket in arrivo durante gli incidenti dovrebbero utilizzare risposte macro che rimandano alla pagina di stato, impedendo agli agenti di duplicare gli sforzi di indagine su singoli ticket.

Un postmortem senza colpe si concentra sui fallimenti del sistema e dei processi, non sulla colpa individuale — l'obiettivo è l'apprendimento e la prevenzione, non l'assegnazione di responsabilità. I postmortem efficaci includono: una cronologia dettagliata dell'incidente dal primo rilevamento alla risoluzione, ricostruita da log, alert di monitoraggio e messaggi Slack; un'analisi della causa principale utilizzando la tecnica dei "5 Perché" (chiedere "perché?" ripetutamente per raggiungere la vera causa sistemica piuttosto che la causa prossima); l'identificazione dei fattori che hanno contribuito oltre la causa principale; e azioni concrete per prevenire la ricorrenza, ciascuna con un responsabile e una data di scadenza. Product Ops facilita la riunione postmortem (tipicamente 60-90 minuti, tenuta entro 5 giorni lavorativi dalla risoluzione), mantiene il database dei postmortem e traccia il completamento delle azioni fino alla chiusura, riportando trimestralmente sui tassi di completamento dal postmortem alla risoluzione.