Gestione degli Incidenti SaaS

La classificazione della gravità dell'incidente è la prima decisione in ogni incidente — determina chi viene avvisato, con quale rapidità e quali SLA di comunicazione si applicano. Un modello di gravità pratico: SEV-1 (Critico): interruzione completa del prodotto o evento di perdita di dati. Zero utenti possono accedere al prodotto principale OPPURE violazione confermata dell'integrità dei dati. Risposta: chiamata di bridge immediata per tutto il personale, notifica a CEO e consiglio entro 1 ora, aggiornamento della pagina di stato pubblica entro 15 minuti, notifica al cliente entro 30 minuti. SEV-2 (Maggiore): indisponibilità significativa di una funzionalità che colpisce > 10% della base utenti attiva, o una funzionalità critica non funzionante per tutti gli account di livello enterprise. Risposta: responsabile dell'ingegneria e rotazione on-call immediatamente coinvolti, riunione di coordinamento interfunzionale entro 30 minuti, notifica al cliente entro 1 ora. SEV-3 (Minore): degrado isolato di una funzionalità che colpisce < 10% degli utenti o una funzionalità non critica non funzionante. Risposta: ingegnere assegnato, escalation durante l'orario di lavoro standard, pagina di stato aggiornata se visibile pubblicamente, nessun contatto proattivo con il cliente a meno che la funzionalità interessata non sia di uso comune. SEV-4 (Basso): bug minore con soluzione alternativa nota, nessun impatto diffuso sul cliente. Risposta: registrato come bug tracciato nel backlog di ingegneria, nessuna escalation.

La qualità della comunicazione durante un incidente influisce drasticamente sulla fiducia del cliente e sul rischio di churn, spesso più dell'incidente stesso. Principi: comunicare presto e spesso, anche quando non si ha nulla da segnalare — il silenzio viene interpretato come incompetenza o evasione. Strutturare la comunicazione dell'incidente su tre canali: (1) Pagina di stato pubblica (Statuspage.io è lo standard): aggiornata entro 15 minuti dalla classificazione dell'incidente. Aggiornamento iniziale: "Siamo a conoscenza di un problema che interessa [Funzionalità X] e stiamo indagando. Aggiorneremo ogni 30 minuti." Aggiornamenti successivi ogni 30 minuti con esattamente tre elementi: cosa è ancora interessato, cosa ha imparato il team e l'ora del prossimo aggiornamento. Aggiornamento di risoluzione: "Questo incidente è stato risolto. Tutte le funzionalità di [Funzionalità X] sono state ripristinate a partire da [ora]. Pubblicheremo un post-mortem completo entro 48 ore." (2) Email proattiva agli account interessati: per SEV-1 e SEV-2, il team di Supporto o CS invia un'email diretta a tutti gli account di livello enterprise informandoli dell'impatto prima che lo riscontrino. Essere i primi a informare è significativamente meglio che aspettare che i clienti scoprano e si lamentino. (3) Banner in-app durante l'incidente attivo: un banner visibile nell'interfaccia utente del prodotto che riconosce il problema in modo che gli utenti che riscontrano problemi capiscano immediatamente che è noto, non un errore dell'utente.

La revisione post-incidente (PIR, chiamata anche post-mortem nella cultura ingegneristica) è il debriefing strutturato che trasforma un incidente doloroso in apprendimento organizzativo. Un PIR efficace è senza colpe — focalizzato sui miglioramenti sistemici dei processi e dell'infrastruttura, non sulla ricerca e la critica dell'individuo che ha commesso un errore. La tecnica dei "cinque perché": chiedi "perché è successo questo?" e poi chiedi "perché" per ogni risposta, cinque volte. Questo esercizio rivela quasi sempre che ciò che sembrava un errore umano (un ingegnere ha apportato una modifica di configurazione errata) era in realtà un fallimento sistemico (il processo di modifica non includeva un passaggio di revisione che avrebbe rilevato l'errore, il monitoraggio non ha allarmato in tempo, il runbook ha indirizzato l'ingegnere on-call in modo errato). Struttura del PIR: ricostruzione della timeline (un resoconto preciso minuto per minuto di ciò che è accaduto, convalidato dai membri del team coinvolti); quantificazione dell'impatto (quanti clienti sono stati interessati, per quanto tempo, qual era l'ARR stimato a rischio?); analisi della causa principale (quali condizioni sistemiche hanno permesso questo incidente?); mitigazioni immediate completate; e — cosa più importante — elementi d'azione. Gli elementi d'azione del PIR devono essere specifici, di proprietà e programmati: "Mehmet aggiungerà il passaggio di revisione della modifica della configurazione di deployment al runbook entro il 15 marzo." Product Ops traccia mensilmente gli elementi d'azione del PIR e riporta i tassi di completamento alla leadership ingegneristica.