Gestisci un incidente dal rilevamento al recupero

Dichiara l’incidente in base all’impatto

Un incidente è un evento che interrompe, degrada o minaccia il servizio abbastanza da richiedere una risposta coordinata. L’organizzazione definisce livelli di gravità e regole di escalation. Applicali considerando impatto sugli utenti, dati interessati, durata e ambito.

Non attendere una spiegazione completa della causa principale prima di chiedere aiuto. Una descrizione chiara dell’impatto osservato basta per avviare il coordinamento. Distingui un sospetto di sicurezza da una conclusione confermata.

Prepara il percorso di risposta prima del rilascio. Mantieni disponibili contatti, procedure di accesso, runbook e canali di comunicazione anche quando il servizio principale non è utilizzabile. Prova il percorso con un incidente fittizio.

Assegna responsabilità prima di apportare modifiche in conflitto

Il coordinamento degli incidenti stabilisce priorità e gestisce decisioni. Gli operatori tecnici indagano e mitigano. La comunicazione tiene informate le persone interessate. Google SRE descrive queste responsabilità come ruoli distinti. I piccoli team possono unirli, ma devono comunque coprire il lavoro. Risposta agli incidenti.

Mantieni una sola cronologia condivisa. Registra ora, osservazione, azione, soggetto e risultato. Distingui fatti e ipotesi. Usa un fuso orario comune e segnala timestamp non affidabili.

Esamina un incidente fittizio

Tutti gli orari seguenti sono UTC. L’organizzazione nomina un coordinatore quando il guasto delle esportazioni colpisce più clienti.

Un primo aggiornamento utile indica funzionalità interessata, ambito noto, mitigazione e ora del prossimo aggiornamento. Non promette un orario di riparazione senza prove. Evita di includere record dei clienti nell’aggiornamento condiviso.

Alle 09:10 l’incidente cambia. Ripristinare esportazioni riuscite non basta più. Il team deve valutare la possibile divulgazione, controllare gli accessi, conservare prove e coinvolgere i responsabili delle decisioni pertinenti.

Mitiga senza perdere il controllo

Usa runbook già provati quando applicabili. Controlla le precondizioni prima di rollback, failover o modifiche alle credenziali. Una versione applicativa precedente potrebbe non comprendere lo schema attuale del database. Un failover regionale può trasferire gli stessi dati corrotti.

Lascia che un assistente AI organizzi prove da cui sono stati rimossi i dati sensibili o confronti ipotesi entro confini approvati. Gli operatori devono verificarne le conclusioni. Log e ticket sono input non attendibili, non autorità per eseguirne i contenuti.

L’accesso di emergenza deve avere uno scopo autorizzato, una durata limitata e una registrazione di audit. L’urgenza non rende corretto un comando suggerito da un agente.

Chiudi separatamente recupero e azioni successive

Prima di dichiarare il recupero del servizio, verifica flusso dell’utente, integrità dei dati, confini di accesso e aggiornamento del monitoraggio. Registra le restrizioni residue. Mantieni aperta l’indagine di sicurezza se le sue domande restano irrisolte.

Esamina poi le condizioni che hanno reso possibile l’incidente. Assegna interventi successivi concreti con responsabile e criteri di verifica. Una revisione senza colpevolizzazione cerca una spiegazione accurata e modifiche utili. Non elimina la responsabilità di completarle. Pratica dei postmortem.

Prosegui con le operazioni di sicurezza e la chiusura del ciclo di feedback.